Practical coding & data
Clean, tested code for messy real-world data, written while you explain your thinking.
Roadmap: Engineering baseline, Interview readiness & senior judgment
Why it matters
FDE coding rounds look less like puzzle contests and more like a day at a customer site: parse this export, reconcile these records, make this paginator survive a flaky API, fix this bug in code you've never seen. Interviewers grade clear contracts, edge cases, tests and how well you talk through your thinking more than clever tricks.
What it's made of
- Parsing JSON, CSV and logs defensively
- Hash maps, sets and sliding windows for dedup, joins and quotas
- Queues and state machines for job lifecycles
- Pagination, cursors, retries and rate limiting
- Caching (LRU, TTL) and idempotency registries
- SQL: joins, CTEs and window functions
- Tests first: edge cases, injected clocks, hand-traced examples
- Reading and safely changing unfamiliar code
A time budget that works
For a 30-minute practical problem:
- ~3 min: clarify inputs, outputs, errors and constraints. Ask about scale.
- ~4 min: walk through two examples and outline your approach out loud.
- ~15 min: write the code, narrating key decisions.
- ~5 min: trace three test cases by hand, including an edge case.
- ~3 min: complexity, and how you'd harden it for production.
The pattern families to drill
Most FDE coding problems are variations on a handful of themes:
- Parsing and normalising messy input (configs, logs, exports).
- Reconciliation and dedup with hash maps.
- Rate limits and quotas with sliding windows.
- Cursor pagination with retries and loop protection.
- Idempotent event processing (webhooks arriving twice or out of order).
- Caches with eviction and expiry.
- Dependency graphs and topological order.
- Debugging a small, broken module and proving the fix with tests.
Debugging rounds: reproduce, then fix
When handed broken code, resist rewriting it. State what the code is supposed to guarantee, rank your hypotheses, write a failing test that reproduces each bug, make the smallest fix that passes, and keep the test. If you're shown an AI-suggested patch, check it as carefully as a colleague's: plausible-looking is not the same as correct.
Mid-level looks like
Writes correct, readable code with tests for the main cases.
Senior looks like
States invariants up front, compares approaches, traces tests by hand, and extends the design for scale or concurrency without breaking its contract.
Common pitfalls
- A correct solution delivered in silence. Talking through it is part of the score.
- Ignoring empty, malformed or duplicate input.
- Mutating inputs, or depending on dictionary order for output.
- Rewriting a whole module when a two-line fix and a test would do.
Practice drills
Drill 1
Reconcile invoice lines from a billing API with a warehouse export. IDs differ in case and whitespace; amounts may be strings or numbers. Return matches, items missing on each side, and amount mismatches.
A strong answer: A separate normalisation function, exact decimal comparison, deterministic output order, and unmodified inputs.
Drill 2
Write fetch_all(client) for a cursor-paginated API that sometimes returns 429/5xx and occasionally repeats a cursor.
A strong answer: Bounded retries with backoff and jitter, repeated-cursor detection, a page cap, and a fake client in the tests.
Drill 3
Implement try_consume(tenant, tokens, now) with a rolling 60-second token budget per tenant plus a global ceiling.
A strong answer: An injected clock, correct window-boundary handling, rejecting requests bigger than the whole budget, and a note on multi-replica enforcement.
Drill 4
Model output sometimes comes back as "almost JSON" (code fences, trailing commas, cut off). Write a safe repair-then-validate function.
A strong answer: Repairing only well-defined cases, never inventing values, schema validation, typed errors, and valid JSON passing through unchanged.
Best resources for this skill
Repos, courses, articles and podcasts, ranked by how much they teach.
adityatandon15/Forward-Deployed-Engineer-Full-Course
All Notes & Code for Forward Deployed Engineer series on CoderArmy
Forward Deployed Engineer Interview Prep
Forward deployed engineer interview prep for OpenAI, Anthropic and Palantir: practical coding, decomposition, LLM systems, evals and six interview cases.
Palantir Learn (Foundry & AIP)
Official training for Foundry and AIP, the platforms Palantir FDEs deploy every day.
Anthropic Forward Deployed Engineer (FDE) Interview Guide
Build a rate limiter · Process streaming events · Build a retry queue · Implement a job scheduler · Write a document chunker for RAG · Build an eval ...
Read next
Debugging
David J. Agans
Nine simple rules for finding bugs systematically (make it fail, quit thinking and look, change one thing at a time). Essential when you are debugging in an environment you did not build and cannot fully inspect.
Working Effectively with Legacy Code
Michael C. Feathers
Techniques for safely changing code that has no tests: finding seams, breaking dependencies and adding characterisation tests. Customer codebases are often exactly this, and you need to change them without breaking production.
The Pragmatic Programmer
David Thomas, Andrew Hunt
Broad, durable habits for working engineers: tracer bullets, prototyping, automation and taking ownership. The tracer-bullet approach is a natural fit for getting a thin end-to-end slice working early at a customer.
A Philosophy of Software Design
John Ousterhout
Argues that managing complexity is the core of design, with concrete advice on deep modules and information hiding. Helps you leave customer integrations simple enough for their team to maintain after you leave.