How to conduct a technical interview you can actually defend

To conduct a technical interview well, you run a repeatable process: define what the role actually needs, ask every candidate the same leveled questions, and score each answer against a rubric so the decision holds up. The goal is not to test trivia; it is to predict whether someone can do the job. Do that consistently and you can defend every hire, even when the candidate works in a stack you do not know deeply.

Most advice on running a technical interview is one person's experience. This is the structured version, the same repeatable technical interview process our own scoring is built on, so it works whether you are a senior engineer or a recruiter conducting a technical interview for the first time.

Key Takeaways

• A technical interview exists to predict job performance, not to test whether someone memorized algorithms. Structure is what makes it predictive.

• The four-step technical interview process is: define the must-haves, pick leveled questions, run it consistently, and score against a rubric.

• You do not need to be an expert in the candidate's stack. A rubric plus good follow-up questions lets a non-expert evaluate fairly.

• The same questions and the same scoring for every candidate is the single biggest lever on fairness and accuracy.

• A structured, rubric-scored interview predicts performance far better than an unstructured chat. Schmidt and Hunter put structured interview validity at about 0.51.

What a technical interview is actually for

A technical interview is not a quiz and not a hazing ritual. Its job is to gather evidence that a candidate can do the actual work, and to do it consistently enough that you can compare candidates fairly. That reframing matters, because it rules out the two most common failure modes: asking obscure trivia, and letting each interviewer freelance so you end up comparing notes that were never comparable.

The rest of this guide is a four-step process for running one. It is deliberately repeatable, because consistency is what turns a set of conversations into a decision you can stand behind.

Schmidt and Hunter's meta-analysis of hiring methods puts structured interview validity at about 0.51, more than double an unstructured conversation, and structure is exactly what these steps add. SHRM's 2026 State of AI in HR report adds the operational case: most HR teams using AI in recruiting report meaningful time savings, which is what lets a team run a consistent structured process at scale.

Step 1: define what the role actually needs

Before you write a single question, list the three to five things a person must be able to do to succeed in this role. Not a wish list, the real must-haves. For a backend role that might be reasoning about data models, writing correct concurrent code, and debugging under pressure. For a frontend role it might be component architecture and performance.

This list becomes the backbone of everything else. Each interview question should map to one of these competencies, and each score should tell you how the candidate did on that competency. If a question does not test a must-have, cut it. Knowing how to structure a technical interview starts here, not with a question bank.

Step 2: pick leveled questions from a bank

Once you know the competencies, pull questions that test them, leveled to the seniority you are hiring for. A junior candidate should get questions about mechanics; a senior candidate should get questions about trade-offs and judgment. Asking a junior a staff-level system design prompt tells you nothing useful.

This is where a maintained question bank saves you. Instead of inventing questions on the fly, pull from a leveled set with model answers and scoring notes.

Our question bank library covers the common rounds: behavioral interview questions, SQL interview questions, Python interview questions, and system design interview questions. Each question comes with a model answer and a note on what a strong versus weak response looks like, which is what makes the next steps possible.

Step 3: run it consistently

Here is the rule that does the most work: ask every candidate for the same role the same core questions, in the same rough order, with the same time budget. Consistency is not bureaucracy; it is the only way to compare two candidates honestly. When interviewers each ask different questions and rate on instinct, you are measuring the interviewers as much as the candidates.

Running a technical interview consistently also means managing the mechanics: set the candidate at ease, state the format up front, let them think out loud, and resist the urge to jump in. Your job is to gather signal, not to demonstrate your own knowledge. Reserve your energy for the follow-up, which is where the real signal lives.

Step 4: score against a rubric

Do not leave the interview with a gut feeling; leave it with a score per competency, recorded against a rubric. For each question, decide in advance what a strong, average, and weak answer contains, then rate what you heard against those anchors. This is the difference between "seemed sharp" and "correctly reasoned about the concurrency trade-off, missed the failure case."

A technical interview scorecard captures both the rating and the reasoning, so the decision can be reviewed and defended later. This is exactly what Expert Hire's scoring methodology does, and what structured interview software enforces: the same rubric, applied to every candidate, with the reasoning attached to every score.

How to conduct a technical interview in a stack you do not know

The most common worry from recruiters and hiring managers is running a technical interview in a language they do not write. The good news: you do not need to be an expert if you have a rubric and good follow-ups.

The rubric tells you what a strong answer contains, so you can recognize one without generating it yourself. The follow-up does the rest: after any clean answer, ask "why" or "what happens if." A candidate who understands the material extends their reasoning; one who memorized an answer stalls.

You can run a defensible screen this way, and if you would rather not, an AI interviewer that scores against a published rubric can run the structured round for you and hand back a transcript. Our guide on how non-technical recruiters can evaluate engineering talent goes deeper on this.

Common mistakes that break technical interviews

A few anti-patterns undo all of the above:

• Trivia over reasoning.

  Obscure syntax questions test memory, not ability. Ask questions that reveal how someone thinks.

• Improvised questions.

  Different questions per candidate make comparison impossible. Standardize the core set.

• Gut-feel scoring.

  "I liked them" is where bias hides. Score against a rubric.

• Talking too much.

  The candidate should be doing most of the talking and reasoning. Ask, then listen.

• No follow-up.

  A single clean answer proves little. The follow-up is where you separate understanding from recall.

Avoid these five and your technical interview process is already better than most.

Frequently asked questions

What is the best structure for a technical interview? Four steps: define the role's must-have competencies, pick leveled questions that test them, ask every candidate the same core questions consistently, and score each answer against a rubric. Structure is what makes the interview predictive and comparable across candidates.

How do I conduct a technical interview if I am not technical? Use a rubric that defines what a strong answer contains, so you can recognize quality without generating it, and lean on follow-up questions ("why," "what happens if") to test depth. For stacks you do not know at all, an AI interviewer that scores against a published rubric can run the round and give you a reviewable transcript.

What are good technical interview tips for interviewers? Ask the same questions of every candidate, let them think out loud, resist jumping in, always ask a follow-up, and score against a rubric rather than a gut feeling. Your job is to gather signal, not to prove your own expertise.

How long should a technical interview be? Most effective technical rounds run 45 to 60 minutes: a few minutes to set up, the leveled questions with follow-ups, and time for the candidate's questions. Depth of follow-up matters more than the number of questions you cram in.

What is a technical interview scorecard? It is a structured record of how a candidate did on each competency, with a rating and the reasoning behind it, scored against predefined rubric anchors. It replaces "seemed good" with defensible, comparable evidence you can review later.

The bottom line

Conducting a technical interview well is not about being the smartest person in the room. It is about running a repeatable process: define the must-haves, pull leveled questions, ask them consistently, and score against a rubric. Do that and you can compare candidates fairly, defend every decision, and run a strong technical screen even in a stack you do not write.

If you want the structured version without building it yourself, look at a sample candidate scorecard and decide whether that rubric-scored, reasoning-attached output is something you would trust to advance a candidate. That is what turns a set of interviews into a decision you can stand behind.

• By TK, Growth at Expert Hire. Last updated July 6, 2026. Reviewed by Anand Suresh, CPO at Expert Hire.