Capstone: Mock Loop & Self-Exam

Cursor's technical phone screen is a medium-hard coding problem with a security overlay. You write clean code under a clock and you carry a threat lens while you do it. The only honest prep is to run that exact constraint on yourself, on a timer, out loud.

Set a 45-minute timer and pick a problem that forces you to handle untrusted input: parse and validate a config file, build a URL allowlist for an outbound fetcher or sanitize a path before a file read. The coding bar is real, so the code has to compile and pass your own tests. The security bar is the second axis the interviewer is grading in parallel.

Pick one input-handling problemDrill scope

Narrate the entire time as if an interviewer is on the call. State your approach and its complexity before you type, then call out the threat implication of each decision as you hit it: “I'm allocating the buffer after I've checked the declared length, so a lying length header can't over-allocate.”

The 45-minute protocolRun it like the real screen

1. 10–5 min · Clarify and define the trust boundary. Name where untrusted data enters and what's authoritative. Is the input attacker-controlled? What's the max size? Who calls this? The boundary changes your whole design.
2. 25–10 min · State the plan, the Big-O and the failure mode. Commit out loud: “Single pass, O(n) and I fail closed - reject on any field I don't recognize rather than ignoring it.”
3. 310–35 min · Write production code with secure defaults. Validate before you use. Parameterize, don't concatenate. Canonicalize then check containment. Keep functions small enough to defend line by line.
4. 435–42 min · Test the happy path and the attack path. Run a normal input, an oversized input and a crafted bypass (a ..%2f, a redirect to 127.0.0.1, a deeply nested array). Fix what breaks while narrating the bug.
5. 542–45 min · State residual risk and what you'd add in prod. Name what your code does not defend against and the next control: rate limits, a deny-by-default WAF rule, structured audit logging.

import net from "node:net";
import dns from "node:dns/promises";

const BLOCKED_V4 = [
  /^10\./, /^127\./, /^169\.254\./, /^192\.168\./,
  /^172\.(1[6-9]|2\d|3[01])\./,
];

async function isPublicHost(host: string): Promise<boolean> {
  // Resolve first - a hostname can point anywhere, incl. internal IPs.
  const { address } = await dns.lookup(host);
  if (net.isIPv6(address)) return false; // be conservative; vet v6 explicitly
  return !BLOCKED_V4.some((re) => re.test(address));
}

// Caller MUST re-run isPublicHost on every redirect target,
// not just the original URL - the bypass is a 302 to 169.254.169.254.

Typing it isn't the point. The point is that you can answer: why resolve DNS before deciding, why re-check on each redirect, why IPv6 is a separate landmine. If you can't defend a line, you don't actually know it yet.

Self-rubric - score four axes 1–5Match what Cursor grades

Cross-check your patterns against the secure-coding module before you move on. The screen rewards the same defaults every time: validate at the boundary, parameterize queries, fail closed. If those aren't reflexes yet, that's the drill for tomorrow.

Cursor runs agent-assisted security review on 3,000+ internal PRs a week, catching 200+ vulnerabilities before they reach production. The onsite code-review round asks you to do by hand what that system does at scale: read unfamiliar code, find the real bugs, rank them by impact and propose fixes a developer will actually accept.

Below is a small Express handler with three seeded flaws: a broken object-level authorization (IDOR), a SQL injection and a secret-handling mistake. Set a 15-minute timer, find them cold and write PR-style comments before you read on.

app.get("/api/invoices/:id", async (req, res) => {
  const id = req.params.id;
  const sql = "SELECT * FROM invoices WHERE id = " + id;
  const invoice = await db.query(sql);

  console.log("fetched invoice", invoice, "key:", process.env.STRIPE_SECRET);

  return res.json(invoice);
});

The three seeded flawsWhat review should surface

Prioritize the way the review system does. The SQLi and the IDOR are both critical and trivially exploitable, so they block the PR. The logged secret is high, separately tracked because it needs a key rotation, not just a code change - the key is already compromised the moment it hits a log.

Write the fix as a frictionless PR commentRemediation quality is half the score

app.get("/api/invoices/:id", requireAuth, async (req, res) => {
  const id = req.params.id;
  // Parameterized query - driver escapes; injection closed.
  // Ownership in the WHERE clause - authz can't be forgotten downstream.
  const invoice = await db.query(
    "SELECT * FROM invoices WHERE id = $1 AND owner_id = $2",
    [id, req.user.id],
  );
  if (!invoice) return res.status(404).end(); // 404, not 403: don't confirm existence
  return res.json(invoice); // no secrets logged, ever
});

Note the design choices a reviewer rewards. Ownership lives in the WHERE clause, so the authorization can't be skipped by a later refactor. The miss returns 404 rather than 403, because a 403 confirms the record exists and leaks information. That's the difference between patching a line and removing the bug class.

Score yourself honestlyFindings caught vs missed and fix quality

• Did you catch all three or did one slip? Which class did you miss - authz, injection or secret handling?
• Did you rank by impact or list them in the order you happened to read them?
• Did your fix remove the bug class (ownership in the query) or just patch the one line?
• Did you flag the secret as needing rotation, not just removal from the log line?

