Palantir Forward Deployed Engineer interview questions

The question that separates demo-builders from production engineers. Idempotency keys, the saga pattern, dry-run modes, approval tiers: the distributed-systems toolkit applied to agents, with the trap most answers miss.

The most FDE question in the bank: every real deployment hits an unchangeable legacy system. The answer is an architectural principle, concentrate brittleness in one owned layer, plus what to do when the GUI is the only API.

A multi-hop question over a property graph is a query-generation problem, not a similarity-search one. The staff-level move is grounding generation in the live schema and closing an auto-healing loop on the DB's own error messages.

The hard part is not the retrieval pipeline, it is the boundary. Embeddings and the index live inside the VPC; the only question is whether the generation model is an in-VPC open model or an external API with a zero-retention DPA, and what crosses that line.

Every eval question in the prep canon is about answer quality. This agent does not produce answers, it moves freight. You cannot score a reroute for faithfulness, and the candidate who tries has not understood what they built.

A query that errors is a bug. A query that runs and returns a plausible wrong number is a product teaching a finance team, one figure at a time, not to trust it. The diagnosis is a classification exercise, and the fix is almost never a better prompt.

Before you touch a model, check whether the two numbers measure the same thing. Field accuracy of 96% across twelve fields is 61% of documents fully correct, which means half of the drop may be arithmetic. The other half is the documents the pilot never saw.

The eval set says recall fell 2.3 points, which is inside the noise you would expect from a re-index. Support says the product got worse. Both are right, and the reason is that one document class lost 49 points of recall while everything else improved slightly.

The most common screen opener, and interviewers use it to check whether hashmap thinking is reflexive. Here's the one-pass answer, the narration that earns points, and the duplicate-handling edge case most candidates fumble.

The interval pattern shows up everywhere in FDE loops: calendars, flight segments, log windows. Master the sort-then-sweep idiom here and three other interview questions fall out for free.

The follow-up interviewers reach for when merge-intervals goes too smoothly. The three-phase scan is elegant, but only if you've internalized the overlap condition most candidates have to re-derive under pressure.

The single most-asked design-a-data-structure question in FDE loops. There's an interview-legal Python shortcut and a from-scratch version, and knowing when to offer which is half the grade.

The canonical grid question, and the template for every flood-fill, shortest-path, and region-labeling variant FDE loops throw at you. BFS vs DFS vs union-find: here's which to write and which to merely mention.

The follow-up to number-of-islands, and the question where candidates reveal whether they understand WHY BFS finds shortest paths. Plus the two variants (weights, eliminating obstacles) that decide hard-screen outcomes at xAI.

The third member of the grid trilogy, and the one that tests backtracking discipline: marking, unmarking, and the early-exit pruning that turns a timeout into a pass.

The Palantir coding-screen classic. It looks like merge-intervals but needs a different weapon, the sweep line, and the boundary-tie detail decides whether your answer is right or off by a planeload.

The quintessential FDE practical: messy real-world input, grouping, ranking, and a hidden rubric line for how you treat malformed data. Most candidates parse happily and lose the round on the lines that don't parse.

Every data migration at every customer site needs this exact tool, which is why Palantir and Retool keep asking it. The diff is a dict comparison; the grade hides in keys, duplicates, and column drift.

Palantir's bread and butter: 'Acme Corp.' and 'ACME Corporation, Inc.' are the same customer; prove it in code. Normalization does more work than the clever algorithm, and blocking is what makes it run before the heat death of the universe.

Kahn's algorithm gets you level one. The round is won at level three, where 'run up to K tasks at once' breaks naive topo sort, and the indegree bookkeeping you chose at L1 either saves you or sinks you.

Palantir's signature coding genre isn't an algorithm; it's working from unfamiliar documentation: a graph API, a custom serialization spec, a mini query language. The behaviors graders score, plus the BFS-over-an-opaque-client worked example.

The build behind every access policy and routing rule a customer wants to edit without a deploy. The trap is operator precedence: candidates who tokenize fine still get `a or b and c` wrong, and that's the whole grade.

Executing a query is the easy half; deciding HOW to execute it is the staff-level half. The interesting failure is choosing an index that returns 90% of the table, where a full scan is faster, and a planner that knows that beats one that always uses the index.

