AI Engineer

 

The Complete AI Engineer Interview Roadmap

Covers all experience levels (fresher → senior) and all four role flavours: GenAI/LLM apps & RAG, Classical ML/MLE, Deep learning modelling, AI infra/MLOps.

How to use this: read Part 1–3 once to locate yourself, then live in Part 5 (study plan) and Part 7 (question bank). Nobody needs 100% of this document. The Core items are non-negotiable for every track.


Part 1 — What an "AI Engineer" loop actually looks like

Job titles are noise. Read the JD and classify the role before you prep, because the loops differ.

Round What they test Who runs it
Recruiter screen Comp, notice period, basic story Recruiter
Coding Python fluency, DSA-lite, "implement X from scratch" Engineer
ML/DL fundamentals Do you understand what you use Senior engineer / scientist
Project deep dive Is your resume real Hiring manager
ML / GenAI system design Can you ship, not just train Senior/staff
Take-home or live build Practical delivery Team
Behavioural / bar-raiser Ownership, judgement, collaboration HM / cross-team

How to classify the JD in 60 seconds:

  • Words like RAG, agents, prompt, LangChain, vector DB, LLM APIs, evalsGenAI/LLM track. Expect light DSA, heavy system design + product judgement. Often no math round.
  • XGBoost, feature engineering, A/B test, forecasting, churn, ranking, SQLClassical ML/MLE track. Expect stats, metrics, SQL, and ML system design.
  • PyTorch, training, CUDA, architecture, papers, fine-tuning, CV/NLPDL modelling track. Expect real depth on backprop, transformers, training dynamics.
  • Kubernetes, Triton/vLLM, latency, throughput, monitoring, pipelines, TerraformAI infra/MLOps track. Expect distributed systems + deployment + observability.

Many real roles are a blend of two. Prep the blend, not all four at max depth.


Part 2 — The skill map (8 pillars)

Rate yourself 1–5 on each. Anything ≤3 that is Core or in your track becomes a study block in Part 4.

1. Programming & Python Idiomatic Python (comprehensions, generators, decorators, context managers, dataclasses, typing, asyncio), NumPy vectorisation, pandas, OOP, error handling, testing with pytest, Git, virtualenv/uv/poetry, reading a stack trace.

2. Math you actually get asked Linear algebra (matrix multiply shapes, dot product, eigenvectors, SVD intuition), probability (Bayes, conditional probability, distributions, expectation), statistics (hypothesis testing, p-values, confidence intervals, sampling bias), calculus (gradients, chain rule, why gradients vanish), optimisation (convexity, GD variants). You will not be asked to prove theorems. You will be asked why things work.

3. Classical ML Bias–variance, over/underfitting, regularisation, cross-validation, metrics & their failure modes, class imbalance, feature engineering, leakage, tree ensembles, linear/logistic models, clustering, dimensionality reduction, calibration, interpretability.

4. Deep learning Backprop, initialisation, normalisation, dropout, optimisers, LR schedules, residual connections, CNNs, RNN→attention→transformer, tokenisation, pretraining objectives, fine-tuning, training instabilities.

5. LLMs & GenAI engineering Prompting techniques, structured outputs, context engineering, RAG end-to-end, embeddings & vector search, reranking, agents & tool use, memory, guardrails, evals, cost/latency optimisation, fine-tuning vs RAG vs prompting decisions.

6. Data engineering (enough of it) SQL (joins, group by, window functions, CTEs), batch vs streaming, ETL/ELT, data quality checks, partitioning, warehouses vs lakes, Spark basics, Airflow/Dagster/Prefect concepts.

7. MLOps, serving & infra Experiment tracking, model & data versioning, model registry, CI/CD for ML, containers & K8s, deployment patterns, serving stacks, GPU memory math, distributed training, monitoring & drift, retraining, cost control, incident response.

8. Communication & product sense Structured answers, clarifying questions, tradeoff articulation, whiteboard/verbal design, metric definition, stakeholder framing, STAR stories, saying "I don't know" cleanly.


Part 3 — The bar by level

The topics barely change across levels. What changes is scope of ownership and how much ambiguity you can absorb.

Fresher / 0–1 yr

  • They're buying: raw fundamentals + evidence you can build something end-to-end without hand-holding.
  • Must clear: clean Python, ML basics explained in your own words, 2–3 real projects you can defend line by line, one deployed thing (even a Streamlit/FastAPI app on a free tier).
  • Weighting: coding 30%, fundamentals 40%, projects 25%, design 5%.
  • Kills candidacy: tutorial projects with no metrics, "I used LangChain" with zero understanding of what it did, no baseline comparison.
  • Your unfair advantage: a small, sharp, deployed project with an eval harness. Almost no fresher does evals. It reads as 2 years of experience.

1–3 yrs

  • They're buying: someone who ships features independently.
  • Must clear: everything above plus real debugging stories, familiarity with production pain (latency, cost, data quality, a model that degraded), the ability to sketch a simple end-to-end system.
  • Weighting: coding 25%, fundamentals 30%, projects 25%, design 20%.
  • Kills candidacy: notebook-only experience; no clue how your model was served or monitored.

