Practical FDE coding — production-shaped drills

Expected question

"Live or take-home: implement a small production-shaped piece (rate limit, retry, messy parse, mini-RAG, SQL) and narrate failure modes — not LeetCode hard."

Variant forms

• "Write a rate limiter with per-user and global limits."
• "Parse a messy CSV with inconsistent quoting into clean records; flag low confidence."
• "Implement exponential backoff with jitter for a flaky customer API."
• "Streaming consumer with backpressure when downstream is slow."
• "Build a tiny RAG over a folder of docs; defend chunking."
• "SQL: customers whose return rate exceeded 30% last quarter; then why is this query slow?"
• "CLI: ingest PDFs → JSON index with extracted entities."
• "Token-budget allocator for a multi-tool agent turn."
• "Tool-use orchestrator stub: call tools with timeouts, retries, and audit log."
• "Debug intermittent third-party timeouts in a customer integration."
• "Duplicate records appearing in the warehouse — isolate the cause."

Where this actually gets asked

Anthropic Applied AI practical screens, OpenAI FDE coding, Databricks SQL/Python emphasis, Exponent-style FDE banks. Grades practical reliability under narration, not LeetCode hard.

The question, as it might actually be asked

"Make something that runs. Talk while you write. Silence fails."

The framework

30-second thesis

I'd clarify edge cases and the SLA first, ship a boring correct path with timeouts, retries, idempotency, and logs, and narrate hypothesis → test → fix out loud. Then I'd say the single-box limit and the honest distributed next step — before they ask.

2-minute method

What FDE coding grades isn't cleverness. It's whether you sound like someone who's broken a customer integration at 2am.

Mini playbooks (how I'd talk while coding)

Rate limit: “Token bucket, keys for user and global. On breach I reject with 429 unless you want a bounded queue. This is single-process — three instances need a shared counter.”

Retry/backoff: “Jittered exponential, capped attempts. I won't retry a non-idempotent POST without an idempotency key.”

Messy CSV: “Dialect sniff, quarantine bad rows, emit confidence + error codes — don't silently drop.”

Mini-RAG: “Chunk by structure before tokens; store doc_id, page, acl; retrieve → cite → decline if empty. Same access-aware instinct as the platform brand.”

SQL: “CTE / window for the return-rate cut; then EXPLAIN — indexes, partition pruning, SELECT *.”

Integration debug: “Reproduce → classify timeout (client/network/server) → breaker → respect their change window.”

Token budget: “Soft cap per turn; reserve tokens for the final answer; drop low-value tool traces first” (H Anthropic-style).

Tie to take-home

Ship runnable code + README with eval notes + failure modes. Same artifact feeds deep-dive (05).

Requirements

Functional

• Clarifying questions before code.
• Works on ugly input; quarantine or explicit errors.
• Observable failure modes (logs/metrics codes).

Non-functional

• Timeouts and bounded retries.
• Idempotency story for side-effecting calls.
• Honest scale statement (single-node vs distributed).

Core entities

• Request / event: unit of work with idempotency key when needed.
• Quota / budget: rate limit or token budget.
• Quarantine record: bad input preserved with reason.
• Audit line: tool call, latency, success/fail.
• Chunk / citation: mini-RAG retrieval unit with lineage.

Process flow — live drill

Rendering architecture diagram…

High-level design (generic drill skeleton)

input → validate/parse → core logic → side effects (idempotent)
      → emit metrics/logs → degrade/reject paths documented

For mini-RAG: docs → chunk+lineage → index → retrieve → cite|decline.

For tool stub: plan → allowlisted tool → timeout/retry → audit → HITL hook if irreversible.

Deep dive 1: rate limiter interview narration

I'd start single-process token bucket, define 429 vs queue, show a burst test, then say multi-instance needs a shared atomic store. I wouldn't open with Redis cluster design.

Deep dive 2: mini-RAG in one hour

Structure-aware chunks; store ACL if present; retrieve top-k; require citation; decline on empty. Defend chunking with a quick groundedness thought experiment — link to 05.

Deep dive 3: flaky customer API

Classify timeout; jittered backoff; circuit breaker; idempotency keys on mutating calls; never infinite retry. Prior art in the coding catalog (O): circuit breaker, idempotent consumer — method, not a claim Lucid shipped that drill.

Quantitative trade-offs

Migration / practice plan (weekly)

1. Rate limiter + tests.
2. CSV quarantine.
3. Backoff + circuit breaker.
4. One SQL window-function query + explain.
5. 1-hour mini-RAG with decline path.
6. Narrate each under a timer (silence fails).

Org ownership (customer integration context)

• FDE owns the stub → hardened connector path.
• Customer API owner owns SLA and change windows.
• Platform owns shared retry/breaker SDKs once patterns repeat.

Situation

FDE coding screens ask for production-shaped scraps under time pressure — the same instincts as hardening customer integrations and open reference services (O: circuit breaker / idempotent consumer entries; Enterprise RAG chunk+cite tests).

Task

Implement a small reliable piece, narrate continuously, and leave failure modes and scale honesty visible — not a clever silent algorithm.

Action

1. Ask clarifying questions (edges, SLA, single-node assumption).
2. Implement happy path quickly; immediately hit ugly input.
3. Add timeouts, bounded retries, idempotency, quarantine/logs.
4. Narrate hypothesis → experiment → fix when debugging.
5. State what breaks at multi-instance / 100× and the boring next step.
6. For take-home: README with eval notes + failure modes tied to 05.

Result

Runnable artifact + operability + narration. Principal signal: turn the drill into a reusable customer SDK/runbook pattern — not a one-off clever snippet.

The follow-up question you should expect

"What breaks when we run three instances?"
In-memory rate limits and caches diverge — need shared counters/cache. Retries without idempotency keys double-write. I'd say it before they ask.

What I'd ask them (before coding)

1. Single-process assumption ok, or do we need multi-instance from the start?
2. On limit / failure — reject, queue, or degrade?
3. Are mutating calls idempotent today, or do I need to add a key?
4. What's the latency SLA you're actually grading?

Candidate-owned evidence prompts

1. Which two drills will you rehearse weekly under a timer?
2. Which O coding entry will you mention if they ask for prior art?
3. What is your decline-path sentence for mini-RAG?
4. Have you practiced explaining EXPLAIN output in ≤60s?

Author reference (do not memorize)

Playbooks are scaffolds — interview code should be yours. Don’t claim LeetCode-hard prep as FDE signal; claim operability.

Staff+/Principal signal rubric

• Mid-level: Works on happy path with prompting.
• Senior: Handles edges; basic retries/timeouts.
• Staff+: Clarifies, narrates, idempotency/backpressure, honest scale next step, ties to customer ops.
• Principal: Turns drill into reusable customer SDK patterns / runbooks.

Related

• 05-production-ai-evals-cost-guardrails-takehome.md
• ../coding/18-circuit-breaker.md
• ../coding/19-idempotent-event-consumer.md