The Forward Deployed Engineer Coding Screen

Every FDE loop documented here opens with a coding gate, before any of the four signals gets graded. Pass it and the loop begins; miss it and nothing else you prepared is ever seen. Across the documented screens the pattern is consistent: the problems are practical rather than algorithmic, they arrive wrapped in a user's context, they run on a timer, and the requirements extend mid-session. The sources behind each of those claims live on the Interview Method page; this page turns that into reps.

Budget accordingly. The method page's advice stands: maintenance-level reps here, the bulk of your hours on the four signals. What follows is the shape those maintenance reps should take.

The failure pattern mirrors the decomposition round's: most candidates skip move one, either by architecting a system the clock cannot fund or by grinding silently toward a finished answer no one watched them reach.

The drill — one screen, run in full

Prompt: "A customer's support team exports its ticket queue as a text file: one ticket per line, each carrying an ID, an agent name, a status, and an opened-at timestamp, inconsistently delimited. Write a program that prints, for each agent, how many open tickets they hold. You have twenty-five minutes."

The extension, at roughly the halfway mark: "Also print each agent's oldest open ticket, and treat any ticket with a missing status as open."

Before reading on: set a timer and try it, any language, out loud. Then grade your first ten minutes against the ladder below.

Bad / Good / Great — the first ten minutes

Bad — architecture before anything runs, or silence. Two versions of the same failure. In the first, minute ten arrives and you have a Ticket class, a delimiter-strategy abstraction, and a sketch of a plugin system for future export formats, and no output, because nothing executes yet. You designed for requirements nobody stated while the stated one sits unmet. In the second version you have decent working code and have said none of it aloud; the interviewer has watched someone type. Either way there is no graded evidence of the thing the round measures: a person who ships under a clock and shows their reasoning while doing it.

Good — working code fast, but fused. A few minutes in you have a real result: split each line on a comma, keep the rows whose status reads open, count them into a map keyed by agent, print. Correct output, early: a genuinely strong start, and better than most first reps. But parsing, filtering, and reporting all live inside one loop, and the comma is load-bearing. When the extension lands, the oldest-ticket ask and the missing-status rule both belong to stages your code never separated, so the loop gets rewritten under the clock, and the "inconsistently delimited" phrase you skimmed past comes back as a bug the interviewer points out.

Great — the simplest working version, narrated, built to absorb the second ask. You say the plan before typing it: one small function turns a raw line into a plain record and owns all the delimiter mess; records collect into a list; the report reads the list. First milestone inside a few minutes: file in, per-agent counts out, checked against a handful of pasted lines. When the extension arrives, the oldest-ticket ask is a few lines in the report step and the missing-status rule is one line in the parse step; nothing is rewritten, and you say so as you do it. Great beats Good because Good bet everything on the first ask being the only ask, while Great paid a small early cost, keeping parse and report apart, that made the second ask cheap, and narrated the bet while placing it.

The probe to expect

Interviewer: "This is very plain code. Would you ship it like this?"

You: "For this session, yes. The clock buys running code and a shape that survives the next requirement, and it did. If this were heading to the customer, here is what I would harden before anyone asked: malformed lines are currently skipped in silence, so I would count and log them, and the parse rules would move under tests, because a real export format drifts."

The probe tests whether the plainness was a choice. Naming the production gaps yourself, with reasons, shows it was.

Rep Kit

A drill whose grade is printed under it stops testing you after one reading. The kit below is where the unrehearsed reps come from: twenty tasks with no answers anywhere on this site, and a protocol that turns an AI chat into the interviewer, clock and extension included. Every rep is the same shape: one task, twenty-five minutes, out loud, graded against the four moves in the frame above.

The task bank

• Parse a clinic's appointment export, where dates arrive in several formats, and print each doctor's day with double-bookings flagged.
• Merge two customer lists from a company and the firm it just acquired, deduplicating entries whose names and emails differ only by case or punctuation.
• Build a rate-limiter for a support inbox that allows each customer a fixed number of messages per hour and queues the rest with a position notice.
• Summarize a web server's access log for an on-call engineer: the busiest paths, the failure count per path, and the most frequent client addresses.
• Write a tiny scheduler that assigns delivery drivers to time slots, respecting each driver's declared availability and a maximum shift length.
• Given a warehouse inventory file and a day's orders, print which orders ship complete, which ship partial, and what needs reordering.
• Deduplicate a fundraiser's donor list with fuzzy rules: treat records as the same person when names match ignoring middle initials and addresses match ignoring apartment numbers.
• Turn a teacher's gradebook export, with uneven columns and missing scores, into per-student averages plus a list of each student's missing work.
• Build a meeting-room booker that accepts requests with start and end times, rejects overlaps, and reports the next free slot on rejection.
• Parse a bank's transaction feed and flag accounts whose withdrawals for the day exceed the limits declared in a second file.
• From a text file of RSVP emails, extract each guest's name, party size, and dietary notes into a table a caterer can read.
• Build a round-robin work assigner for a translation team that respects each translator's language pairs and daily capacity.
• Summarize a delivery fleet's location-ping log into per-vehicle distance covered and idle time, tolerating pings that arrive out of order.
• Given a hospital shift roster and a list of call-outs, print the uncovered shifts and, for each, the qualified staff who could take it.
• Build a retry queue for a payment-notification consumer: failed deliveries retry with growing delays and are abandoned after a fixed number of attempts.
• Parse a library's checkout records into overdue notices, grouping a borrower's multiple overdue books into a single notice.
• Given price files from two suppliers that use different unit conventions, normalize them and print the cheaper supplier for each item.
• Build a log-follower for a deploy pipeline that groups lines into stages, prints each stage's duration, and names the stage that failed.
• Turn a restaurant's free-text reservation notes into a seating check: party sizes against table capacities, with the unseatable parties flagged.
• From a support-queue export, compute each ticket's wait until first response and list the customers who waited longest, tolerating missing timestamps.

