Forward deployed engineer skills: the real requirements
The technical floor for this role is a working software engineer who can build and ship something end to end without supervision: Python, SQL, APIs, enough infrastructure to get a service running in an environment you do not control, and enough understanding of model behaviour to diagnose why a system is confidently wrong. That floor is high, and it is also not what decides who gets hired, because everyone who reaches an interview has cleared it. The decision is made on four things that are harder to name and much harder to teach: hearing what a customer means rather than what they said, staying useful when the problem turns out not to be technical, knowing what not to build, and being willing to do unglamorous work that sits directly next to work requiring real depth. People leave this role over the fourth one more often than over any of the others.
The technical floor, stated plainly
Python and SQL do most of the work. Python because the surrounding ecosystem is written in it and because a customer’s data team will already have it. SQL because a large share of deployment work is joining records across systems that disagree about what a record is, and because the person who can write the query themselves at eleven at night is not blocked.
Beyond those, the requirement is breadth rather than depth, and it is genuinely unusual. You inherit whatever the customer has: an authentication scheme from 2016, a message queue nobody maintains, a data warehouse in a product you have never used. Nobody can prepare for the specific instance. What can be prepared is the habit of getting productive in an unfamiliar system quickly, which is a real skill and is mostly practice.
On the model side, what is needed is diagnostic. Why does retrieval return the wrong passage for this class of query. Why is the system fluent and wrong on exactly the cases the customer cares about. Why does it degrade when the document is a scan rather than a file. Being able to answer these is the job; being able to train a model is not, and candidates consistently over-prepare for the second because it feels more like a credential.
The four that actually decide
Hearing the real problem. Customers describe problems in their own vocabulary, having already simplified them for you, usually in good faith. The stated problem and the real one differ most of the time. The skill is a specific technique as much as a disposition: ask to see the last five times they did the thing rather than asking how they do it. Descriptions are idealised, examples contain the exceptions, and the exceptions are the project.
Staying useful when it is not a technical problem. A substantial share of deployments stall on something no engineering effort can resolve: an approval queue, a team whose bonus depends on the old process, a sponsor who has moved on. Engineers who treat this as outside their remit become blocked and stay blocked. The ones who do well find the smallest thing that can still move while the obstruction resolves, and keep the project alive through a month where nothing was possible.
Knowing what not to build. The most valuable judgement in the role, and the hardest to evidence, because success looks like a project that finished rather than an artefact anyone can point at. Every deployment contains three or four things the customer asked for that will not change anything. Building all of them is how a six-week project becomes a six-month one. Refusing well, so that the customer feels heard rather than overruled, is the actual skill.
Tolerance for the unglamorous. The job contains a great deal of work a strong product engineer would consider beneath their level, sitting directly next to work requiring genuine depth. Cleaning an export by hand because it will take two hours and the proper pipeline would take two weeks. Sitting through a meeting to hear one sentence. Someone who needs the whole job to be interesting will be unhappy, and this is the most common reason people leave the role rather than the travel.
Three things employers ask for that matter less than they look
Deep expertise in one specific stack. Postings list the technologies the current accounts happen to use. By the time you are productive, the accounts will have changed. Hiring managers know this and weigh it accordingly, whatever the posting says.
Prior experience with the exact industry. It helps, genuinely, and it is not the constraint people think. Domain knowledge can be acquired in weeks by someone who is interested. Interest cannot be acquired at all, which is why the question worth preparing for is not whether you know the industry but whether you find it interesting enough to learn.
Certifications. A cloud certification is not negative and is rarely decisive. It demonstrates that you learned something structured, which in a role this unstructured is a weak signal. The strong signal is having shipped something into somebody else’s environment and being able to describe what went wrong.
What to build if you want to demonstrate this
The portfolio that works for this role is different from the one that works for product engineering, and the difference is instructive. A clean, well-architected side project demonstrates the wrong thing. What demonstrates the right thing is a messy integration between two systems that were not designed to talk to each other, with a written account of the three things that turned out not to work as documented.
The write-up matters more than the code. An engineer who can explain why the field named `status` contained four values that no one could account for, and what they did about it, is demonstrating the exact judgement the role is hired for. An engineer with a beautiful repository and no story about anything going wrong has demonstrated that they have not yet worked in these conditions.