The function reads a file, parses it, computes a metric, and prints, all tangled together. The move interviewers want is not prettier code, it's pulling pure logic out from side effects so each piece can be tested in isolation.

A classic FDE take-home shape: messy real documents in, structured index out. The grade is in the seams between reader, extractor, and writer, and in what happens when one file is garbage.

All-pairs comparison is O(n^2) and dies long before 1TB. The senior move is MinHash plus LSH: hash documents so only likely-similar pairs ever land in the same bucket, then verify just those.

It looks like the grid BFS everyone has written a hundred times, and the usual visited set is exactly what makes it wrong. The fix is one line and it is the whole point of the question.

A stateful pass over sorted events, which most candidates get working in ten minutes. The reason it is asked is the next ten: in this domain a false positive is a person accused of something.

The round that punishes fluency. Candidates who can draw a class diagram in ninety seconds usually score worst, because they modeled the nouns in the prompt instead of the operations the system has to support.

The classic market-sizing question with Palantir's twist: the estimate is the warm-up, and the scored move is the verification plan. Two independent decompositions, a cross-check, and the datasets that settle it.

Profile before you model: shape, types, target balance, leakage check. Then the part most candidates botch, that a missing value is often the most predictive feature in the table, so you flag it before you fill it. The first-hour playbook and the imputation decisions that survive production.

The amateur move is to train a fresh deep net on 200 rows and overfit instantly. The senior move is to spend almost no labels on training: lean on a pretrained model, use the 200 as a validation set, and design a labeling loop that buys the most signal per label.

Everyone spots that the customer records need resolving. The failure that actually sinks this project is quieter: the word fraud means three different things in the three datasets, so the union of their labels trains a model that is confidently wrong.

Thirty percent disagreement is not a fact about the annotators. It is a fact about the task definition, and on a skewed label set it can mean the labels are worse than chance. The week is spent on the guideline and the gold set, not on the model, because no model trains past the noise in its labels.

The single most-reported live-SQL question in data-platform FDE screens. The pattern is standard, the points are in tie handling, the QUALIFY shortcut, and one aggregation trap most candidates miss.

Every pipeline eventually double-loads data, so every FDE screen eventually asks this. There's one canonical idiom, plus a determinism detail that decides whether your dedupe is rerun-safe.

The hardest 'standard' SQL interview pattern, asked everywhere from Meta to Palantir. There's a three-line trick that turns consecutive runs into a GROUP BY key, once you've seen it, you can't unsee it.

Join fan-out is the bug behind half of all 'the dashboard numbers are wrong' escalations an FDE will ever field. The mechanism, the 30-second detection query, and the three legitimate fixes.

Snowflake's signature semi-structured question. Dot-notation, LATERAL FLATTEN for nested arrays, the casting traps, and the schema-on-read vs flattened-model judgment call interviewers really want to hear.

The Databricks signature triage question. Strong candidates don't list optimizations, they run a diagnostic decision tree: plan first, then scan, shuffle, join strategy, files. Here's the tree.

Snowflake's signature internals question, and the trap is in the second half: most candidates can define micro-partitions, but the scoring is on knowing the four cases where scaling up burns credits for zero speedup.

A warm-up that quietly reveals whether you understand why analytical engines are fast at all. Compression, projection, predicate pushdown, and the one workload where columnar is the wrong choice.

The Databricks screen opener that decides whether the rest of the interview goes deep or stays remedial. Definitions are table stakes, the points are in explaining what a shuffle physically does and how to see one in the Spark UI.

The Databricks signature deep-dive. Everyone says 'salting', almost nobody can write the salt correctly or explain why AQE might make hand-salting unnecessary. The full playbook, in the order a senior engineer actually tries it.

The small-files problem is the #1 self-inflicted lakehouse wound FDEs find in the field. The causes are always the same three things, and the fix has a prevention half most candidates forget.

The dimensional-modeling staple. The trip fact table is the easy part, interviewers score grain declaration, the surrogate-key rationale, and how you handle the rider who changes cities. Here's the full shape.

Sounds like a definition question; it's actually a judgment question. The economics that flipped the industry to ELT, and the four cases (starting with PII) where transforming before load is still non-negotiable.

