Capstone: Mock Loop & Self-Exam

You will not discover whether you can defend your work by re-reading your slides. You discover it by saying the words out loud, on a clock, while someone tries to break your claims. This section is a rehearsal you run on yourself before Cursor runs it on you.

The deep-dive grades whether the key decisions in a project were really yours and whether you understood them. So the rehearsal has two halves: a 10-minute presentation you deliver clean, then a round of adversarial questions you answer cold. Treat the questions as the real exam.

Run the 10-minute presentationdo this first, uninterrupted

1. 1Problem and hypothesis (90s). State the question you were answering and what you believed before any results. One sentence of stakes: why it mattered that the answer be true.
2. 2Method, with rejected alternatives (3-4 min). Walk what you built. For each major fork, name the option you rejected and the reason. This is where ownership shows.
3. 3Eval and result (3 min). Give the metric, the baseline, the effect size and the variance you ruled out. Numbers, not adjectives.
4. 4The weakest part (60s). Close by naming the limitation you would attack next. Volunteering it is the strongest single move in the round.

Record the run on your phone. You are not checking for polish; you are checking whether a stranger could follow the argument and whether you ever hand-waved a number you should have known.

Then field the adversarial questions, cold

Self-score the run

The onsite decides the offer and you cannot rehearse it by reading about it. You rehearse it by sitting down with a real RL/eval/grader problem, a hard time box and Cursor open, then operating exactly as you would on the day.

Pick something small and real: build a grader that separates a passing edit from a reward-hacked stub or write a GRPO advantage and unit-test it on a known batch. Give yourself a fixed block, 2 to 3 hours and a notebook for one running log.

The block, start to finish

1. 1Frame and assume (10 min). Restate the problem in your own words. Write down your assumptions and pick the smallest version that still proves the idea.
2. 2Prioritize out loud. Say what you're doing first, what you're cutting and why. Treat scope like the real job, not a test you must finish.
3. 3Use Cursor on a leash. Let it draft and accelerate, then read every line, run it and verify the claim before you build on it. Log each accept, reject and override.
4. 4Reach a validated result. A measured outcome on a narrow slice beats a sprawling half-built system you can't trust. Stop with something you can stand behind.

Keep the verification logthe single highest-value artifact

Every time you touch a model suggestion, write one line. This log is both your rehearsal of narration and your debrief data.

Debrief honestly

Some answers must be reflexive. If you have to reconstruct the policy-gradient objective from scratch in a 60-minute screen, you've already spent the time you needed for the follow-ups. This is the cold-recall battery: cover the answer, say it out loud, then check.

Q1 - Policy gradient, baseline, advantage

State the objective, then explain why subtracting a baseline keeps the gradient unbiased while cutting variance.

grad J(θ) = E[ Σ_t  ∇_θ log π_θ(a_t | s_t) · A_t ]
# A_t = advantage = (return or Q) − baseline b(s_t)
# A baseline that doesn't depend on the action a_t leaves E[grad] unchanged
# but reduces Var, because E[ ∇ log π · b(s) ] = b(s) · ∇ Σ π = b(s) · ∇ 1 = 0

Q2 - PPO vs GRPO and their compute tradeoffs

Q3 - RLHF vs RLVR and two reward hacks in coding

Q4 - Attention from first principles

Walk Q/K/V, the scaled dot-product and why the scale is the square root of d_k.

Attention(Q, K, V) = softmax( Q Kᵀ / sqrt(d_k) ) V
# Q·K grows with d_k; without /sqrt(d_k) the logits get large,
# softmax saturates and gradients vanish. The scale keeps variance ~1.
# Multi-head: run h of these on projected subspaces, concat, project out.
# KV cache: at decode, cache past K and V so each new token is O(seq),
# not O(seq²) - you only compute Q for the new token.

Q5 - Chinchilla and training with less compute

State the compute-optimal intuition and tie it to the role's charter of training at lower compute.

• For a fixed compute budget, model size and training tokens should scale together - roughly in proportion - not pour everything into parameters.
• Earlier large models were under-trained: too many parameters, too few tokens. Chinchilla showed a smaller model on more data beats them at equal compute.
• Heuristic anchor: on the order of ~20 tokens per parameter at the compute-optimal point (an intuition, not a law).
• For Cursor's “less compute” charter, the lever shifts to data quality, difficulty calibration and sample efficiency - squeezing more signal per token rather than buying more FLOPs.

Open-ended design prompts are where the onsite and the deep-dive overlap. There's no answer key; they're watching how you decompose an ambiguous problem, where you put the risk and whether you anticipate the failure modes before they bite. Drill these four until you can structure a strong answer in two minutes.

Four prompts to rehearse

The structure that works for all four

1. 1Restate and scope. Pin down what “good” means and what you're explicitly not solving. Ambiguity is the test; naming your assumptions is the answer.
2. 2Propose the design. Sketch the concrete pipeline - data in, signal out - at a level you could start building.
3. 3Attack your own design. Name the failure mode (reward hacking, contamination, off-policy bias) before they do and the mitigation for each.
4. 4Define success. State the metric and the validation that would tell you it worked, including how you'd separate real gains from noise.

Worked sketch - Drill 1, the non-verifiable grader

Readiness is a measurement, not a feeling. By now you've rehearsed the deep-dive, run a timed simulation, drilled the cold recall and practiced design prompts. This section turns those reps into an honest score and a short list of the most impactful fixes.

Treat the rubric as a gap finder, not a score to admire. Mark the weakest proof, turn it into one practice rep and keep the artifact you would show an interviewer.

Stage coverage - can you pass each round?

Domain coverage - rate the four areas

Cursor-specific readiness

• You've used Cursor daily for two or more weeks - enough that your AI-native fluency is real, not performed.
• You've read the ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. model reports and the Tab online-RL post and you hold a specific opinion on a tradeoff in each.
• You can name one research bet of theirs you find exciting and say why, without reaching for “I love LLMs.”
• You can cite one constraint they actually operate under (async multi-region RL, Anyrun-style sandboxes, training on real sessions) and what it implies.

Build the gap plan

1. 1Sort by impact, not by comfort. Take your two lowest stage ratings and two lowest domain ratings; ignore the rest for now.
2. 2Make each fix concrete and checkable. Not “study RL” but “re-derive GRPO advantage and unit-test it,” or “re-record the deep-dive until I volunteer the weakest part unprompted.”
3. 3Cap the list. Three to five items. A gap plan you'll actually finish beats a complete one you won't.
4. 4Set the go/no-go. Pick the threshold that means ready - for example, every stage at 4+ and no domain below 3 - and don't schedule the loop until you clear it.