How to Interview a Software Engineer: A Practical Guide 2026

To interview a software engineer well, run a structured multi-stage loop where each round tests one competency, every interviewer scores against the same rubric, and a group debrief makes the call on evidence instead of whoever interviewed last. Hiring managers who skip the rubric and argue from memory end up with a coin flip and a bad hire three months later.

This guide is written for the person on the hiring side: the tech lead with four candidates in the pipeline, the engineering manager replacing a departing engineer, the founder hiring the first hire without a recruiting team. It covers the loop, the question bank, the scorecard, the debrief, and the awkward questions about AI-assisted answers.

One thing worth saying up front. The loops most companies run were built by copying a large-tech process that assumed a much bigger hiring funnel and a job the interviewer does not understand. When interview scores do not line up with how people actually perform in their first 90 days, the process is the thing that needs fixing, not the candidate.

Table of Contents

• What You Need
• Step-by-Step
• Define the role and competencies before you write a single question
• Create a consistent question bank and scoring rubric
• Example questions and what strong answers contain
• Choose the right interview format and participants
• Run the interview with active listening and useful follow-ups
• Evaluate evidence instead of personality or familiarity
• Run a fair debrief and make a documented decision
• Common Mistakes
• Frequently Asked Questions
• How do I interview a software engineer without testing obscure algorithms?
• Should a software engineer interview include a coding test?
• How long should a software engineering interview last?
• How do I compare candidates fairly during the debrief?
• What questions reveal a software engineer’s collaboration skills?
• How should I follow up after a software engineering interview?

What You Need

You need five things ready before the first candidate arrives, and none of them take more than an afternoon to build.

1. A written role scope. One page covering what the engineer will own in the first six to twelve months, the decisions they will make, and the parts of the system they will touch. Interviewers cannot score what nobody wrote down.
2. A competency list. Four to six things this role genuinely needs. Coding ability is one of them, but rarely the whole list. Collaboration, debugging, system judgment and written communication usually belong there too.
3. A loop with a fixed shape. Number of rounds, who runs each one, and how long each one lasts. Every candidate walks the same path, which is the entire point.
4. A scorecard per round. The competencies that round covers, a 1 to 4 scale with written anchors, and a notes field. Interviewers fill this in during the interview, not an hour later from memory.
5. A written candidate brief. What the exercise covers, how long it should take, whether it is paid, which tools and editor are allowed, and what the interviewers are actually assessing.

Two smaller things matter more than teams expect. First, ask every interviewer to submit scores independently, in writing, before the debrief starts. Second, decide up front how you handle an accommodation request, a reschedule, or a candidate whose home internet fails mid-session. Those situations come up every hiring cycle, and they go badly when nobody decided in advance.

Step-by-Step

Define the role and competencies before you write a single question

Most bad interviews start with someone browsing a list of 50 coding interview questions. Start somewhere else: read the job description and pull out the actual work.

Split what you find into must-have and nice-to-have. For a backend role, “has shipped and maintained a service in production” is a must-have. “Has used Kubernetes” is usually nice-to-have until you have decided otherwise. Then write down the decisions the person will make: which requests the service accepts, how a breaking change ships, what happens when a downstream dependency is slow on a Friday afternoon.

That list is your interview. Every question you ask later should trace back to one line on it. If a question cannot be traced, it is trivia, and trivia is where most loops waste their time.

Write it as if the candidate will see it. Candidates who know what is being assessed give better answers, and you will get fewer people opting out because the exercise sounded like a puzzle.

Create a consistent question bank and scoring rubric

A question bank is just your competencies turned into questions, with the follow-ups you expect and the thing you are listening for written next to each one. It exists so that candidate A and candidate B get asked roughly the same things by interviewers with different backgrounds and different moods.

Example questions and what strong answers contain

For a mid-level engineer, a workable bank looks like this:

• Project depth: “Walk me through a system you owned. What did it do, who depended on it, what broke last?” Listen for: numbers they chose, trade-offs they rejected, and a clear line between what they did and what the team did.
• Debugging: “Describe a production incident you were paged for. What was the first signal, and how did you narrow it down?” Listen for: a method rather than a lucky guess, and whether they say what they would do differently.
• Trade-offs: “When would you denormalize something?” Listen for: named costs, not enthusiasm for one tool.
• Collaboration: “Tell me about a technical decision you lost.” Listen for: a real opponent and a real reason, not a humblebrag about being right.
• Code quality: “Show me code you are proud of, then something in it you would change.” Listen for: honesty about the weak part.

