Technical screens

Each technical screen pairs one medium-hard coding problem with a security overlay. They want to see clean, correct, tested code and an attacker's eye on the same problem. Two or three of these run per the JD, so steady competence across all of them beats one heroic round.

The house languages are TypeScript, Python and Rust. Be genuinely fluent in at least one - not just able to read it, but able to write idiomatic, correct code at speed and reason about its failure modes out loud.

1. 1Solve the coding problem cleanly first. Get to a correct, readable solution with sensible structure. Name your tests as you go; don't bolt them on at the end.
2. 2Then put on the attacker hat unprompted. Walk the inputs an adversary controls. Where does untrusted data reach a sink - a query, a shell, a file path, an HTTP call?
3. 3State the vulnerability class precisely. Say SQL injection, command injection, SSRF, IDOR, broken object-level authorization - naming the class shows you've internalized the taxonomy.
4. 4Propose the fix and its tradeoffs. Parameterized query over string concatenation; allowlist over denylist; why the secure default costs what it costs.
5. 5Generalize to a paved road. Note how you'd make the safe pattern the only easy path, so the next engineer can't reintroduce the bug.

// VULNERABLE: untrusted input concatenated into a query (SQL injection)
const rows = await db.query(
  `SELECT * FROM files WHERE owner = '${userId}' AND id = ${fileId}`
);

// FIXED: parameterized query - input can never change the query's structure
const rows = await db.query(
  "SELECT * FROM files WHERE owner = $1 AND id = $2",
  [userId, fileId]
);
// ...and note the second bug: are we even checking that fileId
// belongs to userId at the authz layer? Concatenation aside, an
// IDOR here lets one tenant read another's files.