Don't Panic: Technical Interviewing

A technical interview is a small machine for turning a prepared task into a hiring signal. The candidate supplies code, questions, diagrams, hypotheses, and tradeoffs. The interviewer supplies the prompt, timing, tools, probes, hints, notes, and rating. This is called an evidence path, because "we had a good conversation" is not a measurement method, however pleasant the conversation may have been.

The course starts after someone has defined the role and decided which competency needs evidence. Its subject is one interview and the kit that makes that interview repeatable. The kit contains the prompt, tool policy, time plan, probes, hint ladder, behavioral anchors, and the rule for handling a broken session. Without it, each interviewer invents a new assessment while administering it, which is an energetic way to avoid comparability.

Three ideas do most of the work.

First, the prompt must create a fair opportunity to show the competency. A debugging task needs a stable symptom and prepared evidence. A system-design task needs enough constraints to define the problem without requiring telepathy. A coding task needs an explicit completion condition and a tool policy. Pilot the task with people who did not write it. Authors are unusually good at understanding their own clues.

Second, a probe and a hint are different instruments. "Which observation would test that hypothesis?" asks for more evidence. "Inspect the parsing boundary" supplies direction. Both can be useful, but only one leaves the candidate to choose the next technical step. A hint ladder names the assistance levels, says when each applies, and records what was given. Otherwise identical final code can conceal very different journeys.

Third, notes contain observations before they contain conclusions. "Reproduced the timeout, compared it with deploy timing, and tested a rollback" can support a rating. "Strong debugger" cannot. After the session, each interviewer rates independently against a behavioral anchor. Only then does the panel compare results. Disagreement is not an inconvenience to average away. It is a clue that interviewers saw different evidence, interpreted the rubric differently, or administered different tasks.

The surprising part is that the interviewer is part of the instrument. Timing, facial reactions, silence, rescue attempts, and improvised hints all change the task. The same question text is not the same interview when one candidate receives a restated symptom and another receives the missing concept.

Tool failures deserve their own category. If the environment consumes half the session, the result is an administration failure and an evidence gap. It is not a low coding score. Reschedule or collect another comparable signal; the package manager is not applying for the job.

Read the Intro for the complete operating model. Use the Slides to see the flow and failure points at a glance. Keep the Cheatsheet beside an interview kit when you need prompt checks, hint levels, note patterns, and calibration steps. Field Notes covers the less polite truths: help varies more than question text, talk volume becomes a hidden criterion, and realistic environments bring realistic breakage. The purpose is not to remove judgment. It is to leave enough evidence to inspect and improve it.