Forward deployed engineering fundamentals

A forward deployed engineer is a software engineer who works inside a customer's organisation rather than inside their own, writing production code against that customer's data, systems and constraints. The title originated at Palantir and is now used widely by AI-infrastructure companies. The defining condition is not travel and not customer contact: it is that the engineering happens on someone else's estate, against a problem that has usually not been specified properly, with the customer's own staff as your immediate colleagues. You still ship software, still own its correctness, and still get paged when it breaks. What changes is that almost every input you need — data access, a decision, a person's time, a security exception — belongs to an organisation that does not employ you.

The four customer-facing engineering roles are constantly conflated, and an interviewer will ask because candidates apply for one while describing another.

Role                    Sits         Owns                        Deliverable
----------------------  -----------  --------------------------  ------------------------
Forward deployed        After the    Working software inside     A running system the
engineer                signature    the customer's estate       customer now depends on

Presales / solution     Before the   The technical promise       A proposal, a demo, a
engineer                signature    made to win the deal        scoped POC

Customer success /      After the    Whether the customer gets   Adoption, a renewal,
technical account mgr   signature    value from what exists      an escalation resolved

Delivery consultant     Under a      Scope, hours and the        A signed-off milestone
                        contract     statement of work           against a fixed scope

The column that decides everything is the third. A presales engineer's deliverable is being believed; an FDE's deliverable is something running. That single difference reorders every incentive. Presales optimises for a credible commitment, and it is professionally correct there to leave the hard implementation questions as named assumptions. An FDE inherits those assumptions and finds out which of them were false, which is why the two roles are complementary rather than interchangeable and why a good FDE reads the proposal before the first flight.

The boundary with customer success is subtler and worth stating precisely. A technical account manager debugs an integration to establish whose fault it is; an FDE writes the integration. Both spend their week on a customer's problems, but only one of them merges code. Where the boundary genuinely blurs is a small company with one person doing both, and the right interview question is which artefact the role is measured on.

It means the unit of work is a deployment rather than a ticket. You are assigned to one customer, or a small number, for weeks to months, and your objective is a specific outcome inside their business rather than a backlog item inside your product. Practically that means your development environment is theirs, your data is theirs, your review conversations happen with their engineers, and your definition of done is a process of theirs behaving differently. Physical location varies more than the title suggests — plenty of the work is remote — so treat "forward" as describing organisational position, not geography.

Because the gap between a capable product and a working outcome is often not a feature at all. It is the customer's undocumented data, their idiosyncratic process, their integration surface, and the fact that nobody in the building has yet worked out what the software should do. A feature addresses a problem you can name for many customers at once; an FDE addresses a problem that is still unnamed at one. The commercial logic is that early deployments both earn revenue and generate the specification for the product, which is why this role concentrates at companies whose technology outpaces the market's ability to say what it wants from it.

Two things, and confusing them is the most common way a deployment goes wrong. The first is a running system doing load-bearing work inside a business process, which is what the customer paid for. The second is a specification: the account of what was genuinely hard, which parts were bespoke because the product lacked something, and what should therefore be built once for everybody. Only the first is contractually owed and only the second compounds. An FDE who ships the outcome and returns with no product feedback has done a consultant's job well and left the strategic half of the role undone.

It is product engineering staffed like consulting, and the tension between those two facts is the substance of the job. You are usually a permanent employee of the vendor, paid to advance the vendor's product position, working under the scheduling and access constraints of a consulting engagement. That means you carry a consultant's obligations — someone else's calendar, someone else's change window, a stakeholder who can stop you — while being judged by an engineering organisation on what you shipped and what you learned. Candidates who model it purely as consulting undersell the code; those who model it purely as product engineering underestimate how little of their week they control.

Problems where the difficulty is concentrated in the customer's specifics rather than in the algorithm. A pipeline that must reconcile three systems of record that disagree, a workflow whose rules live only in the heads of six operators, a model that needs data nobody has ever extracted before, a process where the correct output is obvious to a domain expert and impossible to define in writing. What these share is that no amount of remote requirement-gathering resolves them, because the information does not exist in a form that can be sent to you. The poor fit is the opposite: a well-specified integration against documented APIs, which is cheaper to do remotely.

They will all be friendly and they do not want the same thing, which is why a deployment can be simultaneously going well and heading for cancellation.

Stakeholder            Wants                          Can kill the project by
---------------------  -----------------------------  -------------------------------
Executive sponsor      A visible result before the    Losing interest, or leaving
                       next budget cycle