Pair each question with an anchor so two interviewers score the same answer the same way. This is the piece most teams skip, and skipping it is why debriefs become arguments about people instead of about evidence.

Competency	1 (weak)	2 (mixed)	3 (strong)	4 (exceptional)	Weight
Problem solving	Needed a full walkthrough, still stalled	Solved with prompts, narrow approach	Decomposed cleanly, explained trade-offs	Reframed the problem and proposed two paths	25%
Coding quality	Not runnable by the end	Runs but untested and unowned	Runs, tested, reads clearly to a stranger	Handles the cases they were not asked about	25%
System judgment	Jumped to a solution immediately	Some reasoning, no cost considered	Named costs and picked a defensible option	Argued the option out loud as a trade-off	25%
Collaboration	Described work, not decisions	Some context, took no position	Clear role, named disagreements	Surfaced a team problem nobody had raised	25%

Weight the competencies before you interview anyone, not after the scores are in. If you set the weights in the debrief, you will find them for whichever candidate you like.

Choose the right interview format and participants

Decide each round’s format before you schedule it. A loop that looks like this keeps rounds single-purpose and stops two people testing the same thing twice.

Stage	Duration	Who runs it	What it tests	Where candidates lose
Recruiter screen	20-30 min	Recruiter	Motivation, logistics, compensation range	Cannot say why this role, at this company
Technical phone screen	45 min	Senior engineer	Problem decomposition, fluency in the stack	Goes silent for fifteen minutes
Working sample	60-90 min live, or 3-4 hours paid take-home	Engineer on the team	Real code, tests, decisions made in the open	Nothing runnable at the end
System design	45-60 min	Staff or senior engineer	Architecture judgment and requirement framing	Proposes microservices before asking a question
Behavioral	45 min	Hiring manager	Ownership, feedback, collaboration under pressure	Repeats one project story every answer
Bar raiser	30-45 min	Engineer outside the hiring team	Independent calibration against the level	Skims the file, decides on instinct

Most loops for a mid-level role need four to six rounds. Add more and you mostly add dropouts: candidates start declining or going quiet around the fifth conversation, and you pay engineering hours for the privilege.

The three working-sample formats trade off differently, so pick on the axis you care about. Live pairing gives you the highest signal per minute and the worst experience for anyone nervous on camera. A take-home is comfortable and asynchronous, but it is also solo, so you learn nothing about collaboration, and it is the easiest format to quietly over-assign. A whiteboard without a computer shows reasoning and shows almost nothing about writing code you would actually merge.

Whatever you choose, keep the exercise small enough to finish. A four-hour assignment completed on top of a full-time job tells you about free time, not about engineering. If you cannot shrink it, pay for it.

Run the interview with active listening and useful follow-ups

Most of the value in an interview round happens in the second and third follow-up, not the first answer. Write down the questions you plan to ask and the follow-ups you might need, then stop reading the list once the conversation is moving.

Spend the first five minutes setting expectations: what you will cover, how long it runs, who else they will meet, what you are assessing. It costs nothing and it settles nerves. Then ask one question at a time and let silence sit for a few seconds after you finish speaking. Most candidates need that pause more than they need a rephrased question.

Probe decisions, not adjectives. When someone says they led a migration, ask what the alternative was, what would have happened if they had waited six months, and who disagreed. When someone says they improved performance, ask by how much and how they measured it. Answers like “we” and “a lot” are the start of a follow-up, not the end of one.

Leave the last ten minutes for their questions, and answer honestly. A candidate who learns your deployment process is nightly and your test suite is slow will make a better decision about joining, which is the outcome you want anyway.

While you listen, note specifics: numbers, names of teams, the decision they made, what they would do differently. Those notes are the raw material for the scorecard, and vague notes produce vague decisions.

Evaluate evidence instead of personality or familiarity

Two interviewers will like different candidates for reasons that have nothing to do with the job. The fix is not to become less human during the interview. It is to decide in advance what evidence counts, and to write down what you actually heard before the debrief starts.

