Forward Deployed Engineer interview questionsCoding — the customer's export round

Purpose

Sets out the estate in one breath - their system, their vendor, their schedule, a machine of theirs we run on, our index - so that everything the candidate does not control has been named, where each part runs is clear, and nothing has been described as reliable.

Purpose

Makes tools explicitly allowed, so the round reads judgment rather than recall, and warns that the folder will change underneath them so they do not spend minutes doubting their own code.

Purpose

Deliberately open, and the first move is the read. Once they have started, run drop slow so their runner picks up Sunday's export mid-write; once they have handled that, run drop resend. Those two events test the two properties the rest of the hour depends on: the job never reads a file that is still arriving, and a file processed twice leaves the index exactly as it was.

Signals to score

• Treats the arriving file as untrusted input and checks it before anything reaches the index
• Notices the job can start while the file is still being written, and waits for evidence it is complete - a marker file, a rename, a size that has stopped changing - rather than sleeping
• Makes the run idempotent, so the same records processed twice leave the index unchanged
• Records which files have been processed by their content rather than their name
• Makes a failed run safe to repeat - a staging table and a swap, a transaction, or upserts whose replay is harmless - rather than leaving the index half-written
• Decides what a bad row does - skip it, quarantine it, stop the run - and says why for each case
• Asks what the vendor actually guarantees about the export before relying on the specification
• Writes or extends a test for each failure as it appears
• Adds nothing the customer would have to install, operate or pay for to keep it running

Follow-up questions

• The upload was still in progress when your job started. What did your code read?
• The same file has arrived under a new name. What happens to the index?
• The run dies on row two hundred thousand of four hundred thousand. What does a technician see at eight?
• What does "processed" mean in your code?
• What does their IT team have to run for this to work?

Purpose

Contradicts the specification with the data and says nothing about how, so the candidate has to find it.

Purpose

Reads two things at once: whether the code copes with real data from a system nobody on the call can change, and whether the candidate turns a vendor's mistake into a useful conversation with the customer rather than a complaint about them.

Signals to score

• Looks at the bytes before trusting the specification, and identifies the encoding from the data
• Uses a parser that handles quoted line breaks rather than splitting the file on newlines
• Decides what happens to a row that cannot be decoded, and does not drop it silently
• Notices the timestamps carry no time zone, and asks which zone the source system writes in
• Asked about the night the clocks went back, says how two records inside the repeated hour are ordered
• Keeps each file exactly as received, so a later fix can be replayed against it
• Turns each claim in the specification into a check that fails loudly when the data contradicts it
• Takes the mismatch to the customer as information, and asks which they want to be true - the document or the file
• Runs each change against the dropped file before moving on, and leaves a test behind it
• Keeps reading, checking and writing separate enough that each can be tested on its own

Follow-up questions

• How did you find out it was not UTF-8?
• What happens to the note with a line break in it if you read the file line by line?
• Two work orders say 1:30 on the morning the clocks went back. Which came first?
• If the encoding was wrong last week too, how do you repair the index?
• Who at the customer can change the export, and would you ask them to?

Purpose

Moves the problem from fields, which the candidate already controls, to free text, which nobody fully controls. Dropping a column is not available as an answer.

Purpose

The read is whether the candidate treats a data obligation as an engineering problem with a measurable miss rate - and says so to the customer - or as a box to tick. Every honest answer admits that some text will get through; what is scored is what they do about that and what they promise.

Signals to score

• Asks exactly what the obligation covers before deciding what to remove
• Removes the restricted details before the data leaves the customer's environment, not after it reaches ours
• Sends an allowlist of fields rather than removing a list of known-bad ones
• Accepts that numbers and codes inside free text are not caught by dropping fields, and proposes how they will be
• Measures the redaction against real notes and reports a miss rate rather than claiming none
• Accounts for every place the text goes: the index, the logs, error reports, the model provider
• Gives the customer a way to verify what left their environment without having to trust us
• Keeps the redaction in code the customer can read and run themselves
• Says plainly what would make the deployment impossible, if the answer turns out to be that no notes may leave at all

Follow-up questions

• Where does the redaction run - in their environment or in ours?
• A note says the gate code is 4471 and to call the resident on 555-0142 before arriving. What leaves the building?
• What is in your logs right now?
• How would their security lead check you without having to trust you?
• What if the answer is that nothing in the notes may leave?

Purpose

Gives a symptom from the field rather than a bug report, so the candidate has to find the mechanism.

Purpose

Deletions are the failure every ingest pipeline has and almost nobody designs for: a record that disappears from the source never arrives to be removed. The read is whether the candidate finds the mechanism in the export's semantics, and treats a stale answer as a correctness failure with a cost.

Signals to score

• Asks whether each file is a full snapshot or changes only, before diagnosing anything
• Finds that a voided or deleted record either never appears in a changes-only file or appears once as a status, and handles both
• Removes the record from the index rather than only marking it in a local copy
• Proposes reconciling the index against a periodic full export, with counts on both sides
• Asks what else in the index could be stale for the same reason
• Says how they would find the answers the assistant has already given from voided records
• Treats a stale answer as a correctness failure with a cost to the technician, not as cosmetic

Follow-up questions

• Is this morning's file the whole system, or only what changed?
• How would your code ever learn that a work order was voided?
• How many other answers this week came from records that no longer exist?
• How often would you check the index against the source, and how?
• What does the technician need to know when an answer is withdrawn?

Purpose

Changes the audience. Everything so far has been read by engineers; the person who has to act on the run is not one.

Purpose

The last read of the round, and the one that decides whether the system can run without the engineer who built it. The distinction that matters is between a run that failed and a run that succeeded on the wrong data - most monitoring catches the first and not the second.

Signals to score

• Leaves a short run summary with counts: received, added, updated, removed, rejected
• Compares those counts with what is normal, and treats an unusual run as a failure even when nothing errored
• Sends a failure to a named person at the customer, through a channel they already read
• Keeps rejected rows somewhere a person can see them, each with its reason
• Makes a re-run after a fix one safe command that someone else can run
• Writes the summary so that someone who is not an engineer can act on it
• Separates "the run failed" from "the run succeeded on bad data"
• Does not depend on the candidate being reachable

Follow-up questions

• What does the message she gets at six say?
• Sunday's run succeeded on forty thousand rows instead of four hundred thousand. Who finds out?
• Where are the rejected rows, and who looks at them?
• What does her team do when the summary says something is wrong?
• Who does she call if you are at another customer by then?