Scenario-based questions are usually the highest-signal part of a Deep Learning interview — they test whether you can actually reason through an ambiguous, realistic problem, not just recall a definition. Each scenario below includes a worked-through approach, not just a final answer.
Scenario 1: "Your model has 99% training accuracy but only 60% validation accuracy. Walk me through how you'd diagnose and fix this."
This is a clear overfitting signature. I'd first confirm there's no data leakage (duplicate examples across train/validation, or a preprocessing step accidentally using validation information). Assuming that's clean, I'd address it through: reducing model complexity if it's clearly oversized for the data, adding regularization (dropout, weight decay), applying data augmentation to increase effective training diversity, and using early stopping guided by the validation curve. I'd also check whether there's simply not enough training data for the task's difficulty, in which case collecting more data or using transfer learning from a pretrained model would be the more fundamental fix.
Scenario 2: "You're asked to deploy a model that must respond in under 100ms per request. What would you consider?"
First, profile where time is currently being spent — preprocessing, model forward pass, postprocessing, network — to know what actually needs optimizing. Then: consider model optimization (quantization, TorchScript/ONNX compilation, possibly a smaller/distilled model if the current one can't hit the target), ensure GPU is used if warranted and utilized efficiently (with careful, latency-bounded micro-batching if serving concurrent requests), and make sure the model is loaded once at startup, not per-request. I'd also measure p99 latency, not just average, since tail latency often determines whether the target is reliably met in practice, not just on average.
Scenario 3: "A stakeholder says your model's accuracy dropped from 92% to 78% three months after deployment, with no code changes. What do you investigate?"
This points to model/data drift. I'd check for data drift first — comparing recent production input distributions against the original training distribution (e.g. via a statistical test on key features). I'd also check for concept drift if ground-truth labels are available for recent predictions — has the actual relationship between inputs and correct outputs changed? I'd also rule out more mundane causes: an upstream data pipeline change, a schema change, or a bug introduced by a dependency update, even without an intentional model code change. The fix, once the cause is identified, is typically retraining on more recent data, though the specific cause should inform the specific response.
Scenario 4: "You have only 500 labeled images for a 20-class classification task. What approach would you take?"
500 images across 20 classes (~25 per class) is quite limited for training a CNN from scratch reliably. I'd strongly favor transfer learning — starting from a model pretrained on a large dataset like ImageNet, and either fine-tuning the later layers or using the pretrained model purely as a feature extractor with a new classification head trained on the small dataset. I'd also apply aggressive data augmentation to increase effective data diversity, use k-fold cross-validation (rather than a single train/val split) given the small dataset size, for a more reliable performance estimate, and set realistic expectations that performance may still be limited by data scarcity even with these mitigations.
Scenario 5: "Your training loss decreases but validation loss starts increasing after epoch 5. What's happening, and what would you do?"
This is the classic overfitting signature appearing at a specific, identifiable point in training. The most immediate, low-cost fix is early stopping — saving the checkpoint from around epoch 5 (or wherever validation loss was lowest) rather than continuing to train past that point. Beyond that, I'd consider the broader overfitting mitigations (regularization, more data/augmentation) if I need the model to train longer to reach a better minimum without this early degradation, rather than simply accepting the epoch-5 checkpoint as the final model.
Scenario 6: "How would you explain backpropagation to a non-technical stakeholder?"
I'd use an analogy: imagine the network makes a guess, and we can measure exactly how wrong that guess was. Backpropagation is the process of tracing that error backward through the network, step by step, figuring out how much each individual internal "decision" (weight) contributed to the final mistake — like tracing a wrong final answer on a multi-step math problem back through each step to see where things went off track. Once we know each weight's share of the blame, we nudge it slightly in the direction that would have reduced the error, and repeat this process many times until the network's guesses become reliably accurate.
Scenario 7: "You need to choose between a bigger model and more training data, with a fixed budget. How do you decide?"
I'd first look for empirical signals from the current setup: if the model is clearly overfitting (large train/validation gap) even at its current size, more data is likely to help more than a bigger model, since the bottleneck is generalization, not capacity. If the model is underfitting (both train and validation performance are limited, with a small gap), more capacity is likely the higher-leverage investment. I'd also consider running a small-scale ablation if time/budget allows — training the current model on progressively more data to see if performance is still climbing (suggesting data is the bottleneck) or has plateaued (suggesting capacity is the bottleneck) — rather than guessing blind.
Scenario 8: "A user reports the LLM-powered feature 'made up' a fact. How would you address this both immediately and long term?"
Immediately: I'd verify the specific hallucination, assess its severity/impact, and if it's a systematic pattern (not a one-off), consider a quick mitigation like tightening the system prompt to explicitly instruct grounding in provided context, or adding a disclaimer for the affected use case. Longer term: I'd evaluate whether RAG is being used and, if so, whether retrieval quality needs improvement (better chunking, better embedding model) or whether the prompt needs to more strongly instruct the model to rely on retrieved context rather than its parametric knowledge. I'd also build monitoring to track hallucination rate systematically (e.g. via periodic human review of a sample of outputs) rather than relying solely on reactive user reports.