Score only the competencies your round covers. A brilliant systems thinker should not be penalised for the ergonomics of a take-home they were never asked to design. And when a claim is unsupported, ask once more rather than quietly downgrading the candidate in your head. “You said you cut latency by 60 percent. What was the measurement, and what was the baseline?” often produces a better answer, or a clearer no.

Two categories of question cause most of the damage. Culture fit is the obvious one. It rewards people who sound like the people already in the room, and it is the reason identical evidence gets read two different ways. Replace it with a named competency, like how they handle disagreement with a stakeholder or how they document decisions.

The second is anything that asks about hobbies, schools, accents, family plans, or where somebody grew up. None of it predicts whether someone can find a bug in your billing pipeline at 2am.

On AI-assisted answers, take a practical view. Coders use assistants every day, so banning them is not a realistic rule and cheating with one is not the same crime everyone treats it as. What you actually want to know is whether the person understands what they are proposing. Ask them to explain before they type, ask them to change one requirement mid-task and talk through what breaks, and watch whether they can defend the output without the tool. Follow-up questions about their own code are the most reliable test there is.

One more bias check worth doing: interviewers understate the work of candidates who describe it modestly. There is a documented pattern of women, in particular, minimising their contribution in exactly these conversations. The countermeasure is boring and it works. Ask what was hard, what they chose, and what they would do differently, then wait through the pause after they first say “we”.

Run a fair debrief and make a documented decision

The debrief is where a good loop is usually lost. If interviewers walk in and start talking without submitting scores, the loudest voice decides, and whoever interviewed last wins.

Run it in this order. Everyone submits their written scorecard before the meeting starts. The hiring manager presents the evidence first, round by round, and each interviewer confirms or corrects only their own round. Disagreements get named out loud, with the specific evidence behind each position, rather than settled by seniority. You check for bias by asking one question: would we score a candidate who described this exact work in a different tone or accent the same way?

Then decide against the bar you set before the process, not against the strongest candidate you saw this quarter. Some candidates clear the bar and still get a no, and that is fine as long as the bar did not move during the loop.

Write the feedback the same day, in plain language with evidence in it. “Strong on debugging, we could not tell how they handle disagreement, so the collaboration round came back mixed” is useful. “Not a fit” is not, and it costs you referrals later. Then tell the candidate quickly, pass or fail, with the honest reason. Speed after a loop matters as much as speed during one.

Calibrate compensation as an interviewer, not as an afterthought. Know the band and the level definition before you fall in love with a finalist, so you do not stall a week discussing numbers after saying yes. If you are hiring into civic work, salary transparency questions usually arrive early and you should have a straight answer ready.

Common Mistakes

Most loops I have seen fail in the same seven places, and every one of them has a straight correction.

• Interviewing without a written bar. Each interviewer uses their own standard, so the debrief becomes a comparison of moods. Fix: publish the 1 to 4 anchors before the first round and score against them.
• Asking trivia disguised as experience. “What does this framework do under the hood” tests recall, not judgement. Fix: ask what they chose and why, in their own system.
• Running the same loop for a junior and a principal. Senior candidates get bored and junior candidates get steamrolled. Fix: write a separate competency list and bar for each level.
• Debriefing before scores are written. Anchoring wins, and the most senior person in the room sets the frame. Fix: submissions closed before anyone speaks.
• Letting the loop run six weeks. Your best candidate accepts another offer, and you learn this after you have spent 30 engineering hours. Fix: decide the calendar up front, run stages in parallel where you can, and send a decision within 48 hours of the final round.
• Treating take-homes as free work. A four-hour solo assignment gets worked on at midnight by a candidate with a demanding week. Fix: cap it at two hours or pay for it.
• Hiring for a job description that is out of date. Interviewers screen for the engineer you needed last year, because nobody compared the loop to the actual first 90 days. Fix: have the hiring manager walk through the role scope with the panel before round one.

Frequently Asked Questions

Start with the least glamorous part. Write the role scope and the four to six competencies for this specific job, put the 1 to 4 anchors next to them, and hand the same scorecard to everyone who will meet a candidate. A loop built that way takes an afternoon to prepare, and it is the only version of how to interview a software engineer that produces a decision you can defend weeks later.