How to Run a Technical Interview in 6 Steps

A technical interview has one job: show you how a developer works when the answer is not already in their head. Most sessions end up testing something else, which is whether the candidate has seen that particular puzzle before. You learn who memorized a question set, and you still have no idea how they behave on a Tuesday afternoon when a requirement changes.

In the format below, one small problem stays on screen for the entire session, and pressure is added to it in six steps. Every step is a probe that carries a signal: how the candidate scopes a problem, what they ask before committing, how they take a nudge, whether they check their output, how they refactor once the rules move, and how they talk about cost. A founder making a first engineering hire can use it just as well as a CTO trying to get five interviewers to run the same session.

Throughout, the problem is FizzBuzz: print the numbers 1 to 100, print Fizz for multiples of 3, Buzz for multiples of 5, and FizzBuzz for multiples of both. Any small problem would work. The signal comes from the sequence of follow-ups you attach to it.

Step 1: pick a problem smaller than the job, then ban code for a few minutes

Start with something the candidate can finish, and state the rules in full before anyone touches a keyboard. A famous, easy problem removes the trivia lottery from the session. Nobody gets credit for having rehearsed it last week, which means everything you learn over the next hour comes from how the person works rather than what they happened to revise.

Then hold the code back. Open with "before we write anything, how would you approach a problem like this?" instead of "go ahead and solve it". That gets you two things. You see the decomposition before syntax hides it. An anxious candidate also gets somewhere to stand. Freezing at the start of a technical interview is common, and a candidate who blanks in the first minute has told you nothing about how they work. It is much harder to freeze on a conversation than on a blinking cursor.

1. Ask for the approach in words. Conditions in the rules become conditionals in the code, and you want to hear the candidate say so out loud before typing it.
2. Accept pseudocode or a sketch. A whiteboard flowchart is enough, and so are four lines of plain text. Neither one locks them into syntax or boilerplate while the shape of the solution is still moving.
3. Watch the ordering. These rules have only one subtlety: the combined case must be checked before the single ones. When a candidate writes the Fizz check first and then catches the problem, you have seen how they review their own work.
4. Do not grade the pseudocode. It is an artifact of thinking. What it tells you is whether the candidate can break a problem into parts, not whether their indentation is consistent.

At this stage, most problems that look complicated come apart quickly, and once the rules are written down candidates often say so themselves. Notice that reaction. The same habit is what keeps an estimate honest later on.

Step 2: make the rules of the room explicit

Two sentences at the start of the session change what you get from the rest of it. First, you cannot give them the answer, and you want them to get there. Second, they should ask questions as they go and keep talking while they work. Once you say both out loud, they stop being risks the candidate has to weigh.

Their questions are data. Before filling in the body of the loop, a strong candidate pins down the requirements. Should the program take an input and return the answer for one index, or always iterate over all 100? The answer hardly matters, and a loop is usually fine. What you are measuring is the instinct to settle the shape of the problem before building inside it, and that same instinct keeps a small ticket from quietly turning into a large one.

Narration is the other half. You are listening for decisions with reasons attached: a counted loop chosen over an iteration helper, a variable named before it is used, a check deferred because it belongs further down. Being right about the reason is secondary. A candidate who explains a choice you disagree with is still showing you their problem-solving process, while a silent candidate shows you nothing at all.

Step in if they go quiet and stay that way. Ask them to tell you what they are stuck on, or to come up with a question for you. Silent staring at the screen is the one state in an interview that carries no signal, and left alone it tends to get worse.

Step 3: let the first version stand, even when it leans on a language trick

The only part of this problem with any content in it is deciding whether one number is a multiple of another. A candidate who does not reach for the standard operator can still derive something that works: divide, then check if the result is a whole number. Twelve divided by three is four, eleven divided by three is 3.6666, so the rule holds and the code runs.

Hold off on correcting it. Watching someone work out a rule from first principles under time pressure is exactly the signal you came for, and cutting in with the right answer turns an exercise in reasoning into a vocabulary test. Let them finish and run it, then let them be pleased with it.

Make a note of the weakness instead, since it is real. The check relies on how this particular language handles division and type conversion. That dependency is what the next question is for.

Step 4: ask for the portable version

Now make the weakness a probe. Usually "What can you do without the type conversion?" is enough. If nothing comes back, name it: "do you know what modulo is?" JavaScript calls it the remainder operator, and a candidate who recognizes it by either name can rewrite the condition to check that the remainder of the division is zero.