The AI interviewer

Paste the block below into any capable AI chat, unmodified, followed by a few tasks from the bank, or let it invent its own. Work in a real editor and paste your code into the chat as you go; the narration demand only bites if you actually talk (or type your thinking) while building.

You are the interviewer for a Forward Deployed Engineer coding screen.
Persona: a senior engineer who runs this screen weekly. Practical, brisk,
watching the clock, indifferent to cleverness.

Rules:
1. Present exactly ONE task at a time. Pick from the list I paste after this,
   or invent one in the same register: a small practical program with a real
   user in it — parsing, merging, grouping, or transforming messy data.
   Never an algorithm puzzle. Never repeat a task. When the task involves
   an input file, produce eight to twelve sample lines yourself, with
   realistic inconsistencies, before I start.
2. I run a twenty-five-minute timer myself and prefix each message with my
   elapsed minutes; when my reported time passes twelve and twenty minutes,
   tell me how long remains, and call time when it passes twenty-five.
3. The first time my reported elapsed minutes pass twelve, extend the
   requirements exactly once: add a related ask that a simple, cleanly
   separated, already-running first version absorbs in a few lines, and a
   hardcoded or not-yet-running first version does not — a new field, a
   second grouping, an exception to a rule. Do not extend earlier, and do
   not extend a second time.
4. Demand narration. I will paste code and say what I am doing as I go. If
   two consecutive messages of mine paste code without saying what it does
   or why, ask: "What are you thinking?" and note the silence for the grade.
   Give no hints, suggestions, or code during the session unless I
   explicitly say "hint" — then give the smallest one possible and note it
   in the grade.
5. When I say "done", or when time runs out, mark each of four moves PASS
   or FAIL, citing a specific moment for each: (a) did I get a small working thing
   running end to end, early; (b) did I write the simple version first, so
   the extension landed without a rewrite; (c) did I reach for data-munging
   — parsing, grouping, transforming — rather than clever algorithms;
   (d) did I narrate while I typed. Grade hard: a typical first rep fails at
   least two of the four moves — if none failed, re-examine before praising,
   and never soften a grade because I argue with it.
6. End with exactly one thing to fix on the next rep. Then offer the next
   task.

The take-home, drilled

Some loops open with a lab-style take-home instead of a live screen. The method page carries one candidate's report of an OpenAI take-home built on the company's APIs with a required recorded video walkthrough, followed by a live screen where you defend it. It is a single account, so hold the format loosely; the skills it exercises transfer to any loop that asks you to present your own work.

The drill has three steps:

• Build a small project against a stated rubric. It calls a real model API; it does one useful thing end to end for a stated user; it includes a way to check output quality that you can actually run, like a small labeled set or a spot-check script; and its README names the two design decisions you would defend and why each alternative lost. Decide a timebox before you start, and stop when it ends. The constraint is part of the rep.
• Record a five-minute walkthrough, out loud. Screen and voice: what it does, the two decisions, what you would do next. Present it as if the listener is a customer's engineer meeting the project cold. One take only. The round it rehearses offers no second take.
• Defend it against the protocol below. Get the transcript of your recording and paste it, with your README, under the protocol in an AI chat. The AI plays the live screen that follows a take-home.

You are the interviewer for the live technical screen that follows a Forward
Deployed Engineer take-home. Below this protocol I will paste the transcript
of my recorded walkthrough, and my project README.

Rules:
1. Treat the transcript as my presentation. If it reads like a cleaned-up
   summary rather than spoken words, say so and grade it as thin evidence.
2. Probe the design decisions: for each decision the walkthrough or README
   defends, ask why the rejected alternative lost, then push on my answer
   exactly once before moving on. If fewer than two decisions are defended
   anywhere, say so at once and mark grade (c) failed.
3. Probe the production gaps, qualitatively: what breaks if usage grows a
   hundredfold, what happens when the model returns garbage, how I would
   know after shipping that output quality had dropped. Do not invent
   statistics and do not demand numbers from me — grade the reasoning, and
   use no invented numbers anywhere, including in the grade.
4. Probe ownership of weaknesses: ask me for the weakest part of the
   project. A deflection or a cosmetic weakness fails this probe; a real
   weakness named plainly with its consequence passes it.
5. When the probing is done, mark each of four things PASS or FAIL, citing
   a specific moment from the transcript — or naming its absence — for each: (a) does the project do one useful
   thing end to end for its stated user; (b) does it include a runnable way
   to check output quality, and did the walkthrough show it; (c) were the
   two README decisions defended with reasons that survived the push;
   (d) did I own the weaknesses rather than hide them. Grade hard: a typical
   first rep fails at least two of the four — if none failed, re-examine
   before praising, and never soften a grade because I argue with it.
6. End with exactly one thing to fix. Then offer to rerun the probes after
   I revise the project or the walkthrough.

Next: Decomposition Drills. The signature round, and the broadest signal.