The pipeline-design question that exposes whether you've ever been paged. One property, idempotency, solves reruns, late data, and backfills at once, and there are exactly three patterns that deliver it.

Pure FDE territory: the customer's data is always dirtier than scoped. The layered defense, contracts, quarantine, drift handling, and the alert-severity matrix that keeps you from crying wolf.

Palantir's home turf: entity resolution disguised as a dedupe task. The naive O(n²) comparison is the trap, blocking, match scoring, transitive closure, and the golden-record question are where the interview actually happens.

The integration question that decides data-platform FDE offers. Log-based vs query-based capture, why deletes break naive designs, the apply-merge that keeps order, and the snapshot step everyone forgets.

The capstone triage scenario data-platform FDEs get role-played through. A 9x blowup with an obvious-looking suspect, the scoring is on your diagnostic order, the questions you ask, and not stopping at the first plausible cause.

The Deployment Strategist data-modeling case. It looks like schema design; it's graded as ontology thinking, entities with identity, events that link them in time, documents as evidence, plus privacy designed in, not bolted on.

The verbatim Deployment Strategist case. The trap is accepting the premise, 'best for whom?' is the first scored move, and the second is designing a natural experiment from public data instead of hand-waving at 'analytics.'

The regression with no smoking gun, no deploy to blame, no single bad night. Staff-level triage is about reading the trend, not the last run, and the four slow-burn causes that a one-night comparison can't see.

The aggregate-restatement problem that breaks naive backfills: events arrive days late and out of order, so any partition you already published may be wrong. The staff answer is event-time partitioning plus bounded restatement, not a bigger watermark.

SCD2 tracks when an attribute was true; bitemporal also tracks when you knew it. The question separates engineers who can audit a number from those who quietly overwrite history when a correction arrives.

Basic salting assumes one side is a small dimension you can explode. When both sides are huge and skewed, exploding either one blows up the cluster. The staff move is to split hot keys out and handle them on a different plan entirely.

CDC design questions usually stop at the happy-path MERGE. This one stress-tests it: an at-least-once stream that double-delivers, hard deletes, soft deletes for audit, and a GDPR erasure that must physically purge even the bronze change log. The guarantees have to compose.

Streaming interviews separate people who have run a job at 3am from people who have read the docs. The hard parts are not the windowed aggregate, they are bounding state so the job does not die, and choosing what a late event does to an already-emitted result.

The most common escalation in any data deployment, and the one that quietly ends trust in the platform. Four causes produce it, one of them means nobody is wrong, and you cannot tell them apart without running the ladder in order.

Four lines of SQL, and one of the three obvious ways to write it returns an empty result set instead of an answer. Not wrong rows. Zero rows, silently, on production data that looks fine.

Everyone writes the join and the ratio. Then the result comes back dominated by people who bought one thing and sent it back, and the list is useless to the person who asked for it.

The constraint is the question. It rules out the two approaches most candidates reach for, and the approach that survives has one failure mode that can take the customer's production database down.

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.

API keys for systems you don't own, in environments you can't always reach, audited by security teams who don't trust you. The strong answer has one organizing principle, and a concrete story for rotation and the air-gapped case.

The Palantir decomposition round has no right answer, it has a right METHOD, and it's the most-failed interview in the FDE loop. Here is the four-move rubric interviewers actually score: clarify, model, spine, iterate.

The classic Palantir decomposition prompt. The winning answer hinges on one asymmetry candidates rarely surface unprompted, and on starting with something embarrassingly simpler than an ML model.

The most open-ended prompt in the Palantir canon, no scale given, no user given, no disaster given. What separates passing answers is one design assumption about the data that almost nobody states out loud.

The purest data-modeling prompt Palantir asks, the whole interview lives in the entity-resolution edge cases. Twins, maiden names, shared insurance IDs... and one architectural decision about merging that candidates get fatally wrong.

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.

Enterprise deals die in this design review. The answer has three layers most candidates blur together: who you are, what you can see, and how an embedded product proves both, plus the permission-staleness trap that fails Glean loops.

The defining Palantir-style deployment question. Everything your laptop did silently (package pulls, API calls, telemetry, auth callbacks, clock sync you never thought about) becomes a named workstream. Strong answers produce the checklist by category, not by anecdote.