Operating team lead    Their team's day to get        Declining to change the process,
                       easier, not harder             politely and indefinitely

Platform / data team   No new unowned system on       Never granting access, without
                       their estate                   ever refusing it

Security / compliance  A defensible answer if this    Requiring a control that makes
                       is ever audited                the design unworkable

Domain expert          To be right, and to be         Being unavailable, because
                       consulted                      nobody freed their time

Read the third column rather than the second. Only security is likely to say no out loud; the others block by omission, which is far harder to detect and far harder to escalate because nothing has technically been refused. The platform team's row is the one that surprises people: they are not obstructive, they are accountable for an estate that will outlive your deployment, and "another thing nobody owns" is a rational thing for them to resist.

The domain expert's row is where most delivered-but-useless systems come from. A sponsor can authorise a project and cannot supply the rules; the person who can supply them has a day job that was not reduced to make room for you. If nobody has freed that person's time, you have a scoping problem disguised as a scheduling problem, and it is worth raising in week one rather than week six.

Surface it rather than average it, because a design that quietly compromises between two stakeholders satisfies neither and cannot be defended later. The usual shape is a sponsor who wants the process automated and a team who want their existing judgement preserved, and both positions are legitimate. Describe the two options concretely, in terms of what each means for the team's day and for the sponsor's reported outcome, and put the choice in front of the sponsor with the team in the room. Your leverage is not authority; it is that you are the only person who can show both sides what the alternatives cost.

Spend it removing the dependencies you cannot schedule, not writing code. Start the access request, because it has the longest lead time and nothing meaningful happens without it. Find out who can answer domain questions and get recurring time with them before their calendar closes. Read whatever was promised in the sale, so you know which assumptions you have inherited. Ask what the process looks like today, from the person who performs it rather than the person who describes it. Day one produces no commits, and a candidate who describes day one as environment setup has misunderstood where the risk lives.

By narrowing the question until refusing to answer it becomes more expensive than answering.

flowchart TD
    A[Decision needed] --> B{Is there one named<br/>owner for this}
    B -->|Yes| C[Ask directly<br/>with two options and a date]
    B -->|No| D[Write the decision down<br/>as a default you will take]
    D --> E[Circulate it with a<br/>deadline for objection]
    E --> F{Anyone objects}
    F -->|Yes| G[You have found<br/>the real owner]
    F -->|No| H[Proceed on the default<br/>and keep the record]

The move that unlocks this is the fourth box. An open question addressed to a group is answered by nobody, because answering it means accepting responsibility for it. A written default with a date converts the cost of silence: doing nothing now means the thing happens the way you proposed, so anyone who cares is obliged to speak. That is how the owner reveals themselves.

Two cautions come with it. The default must be genuinely reversible and honestly described, because using this device on a decision that cannot be undone is manipulation and will be recognised as such the first time it hurts someone. And the record matters more than the decision, since three months later the question of who agreed to what will resurface, usually in a room where nobody remembers the conversation.

It means the ordinary engineering response — work around it, or push harder — is usually wrong. You cannot escalate through a management chain you are not in, and going over someone's head inside a customer buys one action at the price of every subsequent one. What works is finding what the blocker is actually protecting and addressing that: a platform team blocking a deployment is protecting operability, so offer them the monitoring, the ownership story and the rollback. Where the block is genuinely unreasonable, the escalation route runs through your sponsor and their own management, and it costs sponsor capital that is finite.

Treat the concern as accurate rather than paranoid, because from where they sit an outside engineer building the thing they would have built is a real signal about their standing. The practical answer is to make them a beneficiary rather than a spectator: their name on the design decisions, their review on your pull requests, their knowledge visibly relied upon in front of their own manager. It costs you speed and buys you the only durable route into their systems. The alternative — building quickly around them and handing over at the end — produces a system whose new owner has a reason for it to fail.

Escalate when a blocker is outside your influence and has a date attached, not when you are frustrated. A useful escalation has four parts: what is blocked, what it costs and by when, what you have already tried, and the specific decision or intervention you are asking for. The failure mode is the status-shaped escalation that reports difficulty without naming an ask, which invites sympathy and produces nothing. The other failure mode is escalating too late, once the deadline has already gone, because by then the only available responses are expensive ones and your own management has lost the chance to help cheaply.

Refuse to design anything until you have watched the process being performed. Ask to sit with the people who handle claims for a morning, and record what actually happens: where a claim waits, who touches it, which decisions are judgement and which are lookup, and where the current process produces errors that someone downstream fixes. What emerges is almost never the problem as stated. "We want AI in claims" typically resolves into a specific queue that sits for three days because nobody owns triage, which is a narrower and far more tractable problem. Naming that narrower problem in the customer's own words is the first real deliverable.

