fundamentals

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.

Modern LLMs share one architectural skeleton. Learn the five components and you can read almost any model card cold, plus the single distinction that proves to an interviewer you actually understand it rather than the buzzwords.

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.

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.

Rotary embeddings encode position as a rotation of the query and key vectors, so attention scores depend only on the gap between two tokens. That relative property is why RoPE generalizes past its training length where learned absolute tables fall off a cliff.

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.

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.

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.

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.

C3.ai's reported classical-ML screen pair. Textbook recitation passes; what scores is one practical consequence per assumption, and knowing the random-forest failure mode that bites industrial deployments: no extrapolation.

Backprop is just the chain rule run efficiently in reverse, but the question that separates levels is why a hundred-layer network trains when a naive one wouldn't. The credit-assignment intuition plus the three tricks that keep gradients alive.

Convolution and parameter sharing are why a CNN needs a tiny fraction of the weights a dense net would, and why it generalizes across position. The conceptual answer, the feature-hierarchy picture, and the honest take on when a fine-tuned CNN still beats reaching for a giant vision-language model.

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

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.

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.

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.

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.

The backbone question of every frontier-lab infra loop. The answer that scores is organized around what each strategy communicates and how often, not just what it splits.