You get two signals from one question. The first is vocabulary. Modulo exists in effectively every language a team might use, so a candidate who knows it carries their divisibility check to any codebase, while a candidate who only knows the division trick carries a JavaScript habit.

The second signal is how a nudge lands. Some candidates hear the question, see why the original is fragile, and rewrite it without defending it. Others argue that the first version works, which is true and beside the point. You are about to spend a year sending this person review comments. Seeing one land in a low-stakes moment is worth more than another puzzle.

Say the underlying principle out loud to your team: language-specific cleverness costs money in review. A reviewer may have spent their career in a different language and will read the trick as noise. The portable primitive wins, even when the clever version is shorter.

Step 5: test the output against the spec, not against their confidence

Three independent checks produce a bug the candidate will not see unless they read the output. At 15 the program prints Fizz, then Buzz, on two separate lines. The rules asked for FizzBuzz on one.

Do not name the bug. Ask the question instead: "can you make FizzBuzz print on a single line?" That phrasing sends them back to the spec rather than to your face, and what you see next is the habit you actually care about. Some candidates re-read the rules, find the case, and restructure. Others start guessing at edits.

The restructure uses one branch per case: the combined check first, then the multiples of three, then the multiples of five, and the number itself as the fallthrough. It comes out shorter than what it replaces. Point that out, because candidates often show up carrying rules they picked up online, like the one about else being an anti-pattern. Repeated without its context, a rule is a liability, and this is a cheap place to learn whether someone holds one.

Ask them to run it in front of you before they declare it done. Whether someone reads their own output before announcing success is visible in ten seconds and invisible on a resume.

Step 6: change the requirement, then ask what it costs

The final probe is the one closest to the job. Once the solution is correct, move the rules: multiples of 7 now print Bazz. The branch chain that was just tidied must now handle a fourth word, plus every combination that comes with it.

The scalable answer pulls the data out of the control flow. Declare a variable for what will be printed, append to it as each check passes, then print either the accumulated string or, when nothing matched, the number. After that, a fifth rule means two more lines instead of a rewrite. Getting there shows you how the candidate responds when a product manager changes their mind, and that is a large part of the role.

Then close on cost: "how would you describe the performance of your solution?" You are listening for complexity vocabulary. The work grows in step with the range, which is linear time, written O(n). A candidate who then notes that the range is fixed at 100, so the cost is constant in practice, has understood what the notation describes. An answer about how fast it felt when they ran it is also information, and the follow-up is simply to ask the question again in Big O terms.

Pair this session with an exercise on existing code, because writing from scratch is all this format can show you. A short pull request review with the same candidate covers the reading half of the job.

What goes wrong when this is run badly

• Scoring the solution instead of the path. The code you end up with in a FizzBuzz session is worth nothing to you. The whole report is the six moves that produced it.
• Letting the panic run. A candidate who has blacked out is being timed, not tested. Reframe it as a discussion and begin again.
• Correcting too early. Each time you hand over an answer, you buy a moment of comfort at the cost of a signal. Ask a question instead.
• Reading a workaround as a failure. A derived rule that works is evidence of reasoning. Probe it before judging it.
• Accepting a feeling about performance. "It runs instantly" answers a question other than the one you asked.
• Leaving the assistant policy unsaid. Editors now ship with completion assistants turned on, and a suggestion that pops up mid-answer makes the session ambiguous for you both. Decide in advance whether it stays on. Say so at the start, then adjust what you ask to match.
• Stacking more problems instead of more pressure. Every new problem burns minutes re-establishing context. With one problem and six escalating constraints, those minutes go to signal.

Should you also need a language-specific layer over this format, the interview question sets by technology supply the second half of the session, along with notes on what a strong answer covers.

Run the same six probes every time

The format is worth little the first time and a lot by the fifth. It comes down to one small problem, six probes in the same order, and a note recorded against each probe instead of a single score at the end. Two interviewers who run it separately will then produce comparable notes on the same candidate, which is the part most hiring processes never reach.

A good session also tells you what the first month should look like, since you have just watched someone scope, rewrite and verify. Carry those notes into onboarding instead of starting from scratch. And if the harder problem is an empty shortlist rather than the interview itself, hiring through a vetted pool puts candidates in front of this format sooner.