Something a named person uses to do real work, in production, without you present. That definition excludes most of what gets called a milestone. A pipeline that runs but whose output nobody consumes is not an increment; neither is a model with good offline metrics and no path into the workflow. The test is whether switching it off would be noticed by someone outside the project. Insisting on that bar is unpopular early, because it makes the first increment smaller than the sponsor expected, and it is the single strongest predictor of whether the deployment is still alive in six months.

The compression happens by repeatedly removing everything that is not on the path to one person's changed behaviour.

flowchart TD
    A[Stated problem<br/>too vague to build] --> B[Observe the process<br/>as performed today]
    B --> C[Name one decision<br/>or step that is slow]
    C --> D[Find the smallest output<br/>that would change it]
    D --> E{Can one named person<br/>use it in two weeks}
    E -->|No| F[Cut scope, not quality<br/>and return to D]
    E -->|Yes| G[Build it and record<br/>the baseline first]

The loop between the fourth and fifth boxes is the whole technique, and the label on the cut matters: scope, not quality. Deployments are routinely rescued by narrowing to one region, one product line, one queue or one user, and routinely ruined by keeping the breadth and dropping the correctness, because a broad system that is wrong teaches the organisation to distrust it permanently.

The step candidates skip is the last one. A baseline recorded after you have started is not a baseline, and without one you will be unable to demonstrate the improvement you actually delivered. It takes an afternoon to capture how long the step currently takes and how often it goes wrong, and it is the difference between a renewal conversation based on evidence and one based on impressions.

By ranking candidate work against the one outcome you agreed, then declining everything that does not move it in this increment — and saying so explicitly rather than letting it sit unmentioned in a backlog. The two things worth deliberately not building are the general case of a specific need, and the request that arrived from someone who is not the person whose behaviour has to change. Both feel productive and neither reaches the outcome. Writing the not-doing list down is what makes this survivable, because the alternative is a conversation in month three about a promise nobody remembers making.

It is the one-page document that makes an ambiguous engagement arguable before it is expensive.

SCOPING NOTE - claims triage, increment 1

The outcome we are aiming at
  The motor claims triage queue is cleared same-day by the existing
  team of four, instead of averaging three days.

Who changes their behaviour
  Priya's triage team. They stop reading every claim in arrival order
  and start working a ranked list.

Baseline recorded on 4 August
  Mean age in queue at pickup: 3.1 days over the last 60 days.
  Manual re-prioritisations per week: about 40, by one person.

In scope for this increment
  Ranking model over the existing claims extract; a ranked view in
  the tool the team already uses.

Explicitly NOT in this increment
  Automatic decisioning. Household claims. The 2019 archive.
  Anything requiring write access to the policy system.

Assumptions, each with an owner
  The nightly extract lands by 06:00           - Dev, platform team
  Priya's team can work a ranked list          - Priya
  Read access to claims_detail by 8 August     - Sanjay, security

What we will know at the end
  Whether ranking changes queue age at all. If it does not, the
  bottleneck is ownership rather than prioritisation.

The two sections that earn their place are the exclusions and the assumptions, and they do different work. Exclusions prevent the quiet reinterpretation at the end, where a sponsor recalls a broader promise and you cannot prove otherwise. Assumptions with named owners convert your risks into other people's commitments, which is the only mechanism that makes an ambiguous engagement fair to you.

The final section is the one experienced FDEs insist on. Framing the increment as a question the business does not yet know the answer to makes a negative result a legitimate outcome rather than a failure, and it is honest: sometimes ranking does not help, and finding that out in two weeks is worth more than a quarter spent proving it slowly.

Accept it warmly, write it down, and put it where the sponsor can see it — never refuse it on the spot and never absorb it silently. Both instincts are damaging: refusing costs you a relationship for something that may be trivially small, and absorbing it means your increment quietly grows while your date does not. The mechanism is a visible list of requests with what each would cost and what it would displace, reviewed with the sponsor. That turns a stream of individual asks into a single prioritisation conversation with the one person entitled to have it.

Say so early, with evidence, and with an alternative. This happens often, because the problem was specified by people who could not see the process closely, and discovering it is a large part of the value of being embedded. What makes the conversation survivable is arriving with an observation rather than a judgement: describe what you watched happen, show the number that contradicts the original premise, and propose the narrower problem you now believe is real. What loses the room is announcing that the project is misconceived without offering the version of it that is not, since your sponsor has already spent credibility to fund this.

