How to interview a forward deployed engineer

This page is for the hiring side: how to design the interview process and what each stage should tell you. A standard engineering interview process will not show the things that decide success here.

What the interviews have to measure

Three dimensions, roughly equally weighted.

Engineering depth. Can they write production code in an unfamiliar system. Non-negotiable, and the one most often given up.

Customer judgment. Can they be in a room with a frustrated stakeholder and leave it with a clearer problem than they entered with.

Reasoning through ambiguity out loud. Can they take a vague brief and turn it into constraints, questions and a plan, while thinking audibly enough that you can follow the reasoning.

The third is what a normal interview process does not test. It is also the one that most predicts whether somebody does well in week three of a real engagement.

A five-stage interview process

Stage one: screen. Confirm the basics and be honest early about travel and compensation structure. Say your travel number here rather than at offer. Wasting a candidate's fourth interview on an issue you knew would end the process is avoidable.

Stage two: coding. Your standard engineering exercise, at your standard level. First Round Review is explicit that this should be rigorous and should not be compromised, because the role writes production code.

Prefer an exercise in an unfamiliar codebase over a whiteboard algorithm. The job is reading somebody else's system and changing it safely, so test that.

Stage three: the ambiguous case. The main round, covered below.

Stage four: production ownership. Ask them to walk through something they owned end to end. Ask about the unglamorous parts: the security review, the release process, the incident, the handover. The framing to listen for is customer problem, then technical choice, then the trade-off, then the measured result.

Stage five: the working-together conversation. Someone senior, unstructured, testing the question Shilpa Balaji describes in First Round's piece: would you want to work through a hard, stressful project with this person. Also the right stage to answer their questions honestly, because good candidates for this role are evaluating you at least as hard.

Order matters more than it looks. Put the coding round early rather than late, because it is the round most likely to end the process, and ending it early respects a busy candidate's time. Put the ambiguous case after coding rather than before it, since a candidate who has already shown they can write code is easier to evaluate for judgment without the two skills getting confused in your notes. Save the working-together conversation for last, once you already know whether the skills are there, so that stage is free to focus entirely on the question it is meant to answer.

The ambiguous case round

Give them a vague problem in a plausible customer context. Something like: a mid-sized insurer wants to use AI to speed up claims triage, their data is in three systems, nobody can tell you what accurate means, and the person who asked for it is not the person who will use it.

Then stop talking and watch what they do.

What a strong candidate does. Asks who the user is. Asks what happens today and what it costs. Asks what accurate would have to mean before anybody would trust it. Asks what happens when the system is wrong. Establishes constraints before proposing anything. Then proposes something small that could be running in a fortnight, and says what it would teach them.

What a weak candidate does. Proposes an architecture in the first three minutes.

That is the single most common failure, and it is worth making an explicit line on the scorecard: did they scope before solving. An engineer who proposes a solution too early in an interview will do the same in somebody's production environment, which is how you get a system that solves the described problem rather than the real one.

What to score, specifically

• Did they establish who the user is
• Did they ask what correct means, and notice that nobody knows yet
• Did they ask about the failure path
• Did they identify what they would release first, and why that thing
• Did they say what they do not know
• Did they change their mind when you gave them a new fact

That last one matters more than it looks. Give them a piece of information halfway through that invalidates their approach, and see whether they adjust or defend.

A worked example of the fact-change test. The candidate has spent ten minutes proposing a plan built around triaging claims by dollar value, reasonably, since the case as given makes that sound like the obvious priority. Then tell them: the claims that take longest to process are not the highest-value ones, they are the ones involving a specific document type nobody has digitised. Watch what happens next. A strong candidate treats the new fact as more important information and rebuilds the plan around it in real time, out loud, without defensiveness. A weaker candidate tries to fold the new fact into the plan they already built, because the plan itself has become the thing they are defending rather than the problem the plan was meant to solve. That difference is exactly what shows up in week three of a real engagement, when the customer's own operators reveal something the discovery call missed.

Do not run these

A long series of pure algorithm tests. It tests something the job does not need and screens out people who would be excellent at it.

A take-home that builds a full feature. The candidates you want most are employed and busy. A long take-home selects for availability.

A presentation round with slides. It tests presentation skill, which the job does not need.

A culture-fit round with no scoring rubric. It reliably measures similarity to the interviewer, which is the opposite of what this role needs given the range of environments the person will work in.

A panel interview where five people ask questions in one hour. It produces five shallow impressions instead of two or three deep ones, and it is exhausting for the candidate in a way that skews results toward people who interview well under pressure rather than people who will do this job well under pressure, which are related but not identical qualities.

What a passing scorecard actually looks like

A candidate does not need to be strong on every dimension to pass. First Round's five qualities and the three interview dimensions above overlap but are not identical, and a useful way to combine them is to require a clear pass on engineering depth and on scoping ambiguity, with judgment in front of a customer allowed to be a maybe if everything else is strong, since customer manner improves with coaching in a way that engineering ability and problem-scoping largely do not. A candidate who is a maybe on all three dimensions at once is a pass on paper and a risk in practice, because the interview process has told you nothing it can stand behind.

Calibrating against the market

Useful context when setting the standard. Across 1,000 postings, 60 percent targeted three to five years of experience and 20 percent six to eight, so this is a mid-level role in most companies. Customer communication was the most-named soft skill at 47 percent.

You are competing for these candidates against companies who will pay well, so a slow interview process loses candidates. Decide fast, and tell candidates the timeline you will actually hold to. A process that takes six weeks and five stages will lose strong candidates to a competitor running three stages in ten days, regardless of how good the offer eventually is, because the best candidates for this role have other offers moving on their own schedule.

One question to add if AI writes your code

Ask how they would know a change was correct if a model wrote it.

The answers separate quickly. Weak answers describe reading the diff carefully. Strong answers talk about deriving checks from the specification before the code exists, and about not letting the thing that wrote the code be the thing that grades it. That is the discipline eval-driven development describes, and in a customer's production environment it is the difference between speed and liability. Add this question at stage two rather than stage four, because a candidate's answer here often reshapes how you read the rest of the coding round.

Next: where the function should report, which affects who these people work for once hired.