3–6 yrs

  • They're buying: an owner of a system or a workstream.
  • Must clear: strong ML/GenAI system design, tradeoff fluency with numbers attached, cross-functional stories, mentoring evidence, at least one project you drove from ambiguity to production impact.
  • Weighting: design 35%, projects/impact 30%, fundamentals 20%, coding 15%.
  • Kills candidacy: narrating what the team did instead of what you decided; no cost/latency awareness; no failure story.

6+ yrs / senior & staff

  • They're buying: judgement, leverage, and risk reduction.
  • Must clear: architecture across multiple services, build-vs-buy calls, capacity and cost modelling, platform thinking, hiring/mentoring, influence without authority, technical strategy narrative.
  • Weighting: design & strategy 45%, leadership/impact 30%, depth spot-checks 25%.
  • Kills candidacy: hand-waving on depth ("the team handled that"), no opinions, no evidence of changing an org's direction.

One rule at every level: every claim on your resume must survive three "why" questions.


Part 4 — Track deep dives: what "deep enough" means

Track A — GenAI / LLM apps & RAG

Prompting & context Zero/few-shot, chain-of-thought, self-consistency, role & delimiter discipline, output schemas (JSON mode / function calling / constrained decoding), prompt versioning. Context engineering: what goes in the window, in what order, and what you evict. Know why stuffing a 200k window is often worse and pricier than retrieving 6 good chunks.

RAG, properly

  • Ingestion: parsing (PDF tables are where projects die), cleaning, deduplication, metadata extraction.
  • Chunking: fixed-size, recursive, semantic, parent-document / small-to-big, sentence-window. Be able to defend a choice with an example.
  • Embeddings: model choice, dimensionality, domain mismatch, normalisation, when to fine-tune embeddings, multilingual cases.
  • Vector search: HNSW vs IVF-PQ vs flat, recall/latency/memory tradeoffs, filtering + ANN interactions, pgvector vs a dedicated store.
  • Retrieval quality: hybrid search (BM25 + dense), reciprocal rank fusion, cross-encoder reranking, query rewriting, HyDE, multi-query, decomposition.
  • Generation: grounding, citations, refusal when context is insufficient.
  • Evaluation — the part that separates seniors from demo-builders: a golden set, retrieval metrics (recall@k, MRR, nDCG, context precision/recall), generation metrics (faithfulness, answer relevance), LLM-as-judge with its biases (position, verbosity, self-preference), regression testing in CI, human review loops.

Agents Tool/function calling, ReAct loop, planner–executor, reflection, multi-agent handoffs, MCP-style tool interfaces. Failure modes you must name: infinite loops, tool-call hallucination, error cascading, cost explosion, unbounded latency. Controls: step budgets, timeouts, retries with backoff, validation of every tool output, human-in-the-loop gates, idempotency for write actions.

Safety & guardrails Prompt injection (direct and indirect via retrieved documents), jailbreaks, data exfiltration through tools, PII redaction, output validation, allow-lists, sandboxing, rate limits, audit logs, tenant isolation in multi-tenant RAG.

Ops Latency budget decomposition (retrieval vs prefill vs decode vs reranking), streaming, exact + semantic caching, prompt caching, model routing (cheap model first, escalate), batching, token accounting and unit economics (cost per query, cost per resolved ticket), observability & tracing.

Decision framework to have memorised: prompt → few-shot → RAG → tool use/agents → fine-tune. Fine-tuning buys behaviour, format and style; RAG buys knowledge and freshness. Never fine-tune to add facts if the facts change.

Track B — Classical ML / MLE

  • Problem framing: business metric → ML metric → label definition → data availability. The label definition question ("what exactly counts as churn?") wins interviews.
  • Metrics: precision/recall/F1, ROC-AUC vs PR-AUC (use PR-AUC on heavy imbalance), log loss, threshold selection by business cost, regression metrics (MAE/RMSE/MAPE and when MAPE lies), ranking metrics (nDCG, MAP), calibration (reliability curves, Platt, isotonic) and why calibration matters when scores drive decisions.
  • Validation: k-fold, stratified, grouped, time-based splits, nested CV, and every flavour of leakage (target leakage, temporal leakage, group leakage, preprocessing before splitting, duplicate rows across folds).
  • Imbalance: class weights, resampling, SMOTE and its limits, focal loss, threshold moving, anomaly-detection framing.
  • Models: linear/logistic with regularisation, decision trees and split criteria, bagging vs boosting, GBDT mechanics (XGBoost/LightGBM/CatBoost differences: histogram splitting, leaf-wise growth, categorical handling), SVM kernels, k-NN, Naive Bayes, k-means/DBSCAN/GMM, PCA. Tabular truth: gradient boosting usually beats deep learning; know why.
  • Feature work: encodings (one-hot, target/mean with CV folds, hashing), scaling, missing-value strategy, outliers, interactions, time features, aggregation windows, feature selection.
  • Explainability: feature importance pitfalls, permutation importance, SHAP, partial dependence.
  • Experimentation: A/B testing, sample size & power, novelty effects, guardrail metrics, interference, sequential testing dangers, offline–online metric gaps.
  • SQL: you will be asked. Window functions and multi-table joins at minimum.

