Skip to content
PracticalHandbooksSoftware Handbooks
Library

Senior Engineering Interview Handbook / Chapter 973

Appendix I - Interview Scorecards

Printable interview scorecards for preserving observable behavior, judging evidence without false arithmetic, choosing one correction, and retesting it on an adjacent prompt.

Preserve the attempt before memory improves it

“The design went well, but production was weak” is not yet useful feedback. Neither is a row of numbers completed after the details have faded. A scorecard earns its place when it preserves what happened closely enough to change the next attempt.

Use the cards in this appendix after a mock, a drill recorded with consent, or a practice session with an inspectable artifact. After a real interview, record only what you remember with confidence. You will not have the prompt, interviewer notes, or complete context needed for a precise rating, and reconstructing them can turn anxiety into invented evidence.

The candidate and mock interviewer should complete their cards independently before discussing them. Their disagreement is often more instructive than their marks. One person may remember a good architectural choice; the other may remember that it arrived only after a hint.

Mark the evidence without turning it into arithmetic

Use one of these marks for each dimension:

  • — No opportunity: the prompt never created a fair chance to show it.
  • N Not demonstrated: the opportunity existed, but the behavior was absent or the result remained unsound.
  • P Prompted: the behavior appeared after a hint, correction, or direct interviewer request.
  • I Independent: the behavior appeared at the right time without rescue.
  • D Deepened: challenge made the reasoning clearer, more complete, or better connected to consequences.

Every mark needs a short evidence sentence. “I would have tested the empty case” is an intention; “I named the empty case after the interviewer asked whether the input could be empty” supports P. A correct result does not silently upgrade weak framing, hidden reasoning, or absent proof.

Do not total or average the marks. Dimensions do not have equal weight, and a missing opportunity is not zero. A severe correctness failure may govern a coding sample. Shallow production judgment may govern an infrastructure design. In another role or round, those same observations may carry different weight. Write the consequential judgment in words.

The record shared by every card

Complete this header once. It keeps the judgment tied to the conditions that produced it.

SESSION
Date and reviewer:
Round, prompt family, target level, and time box:
Primary signal or correction under test:

CONDITIONS
Unfamiliar, adjacent, or repeated prompt:
Artifacts available for review:
Hints, interruptions, requirement changes, or tool failures:
Anything that makes the sample less trustworthy:

OBSERVATIONS
1. At [phase or time], the candidate...
   Consequence for the answer:
2. At [phase or time], the candidate...
   Consequence for the answer:
3. At [phase or time], the candidate...
   Consequence for the answer:

Capture behavior before explaining its cause. “Chose a queue without naming delivery semantics” is an observation. “Does not understand queues” is a diagnosis that the sample may not support.

Coding scorecard

Use this card for algorithmic coding where the candidate must make the approach, implementation, proof, and recovery visible.

CODING

Problem framing — clarified the contract, constraints, and consequential
boundaries before committing to a solution.
Mark and evidence:

Approach — established a valid baseline, found the bottleneck or invariant,
and justified the chosen data structure or algorithm.
Mark and evidence:

Implementation — translated the plan into readable code while preserving the
invariant and controlling state.
Mark and evidence:

Proof and testing — used complexity reasoning and representative tests to
challenge the answer, including a boundary capable of disproving it.
Mark and evidence:

Recovery and communication — exposed the plan, interpreted hints, corrected
mistakes, and kept the interviewer oriented through changes.
Mark and evidence:

Consequential judgment:
Evidence still missing:

Do not let a passing test suite erase heavy prompting or an invalid argument. Do not let one syntax slip erase a sound plan that was repaired and verified. The evidence sentence should preserve both the failure and the recovery.

Practical coding scorecard

Use this card when the work is a small product or engineering artifact rather than an isolated algorithm.

PRACTICAL CODING

Scope — separated the required behavior from polish and delivered a coherent
slice inside the time box.
Mark and evidence:

Contract and state — chose a usable interface, represented state explicitly,
and named the policies or invariants that govern transitions.
Mark and evidence:

Implementation quality — kept responsibilities legible and made the code
changeable without building infrastructure the prompt did not require.
Mark and evidence:

