Interview guide for software engineers: the full loop, stage by stage

A software engineer interview loop works when every stage owns different skills, every interviewer knows which ones, and the hiring decision follows a rule written before the first candidate. This guide lays out a complete loop for a mid-level engineer: five stages, who runs each, two to four core questions per stage with what to listen for, a paired coding task, the scorecard weights, and the debrief decision rule. Adjustments for junior and senior levels are at the end.

This page is the plan for the whole loop. The anchored 1–4 scale for each competency is in the interview scorecard for software engineers, and the questions for the first call are in software engineer phone screen questions. Use those two pages alongside this one rather than rewriting them.

The loop at a glance

An example loop for a mid-level product engineer on a web application team. Adjust the names; keep one owner per competency.

Total candidate time is about four hours, delivered as two calls and a half-day final. The stage-design logic behind a table like this, including the coverage matrix, is in the interview process template.

Stage 1: recruiter screen (30 minutes)

The screen confirms the candidate has done this kind of work recently and that the logistics fit. It does not score coding skill. Two questions carry most of the weight:

• "Walk me through something you built in the last year that is running in production now." Listen for what they personally wrote versus what the team owned, the stack, and whether they maintained it after launch.
• "What does a normal week of work look like: how much is new features, maintenance, reviews, on-call?" Listen for a realistic split. Someone who has only built prototypes may struggle with a maintenance-heavy role.

Write a one-line summary for the hiring manager and the pay and notice details, so nobody asks them again.

Stage 2: hiring manager interview (45 minutes)

The engineering manager owns ownership and collaboration. Do not run a technical quiz here; the next two stages cover skills with better methods.

1. "Tell me about a production problem you were responsible for. What happened, what did you do, and what changed afterward?" Listen for: their own actions in the first hour, how they communicated status, and a concrete follow-up such as an alert, a test or a runbook change. A strong answer names a mistake they made.
2. "Tell me about a time the product requirement was unclear or wrong once you started building." Listen for: whether they went back to the product manager or designer with a specific question or option, rather than guessing or building exactly what was written.
3. "Describe a technical disagreement with another engineer. How was it settled?" Listen for: the actual trade-off, what evidence they used, and whether they could commit to a decision that went against them.
4. "What is a piece of code you wrote that you would now write differently?" Listen for: a specific reason (it was hard to test, it coupled two things that change separately), not a generic "I'd add more tests".

Stage 3: the paired coding work sample (75 minutes)

The work sample is a small, realistic codebase rather than a puzzle. Two engineers pair with the candidate; one drives the conversation, one takes notes on evidence.

The brief

• A repository of a few hundred lines in the team's main language: a small service or component with tests that pass.
• Task 1 (35 minutes): add a feature described in three sentences, with one ambiguity deliberately left in the description.
• Task 2 (20 minutes): a failing test someone else wrote; find the cause and fix it.
• Wrap-up (10 minutes): "If this were going to production tomorrow, what would you change?"
• Candidates use their own editor and may look up documentation, as they would at work. Send the language and setup instructions in advance.

What to listen for

• Decomposition: did they notice the ambiguity and ask about it before coding?
• Correctness and clarity: does it work for the stated cases, and could a teammate read it without narration?
• Debugging: on the failing test, did they form a hypothesis and check it, or change lines until it passed?

If your team prefers a take-home instead, cap it at a stated number of hours, score it against the same competencies, and walk through it live so the candidate explains their choices. The rules for that are in how to evaluate a take-home assignment. Do not run both; the second one adds hours for the candidate and little new evidence.

Stage 4: system design and code review (60 minutes)

A senior engineer runs two parts with a hard switch at 40 minutes.

System design (40 minutes)

• "Design the notification system for our app: users get email and in-app alerts when someone comments on their work." Use a problem close to your product, scoped to one or two services for mid-level.
• Constraint change at minute 25: "Volume is now ten times higher and some notifications must arrive within a few seconds. What changes?"

Listen for questions about scale and failure before drawing boxes, at least one explained trade-off, and a specific revision when the constraint changes. Naming components without saying why they are needed scores low.

Code review (20 minutes)

• A short pull request with one functional bug planted (for example a race condition or an off-by-one) and two style issues. "Review this as you would for a teammate."

Listen for whether they find the functional bug, separate blocking issues from preferences, and phrase the comment so the author knows what to do.

Scorecard competencies and weights

The competencies come from the software engineer scorecard, plus one for working with product and design. These weights are an example for a mid-level product engineer; set your own at intake and lock them before the first interview.

Coding correctness is also a gate: below 3 from either pairing engineer means no hire, whatever the weighted total. How the weighted arithmetic works, and when a gate is better than a weight, is in weighted interview scorecard. The scorecard builder has a software engineer preset and checks that the weights add up to 100.

The debrief decision rule

Write this into the loop plan before the first candidate and read it aloud at the start of every debrief.

1. Scorecards first. Every interviewer submits scores and evidence before the debrief and before reading anyone else's.
2. Gate. Coding correctness at 3 or above from both pairing engineers. If not, the answer is no.
3. No must-have at 1. A 1 on any competency weighted 15% or more is a no unless the debrief finds the evidence was not collected (for example, time ran out), in which case run one short follow-up on that competency.
4. Weighted total. In this example, 2.8 or higher on the 1–4 scale moves to an offer discussion. Set your own threshold and keep it for the whole search.
5. The hiring manager decides, with the reasons recorded against the evidence, not against "culture" or "vibe".

The speaking order and the decision record are in the interview debrief template.

Adjusting the loop by level

Common loop mistakes

• Every engineer asks their favorite algorithm question. Overlapping evidence on coding and none on collaboration or review. Give each interviewer their owned competencies in writing.
• Puzzles unrelated to the job. A realistic codebase predicts the work better and is fairer to candidates who have not drilled puzzle sites.
• The hiring manager re-interviews technical skill. If the manager does not trust the pairing engineers' scores, calibrate the engineers; do not add a stage.
• Weights decided in the debrief. Weights changed after seeing a candidate are a justification, not a rule.