Appendix J - Mock Interviewer Scripts

The interviewer should not have to invent the test

A willing peer is not automatically a practiced interviewer. Give them only a round label and they must invent the difficulty while watching the candidate: which facts to volunteer, when silence has lasted long enough, whether a weak answer deserves a hint, and what to say in the debrief. The mock then measures two improvisations at once.

A useful script settles those choices before the clock starts. It gives the candidate a fair opportunity to demonstrate one target behavior and gives the interviewer enough structure to resist both rescue and arbitrary pressure. It does not prescribe one correct answer. Senior coding, design, and leadership questions often admit several. The script preserves the constraints against which an answer can be judged.

Prepare two sides of the packet

The candidate sends a short request that names the round, level, time box, and one correction under test. They may also name relevant interview conditions: shared editor or whiteboard, executable code or pseudocode, permitted references, accessibility needs, and whether a recording is proposed. They do not send a rehearsed answer or their notes for the chosen prompt.

CANDIDATE REQUEST

Round, level, and time box:
Primary behavior to observe:
Earlier failure or uncertainty:
Correction under test:
Useful pressure: unfamiliarity, interruption, hint recovery, or late change:
Tools and format:
Artifacts we may retain:
Recording consent: yes / no / not requested

The interviewer prepares the other side privately. A prompt title is not enough. The packet must contain the facts available at the start, answers to likely clarifying questions, required turns in the problem, the smallest hints that could restart progress, and the evidence that would settle the primary question.

INTERVIEWER BRIEF — KEEP PRIVATE UNTIL THE DEBRIEF

Opening prompt:
Facts available at the start:
Facts to reveal only if asked:
Primary behavior to observe:
Required follow-ups and approximate times:
Legitimate interruption triggers:
Hint ladder:
Round-specific evidence dimensions:
Artifact and timestamp plan:
Condition that would make the sample untrustworthy:
Debrief limit:
Adjacent retest if the correction does not transfer:

Select the prompt before the session. For coding, verify the examples, boundaries, and expected complexity. For design, decide the important product and operating constraints without committing the candidate to your preferred architecture. For a project or behavioral round, choose probes rather than a desired story. If the interviewer cannot prepare the private side honestly, narrow the mock or find a reviewer who can.

Agree on the boundary before starting

Spend two or three minutes on logistics, outside the scored time. Confirm the tool, duration, time announcements, recording decision, and what will be kept. Do not retain proprietary employer prompts, confidential project details, or a person’s voice without their consent. A prompt family and sparse observation log are often sufficient.

Name the conditions that justify pausing or discarding the sample: a broken editor, an inaccessible format, an interviewer mistake that changes the problem, or an interruption unrelated to the mock. Correct logistics and prompt wording immediately. Do not quietly compensate by extending time or making the technical task easier.

Let the round produce evidence

Read the opening once. Let the candidate drive clarification. When they ask a question covered by the private brief, answer it directly; forcing them to guess facts that the script already defines creates noise rather than difficulty.

Short silence is work. As a default, allow roughly twenty seconds before intervening, longer when the candidate has explicitly asked for thinking time. Interrupt when a scripted checkpoint arrives, when a requirement has been misheard, or when the target behavior can no longer become visible without a time warning. Do not interrupt merely to demonstrate expertise.

Use a four-step hint ladder:

1. Clarify the wording or restate information already available.
2. Ask a focusing question about the missing boundary, invariant, or evidence.
3. Point to the relevant cue without supplying the decision.
4. Supply enough of the missing idea to restart the attempt, then observe the recovery.

Record the step and time. Help changes what the first behavior demonstrates, but it opens a different question: can the candidate absorb new information, repair the plan, and finish coherently? Appendix I distinguishes independent, prompted, and deepened evidence; do not collapse those states into a single impression that the answer was eventually correct.

A complete system-design packet

This packet tests whether reliability decisions become explicit before the candidate treats a queue as a complete design. It is ready for a peer who can reason about asynchronous work but need not share one canonical architecture.

OPENING

Design report exports for a multi-tenant analytics product. A user requests an
export and later downloads a file. Large exports cannot complete inside the
request that creates them.

STARTING FACTS

- The first release serves one region.
- Most exports should be ready within fifteen minutes.
- Tenant isolation is a hard product boundary.

REVEAL ONLY IF ASKED

- Peak creation rate is about one hundred export requests per second.
- An export may be as large as five gigabytes.
- Source records can change while an export is running.
- Workers may receive the same job more than once.
- Files are retained for seven days.
- Users need to see queued, running, complete, and failed outcomes.

PRIMARY QUESTION

Before choosing retries, does the candidate define durable job state,
duplicate-work behavior, retry exhaustion, and the user-visible failure path?

REQUIRED TURNS

At about minute 18: the create request times out, so the client sends it again.
At about minute 30: a worker finishes the file, crashes before acknowledging
the job, and receives the job again.
Before the close: the source data changes during generation, and one tenant
must never receive another tenant's file.

