FDE interview round guide
System design for customer deployments
Updated November 11, 2026 · 14 practice questions
TL;DR
FDE system design is not "design Twitter". The system runs inside a customer's world: their single sign-on, their network rules, their data residency, their system of record that you cannot change. Strong answers start from those constraints, define the contracts with existing systems, draw the data flow with idempotent writes, put permissions and audit at the centre, plan for partial failure and backfills, and end with a rollout the customer can operate. Size things with real arithmetic, not "it scales".
What this round tests
- Designing under constraints you do not control: where the system may run (customer cloud account, on premises, your SaaS), which identity provider is used, what data may leave which region.
- Integrating with systems of record through their real interfaces: rate-limited APIs, nightly files, change feeds, webhooks that arrive twice or out of order.
- Security as a design input: authentication through the customer's single sign-on, authorisation that mirrors the source system's permissions, secrets, audit logs and personal data handling.
- Failure and recovery: retries, dead-letter queues, replays, backfills and reprocessing after a bug, without double effects.
- Operating it: rollout in stages, observability, cost, and what the customer's own team will run after you leave.
- For AI systems: retrieval and agent design with evaluation, grounding and guardrails, not only a model call.
How to approach it: context, contracts, data flow, trust, failure, rollout
Our guidance (editorial), not a candidate report
1. Context and constraints
Ask where it runs, who uses it, how many users and how much data, latency expectations, compliance regime and the deadline. Write the numbers down; you will use them for sizing.
2. Contracts with existing systems
List each system you read from or write to, its interface (API, file drop, database replica, event stream), its limits and who owns it. Decide what must be synchronous for the user and what can be asynchronous.
3. Data flow
Ingest, transform, store, serve. Choose batch or streaming per flow, make every write idempotent (a natural key or idempotency key), and say how schema changes upstream are detected.
4. Trust boundaries
Single sign-on through the customer's identity provider (SAML or OIDC), authorisation derived from the source system, least-privilege service accounts, secrets in a managed store, audit logs for every read of sensitive data, and what personal data is stored, where and for how long.
5. Failure modes
For each external dependency: what happens when it is slow, down, rate-limits you or sends bad data. Bounded retries with backoff, dead-letter queues with replay, reconciliation jobs, and the ability to reprocess history after a bug fix.
6. Rollout and operations
Shadow mode, a pilot group, feature flags, the three or four metrics on the dashboard, alerts with runbooks, cost per month, and the hand-off to the customer's team.
Worked example: a permission-aware document assistant for a law firm
The prompt
A 5,000-person law firm wants an internal assistant that answers questions over its document management system (DMS): about 8 million documents, organised by client matter. Some matters sit behind ethical walls: only the lawyers on the matter may see them. Everything must stay in the firm's own cloud account. Design it.
Context and numbers
Assume 2,000 daily users, peaks of 20 questions per second, a target of the first answer token within 3 seconds at the 95th percentile, and that every answer must cite the documents it used. Assume an average of 10 chunks of about 250 tokens per document: 80 million chunks.
Contracts
The DMS is the system of record for documents and permissions. Read documents and access lists through its API with a read-only service account, and subscribe to its change events (new version, deleted, permissions changed). Users sign in with the firm's identity provider; group membership comes from there.
Ingestion
A backfill job and an incremental job feed one pipeline: fetch the document, extract text (with OCR for scans), split into chunks that respect headings, embed, and write chunk text, vector and metadata (document id, version, matter id, allowed principals) to the index. The key is document id plus version, so replays overwrite instead of duplicating. Sizing: 80 million vectors of 1,024 dimensions in float32 is about 330 GB; int8 quantisation brings it to about 82 GB plus graph overhead, which fits a few memory-optimised nodes. The backfill is limited by embedding throughput, not money: 20 billion tokens at 1 million tokens a minute is about two weeks, so start it on day one and prioritise active matters.
Permissions at query time
This is the core of the design. Each chunk stores the principals allowed to read its document. At query time, resolve the user's principals (user id plus groups) and pass them as a filter inside the vector search, so restricted chunks are never candidates. Filtering after retrieval is wrong twice over: restricted text has already been fetched, and the top 10 can come back empty. When the DMS changes a document's access list, update the chunk metadata (no re-embedding needed); a nightly job compares access lists between the DMS and the index and repairs drift. If the permission lookup fails, answer nothing: fail closed.
Answering
Hybrid retrieval (keyword plus vector) because lawyers search for defined terms, case names and clause numbers; rerank the top 50 to 8; generate with an instruction to answer only from the passages and cite each claim. Show citations as links into the DMS, which re-checks permission when opened.
Trust, audit and failure
Log every question, the retrieved document ids and the answer, retained per the firm's policy, because the firm must be able to show who saw what. Model endpoints run inside the firm's cloud account. If the DMS rate-limits the ingest, the change-event queue absorbs it; events that fail repeatedly go to a dead-letter queue with a replay tool.
Evaluation and rollout
Before launch, build a test set with two practice groups: 200 real questions with the documents that answer them. Track retrieval recall at 10, the share of answers whose citations support every claim, and a permission test suite run as accounts with restricted access, where the pass bar is zero leaks. Roll out to one practice group in shadow mode (answers visible only to the project team), then to the group, then firm-wide.
Why it scores well: the candidate put permissions at the centre and chose pre-filtering for a stated reason, did the storage and backfill arithmetic and drew a scheduling consequence from it, kept the DMS as the source of truth, and defined an evaluation that includes a security bar. Note what is not there: no time spent choosing between vector database brands.
Common follow-ups and what they probe
- "A lawyer is removed from a matter at 10:00. When do they stop seeing its documents?"
- Probes permission freshness. Event-driven updates take seconds to minutes; state the window, and add a per-query check against the DMS for matters behind ethical walls if the firm needs zero lag.
- "The customer cannot let any data leave their network, including to a model API."
- Probes deployment options. Self-hosted open-weight models inside their network, with the capacity and quality trade-offs that brings, or a provider's model hosted inside their cloud account if that meets the rule.
- "How do you know the answers are good after launch?"
- Probes evaluation in production. Sampled human review, thumbs up or down with a reason, monitoring of answers with no citations, and re-running the offline test set on every change to prompts, chunking or models.
- "The source API allows 10 requests per second and you need to read 8 million documents."
- Probes arithmetic. 8 million requests at 10 per second is more than nine days. Ask for a bulk export or a higher limit, prioritise active data, and design the pipeline to resume.
- "Single-tenant or multi-tenant?"
- Probes isolation trade-offs. Regulated customers often require a dedicated deployment; it costs more to run and upgrade. If multi-tenant, tenant id in every key, query and log, with tests that prove isolation.
How it is scored
Our guidance (editorial), not a candidate report
Our synthesis of the signals this round is designed to surface; companies do not publish their rubrics.
| Dimension | Weak signal | Strong signal |
|---|---|---|
| Constraints | Generic cloud design | Starts from where it runs, identity, residency and the systems of record |
| Integration | Assumes APIs are fast and reliable | Designs for limits, duplicates, ordering and backfills |
| Security | Mentions "auth" at the end | Permissions and audit drive the data model |
| Sizing | "It scales horizontally" | Back-of-envelope numbers that change a decision |
| Failure handling | Happy path only | Retries, dead letters, replay, reconciliation and fail-closed choices |
| Operability | No rollout or ownership | Staged rollout, metrics, runbooks and a hand-off plan |
Common mistakes
- Designing for internet scale when the customer has 2,000 users, and missing the hard part, which is integration and permissions.
- Filtering permissions after retrieval, or ignoring permission changes after ingestion.
- "We will use a vector database" with no chunking, retrieval, evaluation or update strategy.
- No plan for backfill, reprocessing after a bug or schema changes upstream.
- Writes that are not idempotent, so every retry risks a duplicate record in the customer's system.
- No rollout, monitoring or cost estimate.
Practice questions for this round
Reported interview questions from our bank that fit this round, reviewed by hand. They come from user uploads and 1Point3Acres posts. They were reported from software, ML and AI engineering loops, many of them at companies that hire forward deployed engineers; only 0 on this list were reported from an FDE loop as such. Questions marked Free are open to everyone.
A system design question about building a secure, large-scale assistant over frequently changing private knowledge. It evaluates API and data modeling, reliability, isolation, freshness, measurable answer quality, and operational trade-offs.
OpenAIreported March 2026A support-bot architecture round where an AI agent relies on a third-party model API that can stall, throttle or cut off mid-answer. Expect to walk a single turn from widget to model and back, then defend backoff with jitter, idempotent tool actions, resumable streaming and a fallback path when things break.
Sierrareported October 2026A system design question about keeping slow, multi-step work alive when processes die and users go offline. Expect a clear split between accepted work and live connections, a plan for recovering after a crash without paying twice, and a way to let a client rejoin a progress feed exactly where it left off.
Perplexityreported July 2026An ML system design question about exposing a two-model pipeline, embeddings followed by classification, through a public API. It covers the contract of the opaque first model, synchronous calls versus background jobs, avoiding repeated expensive work, partial failures and model version changes.
Scale AIreported October 2026This xAI system design prompt asks candidates to construct a robust analytics pipeline that ingests social media data, computes critical engagement metrics, and packages the entire service for scalable deployment. Key engineering requirements include building reliable traffic throttling mechanisms to respect external API boundaries and containerizing the architecture using Docker for seamless portability. The scenario evaluates system resilience, rate-limiting algorithms, and modern deployment practices. Access to the comprehensive design walkthrough, architectural diagrams, and expert recommendations requires a paid subscription.
xAIreported July 2026Architect a secure document storage and management platform inspired by real-world system design interviews at Harvey. This challenge focuses heavily on establishing robust organization-level access control lists and handling scalable file handling for digital assets. You will learn how to design reliable storage hierarchies and security boundaries while addressing enterprise-grade data governance requirements. Gain access to the comprehensive system architecture guide and expert recommendations through our subscription.
Harveyreported October 2026This distributed systems design interview question from Databricks asks you to architect an external fan-out broker service that queries dozens of third-party APIs concurrently to find the best price for customers. You will need to address high-scale concurrency, asynchronous communication, timeout handling, and fallback pricing logic within a robust architecture. The scenario evaluates your capability to build resilient systems that depend on external, unreliable services. The full architectural breakdown and expert solution require a subscription.
Databricksreported June 2026This Databricks machine learning architecture exercise challenges candidates to design a robust pipeline for intercepting and filtering objectionable text generated by large language models. The problem explores dataset curation, handling severe class imbalance, multi-modal classification trade-offs, and continuous monitoring against adversarial model drift. Furthermore, it addresses policy governance, human-in-the-loop oversight, and automated threshold tuning. To explore the detailed system blueprint and comprehensive architectural solution, a paid subscription is necessary.
Databricksreported April 2026Based on system architecture interviews at Stripe, this challenge centers on designing a highly resilient webhook notification service for financial transactions. You will explore core distributed systems concepts such as reliable at-least-once message delivery, automatic retry mechanisms, idempotent consumer patterns, and cryptographic signature verification to ensure secure merchant communication even during server outages. Access the comprehensive architectural guide and implementation strategies by subscribing today.
Stripereported December 2025Designed around real-world scenarios at Atlassian, this machine learning architecture challenge focuses on building an intelligent internal discovery platform that parses employee queries, extracts intent, and retrieves contextual enterprise data. It evaluates your skills in designing retrieval-augmented generation pipelines and search systems at scale. Access the comprehensive architectural breakdown and expert recommendations with a subscription.
Atlassianreported February 2026Explore a complex system architecture challenge reported from NVIDIA interviews focusing on the secure design of a natural language interface for database querying. The scenario requires balancing user accessibility with strict authorization boundaries, ensuring that generated queries respect enterprise permission levels while protecting downstream data infrastructure from catastrophic resource exhaustion. Candidates must address query validation, mitigation of hallucinated syntax, and resource management to prevent cluster instability. Gain full access to the complete design blueprint and expert recommendations with a subscription.
NVIDIAreported July 2026Reported as a Microsoft system design question, this exercise focuses on engineering a dependable orchestration platform capable of running complex data workflows on strict chronological triggers. Candidates must devise mechanisms to handle job dependencies, automatic failure recovery, precise execution timing, and administrative oversight for thousands of concurrent tasks. The evaluation targets distributed locking, fault resilience, state management, and scalability under heavy spikes. Unlocking the complete system architecture and expert solution requires a paid subscription.
Microsoftreported January 2026Presented as a system design challenge at Snowflake, this problem centers on architecting an asynchronous AI pipeline that handles long-running tasks reliably. You are asked to design an infrastructure capable of ingesting event tickets, buffering requests through message queues, tracking states, and preventing duplicate processing during retries. This scenario tests your understanding of distributed systems, database schema design, fault tolerance, and scalability patterns. Access the full design breakdown and expert architectural solutions with a subscription.
Snowflakereported June 2026Designing modern, feature-rich user-facing interfaces with integrated generative capabilities is a standard engineering management system design challenge, as reported in interviews at DoorDash. This exercise evaluates your ability to architect a scalable customer review platform complete with multimedia handling, flexible filtering, infinite scrolling, and automated sentiment distillation running on a regular cadence. Leaders must carefully balance infrastructure costs, API latency, and algorithmic freshness while scoping trade-offs effectively. Unlocking the complete architectural guide and expert design breakdown requires an active subscription.
Companies in this list
FAQ
- How is FDE system design different from a standard system design interview?
- Standard rounds usually let you assume a greenfield system you own. FDE rounds put the system inside a customer's environment, so identity, permissions, integration with systems you cannot change, data residency and rollout carry much more weight than raw scale.
- Do I need to know RAG and agents for this round?
- For AI-focused companies, usually yes: many reported design questions are assistants or pipelines around a model. Know retrieval, chunking, hybrid search, reranking, evaluation and permission-aware filtering well enough to make and defend choices.
- Should I name specific products?
- Name a category and the property you need ("a vector index that supports filtering during search"), and mention a product only as an example. Interviewers care about the property, and the customer may already have a standard.
- How much time should go to security?
- Enough to make it part of the design rather than an afterthought: often a quarter of the discussion for enterprise deployments. Show where authentication happens, how authorisation is derived and what is logged.
Other FDE rounds
Decomposition
Turn a vague business ask into a scoped, buildable plan: the outcome, the data you really have, the first slice and how you will know it worked.
Practical coding
Working code against messy input: data wrangling, calling a paginated, rate-limited API, and debugging code you did not write.
AI / LLM applications
Build something useful on a model API: structured outputs, retrieval, tools and agents, with an evaluation that proves it works and guardrails for when it does not.
Behavioral & customer
Stories about ownership and judgement, plus live role-plays: a failed demo, an unhappy sponsor, a request you have to turn down.