Track C — Deep learning modelling

  • Fundamentals: backprop by hand on a tiny network, computational graphs, initialisation (Xavier/He), vanishing/exploding gradients, gradient clipping, BatchNorm vs LayerNorm vs RMSNorm (and why transformers use pre-LN), dropout, weight decay, label smoothing, loss functions and when each applies.
  • Optimisation: SGD+momentum, Adam vs AdamW, warmup + cosine decay, batch size ↔ LR relationship, gradient accumulation, mixed precision (FP16/BF16) and loss scaling.
  • Architectures: CNNs (receptive field, stride/padding arithmetic, ResNet), sequence models (RNN/LSTM limits), transformers in full detail — QKV projections, scaled dot-product attention and why the √d scaling, multi-head purpose, causal masking, positional encodings (sinusoidal, learned, RoPE, ALiBi), FFN block, encoder vs decoder vs encoder-decoder, MHA vs MQA vs GQA, KV cache mechanics and its memory cost, FlashAttention's contribution, MoE routing.
  • LLM lifecycle: tokenisation (BPE/WordPiece/SentencePiece), pretraining objectives (causal LM vs masked LM), scaling laws intuition, SFT, instruction tuning, PEFT (LoRA rank/alpha/target modules, QLoRA), alignment (reward modelling + PPO, DPO, and newer preference methods), catastrophic forgetting, data curation and contamination.
  • Efficiency: quantisation (post-training INT8/INT4, GPTQ/AWQ, QAT), pruning, distillation, speculative decoding, paged attention & continuous batching.
  • Debugging drills — expect these as questions: loss is NaN; loss won't go down; train loss falls but val loss rises; val loss lower than train loss; model works in notebook, fails in prod; great offline metrics, bad user outcomes. Have a diagnostic sequence for each.
  • Domain extras: CV (augmentation, detection/segmentation heads, ViT), NLP (NER, classification, seq2seq, evaluation beyond accuracy), multimodal (CLIP-style contrastive training).

Track D — AI infra / MLOps

  • Pipelines: orchestration (Airflow/Dagster/Prefect/Kubeflow), idempotency, backfills, retries, data contracts, schema evolution, lineage.
  • Reproducibility: experiment tracking, config management (Hydra), data/model versioning, seeds, environment pinning, model registry with stage promotion.
  • Serving: REST/gRPC, batch vs real-time vs streaming, TorchServe/Triton/BentoML/Ray Serve/KServe, vLLM/TGI for LLMs, continuous batching, autoscaling and cold starts, GPU sharing, multi-model serving, canary/shadow/blue-green rollouts.
  • GPU literacy: memory math (params + gradients + optimiser states + activations; ~2 bytes/param at BF16 for weights, and know why Adam roughly triples training memory), throughput vs latency, DDP vs FSDP vs DeepSpeed ZeRO stages, tensor/pipeline/sequence parallelism, communication overhead, profiling.
  • Monitoring: service metrics (p50/p95/p99, error rate, saturation), data drift (PSI, KL, KS test), concept drift, prediction drift, delayed labels, alert design that doesn't cry wolf, retraining triggers, rollback plans, on-call runbooks.
  • Governance & cost: access control, PII handling, audit trails, model cards, cost per prediction, spot instances, right-sizing, capacity planning.

Part 5 — The study plan

No deadline means you get the version that actually builds durable skill instead of cramming. 12 weeks at ~10–12 hrs/week. Compressed variants follow.

The weekly rhythm (keep this constant)

Slot Time Activity
Concept study 3 hrs Read/watch one topic cluster, take notes in your own words
Hands-on 4 hrs Code it. Notebook or repo. No passive learning.
Drills 2 hrs 4–6 coding problems or 15 flashcard-style Q&A out loud
Retrieval + writing 1 hr Close everything, write last week's topics from memory. Fix gaps.
Mock/verbal 1 hr Explain 2 topics aloud on camera, or one mock round from week 7 onward

Two rules: explain out loud (silent understanding collapses under interview pressure), and maintain a mistakes log you re-read every Sunday.

Phase 0 — Weeks 1–2: audit + foundations

  • Score yourself on the 8 pillars. Pick your track blend from the JDs you're actually targeting.
  • Python tune-up: 20 problems on arrays/strings/hashmaps + write one small class-based module with tests.
  • NumPy/pandas drills: vectorisation, groupby-agg, merges, reshaping, no-loop challenges.
  • Math refresh, applied only: matrix shapes in a forward pass, Bayes problems, gradient of a simple loss by hand, hypothesis test on a toy dataset.
  • SQL: 15 queries ending in window functions.
  • Deliverable: a one-page skills gap doc + your target-role classification.

Phase 1 — Weeks 3–4: classical ML (Core, all tracks)

  • Week 3: bias–variance, regularisation, CV strategies, leakage, metrics deep dive, imbalance, calibration.
  • Week 4: linear/logistic, trees, bagging vs boosting, GBDT internals, clustering, PCA, SHAP.
  • Hands-on: take one tabular dataset. Build a dumb baseline → logistic regression → LightGBM. Log metrics, plot PR curves, tune a threshold against a made-up business cost, run SHAP. Write a README explaining every decision.
  • Deliverable: one repo where the README is more impressive than the model.