Log the vuln class you keep missing across drills. If IDOR slips twice, that's not bad luck, it's a blind spot - revisit the secure-coding module on broken access control and re-run this drill with a fresh snippet.

The onsite threat-modeling round hands you a prompt and a whiteboard and watches how you reason about trust. The two prompts most aligned to this role: design just-in-time cloud access or design a safe agent-execution sandbox. Pick one, set a 30-minute timer and produce trust boundaries, attacker goals and systemic mitigations.

There's no diagram tool in your head, so work the structure explicitly. A threat model is four questions in order: what are we building, what can go wrong, what do we do about it and did the mitigations hold. Most candidates jump to mitigations and skip the boundaries - the boundaries are where the score is.

The four-step protocolRun it on whichever prompt you draw

1. 10–5 min · Enumerate trust boundaries. Draw the components and mark every line where data or control crosses a privilege level: user → control plane, control plane → cloud API, agent → host filesystem. Name what's trusted on each side.
2. 25–15 min · Enumerate attacker goals per boundary. For each crossing, ask what an attacker wants: standing admin creds, lateral movement, reading another tenant's data, escaping the sandbox to the host. STRIDE is a fine checklist if you blank.
3. 315–25 min · Design systemic mitigations. For each goal, a control that kills the class: least-privilege scoping, JIT grants with auto-expiry, blast-radius isolation per tenant, deny-by-default egress from the sandbox.
4. 425–30 min · Justify the friction tradeoff. State what each control costs the engineer or the agent and why it's worth it - or where you deliberately accepted risk to keep the paved road usable.

Worked example: just-in-time cloud accessTrust boundaries and the controls that fit

The least-privilege story is the spine of this answer. Standing permissions are a constant liability - every credential that exists is a credential that can leak. JIT flips the default: zero standing access, a scoped grant when you prove you need it, automatic revocation when the window closes. The blast radiusHow much breaks if a change goes wrong; the scope of potential damage. of a stolen laptop drops from “the whole account, forever” to “one resource, for two hours, fully logged.”

The DX tradeoff is part of the designFrictionless or it gets bypassed

Cross-check against the cloud-security and threat-modeling modules. If you stalled enumerating boundaries or couldn't justify a friction tradeoff, that's the gap to close before the onsite.

The AI/agent-security deep dive is where this role's edge shows. Cursor builds agents that read, write and execute code on customer systems, which is a threat surface off-the-shelf playbooks don't cover. Expect rapid Q&A: crisp one-paragraph answers that diagnose the threat, name a mitigation and admit the residual risk.

The unifying frame to carry into every answer is the lethal trifecta: an agent that has access to private data, can be exposed to untrusted content and can communicate externally is the dangerous combination. Remove any one leg and the worst exfiltration paths close. Say that frame out loud - it shows you reason about the system, not the individual prompt.

Rapid-fire answer bankDiagnose → mitigate → residual risk

Notice the common spine: every answer starts by naming the trust boundary that's being crossed. “The boundary between content and instructions” for injection, “the agent-to-host execution boundary” for command abuse. Naming the boundary is the senior signal; jumping straight to “add a guardrail prompt” is the junior one.

Defense in depth for the agentLayers, because no single control holds

• Capability layer: least-privilege tools, no standing creds, scoped MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers.
• Execution layer: sandbox with deny-by-default egress, ephemeral environments, irreversible actions gated on human confirm.
• Data layer: redact secrets before context, tenant isolation, retention limits, privacy modes.
• Detection layer: log tool calls and commands, alert on anomalous egress and on blocked-action spikes.

The behavioral round checks whether you're builder-first and attacker-minded, whether you own problems end-to-end with little guidance and whether you tell the truth about what you don't know. Run your stories out loud, map each to a Cursor value and tighten every one to under two minutes.

You need three stories ready, each a clean STAR with a quantified result. Rehearse them spoken, not read - the gap between a story you've written and a story you can deliver in 90 seconds is the gap this round measures.

Three stories, mapped to Cursor valuesOne per behavioral theme

The builder-vs-attacker story is the one that most distinguishes this role. Cursor wants security as a superpower on top of strong engineering, so the hero of your best story should be something you shipped that shrank a class of risk, with you narrating the attacker's view that motivated it.

The two-minute shapeTighten every story to this

1. 1Situation (20s). The system, the stakes and the trust boundary at risk. No backstory.
2. 2Action (60s, first person). What you did - the attacker reasoning, the design choice, the build. “I” not “we.”
3. 3Result (30s, quantified). The outcome in numbers: vulns prevented, threat surface reduced, adoption rate, time-to-detect.
4. 4Reflection (10s). What you'd do differently or carried forward. This is where truth-seeking shows.

Final readiness checklist - score each axis 1–5Across all five rounds

Your concrete, product-grounded “why Cursor”Specific beats enthusiastic

The recruiter screen and the values round both probe genuine interest. A strong answer is specific to the security surface: you want to defend a product where the threat model is genuinely new - autonomous agents executing code on customer systems - and to build paved-road defenses in a flat, fast org rather than gatekeep. Ground it in something real you've seen: the agent-assisted review on 3,000+ PRs a week, the privacy modes, the JIT posture.