Profile it rather than read it, because the documentation is either absent or wrong and the data is the only account of itself that exists.

-- Cardinality and nullability first: it tells you which columns are real
select count(*)                                    as rows,
       count(distinct claim_ref)                   as distinct_refs,
       count(*) - count(status_code)               as status_nulls,
       count(distinct status_code)                 as status_values,
       min(created_at), max(created_at)
from claims_detail;

-- Then the actual domain of the column you were told was an enum
select status_code, count(*) as n
from claims_detail
group by status_code
order by n desc;

-- Then whether the join you were promised actually holds
select count(*) as orphans
from claims_detail c
left join policy p on p.policy_ref = c.policy_ref
where p.policy_ref is null;

The first query answers whether the key is a key. If distinct_refs is lower than rows, the column you were told identifies a claim identifies something else — a claim version, a line item, or a re-keyed record after a migration — and every count you build on it will be wrong in a way that is invisible until someone in the business notices a total they recognise is too high.

The second query is where documentation dies. A status column described as having five values routinely has forty, including case variants, trailing spaces, codes from a system decommissioned in 2014, and a handful used by one regional team for something else entirely. The long tail is small by row count and disproportionately represented in exactly the problem cases you were sent to fix.

The third is the one to run before agreeing to any design that spans two systems. Orphan rates are the cheapest possible measurement of how much the customer's systems actually agree with each other, and a non-trivial orphan rate is a scoping fact, not a data-quality footnote.

The four per cent is information about the business, not an error to clean, and the work is finding out what it means before deciding anything.

Reported: "underwriter_id is always populated."
Observed: 41,802 of 1,044,000 rows are null - 4.0%

Nulls by year                Nulls by channel
  2019   0.2%                  broker     0.1%
  2020   0.4%                  direct     0.3%
  2024  11.7%                  partner   38.6%
  2025  12.1%

Asked the domain expert about the partner channel:
  Partner claims are auto-accepted below a threshold and never
  reach an underwriter. There is no missing value - the event
  did not happen.

The distribution is what turns a data-quality complaint into a domain discovery. Nulls spread evenly across every dimension usually mean a defect: a broken feed, a column added later, a bad migration. Nulls concentrated in one channel and one period almost always mean a real business rule that nobody thought to mention, because to the people inside it, it is not a rule, it is just how partner claims work.

That distinction changes the design. Imputing a value here would have been actively harmful, inventing an underwriter for claims no underwriter saw, and any model trained on it would have learned to predict the channel. The correct handling is to represent the absence explicitly and to exclude those rows from anything that assumes an underwriting decision took place.

The general lesson is worth carrying into interviews. When the data disagrees with what you were told, the data is describing something true and your informant is describing what they believe to be normal. Both are useful. Cut the distribution by every dimension you have before you raise it, because arriving with "your data is wrong" is a bad conversation and arriving with "partner claims behave differently, is that expected" is a good one.

You build one from what you are permitted to have, and you make the absence explicit rather than working around it silently. In practice that means an extract or snapshot of production data held wherever the customer's rules allow, a local environment that reproduces the schema and the awkward parts of the distribution, and a strict discipline that anything touching production is read-only until a change has been reviewed by someone who owns the system. It is worth pricing the risk out loud to your sponsor, because "there is no test environment" is a fact that belongs in the scoping note, and the cost of it will otherwise be attributed to you.

Frequently yes, and it is a better starting position than it sounds. Read access lets you profile, reconcile, build and validate the entire analytical path, and produce output somewhere you control — which is enough for most first increments, since the first increment usually informs a human decision rather than writing back into a system of record. What it does not let you do is close the loop, so plan for a write path as a separate negotiation with its own lead time. The mistake is treating read-only as a blocker and waiting; the second mistake is designing for write access you have merely been promised.

Reconcile before you build, and treat the disagreement as a fact about the business rather than a bug to be fixed.

Same claim, two systems of record

                      Policy system      Claims platform
  claim reference     CLM-0093412        93412
  status              SETTLED            IN_REVIEW
  settled amount      4,820.00           4,820.00
  last updated        2025-11-04 22:10   2025-11-05 09:02

Reconciliation over 30 days of overlap
  matched on both key and status              91.4%
  key matched, status differs                  7.9%
  no counterpart in the policy system          0.7%

Of the 7.9%: 96% resolve within one working day.