Phase 2 — Weeks 5–6: deep learning & transformers

  • Week 5: backprop from scratch in NumPy (2-layer MLP, no autograd), initialisation, normalisation, optimisers, LR schedules, overfitting controls. Then PyTorch: dataset/dataloader, training loop, checkpointing, mixed precision.
  • Week 6: attention and transformers. Implement scaled dot-product attention, multi-head attention, and a tiny character-level GPT from scratch. Then read the architecture papers — they land completely differently after you've coded it.
  • Drill the debugging scenarios from Part 4C until diagnosis is reflexive.
  • Deliverable: a from-scratch mini-transformer repo + a fine-tuning notebook (LoRA on a small model or a BERT-family classifier).

Phase 3 — Weeks 7–8: LLMs & GenAI engineering

  • Week 7: prompting, structured outputs, embeddings, vector search internals, chunking strategies, hybrid retrieval, reranking. Build a RAG system without a framework first (raw API + your own retrieval), then rebuild with a framework so you can compare honestly.
  • Week 8: evals (golden set, retrieval + generation metrics, LLM-as-judge, CI regression), agents & tool calling with step budgets and validation, guardrails, caching, cost/latency instrumentation.
  • Start mock interviews this phase, even if you feel unready. Feeling unready is the point.
  • Deliverable: a RAG or agent app with a real eval harness, a metrics table, and a documented cost-per-query figure.

Phase 4 — Weeks 9–10: MLOps, serving & system design

  • Week 9: FastAPI service → Docker → deploy somewhere real. Add tracking (MLflow/W&B), a model registry step, CI that runs tests + evals, and monitoring with drift checks and a dashboard.
  • Week 10: system design practice. 8 designs written out, 4 delivered aloud on a whiteboard. Mix: recommendation feed, fraud detection, search ranking, content moderation, enterprise doc QA over 10M documents, a support agent with actions, a multi-tenant RAG platform, an LLM eval platform.
  • Deliverable: one deployed, monitored service + a folder of 8 design write-ups.

Phase 5 — Weeks 11–12: polish, stories, mocks

  • Rewrite your resume metric-first (Part 9). Rebuild your project narratives.
  • Write 10 STAR stories covering: hardest technical problem, a failure, a disagreement, a deadline call, mentoring, an ambiguous problem you scoped, a cost/latency win, a data-quality save, a wrong decision you reversed, something you shipped end-to-end.
  • 6–8 full mock rounds across coding, fundamentals, design, behavioural. Record them. Watch them, however unpleasant.
  • Re-read your mistakes log. Close the top 10 gaps only.
  • Deliverable: interview-ready. Start applying in week 11, not week 13 — real loops are the best mocks and early rejections are cheap data.

After week 12 — maintenance loop (2–4 hrs/week)

One paper or release note per week, one design problem per fortnight, weekly coding drills, ship a small improvement to a portfolio project monthly, keep the mistakes log alive.

Compressed variants

~1 month (crunch, ~20 hrs/week)

  • Wk 1: metrics, validation, leakage, imbalance, GBDT + Python/SQL drills.
  • Wk 2: transformers end-to-end, attention implemented by hand, fine-tuning concepts, debugging drills.
  • Wk 3: RAG + evals + agents + guardrails; build one strong project; instrument cost/latency.
  • Wk 4: 6 system designs, 10 STAR stories, 5 mocks, resume rewrite. Cut: from-scratch backprop, deployment polish, breadth reading.

1–2 weeks (interview already scheduled) Do only this, in order: (1) drill your own projects until every "why" is answered with a number; (2) 30 highest-frequency Q&A from Part 7, out loud; (3) 3 system designs matching the company's domain; (4) 8 coding problems + 3 "implement from scratch" classics; (5) 6 STAR stories; (6) research the company's product, stack and recent launches, and prepare 5 questions to ask them.


Part 6 — Round-by-round playbook

6.1 Coding round

What shows up: easy/medium DSA (arrays, strings, hashmaps, two pointers, sliding window, binary search, trees, graphs BFS/DFS, heaps, light DP), pandas/NumPy manipulation, SQL, and — very commonly for AI roles — implement-from-scratch.

Practise these from-scratch classics until they're muscle memory: cosine similarity · softmax (with the max-subtraction trick) · sigmoid + binary cross-entropy · linear regression with gradient descent · logistic regression · k-means · k-NN · one decision-tree split by Gini/entropy · train/val split with stratification · precision/recall/F1/AUC by hand · scaled dot-product attention · layer norm · a PyTorch training loop from an empty file · a mini BPE tokeniser · a minimal RAG retrieve-and-answer function · a batched embedding call with retry and rate limiting.

Method: restate the problem → state your approach and complexity before typing → narrate while coding → test with a normal case, an empty input, and one edge case → then discuss optimisation. Silence is the only real failure mode.

6.2 ML/DL fundamentals round

Rapid-fire, and they will push until you hit your limit — that's the design of the round, not a sign you're failing.

Answer shape: definition → why it matters → concrete example → tradeoff/failure case. 30–60 seconds, then stop. Rambling reads as uncertainty.

