The Mock Interview Engine

A mock must answer a question

Nia has repaired the reasoning failure from the previous chapter. On two untimed design drills, she now defines allowed and forbidden states before choosing a consistency mechanism. The correction is available. She does not yet know whether it will survive an unfamiliar system, a clock, and an interviewer who keeps moving.

“Do a system-design mock” is too loose to answer that question. A pleasant session could leave Nia encouraged; a difficult one could leave her rattled. Neither feeling would show whether the repair held. Her mock needs a more exact job:

Under realistic design-round pressure, does Nia establish the consistency boundary before selecting storage and replication, and can she preserve that reasoning when a follow-up invalidates her first assumption?

That sentence controls the prompt, the interviewer, the timing, the hints, the evidence, and the next assignment. It also prevents a common waste: booking a full mock because it resembles serious preparation, then discovering afterward that nobody agreed what the session was meant to reveal.

Comfort, fluency, and stamina can be legitimate targets. So can clarification, testing, migration judgment, personal ownership, or recovery after a hint. But one of them must be primary. A mock that claims to measure everything usually produces a debrief full of impressions.

Build backward from the failure

Begin with a live entry from the mistake taxonomy, not a generic round label. The entry supplies the earlier failure, the proposed correction, and the kind of adjacent task that would demonstrate transfer. Then add the conditions that make the target interview meaningfully harder than a drill.

Nia writes the setup before asking anyone for time:

Round and level: senior system design, 50 minutes
Primary signal: consistency reasoning before mechanism choice
Earlier failure: named a consistency model before defining allowed states
Correction under test: state the user-visible invariant and authority first
Prompt family: scarce-resource allocation, unfamiliar to the candidate
Pressure to add: late requirement change and regional failure follow-up
Evidence needed: time marks, diagram, interviewer score, candidate score
Decision: return to broad design mocks or repeat a narrower reasoning drill

This is a test specification, not a promise that a human performance will be perfectly reproducible. Interviewers differ. Prompts differ. Fatigue matters. The discipline is to make those sources of variation visible enough that one rough hour is not mistaken for a verdict on engineering ability.

The prompt should be adjacent to the repair rather than a disguised repeat. Nia already used collaborative editing and inventory reservation. Her mock uses a marketplace that allocates a limited number of appointment slots while payments and cancellations arrive asynchronously. The new domain preserves the disputed boundary—who may believe they own a scarce item—without giving her the language of the earlier solution.

Choose an interviewer for the observation

The most senior person available is not automatically the best interviewer. Choose someone who recognizes the target behavior, can follow a script, and has enough knowledge of the intended hiring bar to interpret what they see.

A senior peer who regularly interviews can calibrate coding, design, and project-depth rounds. A staff engineer may be especially useful when the signal involves ambiguous architecture, production failure, or scope beyond one service. An engineering manager can probe ownership, conflict, influence, and reflection. A domain specialist helps when the target loop genuinely requires security, data, SRE, ML, or another specialty; without a narrow brief, that same specialist may drift into niche trivia. A practiced peer can run timing, interruptions, and repeatable scripts well, even when they should not decide a staff-level architecture bar.

Solo recording has a place too. It can expose a five-minute preamble, silent debugging, weak test narration, or a story that never reaches the decision. It cannot reproduce another person’s follow-up, disagreement, or judgment. Use it for mechanics; save scarce expert time for the observations that require expertise or another mind in the room.

Nia asks a staff engineer for one bounded service: run a 50-minute design round, score whether her consistency reasoning survives two follow-ups, and avoid turning the debrief into a design review. That final boundary matters. An interviewer who teaches throughout the attempt may be generous, but the session can no longer show what Nia produced independently.

Three habits make a reviewer unsuitable for readiness evidence: rescuing every silence, lecturing instead of observing, and offering approval without naming what happened. The problem is not kindness. The problem is that the session cannot support the decision being asked of it.

Put the pressure in the script

A script prevents the interviewer from inventing the test while watching the candidate. It should specify what is known at the start, what can be revealed if asked, which follow-ups are required, when interruption is justified, and how hints alter the result.

Here is the core of Nia’s brief:

Opening prompt:
Design appointment allocation for a marketplace with a limited set of slots.
Customers may reserve, pay, cancel, or time out. Providers need an accurate
schedule; customers need to know whether a booking is confirmed.

Reveal if asked:
- a reservation lasts five minutes
- payment confirmation can be delayed
- providers may edit future availability
- the first release serves one region

