Mock interviews and timed practice

Why it matters

Solving a problem alone at your desk and solving it while explaining yourself to a stranger in 45 minutes are different skills. Under observation, people skip clarification, code before they have a plan, forget to test and go silent when stuck. Mock interviews expose these habits while they are cheap to fix. Jane Street's published mock interview ends with advice that other official guides echo: practice in conditions as close to the real interview as possible, with a timer, out loud, writing out every part of the solution.

Core ideas

Phases and time budget. A typical coding round has a short introduction, clarification of the problem, discussion of an approach, implementation, testing, and a discussion of complexity and extensions. A workable budget for 45 minutes is about 5 minutes clarifying with examples, 5 to 10 on the approach and its complexity, 20 on code and 5 to 10 on testing and follow-ups. Treat it as a guide; the point is to notice when you are 25 minutes in without code.

Self-mocks. Use problems you have not seen, drawn from a study plan rather than from your solved list. Set a timer, talk continuously, and record audio or your screen. Match the environment: if the interview uses a shared editor without execution or autocomplete, practice that way; if it lets you run code, practice running tests early. Afterwards, watch a few minutes of the recording; it is uncomfortable and very informative.

Peer mocks. Swap roles with someone preparing for similar roles. As the interviewer you learn what a rubric looks like from the other side, how hints land and how much silence is too much. Give written feedback against the rubric with one or two concrete changes rather than a list of everything.

Rubric. Score each dimension from 1 to 4 with one sentence of evidence: understanding and clarifying questions; approach and tradeoffs; correctness; code quality and naming; testing and edge cases; complexity analysis; communication and response to hints. A rubric makes progress measurable and stops you rating sessions by how they felt.

Post-mortem log. After every mock, record the date, problem and pattern, time to a working approach, time to working code, hints used, bugs you found versus bugs the interviewer found, rubric scores, and the root cause of the biggest loss: did not recognize the pattern, implementation errors, missed edge case, went silent, misread the problem. Review the log weekly and turn recurring causes into specific tasks, such as twenty minutes of boundary drills or three problems in a weak pattern.

Beyond coding. Mock system design with a whiteboard tool and a 45-minute timer, behavioral rounds with a peer asking follow-ups, and project deep dives with someone who keeps asking why. Rehearse the formats you will actually face; your recruiter and the company's official pages tell you which rounds to expect.

Common misconceptions

• "Solving many problems is the same as practicing interviews." Volume without time pressure and narration trains recognition, not performance.
• "Mocks are for the last week." Starting early reveals communication and process problems while there is still time to fix them.
• "Asking for a hint is failing." Getting unstuck efficiently is part of what is evaluated; ten minutes of silent struggle costs more.
• "A mock that went badly was wasted." It is the most useful kind, provided the post-mortem names a cause and a fix.
• "Watching solution videos counts as practice." Watching helps with technique, but only timed attempts followed by a written post-mortem build the skill.

How to approach it

Watch the Jane Street mock interview once, pausing before each phase to predict what the candidate will do, and note how the interviewer extends the problem. Then schedule two self-mocks a week from a plan of unseen problems, and a weekly peer mock once your foundations are in place. Keep the rubric and the log in one document from the first session. Before real interviews, run at least one full mock in the exact format, environment and language. The routine helps at every level; at senior level, include system design and leadership-story mocks rather than only coding.