Data engineering, ML engineering and LLM/RAG interview questions covering pipelines, model evaluation, overfitting, retrieval, embeddings, vector search and production AI systems.
40 published across 8 topics.
Idiomatic Python, pandas and vectorisation, memory behaviour, and writing correct transformations.
Object-dtype string columns hold pointers to individual Python objects rather than packed bytes, any missing value promotes an integer column to float64, and the parser's peak exceeds the final frame. Declare dtypes, select columns, use categoricals, and prefer a columnar file.
Push the work into a whole-column operation so the interpreter is entered once instead of once per row, replace chained indexing with a single .loc assignment, and move to DuckDB, Polars or a cluster once the frame plus its intermediate copies stop fitting in memory.
Batch versus streaming, orchestration, idempotent backfills, and lakehouse and medallion layering.
Land raw events unchanged by arrival date, then rebuild each revenue day from that raw layer by event date. Each run overwrites only the days its new arrivals touched, a day is provisional until the three-day window closes, and the backfill is the same job run over a date range, never a separate script.
Do not re-download Wikipedia daily. Use incremental ingestion: load the published dump once, follow the recent-changes feed, and fetch only the latest revision of each changed page in small, polite batches. Checkpointing each batch behind a revision-guarded write lets a run that fails at hour six resume.
Make the write idempotent before you make it correct: partition-level replace rather than append, so rerunning a day produces the same result whether it runs once or five times. Then work out how far the contamination spread, because a downstream table that accumulated rather than recomputed will not fix itself when the source is repaired.
Sum the task durations and compare that with the wall-clock span, because nine hours of waiting and nine hours of work are different problems. If the sum is still an hour, you are queueing on a bounded worker pool, usually behind sensors holding slots; if a task genuinely grew, its own duration history over the last thirty runs tells you whether it stepped or sloped.
Validate every record against a declared schema at the ingestion boundary, quarantine what fails instead of dropping it, treat additive changes as safe and renames as breaking, and alert on a field that has gone all-null rather than waiting for a dashboard to look wrong.
An authoritative discussion on Apache Iceberg's table format, focusing on hidden partitioning, the trade-offs of copy-on-write versus merge-on-read, and managing schema drift at scale. Use this data engineering answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects data lakes to the point an interviewer is testing.
An examination of decentralised data governance, exploring dynamic masking in the compute layer, deterministic tokenisation for referential integrity, and standardised tagging. Use this data engineering answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects data governance to the point an interviewer is testing.
Design a safely rerunnable data pipeline by making each output partition a deterministic result of its input partition, overwriting instead of appending, and writing into idempotent sinks that tolerate retries and late events.
Decide it deliberately, because there is no correct default: you can hold the window open longer, accept the record and restate the figure, or drop it and report how much you dropped. What you must not do is let arrival order silently decide, which is what a pipeline keyed on ingestion time does.
An analysis of distributed processing bottlenecks, addressing the limitations of AQE, implementing manual key salting for shuffle optimization, and restructuring data layouts. Use this data engineering answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects batch processing to the point an interviewer is testing.
Designing a robust streaming architecture for embedding generation, detailing GPU adaptive batching, Kafka-driven backpressure management, and asynchronous HNSW indexing. Use this machine learning answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects data engineering to the point an interviewer is testing.
Partitioning and shuffles, skew, joins at scale, catalyst and lazy evaluation, and cluster tuning.
Usually not yet. Itemise the minute across source, trigger interval, processing and read visibility, because a few-second micro-batch in Structured Streaming often fits it. Flink earns the move at sub-second latency or per-record state, and what breaks is the operational model: a long-lived job whose state you must migrate, and a sink that must be idempotent.
The file count is the number of writing tasks multiplied by the partition values each task holds, so a wide shuffle plus a high-cardinality partition column produces a file explosion. Repartition to match the write layout rather than coalescing to one task, and compact behind a table format.
Check the premise first, because two billion edges as vertex id pairs is about 32GB and that fits in one large machine. If it genuinely must be distributed, partition edges rather than vertices, since real graphs are power-law and a single high-degree vertex under an edge cut makes its machine the straggler that every synchronous superstep waits for.
A slow Spark job should be diagnosed from the Spark UI stage list, task duration spread, shuffle volume and physical plan. Common causes are data skew, unnecessary shuffles, missed broadcast joins, repeated recomputation and collect() pulling too much data to the driver.
Star and snowflake schemas, slowly changing dimensions, and dbt-style transformation layering.
The dimension was overwritten, so historical facts joined to it now report the customer's current region rather than the region they were in when they bought. Keeping history means versioning the dimension row and joining facts to the version that was current at the time, not to the customer.
Settle the grain first - what one fact row means. A star still earns its place for conformed dimensions and type-2 history, while a wide table is a serving artefact for one known pattern. A warehouse differs from a lake by having a modelled contract, not by where the bytes live.
Reconcile the two numbers row by row before touching the pipelines: the cause is almost always a grain mismatch that fans out a join, a filter difference over refunds or test accounts, or two timestamps meaning different things. The fix is one certified definition that both dashboards are forced to call.
Two time axes, not one: when the fact was true in the world, and when this warehouse first learned it. Corrections append a new version with a knowledge timestamp instead of updating in place, so a report becomes a query with an as-of predicate and reproduces for ever - and the figure you published should be snapshotted alongside it rather than reconstructed later.
Bias and variance, evaluation-metric selection, leakage, imbalanced data, and validation strategy.
The feature encodes the outcome, so the model reads the answer rather than predicting it. Offline the label and the feature come from the same snapshot, which is why validation looks excellent; in production the feature is empty at scoring time and the signal vanishes. Fix by defining features by when they were available and validating on a forward time split.
Convert the offline gain into the decision it changes and the value of that change, then set it against what the model commits the team to for its whole life. A small metric improvement that no threshold or downstream action responds to is worth nothing, however real it is.
Almost certainly not: if fraud is 0.6% of transactions, a model predicting 'not fraud' for everything scores 99.4% and catches nothing. The metric has to follow from which error costs more, which makes it a business decision expressed in numbers rather than a modelling one.
Detect overfitting by comparing training and validation performance on an honest split. Fix it with more or better data, simpler models, regularisation, early stopping and a final test set that is read only once. It also connects model validation to the point an interviewer is testing.
Experiment tracking, model registries, deployment patterns, drift detection, and retraining triggers.
Serve context instead of history: popularity conditioned on the country, device and referrer you already have, then re-rank on the first two clicks of the session with a model that needs no user identity. Reserve slots for exploration, and segment every offline metric by history length, because a metric averaged over users with history cannot see this cohort at all.
An authoritative deep dive into LLM inference optimization, exploring continuous batching, paged attention for KV cache memory management, and tensor parallelism scheduling.
Retraining only helps when the model's premise still holds. If the proxy it predicts no longer stands for the outcome you care about, or the feature it depended on has stopped being generated, more data cannot recover it, and the decision is retirement plus a stated fallback. Use this model lifecycle answer to show the decision, trade-off, and evidence rather than a memorised definition.
An analysis of the cost, performance, and complexity trade-offs between LoRA fine-tuning and MoE architectures for multi-tenant domain adaptation. Use this cost optimization answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects finetuning to the point an interviewer is testing.
An in-depth look at designing a robust Kubernetes orchestration layer to optimise GPU utilisation across diverse, conflicting machine learning workloads.
Exploring robust security architectures to prevent attackers from extracting sensitive training data from generative AI models.
Check whether training and serving compute the same features from the same definitions, because the usual cause is two implementations that disagree slightly. Nothing raises an error when they diverge - the model receives plausible numbers that mean something different from the ones it learned on.
Features must be computable at decision time, training and serving must share one transformation implementation, the model and dataset version must be pinned together, drift and realised performance monitored separately because labels arrive late, and rollback must move model and features as one unit.
RAG system design interview questions on embeddings, vector search, chunking, retrieval evaluation, hallucination debugging, guardrails, cost and latency.
Almost always in retrieval rather than generation, and most often in chunking: if the answer was split across a boundary, or sits in a chunk whose surrounding context was stripped, no prompt can recover it. Evaluate the retrieval half separately, because it has a yes-or-no answer that needs no model to grade.
Debug a RAG system with confident wrong answers by separating retrieval failure from generation failure. Check whether the gold passage was retrieved, then measure recall@k, reranking quality, faithfulness and abstention on a labelled eval set. It also connects retrieval evaluation to the point an interviewer is testing.
Streaming commits you to the response before you have seen it: the status code is already sent, any check that needs the whole output now runs after the user has read part of it, a mid-stream failure has no clean retry, and an abandoned tab keeps generating tokens you pay for. It also connects llm serving to the point an interviewer is testing.
Distributions, hypothesis testing, A/B design, and reading a result honestly.
Guardrail metrics are outcomes you are not trying to improve but will not let degrade beyond a margin declared before launch. They stop a launch when the data shows harm past that margin, or cannot rule it out, which means guardrails need their own power and their own pre-agreed decision rule.
Treat it as a broken experiment, not a rounding issue. At two million users a 53/47 split is astronomically unlikely by chance, so something removed users non-randomly - and that something almost certainly correlated with the outcome. The result cannot be trusted in either direction, so find the mechanism, fix it and rerun rather than adjusting the numbers.
Fix the hypothesis, one primary metric, the randomisation unit and the sample size before launch. Peeking at a fixed-horizon test inflates false positives because each look is another chance to cross the threshold, and an inconclusive result is an interval to interpret, not proof of no effect.
No, if the analysis was designed as a fixed-horizon test: checking repeatedly inflates the false-positive rate, and stopping at the first significant look also overstates the effect size. Either commit to the horizon, or adopt a sequential design that budgets error across looks.