Easy FDE interview questions

The warm-up that quietly filters out candidates who only know LLMs as a magic API. Nail the two-phase inference picture and you set up every later answer about latency, cost, and hallucinations.

Tokens drive your customer's bill, their latency, and the weird failures like botched arithmetic. The rough numbers every FDE should rattle off, plus the trap answers interviewers listen for.

Everyone can define it; few candidates know why 'advertised context' and 'usable context' aren't the same thing. The cost, latency, and attention caveats that make this answer stand out.

A deceptively simple sampling question with one trap (does temperature 0 fix hallucinations?) and one senior move interviewers reward. Know which workflows want zero.

The concept underneath every RAG system you'll ever deploy. How to explain vectors, cosine similarity, and the one limitation of embeddings that costs real deployments accuracy.

Why a raw base model answers your question with three more questions, what RLHF actually buys, and the niche cases where customers should pick base. A tidy answer most candidates fumble.

Every FDE will face an angry customer asking this. The mechanistic explanation interviewers want (why hallucination is the default behavior, not a bug) plus the framing that defuses customer escalations.

A classic metrics question with a domain twist. The answer isn't 'recall'; it's a cost-of-errors argument plus a threshold strategy, and interviewers grade the reasoning, not the metric you pick.

Three transformer families, one distinction that decides everything: which tokens are allowed to see which. The attention mask is the whole answer, and it explains why GPT generates and BERT does not.

The warm-up that filters out tutorial-level candidates. Interviewers aren't grading the diagram, they're grading whether you know the three places real pipelines fail and how you'd see it happening.

Everyone says '500 tokens with overlap.' The candidates who get hired explain why chunk boundaries are a recall problem, name three strategies, and describe the experiment that picks between them.

Pure vector search fails on the exact queries enterprise users ask most: IDs, error codes, product names. Here's the failure-mode framing that turns a definition question into a design answer.

Arguing against agents reads senior; it's an explicit rubric signal at AI labs. Learn the cost ladder from single call to autonomous loop, and the three conditions that actually justify an agent.

'Evals first' is the #1 hiring signal in FDE design rounds. This is the foundational version: what a 50-case golden set looks like, which metrics split retrieval from generation, and the launch gate that convinces interviewers.

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.

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 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.

Top-K is the most reused primitive in FDE interviews: it reappears inside log parsers, analytics questions, and retrieval ranking. Three solutions exist; knowing which one to lead with is the real test.

Looks like a sliding-window problem; isn't one. The prefix-sum + hashmap trick that solves it is the same idea behind sessionization and cumulative-metrics questions later in the loop: learn it once, reuse it three times.

The gentlest 'design a class' question in FDE screens, and the warm-up interviewers use before rate limiters and sessionization. The deque trick is easy; the API and time-window follow-ups are where the signal is.

Anthropic-style screens open with deceptively simple builds like this, then extend them three times. The grade isn't the counting; it's whether your first version survives the extensions without a rewrite.

Everyone quotes p95 in latency SLOs, but few can compute it without a library and fewer can explain why the index is ceil(p*n)-1, not p*n. The warm-up that screens whether you actually understand the metric you live by.

The arithmetic is three sums; the signal is what you do when a vector is all zeros and the denominator vanishes. The warm-up that gates every RAG and retrieval coding round.

Real LLM logs are JSONL, not JSON, and real log files have a malformed line halfway through. The warm-up that screens whether you can stream a file and aggregate without one bad record nuking the whole run.

Batching inputs is how you keep a GPU fed, but the source is an iterator you cannot index or len(). The warm-up that screens whether you can write a lazy generator that handles the ragged final batch.

A dashboard needs the average tokens/sec over the last N seconds, updated on every sample, forever. The warm-up that screens whether you evict by time and keep a running sum instead of re-summing the window each call.

Every FDE loop opens with this, but the definitions are table stakes. What gets scored is whether you can map each metric to a dollar cost the customer recognizes, here's the framing that does it.

A 0.95 AUC model can still flood a review queue with garbage. Knowing when ROC AUC flatters a model, and what to report instead, separates FDEs who've shipped from those who've only run notebooks.

The textbook answer gets a polite nod. The version that names which side of the tradeoff a 6-week customer pilot usually dies on gets the hire signal, here's that version.

"Use regularization" is the answer everyone gives. The ordered toolbox, and which tool to reach for first when a customer's pilot model collapses in week two, is what actually gets scored.

Everyone can describe the five folds. The question is really about the second half, the two data shapes, both everywhere in enterprise data, where standard k-fold quietly lies to you.

A two-minute explanation, then the real test: learning-rate pathologies, why we use mini-batches, and the one practical diagnosis, reading a loss curve, that customer-facing engineers actually need.

Every RAG deployment runs on this math, and most candidates can't say why cosine beats Euclidean, or when the two are secretly identical. The 90-second version with a worked example.

Unsupervised questions filter out candidates who've only done Kaggle. The elbow method is the warm-up, the real scoring is on validation without labels and the marketing-team handoff.

Most working data scientists state the definition wrong, and interviewers know exactly which wrong versions to listen for. The correct one-sentence definition, the VP translation, and the three classic traps.

The honest version: deep learning learns its own features but is hungry for data and compute, and on a customer's 50,000-row tabular dataset a gradient-boosted tree wins on accuracy, cost, and time-to-ship. The dividing line and the conditions that flip it.

A Type I error blocks a real invoice; a Type II error delivers the phishing email. Which one costs the customer more decides where you set the threshold. The spam-filter framing, the precision/recall mapping, and the asymmetric-cost call interviewers want.

