Advanced Machine Learning Interview Questions and Answers

After a forward pass computes predictions and the loss, backpropagation applies the chain rule of calculus backwards through the network, layer by layer, to compute how the loss changes with respect to every weight (the gradients). An optimiser such as SGD or Adam then moves each weight a small step against its gradient. Frameworks like PyTorch do this automatically with autograd.

In deep networks, gradients are products of many per-layer factors; with sigmoid or tanh activations these factors are often small, so gradients for early layers shrink towards zero and those layers barely learn. Remedies: ReLU-family activations, careful weight initialisation (He/Xavier), batch or layer normalisation, residual (skip) connections as in ResNets and transformers, and gradient clipping for the related exploding-gradient problem.

Dropout randomly switches off a fraction of neurons during training, so the network cannot rely on any single neuron; this reduces overfitting. It is turned off at evaluation (model.eval()). Batch normalisation normalises a layer's inputs over each mini-batch, which stabilises and speeds up training. It also behaves differently in training and evaluation, another reason to call model.eval() before predicting.

Convolutional layers apply small learned filters across the whole image, so they detect local patterns wherever they appear, using far fewer parameters than fully connected layers. Stacked layers build edges into textures, shapes and objects. Transfer learning reuses a network pretrained on a large dataset (such as ImageNet), replacing and retraining the final layers for the new task. It works well with small datasets because the early filters are general.

Embeddings are vectors in which similar items lie close together, compared with cosine similarity. In RAG, documents are split into chunks, embedded and stored in a vector index; a user's question is embedded, the nearest chunks are retrieved, and they are passed to an LLM along with the question so it answers from that context. Key design choices: chunk size, embedding model, number of chunks retrieved, and evaluating both retrieval quality and answer faithfulness.

Use stratified splits and metrics that focus on the rare class (precision, recall, average precision). Then try, in order: class weights (class_weight="balanced"), tuning the decision threshold on validation data according to the real costs of each mistake, and resampling of the training data only (undersampling, oversampling or SMOTE). Always measure: class weights can even hurt some models, such as random forests.

• Leakage in training (a feature unavailable at prediction time, or preprocessing fitted on test data), so the offline score was never real.
• Training-serving skew: features computed differently in production (different code, units or missing-value handling).
• Data drift: production inputs differ from the training distribution.
• Concept drift: the relationship between inputs and outcome changed.
• A test set that did not represent production (wrong time period, random split for time-dependent data, duplicated entities across splits).

Investigate by comparing feature distributions between training and production logs, and re-scoring recent labelled data.

Compare recent production inputs with the training data, feature by feature: statistical tests such as Kolmogorov–Smirnov for numeric features and chi-squared for categorical ones, or distance measures like the population stability index. Look at the size of the shift, not only p-values, since large samples make tiny shifts "significant".

import numpy as np
from scipy.stats import ks_2samp

rng = np.random.default_rng(0)
training = rng.normal(100, 15, 5000)
production = rng.normal(110, 15, 1000)
result = ks_2samp(training, production)
print(f"KS statistic {result.statistic:.3f}, p-value {result.pvalue:.2g}")

KS statistic 0.284, p-value 7.3e-60

Also monitor the distribution of predictions, and real accuracy once labels arrive.

1. Goal and metric: increase purchases from recommendations; offline metrics such as recall@10, online metrics such as click-through and conversion in an A/B test.
2. Data: views, carts, purchases, ratings, product attributes, user profiles.
3. Candidate generation: quickly narrow millions of products to a few hundred, using item-to-item similarity, collaborative filtering or embedding nearest-neighbour search.
4. Ranking: a model (for example gradient boosting) scores candidates with user, product and context features.
5. Cold start: popular or category-based items for new users; content features for new products.
6. Serving: precompute candidates in batch; rank in real time with low latency.
7. Monitoring and feedback: track clicks and conversions, avoid only ever showing already-popular items, and retrain regularly.

Package the model with its preprocessing and pinned dependencies, serve it behind an API (or as a batch job), and add input validation, logging and health checks. For a new version: compare offline on the same data, then run it in shadow mode (predicting without affecting users), release to a small canary share of traffic, run an A/B test on the business metric, and keep the previous version ready for instant rollback. Monitor latency, errors, input drift and prediction distributions.