When you don't know: "I haven't worked with that directly. Based on X, I'd expect it to work like Y — is that the right intuition?" That answer scores well. Bluffing scores zero and invites a deeper probe.

6.3 Project deep dive (highest ROI round, most neglected)

For each resume project, be ready with:

  1. Problem and why it mattered to the business.
  2. Your specific contribution vs the team's.
  3. Data: source, volume, quality issues, labelling.
  4. Baseline you compared against — and the number.
  5. Modelling choices and the alternatives you rejected, with reasons.
  6. Metrics: offline and online, before and after.
  7. How it was served, its latency and cost.
  8. What broke, how you found out, how you fixed it.
  9. What you'd do differently with hindsight.
  10. Impact in a unit a non-ML person cares about.

Rehearse a 90-second version and a 10-minute version of each. If you cannot produce a number, produce an honest estimate and label it as one.

6.4 ML system design round

Use this skeleton and say the section names out loud — interviewers grade structure:

  1. Clarify (2–4 min): users, scale (QPS, data volume, growth), latency budget, online vs batch, existing infra, cost ceiling, success definition. Never start designing without this.
  2. Frame as ML: business metric → ML metric → label definition → what a prediction unit is. Also state whether ML is even the right tool.
  3. Data: sources, volume, labelling strategy, features, freshness, training/serving skew, privacy.
  4. Baseline first: rules or a simple model. Always. Then justify complexity.
  5. Model: candidates + your pick + why. Two-stage (candidate generation → ranking) where it applies.
  6. Training: cadence, data windows, validation strategy respecting time, offline evaluation.
  7. Serving: architecture sketch, batch vs real-time, feature retrieval, caching, fallbacks when the model is down.
  8. Monitoring: metrics, drift, alerts, retraining triggers, rollback.
  9. Iterate: A/B design, guardrail metrics, what you'd build in v2.
  10. Tradeoffs & bottlenecks: name the weakest part of your own design before they do. This is the single highest-signal move in the round.

6.5 GenAI system design round

Same skeleton, different content emphasis:

  • Requirements: accuracy expectations, latency budget, cost per query, data sensitivity, multi-tenancy, languages, compliance.
  • Ingestion & indexing pipeline (including re-indexing and incremental updates).
  • Retrieval design with hybrid search + reranking, and metadata filtering / access control per user.
  • Generation with grounding, citations, refusal behaviour, structured output.
  • Evaluation harness and how it gates deploys. Bring this up unprompted; most candidates don't.
  • Guardrails including indirect prompt injection through retrieved docs.
  • Cost & latency model with a rough per-query calculation.
  • Observability, feedback capture, and the improvement loop.
  • Build-vs-buy and model-choice reasoning, plus how you'd swap models without a rewrite.

6.6 Take-home / live build

Scope ruthlessly. Ship working > ship clever. Non-negotiables: a README with your reasoning and tradeoffs, a documented "what I'd do with more time" section, tests on the critical path, reproducible setup, and an evaluation of your own output. A modest solution with honest evaluation beats an ambitious one with none.

6.7 Behavioural / bar-raiser

STAR, with Result carrying a number. Own failures without self-flagellation, and state the lesson as a changed behaviour. Prepare a genuine disagreement story where you were persuaded, and one where you persuaded — both matter. Have 5 questions ready that only someone who studied the company could ask; "how do you evaluate model quality today?" is a great one for AI teams.


Part 7 — Question bank with answer skeletons

Answer these out loud. If it takes more than 60 seconds, you don't know it yet.

Classical ML

  1. Bias vs variance, and how you'd diagnose which you have? → Compare train vs val error; high both = bias, big gap = variance. Fixes differ (capacity/features vs data/regularisation).
  2. Why can accuracy be useless? → Class imbalance; 99% accuracy on 1% positives by predicting all-negative. Use PR-AUC, recall at fixed precision, cost-weighted thresholds.
  3. ROC-AUC vs PR-AUC? → ROC is insensitive to imbalance because it uses TNR; PR focuses on the positive class. Heavy imbalance → PR-AUC.
  4. L1 vs L2? → L1 gives sparsity and feature selection (corner solutions); L2 shrinks smoothly and handles correlated features better.
  5. What is data leakage, with three examples? → Information at train time unavailable at prediction time: scaling fitted before the split, future-derived features, duplicate/grouped rows across folds.
  6. Cross-validation for time series? → Forward-chaining/rolling-origin splits; never shuffle; respect gaps for label delay.
  7. Bagging vs boosting? → Bagging reduces variance via parallel independent learners; boosting reduces bias via sequential error-correction and is more overfit-prone.
  8. Why does GBDT beat neural nets on tabular data? → Handles heterogeneous, unscaled features and non-smooth relations with far less data and tuning; NN inductive biases suit perceptual data.
  9. How do you handle class imbalance? → Threshold tuning first (cheapest), class weights, resampling, focal loss, better metrics, and reframing as anomaly detection if extreme.
  10. What is calibration and when do you need it? → Predicted probabilities matching observed frequencies; needed when scores feed decisions/expected-value maths. Fix with Platt or isotonic on held-out data.
  11. Curse of dimensionality? → Distances concentrate, data sparsity rises, sample requirements explode; mitigate with feature selection, regularisation, dimensionality reduction.
  12. Generative vs discriminative models? → Model P(x,y) vs P(y|x); generative can synthesise and handle missing data, discriminative usually wins pure prediction accuracy.
  13. Your model is great offline and bad in production. Why? → Training/serving skew, leakage, distribution shift, feedback loops, wrong offline metric, latency-driven degradation, or a broken feature pipeline.
  14. How would you define the label for churn? → It's a business decision: inactivity window, contract end, or explicit cancellation; state the tradeoff between label noise and actionability.

