Hire for the day-to-day, not the resume.
Elena hired the best engineer she interviewed all quarter. Daniel solved the hardest algorithms question in 22 minutes, designed a clean distributed cache on the whiteboard, and had a flawless record at a company you would recognize. She hired him as her first Forward Deployed Engineer, handed him the company’s biggest logistics customer, and cleared his calendar for a week.
Three weeks later, the customer’s dispatch dashboard was still showing trucks arriving before they left. Daniel had found the bug — timestamps exported without timezone information — and had a beautiful fix in progress: a rewrite of the ingestion service with proper timezone handling, tests, and a migration plan. What he had not done was tell the customer. He had not asked the dispatch manager what “correct” looked like, had not warned them the numbers they were planning routes with were wrong, and had not shipped the smallest version of the fix that would have made the dashboard right that week. The customer found out from their own drivers. Elena found out from the customer’s CEO.
Daniel was not a bad engineer. He was a good engineer screened for the wrong job — and the screening failure was Elena’s, not his.
If you are hiring your first Forward Deployed Engineer — or your first few — it is probably because a customer deployment is stuck, a deal depends on someone who can make your product work inside a customer’s world, or your product team is tired of hearing “the customer needs this” secondhand. The temptation is to hire the strongest engineer you can find and assume the customer part will follow. It usually does not. The customer part is the job, and your interview process has to test it directly.
This post is the employer-side companion to the candidate-side hiring track: what to screen for, how to design a take-home that tests customer-facing engineering, what the interview loop should look like, and which red flags predict a bad first deployment. For the candidate’s view of the same process, see The Take-Home Playbook and The FDE Resume Teardown.
The principle: hire for the day-to-day, not the resume
A resume tells you what someone has been near. The day-to-day of an FDE is: a vague customer ask, messy data, a system you did not build, a stakeholder who needs an answer in plain language, and a fix that has to work in production by Friday. Every stage of your hiring process should be a smaller, fairer version of that day. If a stage does not resemble the job, it is selecting for something else.
1. What you are actually hiring for
Before you write the job description, write down the day. An FDE’s week is roughly this: embedded with a customer, turning a vague request into a scoped problem; integrating systems that were never designed to talk to each other; cleaning data that is wrong in ways nobody documented; explaining trade-offs to people who do not write code; and owning the outcome in production after the demo ends. Code is maybe half the work — the other half determines whether the customer renews.
That is a different job from a software engineer who occasionally talks to customers, and from a solutions engineer who mostly configures and demonstrates. The distinction is primary responsibility: delivering an engineering outcome inside a customer’s environment, under that customer’s constraints. For the full comparison, see FDE vs Software Engineer vs Solutions Engineer: Which Role Actually Fits You?, and for the role itself, What Is a Forward Deployed Engineer? Role, Skills & How to Become One.
Two consequences follow. First, the skills that predict success show up in how a candidate handles ambiguity, customers, and broken things — not in how fast they invert a binary tree. Second, a job description that lists every technology your stack touches attracts the wrong applicants and scares off the right ones. Write it around the outcomes — “own our first three customer deployments end to end” — and let the technology list be the supporting detail.
2. The five things to screen for
These five are worth screening for because each one shows up in the first month on the job — and each is hard to train into someone who lacks it. For each trait, screen for the observable behavior, not the adjective. Anyone can claim “strong communication skills” on a resume; far fewer can demonstrate it in a room.
Customer sense
Customer sense is the habit of noticing the human on the other side of the system. The candidate who has it asks who uses the output, what breaks for them when it is wrong, and what “working” looks like from the customer’s chair.
Probe: “Tell me about a time you changed what you built because of something a user told you.” Listen for a specific user, change, and result. Vague answers — “I always listen to users” — are the absence of the trait, not evidence of it.
Ambiguity tolerance — and the habit of clarifying the ask
Real FDE work starts with a request that is underspecified, partly wrong, or both. The strong candidate treats “I don’t know yet” as a status to resolve, not a failure to hide: they ask clarifying questions, state their assumptions out loud, and check the riskiest one first. The weak candidate guesses silently, builds the wrong thing confidently, and discovers the misunderstanding in the demo. Test it directly: hand the candidate a deliberately vague brief (see section 3) and watch whether they ask questions first. Candidates who dive straight in are showing you how they will behave on a customer site.
Probe: “Here is a one-paragraph request from a customer. What would you ask before you wrote any code?” Count the questions, and notice whether they target the riskiest unknowns.
Technical breadth over depth
An FDE rarely needs the deepest possible knowledge of one layer. They need working knowledge across many: a misbehaving API, a wrong SQL query, a CSV with inconsistent dates, a deployment behind a proxy that blocks egress. The tell is how a candidate debugs across a boundary: when something is wrong, do they check the data before the code, and the contract before the implementation? Depth still matters — but depth in one layer with no ability to move across layers is a bad trade for this role.
Probe: “Walk me through a bug that crossed two systems — your code was right and the data was wrong, or the API was fine and your assumption about it was wrong.” Listen for the investigation, not the fix.
Communication: explaining trade-offs to non-technical humans
An FDE’s work is judged by people who will never read their code. The candidate has to explain what broke, what the options cost, and what they recommend — in language an operations director can act on. Test it in one exercise: at the end of the take-home debrief, ask the candidate to explain their solution as if you ran operations and had never written code. Strong candidates switch registers without condescension; weak candidates drown you in jargon or wave the details away with “don’t worry about it.” Both leave the stakeholder unable to decide.
Probe: “Explain the trade-off you made in this take-home to a customer choosing between the fast fix and the correct fix.” The right answer names the cost of each option and recommends one. The wrong answer pretends there is no trade-off.
Ownership of outcomes in production
The job does not end when the demo works. It ends when the customer confirms the outcome holds — the dashboard right a week later, the pipeline still running after a schema change, the tool actually adopted. Strong candidates talk unprompted about what happened after they shipped: the monitoring they added, the follow-up call, the thing that broke at 2am. Weak candidates’ stories end at the merge.
Probe: “Tell me about something you shipped, and what you did when it broke in production.” Listen for who noticed, how fast, and what changed afterward.
3. The take-home that actually tests the job
The take-home is the most predictive stage you have, and the most commonly wasted one. A good one is a small, fair simulation of the job: a messy brief, incomplete requirements, real data with real defects, and a deliverable a customer would actually receive. One that tests something else — usually raw coding speed — is how you hire Daniel and lose the customer.
Four design rules, as a rule of thumb:
- Make it realistic, not hard. Give the candidate a vague customer ask and a small, genuinely messy dataset — inconsistent date formats, a few duplicate records, a column that changes meaning halfway through. The difficulty should come from the mess and the ambiguity, not an obscure algorithm.
- Time-box it at 3–4 hours. That is enough to scope, build, test, and write up — and short enough to respect the candidate’s time. Longer exercises mostly test who has free evenings, not who is good at the job. Say the time box in the brief, and mean it: stop at four hours and submit what you have, plus a note on what you would do next.
- Require a customer-facing deliverable. Code alone is half the job. Ask for a short write-up — a page, not an essay — for the fictional customer: what you built, what you assumed, what is still uncertain, and what you recommend next. This is the part that predicts stakeholder trust.
- Always debrief it live. A take-home without a debrief is an unread exam. Spend 45 minutes on their decisions: why they scoped it this way, what they cut, what they would do with another day. The debrief is where you learn whether the candidate can reason about trade-offs out loud — the daily work.
Here is the shape of a brief that works — an illustrative example with a fictional customer, not a real engagement:
Illustrative take-home brief (fictional customer)
“You are the FDE assigned to Northwind Retail, a fictional mid-size retailer. Their operations team exports orders from two systems into CSV files, and the files disagree: order counts differ by 40–60 rows a week, some dates are in US format and some in European format, and the SKU column changes meaning between exports. The operations director wants one reliable weekly orders report. Build it from a sample of both exports, and write a one-page summary for the operations director: what you found, what you assumed, and what is still uncertain. Time box: 4 hours. Include a short README noting what you would do with another day.”
Notice what the brief does not specify: the schema, the output format, or the definition of “reliable.” The candidate has to decide those things, state them, and defend them.
| What you see | Strong submission | Weak submission |
|---|---|---|
| Answers the question | Solves the customer’s actual problem — the reliable weekly report — even if the code is unglamorous. | Solves a different problem, or builds impressive machinery around the wrong question. |
| Reasoning visible | Assumptions stated, trade-offs written down, uncertainties flagged rather than hidden. | No README, no notes on judgment calls, or a confident write-up that hides what is unknown. |
| Customer write-up | A non-technical stakeholder could read it and decide next steps. | Missing, or written in jargon the customer would not understand. |
| Scope discipline | Something explicit was cut, with a reason; the four-hour box respected. | Everything attempted, nothing finished — or a 12-hour submission that ignores the time box. |
| Edge cases | Bad rows isolated and counted, not silently dropped; the report says how many were excluded and why. | Messy data quietly filtered out with no mention, or the report silently disagrees with the source files. |
The take-home also shows you how the candidate treats your process. One who asks a clarifying question before starting is demonstrating the trait from section 2 in real time. One who writes “I stopped at four hours, here is what I would do next” is demonstrating scope discipline. Reward both.
4. The interview loop
The loop below is a reasonable default for a first FDE hire. Every stage in it tests something the job actually requires, and no stage tests something it does not. If you add a stage, ask what it selects for; if you cannot answer, cut it.
| Stage | Time | What it actually tests | Who runs it |
|---|---|---|---|
| Recruiter screen | 30 min | Role fit: does the candidate want customer-facing engineering, travel, and ambiguity? | Recruiter |
| Take-home | 3–4 hrs, async | The job in miniature: scoping, messy data, a customer-facing deliverable. | Candidate; graded by hiring manager + one FDE or senior engineer |
| Take-home debrief | 45 min | Reasoning out loud, trade-offs, and explaining the work to a non-engineer. | Hiring manager |
| Customer scenario | 45 min | Live ambiguity: a role-play with an unhappy stakeholder or a vague requirement. See Customer Scenario Interviews for prompts. | Hiring manager + a peer who has done customer work |
| Technical depth | 60 min | Debugging across layers and solid engineering judgment — not puzzle speed. See The FDE Interview Question Bank for questions. | Senior engineer |
| Hiring-manager close | 30 min | Scope, ownership, references, and the sell: what the first 90 days actually look like. | Hiring manager |
A few notes on running it well. Grade the take-home before the debrief, blind to the resume if you can — the work sample should speak before the pedigree does. Second, the customer scenario is the stage most teams skip and most regret skipping: the only live test of a candidate with an unhappy stakeholder and no answer in the code. Third, keep the loop to about a week. A four-week loop does not select better candidates; it selects candidates with no other offers.
5. Red flags
A red flag on its own is not a disqualifier — one flag in an otherwise strong loop is a conversation, not a verdict. But a pattern of them predicts a specific failure on the job, and the table names the prediction so you can weigh it honestly.
| Signal | What it predicts on the job |
|---|---|
| Only talks about code, never about users | Will optimize the wrong thing and ship features nobody asked for. |
| Never asks clarifying questions; guesses silently | Will build the wrong thing confidently and discover it in the demo. |
| Blames the customer for “not knowing what they want” | Will lose stakeholder trust on the first hard engagement. |
| Take-home has no write-up, no trade-offs documented | Will not communicate outcomes; their work stays invisible to the people who fund it. |
| Cannot explain a technical decision in plain language | Stakeholders will not follow their work, and decisions will stall. |
| No story about something breaking in production | Has not owned outcomes — or will not admit to them. |
| “I would just rewrite it” for every legacy question | Will blow up timelines and customer trust by rebuilding what should have been integrated. |
6. What not to do
Do not run a LeetCode-only screen
Algorithm puzzles test a skill the job rarely uses, under conditions the job never creates. As the primary screen they do two kinds of damage: they reject candidates strong at the actual work — debugging messy systems, clarifying vague asks, explaining trade-offs — and pass candidates like Daniel, who can invert a binary tree and cannot tell a customer their numbers are wrong. Use the take-home and the debugging conversation in section 4 instead. They test the engineering the job needs, in the shape the job needs it.
Do not write a unicorn requisition
The classic bad FDE posting asks for one person who is a deep infrastructure engineer, a polished salesperson, and an ML researcher. That person does not exist, and posting for them has two bad outcomes: you hire nobody for six months, or you hire the best resume and discover the gaps on a live customer. Rank the requirements instead. For a first FDE, the ranking is usually: customer judgment and communication first, technical breadth second, depth in your specific stack third. Cut anything outside the top three, or mark it nice-to-have. A posting that describes a real human is a filter: the right candidates recognize themselves in it.
Do not hire on pedigree or certifications
There is no single, widely recognized FDE certification you need for the role — see Is There a Forward Deployed Engineer Certification? What to Build Instead — and a certificate answers “did you study?”, not “can you do the work?” The same applies to pedigree: a famous previous employer tells you where someone has been, not what they delivered there. Score the work sample and the debrief — the only evidence that predicts the job, and available to every candidate regardless of background.
7. A scorecard you can copy
Score each dimension 1–5 after every stage, independently, before the panel discusses. The pattern across stages decides — not any single stage, and not a vibe in the room. As a rule of thumb, a candidate strong on the debrief and the scenario but average on technical depth is usually a better FDE hire than the reverse: depth can be coached, customer judgment much less so.
| Dimension | 1 — weak | 3 — solid | 5 — strong |
|---|---|---|---|
| Customer sense | Customer never mentioned; work described in purely technical terms. | Names the user and what breaks for them; checks the outcome from the customer’s side. | Changed the plan because of something a customer said; can describe the customer’s world. |
| Clarifying the ask | Guesses silently; builds before understanding. | Asks good questions; states assumptions out loud. | Finds the riskiest unknown first and checks it before building. |
| Technical breadth | Stuck outside one layer; cannot debug across a boundary. | Moves across API, data, and deployment; checks data before code. | Diagnoses cross-system failures methodically; knows where their knowledge ends. |
| Communication | Jargon or hand-waving; the stakeholder could not decide from it. | Clear explanation with a recommendation; write-up a non-engineer can follow. | Explains trade-offs with costs attached; stakeholders leave the room able to act. |
| Ownership | Stories end at the merge; no production follow-through. | Followed the fix until it worked; monitored or checked back. | Owned an outcome end to end — incident, fix, and customer conversation. |
After the loop, the hiring manager collects the scores, and the panel discusses disagreements before anyone states a verdict — the discussion is where quiet bias gets caught. If the scores disagree wildly across stages, find out which stage was measuring the wrong thing before you decide. And if the take-home debrief was weak, weigh that heavily: it is the stage closest to the daily work, and candidates rarely improve at it after hiring.
8. FAQs
We are a startup hiring our first FDE — should they be senior?
Customer experience matters more than years. A mid-level engineer who has shipped to real users, handled a production incident, and explained a trade-off to a non-technical stakeholder will usually outperform a senior who has never left the codebase. Judgment under ambiguity comes from exposure, not tenure. If you hire someone earlier in their career, pair them with a senior for the first two deployments.
How much should we pay an FDE?
Price the role at the level of the engineers whose work the FDE unblocks, not below it. The FDE is the person who turns your product into a renewal, and discounting the role because it is not “core product” work attracts candidates who could not get the core-product job. Benchmark against your software engineering bands for the same level, and be honest in the posting about travel and on-call expectations — the compensation conversation goes badly when the day-to-day turns out bigger than the salary suggested.
Can we hire a new graduate as an FDE?
It is possible but risky. New graduates can have strong technical breadth and genuine customer sense — from internships, support roles, freelance work, or side projects with real users. What they usually lack is the scar tissue: the incident at 2am, the stakeholder who changed their mind in the demo, the data that turned out to be wrong. If you hire one, build that experience deliberately: pair them with a senior on the first engagements, debrief every customer interaction, and do not make them the sole owner of a deployment until they have watched one go wrong and helped fix it.
What if a candidate is great technically but weak with customers?
It depends on the shape of the role. If the FDE will be embedded with customers most days, that weakness is a no — the technical strength does not compensate, because the customer-facing work is the job. If the role is mostly internal integration with occasional customer contact, it may be workable, especially if a teammate covers the stakeholder-facing parts. Be honest about which one you are hiring: putting a technically strong, customer-weak engineer into an embedded role and hoping they grow into it is how you get Elena’s first month.
How do we evaluate candidates from non-traditional backgrounds?
Score the work sample, not the resume. The take-home and the debrief are the great equalizer: they show how a candidate thinks, builds, and communicates regardless of where they learned it. Candidates from support or operations often have the strongest customer sense in the pool — they have spent years on the receiving end of bad software. If your process leans on pedigree, you will filter them out before they demonstrate it. Grade blind to the resume where you can, and let the scorecard decide.
Field check — before you post the job
- Write down the day, not the stack: what will this person actually do in their first 90 days, and for which customer?
- Rank the requirements and cut everything outside the top three from the posting.
- Build the take-home before you open applications — a messy brief, a 3–4 hour box, and a customer-facing write-up.
- Decide who grades it and how, and agree on the scorecard before the first submission arrives.
- Rehearse the customer scenario with your own team once, so the interviewers know what “good” looks like before they judge it.
Comments
Post a Comment