Three separate problems are visible here and they need separating. The key formats differ, which is a mapping question and the easy one. The statuses differ, which is usually not corruption but latency — one system leads and the other catches up overnight, so a comparison taken at a point in time will always show a fraction in disagreement. And a small population exists in one system only, which is the genuinely interesting group.

The reconciliation figures are what let you make a design decision rather than a guess. If most disagreements resolve within a day, you have a system of record and a follower, and the correct answer is to name which is authoritative for each field and read that one. If they did not converge, you would have two authorities and a business problem no pipeline can fix.

Do not skip the 0.7 per cent. Records that exist in one system and not the other are usually where the money, the complaints or the regulatory exposure sit, and they are always the ones the domain expert already knows about and finds unremarkable.

It is the record of what each field means, as established by profiling and by asking, kept in the repository next to the code that consumes it. It matters because you will otherwise re-learn the same facts at increasing cost: which column is truly the key, which enum values are historical, which timestamp is local and which is UTC, that a particular code means the record was migrated in 2018 and is unreliable. It is also the highest-value handover artefact you produce, because it is the knowledge that exists nowhere else and cannot be reconstructed from the customer's own systems.

Make lateness and incompleteness first-class rather than exceptional, because they will happen and the alternative is silent wrongness. That means a check on arrival that the file is complete on its own terms — a row count, a control total, a date range that matches what was requested — and a pipeline that refuses to run rather than processing half a day. Publish freshness alongside every output so a consumer can see what the answer is based on. The failure mode to avoid is a dashboard that quietly shows yesterday's numbers as today's, since the business will make a decision on it and the trust cost is much greater than a visible outage.

That the values are accurate and the granularity, timeliness or coverage make them unable to answer the question. A claims table that is correct as of last midnight cannot support a decision that has to be made within the hour. A field that is populated accurately only after a case closes cannot be a feature in a model that runs at intake, because at prediction time it does not exist. Checking that every input would genuinely be available at the moment the decision is taken is a discipline candidates skip, and it is how deployments end up with excellent offline results and no usable production path.

It means someone else can operate, change and be accountable for the system after you leave, which is a much higher bar than having documented it. The test is not whether a document exists but whether a named person has performed the operational tasks themselves at least once while you watched, and whether they have the access, the ownership and the mandate to do so when you are gone. Handover fails in a predictable way: a system that works, a wiki page nobody has read, and no owner — after which the first unexplained failure results in the thing being quietly abandoned and the deployment counted as a success in your own company's records.

Six artefacts, and the list is short because everything on it is load-bearing.

HANDOVER SET

1. The code, in the customer's own repository and CI, not yours.
   If it builds only on your laptop, it dies with your laptop.

2. The data dictionary. What each field means, which values are
   historical, which timestamp is UTC, which key is really a key.

3. A runbook of the four things that will actually go wrong:
   extract did not arrive, extract arrived malformed, output looks
   wrong, credentials expired. Each with a check and a first action.

4. Monitoring the new owner receives, not monitoring you receive.
   Freshness, volume against expectation, and one business-level
   check the owner would recognise as wrong.

5. The decision log. Every choice that has a reason not visible in
   the code, especially the ones where the obvious option was
   rejected for a reason specific to this customer.

6. A named owner who has run items 3 and 4 themselves, with you
   watching and not typing.

TEST OF THE SET
  The new owner handles one real incident while you are present
  but silent. If you have to intervene, the handover is not done.

Item six is the one that is always missing, and it is the only one that is not a document. Everything else can be produced by an engineer alone in the last week, which is exactly why it usually is, and why the set as a whole so often fails to transfer anything.

The test at the bottom is what converts the list from good practice into something verifiable. A handover is an event that has either happened or not, and the evidence is that someone else recovered a real failure while you sat on your hands. Plan the schedule so that at least one genuine incident falls inside your remaining time rather than after it.

Ask whether the need is specific to this customer's circumstances or to their situation. A mapping from their particular legacy status codes is specific to them and belongs in bespoke configuration. The fact that legacy status codes need mapping at all is common to every customer of that kind and belongs in the product. The judgement is genuinely hard and getting it wrong is expensive in both directions: bespoke code that should have been product means the next deployment repeats the work, and product features built from one customer's shape mean a platform contorted by an unrepresentative sample of one.

Each transition depends on someone who is not you, which is why deployments stall in states rather than at tasks.

flowchart TD
    A[Access granted<br/>and data profiled] --> B[Increment agreed<br/>with baseline recorded]
    B --> C[Running in production<br/>on real data]
    C --> D[One named team<br/>using it for real work]
    D --> E[Owner operates it<br/>and handles an incident]
    E --> F[Old process<br/>switched off]