FOCUSING QUESTIONS, USED ONLY WHEN THE BEHAVIOR IS ABSENT

- Which record is authoritative for the export's state?
- What may happen twice at this boundary?
- When do retries stop, and what can the user do then?
- What exactly does this file represent if source data changes mid-run?
- Which check prevents possession of a link from becoming authorization?

EVIDENCE TO PRESERVE

Time and wording of the first state contract; where idempotency is enforced;
how duplicate completion is handled; terminal-failure behavior; snapshot
semantics; tenant authorization; and whether each appeared independently or
after a focusing question.

A coherent answer may use different stores, workers, and delivery mechanisms. The packet does not reward a component list. It looks for contracts that keep retries and partial failure from becoming duplicate exports, invisible stuck jobs, inconsistent files, or cross-tenant disclosure.

Coding packet

Choose an unfamiliar prompt whose solution and counterexamples the interviewer has verified. Keep the prompt adjacent to the correction under test: if the candidate repaired boundary testing, change the problem while preserving a boundary capable of disproving the implementation.

DURATION
40 to 45 minutes unless the target format says otherwise.

OPENING
Please clarify the contract, explain an approach, implement it, test it, and
discuss its cost. I will give time checks and may ask follow-ups.

PRIVATE PREPARATION
- Exact input and output contract.
- Empty, singleton, duplicate, invalid, and size behavior where applicable.
- A simple valid baseline and the intended complexity pressure.
- At least three examples, including one that defeats a tempting wrong answer.
- One adjacent follow-up that changes a constraint rather than the whole task.

CHECKPOINTS
At minute 7, if the contract is still unclear: What assumptions must be fixed?
At minute 14, if no valid plan exists: What is the simplest correct baseline?
At minute 28, if no coherent core exists: What smaller slice can you finish?
With eight minutes left: What evidence would convince you this works?

OBSERVE
Framing, invariant or reasoning, implementation, proof through tests,
complexity, recovery, and communication.

Do not reveal an expected pattern because the candidate chose a different valid approach. Do not allow a passing happy-path example to stand in for proof. If the prompt itself is faulty, stop and discard the sample rather than scoring the candidate’s response to a moving contract.

Practical-coding packet

Use a small domain with visible state and policy: a feature-flag evaluator, notification preferences, inventory reservation, a file parser, or a workflow state machine. The task should fit inside the time box without production infrastructure.

DURATION
45 to 60 minutes.

OPENING
Build the smallest coherent implementation of this behavior. I care about the
contract, state transitions, tests, and how the design absorbs one change.

PRIVATE PREPARATION
- One or two required public operations.
- Initial state and valid transitions.
- Invalid-input and error policy.
- Executable examples or tests that define the first useful slice.
- One requirement change prepared in advance.
- One production boundary to discuss, not implement.

REQUIRED PRESSURE
Introduce the change only after a working slice or at the planned midpoint.
Later, ask which boundary must change for persistence, concurrency, security,
or operation in production.

OBSERVE
Scope control, interface contract, state model, policy placement, meaningful
tests, debugging method, maintainability, and change handling.

Do not reward speculative classes over working behavior, and do not turn the production follow-up into a demand for a distributed system. The relevant evidence is whether the candidate can name the boundary and its consequences.

Project-depth packet

The candidate chooses a real project, but the interviewer chooses the probes. Ask for honest attribution and enough technical mechanism to inspect a decision. Respect confidentiality; a candidate who declines a proprietary detail may still explain constraints, alternatives, and consequences.

DURATION
45 to 60 minutes.

OPENING
Choose a project that shows senior engineering judgment. I will probe the
prior state, your ownership, alternatives, technical mechanism, disagreement,
outcome, and what changed afterward.

REQUIRED PROBES
- What would have happened if nobody acted?
- Which decision was yours, and what belonged to other people?
- What credible alternative did you reject?
- Show me the mechanism behind the hardest technical claim.
- Who disagreed, and what was reasonable in their position?
- Which evidence changed the plan or showed the outcome?
- What did you do differently on a later project?

PRESSURE PROBES
- Which assumption turned out to be wrong?
- What would a strong critic challenge in your decision?
- What did the result cost elsewhere?

OBSERVE
Stakes, attribution, technical depth, judgment, influence, consequence,
uncertainty, and transferred learning.

Do not confuse large scale with individual scope. Do not complete the story on the candidate’s behalf when the result is ambiguous. The way they bound a claim can itself be evidence of judgment.

Behavioral-leadership packet

Choose two or three question families that create a fair chance to observe the target behavior. A mock for conflict recovery needs resistance; a mock for story selection needs enough variety to reveal whether the candidate can choose rather than force one prepared story into every prompt.

DURATION
30 to 45 minutes.

OPENING
I will ask behavioral questions and follow-ups. Use real examples, distinguish
your work from the team's, and make the decision and consequence visible.