Deep learning

  1. Walk through backpropagation. → Forward pass caches activations; loss gradient propagates backwards via the chain rule; each layer computes gradients w.r.t. inputs and params; optimiser updates.
  2. Vanishing/exploding gradients — cause and fixes? → Repeated multiplication of small/large Jacobians; fix with ReLU-family activations, He/Xavier init, normalisation, residual connections, clipping, gating.
  3. BatchNorm vs LayerNorm — why do transformers use LayerNorm? → BN normalises across the batch (unstable for variable-length sequences and small batches, and awkward at inference); LN normalises per-sample across features, batch-independent.
  4. Adam vs SGD, and why AdamW? → Adam adapts per-parameter learning rates for faster convergence; SGD+momentum often generalises better. AdamW decouples weight decay from the adaptive update so regularisation behaves as intended.
  5. Why does attention scale by √d_k? → Dot products grow with dimension, pushing softmax into saturated regions with tiny gradients; scaling keeps variance stable.
  6. Purpose of multiple heads? → Attend to different relationships/subspaces in parallel; concatenation gives a richer representation than one large head.
  7. Encoder vs decoder vs encoder–decoder — what suits what? → Bidirectional encoders for understanding/classification, causal decoders for generation, enc-dec for transduction tasks like translation.
  8. What is the KV cache and what does it cost? → Cached keys/values avoid recomputing past tokens during decoding; memory grows linearly with sequence length × layers × heads, which is why long contexts and high concurrency are expensive. MQA/GQA shrink it.
  9. Why positional encodings, and what's RoPE's advantage? → Attention is permutation-invariant. RoPE encodes relative position via rotation, extrapolates better and composes naturally with the dot product.
  10. How does LoRA work and why is it efficient? → Freeze base weights, learn low-rank update matrices on selected projections; drastically fewer trainable params and optimiser states, mergeable at inference, cheap to swap per task.
  11. Fine-tuning vs RAG vs prompting — decide. → Prompting for behaviour with no data; RAG for knowledge, freshness and citations; fine-tuning for consistent format/style/domain skill and latency/cost reduction. Facts that change → RAG.
  12. Loss is NaN. Debug it. → LR too high, bad init, division by zero / log(0), fp16 overflow without loss scaling, corrupted labels, exploding gradients. Isolate by overfitting a single batch first.
  13. Train loss falls, val loss rises. Now what? → Overfitting: more/augmented data, regularisation, early stopping, smaller model, and check for a val-set distribution mismatch or leakage.
  14. Explain temperature, top-k and top-p. → Temperature reshapes the distribution's sharpness; top-k truncates to k tokens; top-p truncates to a cumulative probability mass. Low values for extraction, higher for creative work.
  15. What does quantisation cost you? → Memory and latency wins for some accuracy loss, concentrated on outlier-sensitive layers; INT8 is usually near-lossless, INT4 needs care and evaluation.
  16. Why is inference throughput hard even with a fast GPU? → Decoding is memory-bandwidth-bound and sequential; hence continuous batching, paged attention, speculative decoding.