The transition to look at is the last one. Until the old process is switched off, the customer is running both, which means you have added work rather than removed it and the measured benefit is close to zero. Parallel running is the most polite form of failure in this discipline: nobody objects, nothing is cancelled, and no value is realised.

The other lesson is that these are states, not phases, and a deployment can sit in the fourth one indefinitely. A team using something for real work is a genuine achievement and is not a finish line, because a system with users and no owner has a life expectancy measured in the tenure of whoever currently tolerates it.

Write it against the failures you have actually seen, in the order of likelihood, and make every step something a person can perform rather than understand. That means the exact command or screen, the expected output, and what to do when the output differs — not a description of the architecture. Test it by having the new owner follow it while you say nothing, which reliably exposes the three steps that only work because you know something you did not write down. Keep it short: a runbook covering four real failures gets read, and a thirty-page operations manual gets skimmed once and never opened again.

Documentation is an artefact; handover is a transfer of accountability, and only the second changes what happens when something breaks at three in the morning. You can produce complete documentation and hand over nothing, which is the usual outcome, because writing is under your control and the transfer is not — it requires another team to accept ownership, which requires their management to allocate capacity, which requires a conversation with your sponsor that most engineers do not think is theirs to start. Treat the ownership conversation as a deliverable with a date, and start it at the beginning of the engagement rather than the end.

Name the real question, which is whether the deployment has an owner. A customer asking for you to stay is usually telling you that handover has not happened, and the answer is to convert the request into a specific, bounded piece of transition work with an end date, not to extend indefinitely and not to leave on schedule and hope. Escalate it as a resourcing decision with the reason attached: the system is in production, nobody has accepted ownership, and here is what it would take. Being permanently attached to one customer is how an FDE stops being an engineer at their own company and becomes staff at somebody else's.

Ask for the narrowest thing that unblocks profiling — read access to the specific tables or extracts you need — and ask for it in writing on day one, because the request is a process with a queue and not a favour. Do not ask for broad production access, do not ask for anything with write capability before you need it, and do not ask for a personal exception to a control. Each of those converts a routine request into a security review, which is the difference between days and weeks. Justify each item by the question it answers, because a request that names its purpose is far easier for a security team to approve.

Longer than any plan assumes, and the delay is structural rather than obstructive.

Typical enterprise access path for an external engineer

  Sponsor raises the request                        day 0
  Security review of the vendor and the purpose     days 1-10
  Data owner approval for the specific tables       days 3-15
  Identity provisioning and device requirements     days 5-20
  Network route, VPN or jump host                   days 5-25
  First successful query                            day 25 or later

  Each row depends on a different team, none of
  which is measured on your timeline.

The rows are parallel, not sequential, which is the planning insight. Every one of them can be started on day zero, and the reason access commonly takes two months rather than three weeks is that they are discovered one at a time — device requirements surface only after identity provisioning completes, and the network route is raised only once someone has credentials to use it.

The practical consequence for scoping is that the first two or three weeks of an engagement cannot contain data work, so they should be filled with the things that need no access: observing the process, extracting domain rules, agreeing the increment, recording the baseline. A deployment plan that assumes a query on day three has already lost a fortnight, and a candidate who describes access as an administrative detail is signalling that they have not done this before.

Take the computation to the data instead of the data to the computation, and establish the rule precisely before designing anything. In practice that means working inside their environment — their notebooks, their compute, their repository — and being careful about the incidental leaks: screenshots in tickets, sample rows pasted into a chat with your own colleagues, a laptop copy taken for convenience over a weekend. What you can usually take out is aggregate and structural information, which is often enough to get help from your own team. Ask what class the data is in and who decides, and write the answer in the scoping note.

By generating a synthetic reproduction from the shape rather than the content. Profile the awkward distribution — the null rate, the duplicate keys, the encoding oddity, the out-of-range dates — then construct a local dataset that has those properties and none of the real values. That gets your own team, and your own tooling, working on the actual defect without moving a single customer record. Where the fault genuinely depends on real data, do the work in their environment with tighter logging and take out only the derived facts. Being able to describe this technique cleanly is a common differentiator in an FDE interview.

It is the contract that governs what the vendor may do with the customer's data: for what purpose, in which jurisdictions, with which sub-processors, and for how long. It constrains architecture directly, because it decides whether you may send data to a service in another region, whether you may use a third-party API in the pipeline, whether you may retain anything for debugging, and whether logs containing personal data may leave the estate. Reading it before designing saves rework that is otherwise discovered late and cheerfully by a compliance officer, and knowing that it is the document to ask for is itself a signal of experience.