QUESTION FAMILIES
Influence without authority; technical disagreement; a miss or failure;
mentoring; ambiguity; an incident; or a product and engineering trade-off.

REQUIRED FOLLOW-UPS
- What was at stake?
- What did you decide or do personally?
- What did the other party believe, and why?
- What evidence affected the decision?
- What was the cost or unresolved consequence?
- Where did later behavior actually change?

LEGITIMATE INTERRUPTIONS
The answer accumulates chronology without reaching a decision; ownership
remains plural and unassigned; another party becomes a caricature; or the
consequence is replaced by a generic lesson.

OBSERVE
Story fit, agency, judgment, fair representation of conflict, influence,
accountability, consequence, reflection, and economy.

“We aligned” is a result label, not an account of influence. Ask what changed: a proposal, an experiment, a decision right, a sequence of work, an escalation, or an explicit refusal. If the candidate cannot disclose a metric, ask what observable evidence supported the claimed outcome.

Assemble a complete loop only after isolated repairs

A complete loop tests integration, transitions, and stamina. It is expensive and poor at diagnosing a narrow failure. Use it after the candidate has retested consequential isolated corrections.

Prepare a separate private packet for every segment. A practical default is five minutes of logistics, forty-five minutes of coding or practical coding, a real break, fifty-five minutes of system design, another break, forty-five minutes of project depth or behavioral leadership, and ten minutes for the candidate’s questions. Adjust this shape to verified target-loop information; do not imitate a company ritual from rumor.

Each segment gets a fresh opening and its own evidence card. The interviewer does not teach during the breaks or reveal how the previous segment was marked. If different peers conduct the rounds, they complete their cards independently before a final twenty- to thirty-minute synthesis.

The loop decision comes from repetition, contradiction, severe floors, recovery, and missing opportunities—not an average. Use the complete-loop card in Appendix I.

Freeze the evidence before discussing it

The candidate and interviewer write independently for a few minutes. Otherwise the debrief edits memory: intentions become alleged actions, and a confident explanation can replace what happened under the clock.

PRIMARY BEHAVIOR
What happened, with time or artifact reference:
Consequence for the answer:
Evidence mark: — / N / P / I / D

STRONGEST OTHER EVIDENCE
Observed behavior and consequence:

MOST CONSEQUENTIAL MISS
Observed behavior and consequence:

HELP OR INTERRUPTION
What was used, when, and what happened afterward:

SAMPLE QUALITY
Condition that limits what may be concluded:

Compare cards beside the code, notes, diagram, or sparse timestamp log. Resolve a disagreement by asking what was observable, whether it preceded a prompt, and what consequence it had. Keep uncertainty when the artifact cannot settle the question. Agreement is not the purpose of the debrief; a defensible next decision is.

End with one repair and an adjacent retest

Begin the conversation with the primary question. Reconstruct the few moments that answer it. The interviewer may then offer one observed strength and one consequential miss, but should resist delivering every thought collected during the session.

Find the earliest behavior that could have changed the attempt. “Learn system design” is too broad. “Before selecting retry behavior, name what may repeat, the durable state, retry exhaustion, and the user-visible failure” can govern another attempt.

DEBRIEF CLOSE

Primary observation:
Earliest repairable cause:
Uncertainty in that diagnosis:
Correction rule:
Adjacent prompt:
Pressure the retest must preserve:
Observable pass condition:
Next decision if it transfers:
Next decision if it does not:

Repeat the original task once when the candidate needs to learn the repair. Then change the prompt while preserving the disputed reasoning. Only the adjacent attempt shows whether the behavior transfers. Schedule another full mock when the remaining question is integration or stamina, not because a longer session feels more serious.

Keep the instrument honest

Rescue makes the result look complete while hiding independence. Teaching during the round makes the session a lesson; save it for the debrief. Prompt drift adds difficulty nobody agreed to test. Vague praise provides comfort but no practice decision. Company cosplay rehearses rumored rituals instead of transferable judgment. An overloaded mock produces a long defect list that no one can act on.

The control is the same in each case: return to the private packet. Reveal only the prepared facts, apply only pressure that serves the primary question, record help, and stop the debrief after a correction and retest are clear. If the interviewer abandoned the packet, say so. Do not convert a faulty mock into a verdict on the candidate.

Hand this card to the interviewer

Before: prepare the private brief, verify the prompt, agree on tools and consent.
During: reveal deliberately, allow thought, interrupt by policy, record help.
After: freeze cards independently, compare evidence, choose one repair and retest.

Candidate request:
Please run this as a controlled mock. Let the script determine what you reveal
and when you interrupt. Mark observable behavior, including any help, and end
the debrief with one correction rule and one adjacent retest.

Related links

• The Mock Interview Engine
• Interview Scorecards
• The Mistake Taxonomy
• Complete Annotated Coding Interviews
• Complete System-Design Transcripts