Required follow-ups:
1. At about minute 18: payment succeeds as a reservation expires.
2. At about minute 30: the service must expand to a second region.
3. Before close: describe migration, detection of conflicting ownership,
   and recovery without silently double-booking.

Interruption triggers:
- a database or consistency label appears before the ownership rule
- reservation, payment, and booking are used as if they were one state
- the answer reaches minute 35 without a failure or rollout path

Primary scoring question:
Did the candidate define and preserve the booking invariant before choosing
mechanisms, including after the new requirements arrived?

The script does not prescribe Nia’s architecture. It preserves the difficulty. When she asks a consequential clarification, the interviewer has an answer. When she makes the exact mistake under test, the interviewer asks a question rather than waiting until the debrief. When she succeeds early, the regional follow-up adds interference instead of ending the measurement.

Different rounds require different script material. A coding brief needs constraints, edge cases, acceptable complexity, and a point at which testing must become visible. A behavioral or project-depth brief needs follow-ups that challenge claimed ownership, alternatives, conflict, impact, and learning. A production round needs symptoms, incomplete evidence, changing blast radius, and a limit on which facts the interviewer volunteers. The common requirement is controlled disclosure: the candidate should earn information through the same kinds of questions and reasoning expected in the real round.

Make the clock faithful, not theatrical

Use the target company’s known round shape when you have it. Otherwise, a coding mock often needs roughly 35 to 45 minutes; system design and project depth often need 45 to 60; behavioral work may fit in 30 to 45. Those ranges are defaults, not facts about every employer. Tool access, execution, round format, and expected scope can change the useful time box.

The important choice is what the clock forces. In Nia’s design mock, the first eight minutes are available for requirements and boundaries. By roughly minute 20, there should be an architecture that can be challenged. The final ten minutes must leave room for failure, rollout, and a coherent close. If she spends 35 minutes perfecting the happy path, the clock should expose that trade-off rather than quietly extending the session.

An interruption is useful when it resembles legitimate interviewer pressure: “Which state is authoritative here?” “What would disprove that assumption?” “You have ten minutes left; what must be resolved for this design to be safe?” It is not useful merely because silence makes the interviewer uncomfortable.

Hints need a policy decided in advance. Otherwise the candidate who receives early rescue and the candidate who struggles independently may receive the same final score.

Use a short ladder:

1. Clarify wording when the prompt itself is the obstacle.
2. Ask a focusing question that identifies the missing boundary.
3. Point to the missing cue without supplying the decision.
4. Supply enough information to restart the attempt, then observe recovery.

Record which step was used and when. A hint changes the evidence for the original competency, but it opens a second observation: can the candidate accept steering, reconstruct the reasoning, and finish professionally? Score that recovery separately. Do not treat a hinted finish as either an independent success or a worthless attempt.

Preserve what happened

Memory becomes charitable or punitive surprisingly quickly after a stressful session. Keep the lightest artifact that can settle the primary question. For coding, the editor history, tests, and a few time marks may be enough. For design, preserve the diagram, decision notes, and moments when assumptions changed. Audio or video can reveal communication and recovery, but it is not mandatory.

Get consent from everyone before recording. Do not keep proprietary prompts, employer-confidential details, or another person’s voice in a preparation archive they did not agree to. When a prompt cannot be retained, record the prompt family and the observed behavior rather than its exact wording.

Nia and her interviewer agree to keep the diagram, a scorecard, and a sparse timestamp log:

03:40 distinguishes reservation from confirmed booking
06:10 states: one slot may have at most one confirmed booking
12:30 names booking record as authority; then chooses storage
19:00 expiry/payment race introduced
22:20 preserves invariant but leaves customer response ambiguous
30:00 second region introduced
34:40 chooses asynchronous replicas without a write-ownership rule
37:10 interviewer asks which region may confirm a booking
40:30 revises to single write authority per slot; explains degraded behavior
47:20 migration and conflict alarm covered; rollback remains vague

This record is more useful than “good fundamentals, consider multi-region.” It shows that the original correction survived the first race, then weakened under a second source of pressure. It also distinguishes an unprompted choice from a recovery after intervention.

Score before either person tells a story

Debrief changes memory. Once the interviewer explains the expected answer, the candidate may remember having implied it; once the candidate explains an intention, the interviewer may credit behavior that was never visible. Freeze the first judgment before discussion:

1. The interviewer scores silently and cites evidence for the primary signal.
2. The candidate self-scores silently and cites the same kind of evidence.
3. Each names the strongest behavior and the most consequential miss.
4. Only then do they compare notes.