Testing and debugging — tested meaningful transitions and failure paths;
when something broke, observed, narrowed, changed, and verified.
Mark and evidence:

Product and production judgment — protected user-visible behavior and could
name the boundary that would need to change for persistence, concurrency,
security, or operation in production.
Mark and evidence:

Change handling — absorbed a requirement change without losing the contract
or discarding working structure unnecessarily.
Mark and evidence:

Consequential judgment:
Evidence still missing:

A sophisticated object model is not automatically senior evidence. A small working contract that survives a requirement change may expose better judgment.

System design scorecard

Use this card to judge whether an architecture developed from product and operating constraints rather than from a remembered component diagram.

SYSTEM DESIGN

Requirements and harm — found the critical user journey, scale and quality
constraints, and the failure whose consequence should govern the design.
Mark and evidence:

Authority and data — identified owners of truth, access patterns, important
state transitions, and consistency boundaries before distributing them.
Mark and evidence:

Architecture — assigned clear responsibilities and traced at least one
important request, event, or data path through the system.
Mark and evidence:

Trade-offs — compared credible alternatives against the governing constraint
and stated what the chosen path makes harder.
Mark and evidence:

Production judgment — followed failure into recovery, observability, security,
capacity or cost, and the experience visible to users and operators.
Mark and evidence:

Evolution and conversation — handled follow-up pressure, made rollout or
migration credible, and kept the interviewer involved without surrendering
direction.
Mark and evidence:

Consequential judgment:
Evidence still missing:

Listing reliability, security, observability, and cost near the end does not demonstrate production judgment. At least one of them must change a component, contract, rollout, or operating decision.

Project-depth scorecard

Use this card for a real project discussion. Score only claims that the candidate can attribute honestly; company size and system scale do not stand in for personal judgment.

PROJECT DEPTH

Stakes and constraints — made the prior state, affected users, binding
constraint, and reason the work was worth doing concrete.
Mark and evidence:

Personal ownership — separated personal decisions and actions from the work
of teammates, leaders, and partner groups.
Mark and evidence:

Technical mechanism — explained the difficult part deeply enough to inspect
assumptions, alternatives, implementation, and failure behavior.
Mark and evidence:

Judgment and influence — showed how disagreement, risk, sequencing, or a
cross-team dependency was resolved rather than merely saying alignment
occurred.
Mark and evidence:

Outcome — connected a credible result or miss to the decisions that produced
it and acknowledged evidence that remained ambiguous.
Mark and evidence:

Reflection — named what changed in later behavior, systems, or team practice,
not only what the project “taught.”
Mark and evidence:

Consequential judgment:
Evidence still missing:

If confidentiality prevents a necessary detail, record the limit. Do not reward invented precision or punish an appropriate boundary.

Behavioral-leadership scorecard

Use this card for stories about ambiguity, conflict, influence, failure, mentoring, incidents, delivery, or product trade-offs.

BEHAVIORAL LEADERSHIP

Story fit and stakes — chose a real event that answered the question and made
the consequence of inaction or a poor decision clear.
Mark and evidence:

Agency and judgment — located the candidate's decision, available
alternatives, governing constraint, and accountability.
Mark and evidence:

Influence and conflict — represented other positions fairly and showed the
mechanism of influence, escalation, compromise, or refusal.
Mark and evidence:

Consequence — made the result credible, including cost, uncertainty, or
second-order effects rather than attaching a polished ending.
Mark and evidence:

Reflection — identified a specific later change and could defend it under
follow-up questions.
Mark and evidence:

Communication — gave the interviewer enough chronology to understand the
decision without hiding it inside scene-setting.
Mark and evidence:

Consequential judgment:
Evidence still missing:

Fluency can make a thin story sound complete. Follow-up pressure is part of the evidence: ownership, disagreement, and changed behavior should become more precise when questioned.

Complete-loop scorecard

A complete loop is not the average of its rounds. Complete each relevant round card first, then use this synthesis to inspect repetition, contradiction, floors, recovery, and missing evidence.

COMPLETE LOOP

Evidence repeated across independent rounds:

