Why Gut Feeling Fails
Unstructured interviews feel natural. You sit down with a candidate, have a conversation, and at the end you ask yourself: "Would I want to work with this person?" The problem is that this question is answered almost entirely by cognitive biases, not by evidence of job-relevant skill.
Common failure modes:
- Affinity Bias: "I liked them — we went to the same university." (Shared background, not shared competence.)
- Halo Effect: "They were so confident presenting their past work, they must be technically strong." (One positive trait inflates the overall impression.)
- Recency Bias: "They nailed the last question, so I'm forgetting they struggled with the first three."
- Contrast Effect: "After the terrible candidate this morning, this one seems great by comparison."
None of these biases correlate with whether the candidate will actually perform well in the role. Structured interviewing is the engineering solution to this human problem.
The Loop Architecture
An interview "loop" is a coordinated set of 4–6 sequential interviews where each interviewer owns a specific, pre-assigned competency. The critical constraint: interviewers must stay in their lane. An interviewer assigned to system design should not drift into behavioral questions, and vice versa. This prevents both redundancy (three people asking the same algorithm question) and gaps (nobody testing communication skills).
A well-designed loop for a Senior DevOps Engineer might look like this:
| Interviewer | Role | Competency Owned |
|---|---|---|
| 1 | Senior SRE | Incident diagnosis, Linux internals |
| 2 | Software Engineer | Coding and scripting (Python/Go/Bash) |
| 3 | Product Manager | Communication, ownership, prioritization |
| 4 | Bar Raiser | System architecture and scalability |
The Rubric: Defining "Good" Before You Ask
Every question in the loop must have a pre-defined scoring rubric. If you cannot articulate what a strong answer looks like before you ask the question, you are relying on bias to evaluate the response.
Example question: "Tell me about a time you improved the reliability of a system you owned."
| Signal Level | Characteristics |
|---|---|
| Strong Hire | Quantified impact (e.g., "reduced p99 latency from 800ms to 120ms"), described the diagnostic process, mentioned what they learned and how they applied it later. |
| Hire | Clear ownership, reasonable approach, some measurement of outcome. |
| No Hire | Vague ("I fixed some bugs"), no ownership, no measurement, no learning. |
| Strong No Hire | Cannot recall a specific example, or describes a situation where they waited for someone else to fix it. |
Building rubrics before the interview forces the hiring team to agree on what "good" looks like. This is the equivalent of writing acceptance tests before writing code — it makes the standard explicit and objective.
Interviewers often ask: "How do you handle disagreement in a debrief?" The correct answer is: "I go back to the data." If two interviewers disagree on a candidate's technical ability, the resolution is to compare the specific evidence each gathered — the actual answers the candidate gave — not to debate impressions. Rubrics make this possible because they give everyone a shared vocabulary for what "strong" and "weak" look like.