Use whatever the customer already has, rather than introducing a mechanism they will not maintain. If they run a secret manager, your service reads from it; if they run configuration through their deployment pipeline, you use that. What matters is that no credential lives in your repository, your laptop, your notebook or a message to a colleague, and that every credential you were issued is revocable and attributable to you rather than shared. Also plan for expiry, because a certificate or token that lapses two months after you leave is the classic way a handed-over deployment dies without anyone understanding why.

Treat the refusal as a constraint on the design rather than an obstacle to be routed around, and find out what they were protecting. A refusal is usually specific — no outbound network from that segment, no personal data in logs, no external identity — and there is often a compliant construction that meets the same need, such as processing inside their boundary and exporting aggregates. Where genuinely no compliant design exists, that is a scoping fact for the sponsor to decide on, not a problem for you to solve quietly. Never proceed on an informal exception offered verbally; if it is not written down, it will not exist during an audit.

A business process measurably different, a named owner accountable for the system, and the old way switched off. All three are necessary, and the third is the one that is most often missing. Success is not the system being live, not the customer being pleased, and not the internal report saying delivered, because each of those is compatible with nothing having changed. The way to make this concrete is to agree, at the start, the one number that will be different and the date it will be checked, and to record its current value before writing any code.

Because after you have built something, nobody can establish what it changed.

Recorded before any code was written, 4 August

  Mean age of a claim in the triage queue at pickup   3.1 days
  Claims triaged per person per day                   18
  Manual re-prioritisations per week                  about 40
  Complaints citing delay, last quarter               212

Measured eight weeks later, same definitions

  Mean age at pickup                                  0.7 days
  Claims triaged per person per day                   24
  Manual re-prioritisations per week                  under 5
  Complaints citing delay, this quarter               168

Reported honestly
  Queue age and re-prioritisation are attributable.
  The complaint figure is not: a second team was added
  in September and the quarter is not comparable.

The value of the baseline is not the improvement, it is the attribution. Four numbers moved and only three of them belong to you, and saying which is which is what makes the other three believable. A report claiming all four is the sort of thing a sceptical finance director discounts entirely, which costs you the credit you had genuinely earned.

Note that the definitions are held constant. The most common way a benefit claim collapses under scrutiny is a definition that changed between the two measurements — a different date filter, a different population, a different meaning of triaged — and once a customer's own analyst finds that, no further numbers from you are trusted.

Any number that grows with your activity rather than with the customer's outcome: rows processed, pipelines built, models trained, dashboards published, logins. Each is measurable, each is entirely within your control, and none of them would be missed if it stopped. They are seductive precisely because they are available early and move quickly, while the outcome number moves late and slowly. The correct use of activity metrics is diagnostic — if usage is flat, logins tell you whether people are even arriving — and the incorrect use is reporting them to a sponsor as progress, which trains them to discount everything you report.

Usage is that the system is being touched; adoption is that a process depends on it. The distinguishing question is what would happen if it were switched off for a week: if the answer is that a team would be blocked and someone would complain, that is adoption, and if the answer is that a report would go unread, that is usage. This matters because the two look identical in telemetry and diverge completely at renewal. A deployment with high usage and no dependency is one reorganisation away from disappearing, and the intervention is not more enablement but finding out what the team still does the old way, and why.

A pilot that worked shows the approach produces value in one place. A pilot that will scale additionally shows that the parts which made it work are not the ones that cannot be repeated. The things that quietly do not scale are an unusually cooperative team, a domain expert who answered questions within minutes, manual data preparation someone did each morning, and your own presence covering the operational gaps. Assessing scalability honestly means listing what you personally did that nobody will do next time, which is uncomfortable and is the difference between a second deployment that goes well and one that reveals the first was a bespoke rescue.

The sponsor signs, and what they should be signing is the specific outcome statement agreed at the start, checked against a number, rather than a statement that work was delivered. Getting that distinction right at the beginning is what makes the end of the engagement clean, because a sign-off against deliverables can be true while the process is unchanged, and a sign-off against an outcome cannot. It also protects you in the other direction: where the outcome was not reached for reasons in the assumptions list, the record shows which assumption failed and who owned it, which is a very different conversation from an unqualified failure.

By being delivered. The system runs, the report says complete, the sponsor is satisfied, your own company records a successful engagement, and the team carries on doing the work the old way because the new path is slightly less convenient than the spreadsheet they already trust. Nothing is escalated because nothing is broken. Six months later the licence is not renewed and the stated reason is budget. The only defence is the three-part definition of success — measured change, named owner, old process off — applied honestly while you are still there and able to do something about it.