A confusion matrix is the 2x2 of right and wrong predictions per class, and it is the reason a 99% accurate fraud model can be useless. The worked imbalance example, and how reading the matrix as precision and recall fixes the lie.

The validation set is the one you tune and select on; the test set is the one you only look at once. Confusing them, or tuning so hard you overfit the validation set, is how a model that aced offline metrics dies in production.

The classic SQL screener at Snowflake and Meta. Everyone can recite the definitions, interviewers are listening for the one scenario where picking the wrong function silently corrupts your results.

A 40-year-old SQL classic that still filters out half of candidates, because of ties, NULLs, and departments with one employee. The interview-proof solution fits in six lines.

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 most common bug in analyst SQL, and a favorite warm-up in Retool's debugging-flavored screens. One word's placement, ON vs WHERE, silently deletes your unmatched rows.

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.

Asked constantly because it tests whether you understand aggregation rather than syntax. The CASE-inside-aggregate idiom works on every engine, plus when to reach for Snowflake's PIVOT and its dynamic variant.

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.

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 two reported Snowflake SQL-screen warmups. Both look trivial; both have a silent-failure trap, integer division and divide-by-zero in one, the EXTRACT(MONTH) year-collision in the other.

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.

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.

One malformed message can silently wedge an entire pipeline, and it happens at every customer eventually. The DLQ answer interviewers want covers what most candidates forget: what happens *after* the message lands there.

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.

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 'thanked you later' clause is the trap, it rules out both the pushover story and the stubborn-engineer story. What's left is a specific skill, and interviewers know exactly what it sounds like.

Graded on two things most engineers never practice: the quality of the analogy and knowing when to stop. Here's a two-minute script that lands with a legal exec, and the depth trap to avoid.

Say 'yes' and you've failed the integrity test; say 'no' flatly and you've failed the deal. The pass is a three-beat answer that turns the question into the reason to buy. Here's the script.

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.

Sounds like a softball; it's a filter. 'I read newsletters and follow people on X' is the answer that loses. Interviewers are listening for a system with a build loop, here's one you can describe and actually run.

The CFO ran the same prompt twice and got two answers, and now thinks the system is broken. The analogy that lands in one sentence, the honest framing that keeps trust, and the exact case where you'd set temperature to zero to make it repeat.

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.

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.

The standard AWS ML Engineer opener. Most candidates recite 'data and model versioning' and stall, the answer interviewers score highest explains why ML tests can't be pass/fail and what continuous training adds as a third loop.

An experience probe that sinks more candidates than any design question, because a vague answer ends the interview early. The four-plane structure that proves you're an operator, not a data scientist with MLOps on the resume.

A textbook screen with a non-textbook scoring rubric. Naming Tracking, Projects, Models, and Registry gets you a pass, knowing which component nobody actually uses, and why, gets you the offer conversation.

The trap is that S3 versioning sounds like a complete rebuttal, it isn't, and interviewers at banks know exactly why. What a registry adds that storage never can, and the audit question that decides regulated-industry offers.

Candidates describe a feature store as 'a database for features' and fail, it's a consistency machine with two faces. The online/offline split, the latency numbers each side must hit, and when you shouldn't build one.

They answer different questions, and mixing them up costs you the round: one tests your engineering, the other tests your model's business impact. What each can and cannot catch, and the order a strong candidate always runs them in.

A real interview question designed to catch resume inflation: candidates say 'we promote to production' and can't name the API call. What actually moves when a model is promoted, and the answer that proves you've done it.

The NVIDIA warm-up that exposes whether you've written a kernel or just called .cuda(). The mapping from software hierarchy to silicon explains every GPU performance conversation that follows.

Kernel optimization is mostly the art of feeding 100+ TFLOPs from the small fast end of this hierarchy. Know the rough latencies and bandwidths, interviewers listen for the numbers.

A staple NVIDIA screen with a precise mechanical answer, and a follow-up trap about which branches actually diverge that catches most candidates.

Sounds like small talk; it's actually a depth probe with follow-ups pre-loaded. A scoping framework that works whether you've run 4 GPUs or 4,000, and the bluff that ends interviews.

The resume-walk question for infra roles, with a hidden rubric: layer ownership, scale fluency, and one defensible war story. How to answer credibly at any actual scale, and the inflation tells interviewers catch.

Why the batch is a pool of decode slots, not a bus that waits until it's full. The mental-model shift behind every modern serving stack, and the scheduling tradeoffs interviewers push on next.

OWASP's LLM01 is the opening question of nearly every AI security screen. Most candidates can define direct injection; the ones who get hired explain why indirect injection is the one that ruins enterprise deployments.

Candidates use these terms interchangeably and security interviewers notice immediately. The distinction, whose policy is being violated, drives completely different defenses, and that's the actual question.

OWASP made system prompt leakage its own category (LLM07) because teams keep treating prompts as secrets. The strong answer flips the premise: design so extraction doesn't matter.

OWASP LLM06 is where AI security stops being novel and becomes a least-privilege problem, which is exactly why interviewers love it. The control list is short; knowing which control to lead with is the test.

A deceptively simple screener: each detection method maps to a PII class, and the 'why not regex for names' sub-question has a precise answer about structure vs context that interviewers use as the pass bar.

The most-asked question in every enterprise AI deal, and precision is pass/fail: the contractual answer, what ZDR actually changes, and the retention nuance that separates FDEs from demo engineers.

SOC 2 fluency is the price of admission to enterprise deals, and interviewers check it with two traps: what a SOC 2 report actually proves, and what it doesn't. Engineers who can read one are rarer than you'd think.