The pattern is expand-contract; the interview is everything around it: the backfill that locks the table, the rollback nobody rehearsed, and the fact that it's the customer's database, not yours. One named technique carries the whole answer.

The question that defines forward-deployed engineering as a discipline: production you're responsible for but can't touch. The answer is a system (version skew, telemetry tiers, diagnostic bundles, release trains), not a collection of favors from customer IT.

The capstone FDE question, where every topic in this category shows up as one workstream. The rubric isn't the target architecture; it's whether you can sequence the gap-closing while the customer keeps using the pilot.

A live-reported Palantir FDSE decomp with a built-in twist: after you design for the driver, the interviewer flips you to Uber's side. The expected-value-per-hour model, the tip-prediction ethics trap, and how to survive the flip.

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.

No egress is the easy half. The hard half is that an auditor will read your logs, your access trail, and your model-update process for the next three years. The strong answer designs the evidence the audit consumes as a first-class output.

A port is three coupled scheduling problems in a single prompt: where ships dock, which cranes work them, and where containers land in the yard. The strong answer decomposes them, names where they couple, and refuses to solve the whole thing as one giant optimizer.

Per-account scoring catches the lone fraudster and misses the ring whose accounts each look clean. The strong answer reframes the problem as a graph, makes entity resolution the step everything else depends on, and treats a flagged ring as a case for an investigator, not an automatic block.

CAP is a trap if you recite it. The interviewer wants to see you map a customer's real datastore to a real failure mode, then decide where stale reads are free and where they corrupt an agent's decision.

It reproduces once in a thousand runs, never on your laptop, and the customer's data is wrong. This question separates engineers who name the race and reach for the right lock from those who sprinkle mutexes and pray.

The best FDE deployment is the one that doesn't need the FDE anymore. This question screens for whether you build for handoff from day one or quietly make yourself indispensable, which is the failure mode that looks like success.

A gateway that screens every prompt and streamed token against a live policy without blowing the latency budget. The strong answer separates the policy decision from its data, runs deterministic checks inline and model checks in parallel, and redacts a leaking secret mid-stream before it renders.

Five LLM agents over a hundred steps, and the bar is zero contradictions with a 500-page contract. The real test is the state and grounding layer, not the agent prompts.

No data leaves, you cannot pre-inspect the corpus, and your toolchain arrives on a single USB. Design adaptation and evaluation when you will never observe a single input or output.

Every integration lesson assumes a queue and nobody designs one. Ordering per entity rather than globally, a dead letter path somebody actually reads, and what your pipeline does when the consumer is slower than the producer for four hours.

The most-reported decomposition prompt in the FDE canon. Almost every candidate builds a routing model, and almost every candidate is optimizing the wrong term of the equation.

The number 500 is the trap. Candidates hear it as a scaling problem and design a pipeline factory, when the interviewer is watching to see whether you refuse to ingest 500 things at all.

A dataset lands in your lap with a one-week deadline attached. Most candidates start exploring the data. The ones who pass start by working out which questions this data physically cannot answer.

It reads as an optimization problem and it is not, quite. One of the three inputs can never be traded against the others, and a design that scores all three has quietly built a compliance incident with a scheduler attached.

The obvious engineering answer is to rewrite the notebooks properly and schedule them. Do that and you will have built something correct that the people who own the work can no longer maintain.

The only round where you choose the problem, which sounds like a gift and is where most candidates lose it. Four things get graded in one flow, and the fourth is the one engineers skip.

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.

Every instinct says move fast. The arithmetic says otherwise: eight hours of preparation reached a fixed system 26% sooner than shipping immediately, because each failed attempt costs a two-day approval cycle and you only get one shot per cycle.

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.

The single most common FDE behavioral question, and the 'week one' follow-up is where most candidates collapse. Here's the structure that signals you can be dropped into chaos and produce order.

This is a flight-risk filter, not small talk, FDE teams lose hires back to pure SWE roles constantly. The answer that passes is built on evidence, not enthusiasm. Here's what it sounds like.

There's no trick here, except that interviewers are listening for one specific word: a plan. The candidates who fail give enthusiasm; the ones who pass give logistics.

FDEs change domains every deployment, so interviewers test for a repeatable learning system, and most candidates fail the second half: proving the understanding was real. Here's the method and the validation move.