GenAI / RAG / agents

  1. Design a RAG pipeline end-to-end. → Ingest → parse/clean → chunk → embed → index → hybrid retrieve → rerank → assemble context → generate with citations → log → evaluate → improve.
  2. RAG returns irrelevant chunks. Diagnose systematically. → Inspect retrieval separately from generation: check chunking, embedding-model domain fit, query–document mismatch (add query rewriting/HyDE), missing keyword matching (add BM25), no reranker, wrong k, metadata filters excluding hits, stale index.
  3. How do you choose chunk size? → Empirically against a golden set; balance retrieval precision (small chunks) against sufficient context (large). Small-to-big/parent-document retrieval often resolves the tension.
  4. How do you evaluate a RAG system? → Split retrieval (recall@k, MRR, nDCG, context precision) from generation (faithfulness, answer relevance, citation correctness); golden set + LLM-as-judge with human spot checks; run it in CI as a regression gate.
  5. LLM-as-judge — what are its biases? → Position, verbosity, self-preference, and sensitivity to the rubric. Mitigate with pairwise comparisons, randomised order, explicit rubrics, and human calibration on a sample.
  6. How do you reduce hallucination? → Better retrieval, strict grounding instructions with citations, explicit permission to refuse, structured output validation, lower temperature, verification passes, and eval-driven iteration.
  7. Long context vs RAG? → RAG is cheaper, more auditable, scales past any window and lets you control what the model sees; long context is simpler and better for whole-document reasoning. They compose.
  8. HNSW vs IVF-PQ? → HNSW: graph-based, excellent recall/latency, higher memory. IVF-PQ: compressed, memory-efficient at scale, some recall loss. Choose on corpus size and budget.
  9. When does an agent beat a fixed pipeline? → When the required steps vary per input and tools must be chosen dynamically. If the flow is knowable, hardcode it — cheaper, faster, more reliable.
  10. How do you stop an agent from looping or burning money? → Step/token/time budgets, loop detection on repeated states, validate every tool output, retries with backoff and caps, cost alerts, human approval for writes, idempotency keys.
  11. What is indirect prompt injection? → Malicious instructions embedded in retrieved or fetched content that the model then obeys. Defend with untrusted-content isolation, instruction hierarchies, output validation, tool allow-lists, least-privilege credentials, and never letting retrieved text authorise actions.
  12. How would you cut cost 10x on an LLM feature? → Measure first, then: prompt slimming and context pruning, caching (exact + semantic + prompt caching), model routing/cascades, smaller or fine-tuned models, batching, output-length limits, retrieval instead of stuffing, and self-hosting if volume justifies it.
  13. How do you version and safely ship prompt changes? → Treat prompts as code: version-controlled, tied to an eval suite, gated by regression tests, shipped behind flags with canary traffic and rollback.
  14. How do you enforce structured output reliably? → Native structured-output/function-calling with a JSON schema, validate with a parser, retry with the validation error appended, and keep a fallback path.

MLOps & infra

  1. What is training/serving skew and how do you prevent it? → Different transformation logic or data distributions between train and serve; prevent with shared feature code or a feature store, plus parity tests.
  2. Data drift vs concept drift? → Input distribution changes vs the input→output relationship changing. Detect with PSI/KS on inputs and by monitoring metrics once labels arrive.
  3. Labels arrive 30 days late. How do you monitor? → Proxy signals now (prediction distribution, input drift, business KPIs, user overrides) and delayed ground-truth evaluation on a rolling window.
  4. Design a deployment for a new model version. → Registry promotion → shadow traffic for parity → canary at small % with guardrail metrics → gradual ramp → automated rollback triggers.
  5. How much GPU memory to fine-tune a 7B model? → Full fine-tuning in BF16 needs roughly weights + gradients + Adam states + activations — far beyond 14 GB, typically 80 GB-class or sharded. LoRA/QLoRA brings it to a single consumer GPU. Show the arithmetic, not a memorised number.
  6. DDP vs FSDP vs ZeRO? → DDP replicates the model per GPU (simple, memory-limited); FSDP/ZeRO shard parameters, gradients and optimiser states across GPUs to fit larger models at the cost of communication.
  7. Your p99 latency spiked but p50 is fine. Why? → Tail effects: cold starts, queueing under bursty load, GC/paging, a slow dependency, long-input requests, cache misses, retry storms, noisy-neighbour GPU contention.
  8. How do you decide retraining cadence? → Data velocity + measured decay curve + retraining cost; trigger on drift/metric thresholds rather than a blind schedule where possible.

Behavioural

  1. Hardest technical problem and how you cracked it. 54. A failure and the changed behaviour it produced. 55. A disagreement with a senior colleague. 56. A time you shipped under a bad deadline and what you traded away. 57. An ambiguous problem you scoped yourself. 58. A time you were wrong and reversed course. 59. How you explained a model to a non-technical stakeholder. 60. Something you learned in the last three months and why you chose it.

Part 8 — Portfolio: four projects that survive scrutiny

Three excellent projects beat twelve tutorials. Each needs: a README with reasoning, a baseline comparison, real metrics, an eval harness, a deployed demo where feasible, and an honest limitations section.

1. Production-grade RAG over a non-trivial corpus Pick something with messy real documents (regulations, research papers, manuals — not a clean blog dump). Build hybrid retrieval + reranking, citations, refusal behaviour, a 100-question golden set, retrieval and generation metrics, latency and cost per query, and a comparison table showing what each component added. Talking point: "reranking lifted context precision from 0.61 to 0.84 and cut hallucinated answers by half."

2. An agent with real tool use and real safety limits Something with side effects (scheduling, ticket triage, data queries). Show step budgets, tool-output validation, failure recovery, an audit trail, a human-approval gate, and an eval suite of task scenarios with success rates. Talking point: "task success went 68% → 89% after I added output validation and a retry-with-error-context loop."

3. Classical ML with an experimentation story Tabular prediction with a business framing. Baseline → linear → GBDT, leakage audit, calibration, threshold tuning against explicit costs, SHAP explanations, and a designed A/B test with guardrail metrics (simulated is fine — state that). Talking point: "moving the threshold from 0.5 to 0.31 raised recall to 0.78 and cut expected cost 22%."

4. A deployed, monitored, versioned service Any model behind FastAPI, containerised, with CI running tests and evals, experiment tracking, a model registry step, drift monitoring, a dashboard, and a documented rollback. Least glamorous, most persuasive at 2+ years of experience.

Optional depth flex (DL track): a from-scratch transformer, a fine-tune with a proper ablation table, or a reproduction of a paper's result with your notes on what didn't reproduce.


