Cognition System Design & Production Engineering interview questions

The instinct is to grade the codebase. Grade the feedback loop instead: a repo with no docs and a 90-second test command is friendlier to an agent than a beautifully documented one whose suite takes 40 minutes and flakes 8% of the time, and the arithmetic on that second number is worse than it looks.

Nobody turns off an AI reviewer because it missed a bug. They turn it off because it left nine comments they had to read and three that mattered. Precision is the design variable, and the arithmetic says cutting comments per PR from twelve to four costs you 7% of the real findings and two thirds of the triage time.

Every queue, webhook, and retry loop you'll ever deploy at a customer hides this distinction. Interviewers use it to separate people who've shipped from people who've read about shipping.

A staple at OpenAI and Anthropic in both coding and design rounds. Most candidates can name the algorithms; few can say which one lets 2x your limit through, and that's the part that gets scored.

A Fermi estimate with a paycheck attached. The interviewers' favorite filter: candidates who jump to a dollar figure miss the two numbers that actually break deployments, peak QPS and tokens-per-minute limits.

The signature FDE debugging genre: a moving fault, an opaque client, and a customer who's sure it's your fault. The winning method splits the problem at the boundary, and knows the four classic culprits hiding on their side.

Averages lie, and interviewers know most candidates quote them anyway. The fastest way to sound production-grade in any latency discussion is to reason about percentiles correctly, including the one trap almost everyone falls into.

The round is conversational discovery plus live Excalidraw diagramming, and it's graded on sequence: candidates who draw before asking fail. The discovery battery, the voice-pipeline boxes worth drawing, and the latency budget that anchors the whole design.

This isn't a deployment question, it's a judgment question wearing one. Interviewers are scoring whether you have a decision framework, a safety checklist, and the spine to say no to a customer politely.

A signature FDE triage question with a hidden rubric: interviewers score the *order* of your moves, not just the list. There's a reason 'what changed?' beats 'check the dashboards', and a reason mitigation beats diagnosis.

A reported Palantir FDSE decomposition where the fatal move is putting triage inside an algorithm. The bed-capability data model, the visibility-before-optimization v1, and the conflicting-priorities answer that keeps clinicians in charge.

Under 500ms from end of speech to first audio out, across three models and a network. The trick is that you never wait for any stage to finish: you stream and pipeline everything.

Three different causes produce the same rising line, and resident memory alone cannot tell them apart: a leak climbed 25.2 MB an hour and fragmentation climbed 22.8. The gauge that separates them costs nothing and has to have been shipped before the incident.

The bug only appears under load, the code 'hasn't changed,' and the customer just got charged twice. There's one root-cause pattern behind almost every version of this incident, and a fix with a subtle race most candidates miss.

Looks like an algorithms question; it's actually an operations question wearing one. The candidates who fail reach for 'solve VRP'; the ones who pass design for the 2pm reality that invalidates every morning plan.

The decomposition prompt we use to teach the skill that actually decides these interviews: graceful iteration under perturbation. Your score isn't your design; it's the delta when the design gets punched.

You control the sender; thousands of customer endpoints you've never seen control your fate. The rubric hides in three places: what 'ordering' really costs, why retries need the receiver's cooperation, and the debugging surface most designs forget.