The scale can be simple. A low anchor means the behavior was absent or disruptive. The middle means it appeared but needed material prompting or remained inconsistent. The high anchor means it was clear, timely, and stable under the scripted pressure. Numbers without those behavioral anchors only make opinion look precise.

Score dimensions that belong to the round. Design might require framing, judgment, reliability, communication, recovery, and ownership. Coding needs implementation, testing, and complexity. Behavioral and project-depth rounds need personal decisions and reflection. There is no virtue in forcing every mock through one universal rubric.

Nia scores her primary signal as inconsistent because the regional follow-up broke it. Her interviewer scores it one level higher: the invariant remained correct, but the mechanism temporarily violated it until prompted. Their disagreement is productive because both point to minute 34. The issue is no longer whether the mock “went well.” It is whether choosing regional write ownership needs another isolated repair before a full readiness attempt.

Agreement can also reveal something. When both scores are low and cite the same moment, the blocker is unusually credible. When the candidate scores much higher, ask which observable evidence would justify the difference. When the candidate scores lower, do not respond with reassurance alone; show which behavior already meets the bar so scarce practice is not spent repairing it. If the interviewer cannot score the primary signal at all, the mock failed as an instrument. Redesign it rather than converting uncertainty into a candidate failure.

Debrief toward one next experiment

A debrief is not payment for the interviewer’s time in the form of every thought they had. Start with the primary question. Reconstruct the few moments that answer it, then choose the earliest repairable cause.

Nia does not add five new weaknesses to her log. Her original consistency reasoning held. The new failure is narrower: under regional pressure, she selected replication before assigning authority for confirmation. She records that cause, keeps rollback as a secondary note, and writes a correction she can use:

Before choosing a multi-region write path, name which actor may confirm each
scarce resource, how authority moves, and what customers see while it moves.

The next session should be cheaper than another full mock. Nia first practices the correction on the marketplace design so its mechanics are clear. Two days later, a peer runs a 25-minute partial mock about allocating limited compute capacity across regions. The domain changes; the authority problem remains. Only if the correction transfers does she spend staff-engineer time on another full design mock.

That sequence generalizes:

• Repeat once to learn the correction.
• Retest on an adjacent prompt to prove transfer.
• Return to a full mock to test integration and stamina.

If testing discipline failed in coding, use a different problem whose boundaries can disprove the solution. If a project story hid personal ownership, probe another decision from the project rather than polishing the same opening paragraph. If recovery after hints failed, script a wrong turn instead of avoiding hints next time. If time management failed, enforce a scoreable close; telling the candidate to “go faster” is not a retest.

Spend mocks where cheaper practice stops working

Full mocks are expensive. They require another person, realistic setup, and enough energy to make the result interpretable. Use partial mocks to isolate a known behavior; use full mocks when the question is whether repaired skills coexist under pressure.

A small campaign might therefore move from a testing partial, to a recovery drill, to one full coding round. Design preparation might use a focused migration follow-up before a complete unfamiliar architecture. Behavioral work might begin with ten minutes of hostile-but-fair probing before a full loop. The sequence follows evidence, not a quota of mocks.

Avoid treating exhaustion as rigor. Note unusual sleep, illness, tool failure, or an interviewer who abandoned the brief. These conditions may reveal a real stamina risk, but they may also make the sample unfit for a readiness decision. Likewise, do not overfit to one reviewer’s favorite architecture or one company’s interview customs. A mock should resemble the target loop closely enough to be useful while testing judgment that can transfer.

Before scheduling, the candidate should be able to complete this brief:

This mock must answer:
Round, level, and time box:
Known risk and correction under test:
Adjacent prompt family:
Interviewer and why they can observe it:
Required follow-ups:
Interruption and hint policy:
Artifacts retained with consent:
Scoring dimensions:
Decision after the result:
Adjacent retest if the signal fails:

Immediately afterward, preserve only what can change the plan:

Primary evidence:
Hint or interruption used:
Interviewer score and reason:
Candidate score and reason:
Earliest repairable cause:
Correction rule:
Retest prompt and date:
Decision:

The mistake taxonomy gave Nia a repair hypothesis. The mock supplied interference, another observer, and a clock. It did not pronounce her ready; it made the remaining weakness smaller and more honest. The readiness gates that follow can now judge repeated behavior instead of trusting confidence, volume, or one friendly afternoon.

Related links

• Deliberate Practice
• The Mistake Taxonomy
• Coding Readiness Gates
• Complete Annotated Coding Interviews
• Complete System-Design Transcripts
• Complete Behavioral Mock Loop