Expect a hybrid of an engineering loop and a consulting one. There will be genuine coding, because the role writes production software and companies have learned not to skip it. There will be a data exercise, often deliberately messy, where the scoring is as much about what you notice as what you build. There will be an ambiguity or scoping round, where a vague business problem is described and you are assessed on the questions you ask. And there will be stakeholder scenarios: a sponsor who wants something different from the team, a blocked access request, a request to stay longer. Prepare for all four separately.

Whether you narrow before you build. The interviewer describes something under-specified and watches whether you start designing or start establishing what the actual decision is, who takes it today, and what the smallest useful output would be. They are also watching whether you can commit: candidates who ask questions indefinitely score no better than those who build immediately, because the required behaviour is to gather enough, state your assumptions explicitly, and propose something concrete with a boundary around it. Saying what you would deliberately exclude is the strongest single signal available in this round and the one most often omitted.

With a specific instance, and with the mechanism by which you discovered it.

Situation   We were asked to rank a claims triage queue. The premise
            was that the team could not tell which claims mattered.

Discovery   In two mornings sitting with the team, ranking was not
            the constraint. They already knew which claims mattered.
            Nothing moved because no one owned reassignment, so
            claims waited for the original handler to return.

Evidence    Queue age for claims whose handler was on leave was 6.4
            days against 1.9 for the rest, on 60 days of data.

Action      Took the number to the sponsor with two options: build
            ranking as commissioned, or build reassignment first and
            ranking second. Named the risk in ranking alone.

Outcome     Reassignment shipped in three weeks and queue age fell.
            Ranking shipped after and added less than expected,
            which the sponsor had by then agreed was likely.

What I would do differently
            Sat with the team in week one rather than week three.
            I built a data model first because that felt like
            progress, and it was the wrong two weeks.

The load-bearing part is the evidence line. Every candidate has a story about wrong requirements, and almost all of them consist of an assertion that the candidate knew better. A number that contradicted the premise converts the same story from opinion into observation, and it is what the interviewer is listening for.

The second thing being scored is the action. Notice that the sponsor made the decision and was given a real choice rather than being told the project was misconceived, which is what makes this a story about working inside an organisation instead of around it. The closing admission does more work than it appears to, because a candidate who can name the two weeks they wasted is a candidate whose other claims become credible.

Ordinary engineering competence, with two specific additions. The first is whether you handle real-world data defensively: malformed rows, unexpected nulls, duplicate keys, encodings, timezones. Code that assumes clean input is the single most common way a strong candidate loses this round, because it is the exact failure the job consists of avoiding. The second is whether you can explain what you wrote to someone non-technical, since you will be doing that weekly in front of a customer. Speed matters less than usual, and clarity under interruption matters more, so expect to be interrupted mid-implementation on purpose.

Directly, with the mechanism named and your own part in it stated without either self-flagellation or blame. A useful answer identifies the specific failure — no owner accepted the system, the old process was never switched off, the sponsor left and the business case died with them — and then says what you would now do earlier. What damages a candidate is a failure story whose entire cause sits outside them, because everyone senior in this field has failed deployments and knows that the causes are usually visible in week two if anyone is looking. The recoverable version of the story is one where you learned to look.

Ask the questions whose answers change whether the job is doable. How long does customer access typically take, and who owns unblocking it. Who decides scope when the customer asks for something outside it. What proportion of the work becomes product, and what mechanism carries it there. What happens when a deployment has no owner at the end and the customer wants you to stay. And how travel and time zones actually work in practice rather than in the advert. These questions signal experience precisely because they are the constraints an FDE lives inside, and a company that answers them vaguely is telling you something.

A strong answer treats this as the most valuable information received so far and establishes which of three things it means: the output does not fit how the work is done, the team was not consulted and objects to the process rather than the product, or this person wants the project to fail. None can be distinguished from the statement itself, so the first move is to sit with the people who do the work and watch them. A strong answer also brings the sponsor in early with what was learned and a proposed change of course, because the sponsor funded a premise that has just been challenged and finding out in week three is a gift compared with month six. It names the assumption in the scoping note that this contradicts, which makes the conversation a review rather than an argument. A weak answer either dismisses the objection as resistance to change and continues building, or accepts it wholesale and stops, and both are the same error: treating one stakeholder's statement as the whole truth instead of as a hypothesis to check against the process itself.