The incident is the setup; the disclosure timeline is the test. Interviewers are timing the gap between 'you knew' and 'they knew', here's the answer that builds trust instead of torching it.

'The customer was dumb' is an instant fail, but so is theatrical self-flagellation. There's a narrow honest lane between the two, and this is what driving down it sounds like.

Nobody cares about your final number, they're grading the decomposition, the sanity checks, and whether you convert tokens into dollars unprompted. Here's a clean worked path.

Every deployment has a skeptic, and 'I showed them data and they came around' is the answer everyone gives. The scored version starts with why they were right to be skeptical.

The first use case decides the whole account, pick a flashy-but-doomed one and there's no second. Here's the value × feasibility × data-readiness workshop that strong FDEs run, hour by hour.

A live translation test of the FDE's core skill: same facts, different altitude. There's a four-line formula execs actually read, and one translation error that destroys trust.

The pure autonomy test: no one to ask, a customer waiting, and a scope line in front of you. Strong candidates reveal a decision rule, not a guess. Here's the rule.

Every enterprise AI deployment hits this wall, interviewers want to know if you deliver the bad news early, with options, or sit on it hoping. Here's the conversation script, beat by beat.

The Palantir classic. He's not irrational, your product might really make his role redundant, and escalating over him is the losing move. Here's the playbook that converts the blocker.

An integrity trap with a political twist: the person gaming your metric is usually your own champion. Blowing the whistle loudly and looking away both fail, here's the third path.

A genuine filter, not small talk, Palantir interviewers have heard every dodge. The answer that works engages the controversy directly, with a position you can defend under two rounds of pushback.

FDE comp spans roughly $150K to $550K+ for the same title, because some companies pay it on the engineering ladder and some on a field ladder with variable comp. The first question to ask, and the traps in comparing OTE to base.

The eng lead isn't testing your architecture, he's already decided you should go and is performing it for the room. Trying to win the technical argument is the trap. Here's how to split his audience from his position and leave with a next meeting.

You hit 71% against an 85% bar nobody wants to say out loud, and the easy moves (quietly redefine the metric, ask for 'one more month') are how pilots rot in purgatory. Here's the honest salvage path, and how to recommend a kill without losing the account.

Both dials broke at once and now the most senior person in the building wants answers. The instinct to lead with explanation is how you lose the room in the first minute. Here's the structure that turns an execution interrogation into a decision meeting you control.

The conflict isn't you versus the customer, it's you versus your own quota-carrying colleague who wants the deal. The answer that passes refuses the line without grandstanding, finds the compliant adjacent path, and accepts the churn if there isn't one. Here's how to hold it without becoming the obstacle.

A board isn't an engineering audience and the postmortem they want isn't the one you'd write for your team. Lead with the wrong thing and you confirm their fear that this is unmanageable. Here's the board-grade structure, blameless but accountable, that restores confidence.

The graded shape is specific: learn and ship something small by day 30, own a deployment by day 60, drive a cross-customer improvement by day 90. Vague answers about 'meeting stakeholders and ramping up' fail. Here is the staged plan with what good looks like at each gate.

A research team that owns its own way of working does not adopt your process because you're right. The candidates who win this question don't argue, they run a small proof that makes the practice obviously cheaper than the status quo, then let the team claim it.

Around 95% of enterprise AI pilots produce no measurable impact, almost always from deployment, not the model. As the first FDE in a skeptical SWE shop, your month-one job is to not be pilot 95: pick a project that can win, prove it in 30 days, and turn the engineers who roll their eyes into the ones who vouch for you.

The gap is real, the date is close, and the business is about to ask if you'll make it. The wrong first move is to start tuning prompts. The strong move is to split the failure into causes you can act on, give the business an honest forecast with options, and protect the launch even if you can't fully close the gap.

The screen is whether you build for your own replaceability or your own indispensability. Strong answers treat the handoff as a deliverable with a graduation criterion, not a final week of doc-dumping. Here is what to leave behind, how to transfer it, and the trap that sounds generous.

The deployment worked. The software runs, the data flows, the demo landed. Nobody is using it. Two of the three research sets we vetted surfaced this from different angles, and it is the failure mode that ends renewals.