Part 9 — Resume & positioning

  • One line per bullet, metric-first: "Cut RAG answer latency p95 from 4.2s to 1.1s by adding semantic caching and switching to a smaller reranker, holding faithfulness at 0.91." Not "Worked on RAG optimisation using LangChain."
  • Structure: Action → technical decision → measured outcome. If you have no number, use a scale or a proxy ("across 40k documents", "for 300 daily users").
  • Lead with the track you're targeting. Same person, different resume for a GenAI role vs an MLE role.
  • Skills section: group by category, remove anything you can't defend for five minutes. Every listed tool is an invitation to be questioned.
  • Cut: certifications without projects, coursework lists, "familiar with" hedges, generic soft skills.
  • GitHub: pin 3 repos, each with a README that opens with the problem and the result. Recruiters read the top of the README and nothing else.
  • Keep a brag document updated weekly during your job. It makes every future interview and review dramatically easier.

Part 10 — Resources (curated, not exhaustive)

BooksHands-On Machine Learning (Géron) for practice; Designing Machine Learning Systems (Huyen) — the single best book for the design round; AI Engineering (Huyen) for the LLM-era equivalent; Deep Learning with PyTorch; Speech and Language Processing (Jurafsky & Martin, free) for NLP depth; Machine Learning System Design Interview (Aminian & Xu) for round-specific drills.

Courses/series — Karpathy's Zero to Hero (build a transformer from nothing; do not skip this); fast.ai; Stanford CS224N for NLP; CS231n for vision; DeepLearning.AI short courses for fast GenAI coverage; Full Stack Deep Learning for productionisation.

Papers, in this order — Attention Is All You Need → BERT → GPT-3 → InstructGPT (RLHF) → Chinchilla (scaling) → LoRA → RAG → Chain-of-Thought → ReAct → FlashAttention → DPO → a current open-weights model report (Llama/Qwen/Mistral class). Read abstract + method + results; skip related work.

Practice — LeetCode easy/medium (topic-wise, not random), StrataScratch or DataLemur for SQL, Kaggle notebooks read critically (winning solutions teach feature engineering fast), interview-experience threads on Glassdoor/LinkedIn/Reddit for company-specific loops.

Documentation worth reading properly — PyTorch, the model provider API docs you'll use, vLLM, and one vector database of your choice. Provider docs on prompting and structured outputs are consistently better than blog posts.

Staying current — model provider release notes, one or two high-signal newsletters, and the release notes of the tools in your stack. Ignore hype threads; they cost time and teach nothing you'll be asked about.


Part 11 — Why strong candidates still get rejected

  1. Can't defend their own project. Fix: 10-question drill from Part 6.3 on every project.
  2. Buzzword fluency without mechanism. They know the tool's name, not what it does. Fix: implement one layer below the abstraction you normally use.
  3. No evaluation story. The most common GenAI rejection reason at every level. Fix: build one eval harness, once. It changes how you talk.
  4. No baseline. Jumping to the complex model signals poor judgement. Always mention the baseline first.
  5. Cost and latency blindness. Senior interviewers probe this within two minutes. Know your numbers.
  6. Designing before clarifying. Ask about scale, latency and success criteria first, every time.
  7. Notebook-only experience. Deploy one thing. It removes an entire category of doubt.
  8. Rambling. Structure, 60 seconds, stop. Let them ask for more.
  9. Bluffing. One caught bluff recolours the whole interview. "I don't know, here's how I'd find out" is a strong answer.
  10. Team-voice instead of I-voice. Say what you decided and why.
  11. No questions for the interviewer. Signals indifference. Prepare five, use three.
  12. Over-preparing breadth, under-preparing delivery. Verbal fluency is a separate skill from knowledge. That's what the mocks are for.

Part 12 — Final stretch checklist

Two weeks out: confirm the loop structure with your recruiter (ask directly which rounds and what each covers — they almost always tell you); research the company's product, stack and recent launches; align your project stories to their domain; 3 domain-matched design problems; 4 mocks.

Week of: light review only, no new topics; re-read your mistakes log and project one-pagers; sleep, exercise, hydration — cognition is the whole job here; test your camera, mic, internet and coding environment; prepare your questions and your comp range.

Day of: re-read the JD, warm up with one easy coding problem and one project pitch out loud, keep water and a notepad nearby, plan for a 15-minute buffer.

In the interview: think aloud, ask clarifying questions, state assumptions, use structure, name your own tradeoffs, and when stuck say what you'd try and why. Interviewers hire for how you think under uncertainty — that is the job.

After each round: write down every question you were asked and every one you fumbled, within an hour. That log is the fastest study material you will ever own.

At offer stage: get it in writing, understand the full package (base, bonus, equity terms, vesting), negotiate once, politely, with a specific number and a reason — competing offers or market data. Silence between the number and their reply is fine.


The compressed version of everything above: master the fundamentals one layer below the tools you use, build three things you can defend with numbers, learn to evaluate systems rather than demo them, practise speaking your reasoning out loud, and log every mistake. Depth plus delivery. That's the whole roadmap.

No Comment
Add Comment
comment url