Concern repeated across independent rounds:

One-round concern serious enough to govern the loop, and why:

Contradiction that the evidence does not yet resolve:

Behavior after a hint, failed round, break, or change of interviewer:

Core role signal that received no fair opportunity:

What the artifacts justify saying about readiness:

Decision:
[ ] Repair one isolated behavior before another mock.
[ ] Run an adjacent partial retest.
[ ] Run another full loop to test integration or stamina.
[ ] Apply the relevant readiness gate.

Repeated evidence deserves more confidence than one unusually friendly prompt. A contradiction deserves investigation, not arithmetic. Strong project depth does not cancel a severe coding correctness failure; one awkward coding minute does not cancel a loop that otherwise shows independent correction and proof.

Turn one scored attempt into a repair

Consider a mock design for multi-tenant report exports. The candidate clarifies who requests an export, expected completion time, retention, and tenant isolation. They place work on a queue, but say only that failed jobs will retry. After the interviewer asks what happens when a worker receives the same job twice, the candidate adds an idempotency key. They later mention monitoring without naming a condition tied to delayed or missing exports.

The useful scorecard does not call this “a 2 in production.” It preserves the boundary:

Requirements and harm — I
Named the user, completion expectation, retention, and isolation without a
prompt, but did not state how late delivery becomes visible to the user.

Architecture — I
Separated request acceptance, job state, object storage, workers, and delivery;
traced the asynchronous path from request to downloadable result.

Trade-offs — P
Explained why asynchronous work protects request latency, but discussed
duplicate delivery only after the interviewer introduced it.

Production judgment — P
Added idempotency after a direct prompt. Said “monitor the queue” without a lag
threshold, terminal failure state, alert owner, or user-visible fallback.

Consequential judgment
The happy path is independently coherent. Duplicate processing and failed-job
operation remain prompted evidence, which is consequential for this design.

Earliest useful repair
Reason from delivery semantics before choosing retry behavior.

Correction rule
For every asynchronous boundary, name what may repeat, the durable job state,
the idempotency boundary, retry exhaustion, operator signal, and user-visible
fallback.

Adjacent retest
Design media processing with duplicate delivery and a poisoned job. Pass when
the correction appears before a hint and changes the job-state contract.

The correction is narrower than “study reliability” and cheaper than repeating the whole mock. It can be practised once on the original design, then tested on the adjacent prompt. Only the adjacent result shows whether it transferred.

Reconcile two readers without negotiating a mark

When candidate and interviewer disagree, place the cards beside the artifact. Ask:

  1. What was said, written, coded, tested, or drawn?
  2. Did it appear before or after a prompt?
  3. What consequence did it have for the answer?
  4. What evidence would justify a different mark?

Change a mark when the artifact warrants it, not because agreement feels fairer. If the recording or notes cannot settle the question, keep the uncertainty. Calibration means making the evidence standard more consistent; it does not require two people to have identical judgment.

Across three comparable sessions, look for repeated behavior rather than a rising total. A correction that appears independently on an adjacent prompt is stronger evidence than a “better score” on the original. If marks vary wildly by reviewer, narrow the anchor. If they vary by prompt, test whether the skill transfers. If mock evidence is strong but real interviews collapse, introduce realistic timing, unfamiliarity, interruption, and recovery before concluding that more knowledge is needed.

Close every card with a decision

PRIMARY OBSERVATION
The behavior that most changed this attempt:

REPAIR HYPOTHESIS
Earliest repairable cause and evidence:
Uncertainty in that diagnosis:

CORRECTION RULE
The visible behavior to use next time:

RETEST
Adjacent prompt, reviewer, and date:
Interference or follow-up the retest must include:
Observable pass condition:

RESULT
[ ] Did not transfer
[ ] Appeared after prompting
[ ] Transferred independently
[ ] Transfer remains uncertain

NEXT DECISION
Repeat, change repair route, integrate into a full mock, or apply a readiness
gate:

Choose one primary repair. Secondary observations can remain in the record, but a scorecard that schedules five unrelated remedies has failed to direct practice. The card is finished when another person could run the retest and know what changed behavior would look like.