Nothing about the software changed. The single person whose belief the contract rested on is gone, and the replacement has more to gain from cancelling your project than from finishing it.

The structural tension of the job in one question. You are the customer's advocate inside your company and your company's representative at the customer, and this is the day those two roles openly disagree.

The most common real ticket in applied AI, and it contains almost no information. What you do in the first hour decides whether you spend a day on this or three weeks.

Asked in every loop, prepared for by almost nobody, and it has a single mechanical test that tells you whether your answer is any good before you ever say it out loud.

Palantir hiring managers are reported to spend a large part of the final round on this one question. It is not a stress test, and treating it like one is how strong candidates talk themselves out of an offer.

The trap is that it looks like a prioritization problem you can solve with a scoring rubric. You do not have the authority to rank these people's work, and the moment you try, you have made yourself the obstacle.

The question that separates a forward deployed engineer from a very good consultant. One delivers each engagement. The other notices that the third engagement looked like the first two and does something about it.

Candidate reports describe a Palantir round where you are handed unfamiliar material, given time with it, and asked to explain it. It is the job in miniature: an FDE learns a customer's domain in a week and has to be useful by Thursday. The scoring is on what you chose to teach, and on what you admitted you did not learn.

Reciting all ten gets you a pass on memory and a fail on judgment. The question is really a prioritization exercise, here's the two-risk answer that maps to how agents actually get breached, and the trap hiding in 'walk me through.'

ATLAS questions filter candidates who can name the framework from those who can run an incident through it. The mapping exercise, one concrete attack, kill-chain stage by stage, is what the interviewer actually wants to hear.

The four-point redaction design is becoming the standard FDE privacy round. Most candidates fortify the chat box and lose on the other three doors, here's the full design, including the de-redaction map that makes it usable.

'Can't leave our environment' means four different things to four different stakeholders. The FDE skill is decomposing the demand into the actual requirement, and knowing which deployment tier each requirement really needs.

HIPAA-with-LLMs questions test whether you know the three things that gate the deal: the BAA, the minimum-necessary standard, and audit controls. Engineers who can name 45 CFR obligations in design terms win these rooms.

The AI Act question is a classification exercise in disguise: interviewers give you a use case and watch whether you can tier it, name the obligations, and know whose job each one is, provider or deployer.

A Snowflake solutions-loop classic that generalizes to every AI deployment: why masking retrofits fail, what a role hierarchy actually looks like, and the policy-attachment model that makes governance survive schema growth.

When the agent does something expensive, 'what happened and why' must be answerable in minutes, to an auditor, from records they trust. Most logging designs answer 'what'; the AI-specific work is 'why', and tamper-evidence is what makes it count.

The capstone governance round: AI incidents break standard IR playbooks in three specific places, containment without rollback, blast-radius over probabilistic systems, and root cause for nondeterministic behavior. Interviewers grade you on knowing which three.

Cross-tenant or cross-user data exposure through a model is the breach that starts regulatory clocks. The runbook has to answer 'whose data, to whom, how many' from logs that most teams never designed for, and contain a leak that may live in a cache or a fine-tuned model, not a deploy.

NIST AI RMF is voluntary, which is exactly why a CISO uses it as a shared yardstick. The strong answer turns Govern, Map, Measure, Manage into artifacts you already produce, and uses the Generative AI Profile to name the LLM-specific risks the core framework leaves abstract.

When agents call agents, one agent's output is another's untrusted input, and a single injected instruction can propagate across the whole graph with accumulated privileges. The strong answer treats every inter-agent edge as a trust boundary and bounds privilege per agent, not per system.

Sensitive meeting audio in, speaker-attributed summary out, and a hard guarantee that the raw transcript never lands on disk. The strong answer keeps everything on-prem, processes transcripts in memory only, and proves non-retention with architecture and audit, not a policy promise.

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.

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.

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 reported ElevenLabs live round, written in a shared Google Doc, no execution, no autocomplete. Inherited folder permissions plus permission-change timestamps, and the two-axis resolution rule that keeps the code to thirty lines.

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.

A 5-minute warm-up that quietly tests the most useful idea in practical coding: choosing a canonical key. The sorted-string vs character-count tradeoff is exactly what interviewers want to hear you reason about.

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.