NVIDIA interview prep

Leakage occurs when training uses information unavailable at prediction time. Examples include scaling with statistics from the full dataset, using future transactions, or placing near-duplicate users in both splits. Split first, fit preprocessing only on training data, and use temporal or grouped validation when the deployment setting requires it.

What a strong answer covers: A strong answer connects the split to the actual prediction moment and explains why a random split can be misleading.

Follow-up: How would you validate a model predicting a customer's next purchase?

Last reviewed 2026-09-28

Compare training and validation performance using learning curves. Poor performance on both can indicate underfitting, weak features, or optimization problems. Strong training results and weak validation results suggest overfitting or distribution mismatch. Try regularization, simpler models, more representative data, and cross-validation while keeping a final test set untouched.

What a strong answer covers: Mention that label noise, leakage, and a mismatched split can also explain these patterns.

Follow-up: What would you try if both errors remain high as data grows?

Last reviewed 2026-09-28

Read batches or stream observations, retaining a running count and mean. For a new value x at count n, update mean = mean + (x - mean) / n. Use a generator so loading is lazy. Define how missing and invalid values are handled; use a stable algorithm such as Welford's if variance is also needed.

What a strong answer covers: This uses constant auxiliary memory. Discuss floating-point limits and deterministic aggregation for parallel processing.

Follow-up: How would you merge the counts and means of two independent workers?

Last reviewed 2026-09-28

Use a real example: describe the user need, measured quality difference, and operational constraints. Compare latency, interpretability, cost, and maintenance. Explain the decision you owned, the outcome, and what evidence would make you revisit it. If you lack work experience, use a project and be explicit about its scope.

What a strong answer covers: The goal is a defensible decision supported by measurements, not a claim that simple models always win.

Follow-up: Which production metric would trigger a reevaluation?

Last reviewed 2026-09-28

Profile the serving pipeline first, separating queueing, preprocessing, model execution, and transfer costs. Try controlled batching, concurrency tuning, and appropriate precision. Measure throughput along with p50 and p99 latency under realistic request lengths. Keep an overload policy and compare accuracy before shipping optimizations.

What a strong answer covers: A larger batch can improve throughput while worsening tail latency. Benchmark the actual workload rather than a single synthetic input.

Follow-up: When would batching make an interactive application feel slower?

Last reviewed 2026-09-28

Quantization reduces numerical precision to lower memory use and potentially improve execution efficiency. Measure quality on representative inputs, outlier sensitivity, memory, and latency on the target hardware. Compare post-training quantization with quantization-aware training when feasible. Verify kernel support and avoid assuming fewer bits always mean faster execution.

What a strong answer covers: Memory savings are more predictable than speedups; hardware and workload determine actual performance.

Follow-up: Which layers or operations might you keep at higher precision?

Last reviewed 2026-09-28

Group frames by recording, subject, or scene before splitting so neighboring frames do not appear in both training and evaluation. Fit preprocessing only on training data and augment only training examples. Include shifts in lighting, camera, and environment that match expected deployment conditions.

What a strong answer covers: Highly similar adjacent frames can inflate performance even when no exact duplicate exists.

Follow-up: How would you evaluate generalization to a camera never seen in training?

Last reviewed 2026-09-28

Track availability, latency, resource cost, input quality, feature distributions, and output distributions. When labels arrive, monitor outcome quality and calibration by segment. Define alert thresholds, ownership, and rollback paths. Investigate drift before retraining because a distribution change does not always imply degraded performance.

What a strong answer covers: Monitoring must connect to an action. Labels may be delayed, so proxy signals need explicit limitations.

Follow-up: How would you distinguish a broken data pipeline from genuine behavior change?

Last reviewed 2026-09-28

Adam adapts learning rates per parameter using first and second moment estimates, making it a good default for most networks. SGD with momentum can generalise better on some vision tasks and is preferred when fine-tuning large pretrained models. AdaGrad accumulates all past squared gradients and effectively reduces learning rates to zero for dense features, so it is more suited to sparse settings. Monitor the training loss curve, gradient norms, and validation performance rather than choosing blindly.

What a strong answer covers: Distinguish the update rule from the generalization property. A strong answer mentions the flat-minimum hypothesis linking SGD to better generalization on some tasks.

Follow-up: How does weight decay interact differently with Adam versus SGD?

Last reviewed 2026-10-07

Data parallelism replicates the model across devices and splits the batch; gradients are aggregated at each step. It is simpler but requires the full model to fit on each device and incurs gradient synchronisation cost. Model parallelism splits layers or tensors across devices and is necessary when the model exceeds a single device memory, but introduces pipeline bubbles or recomputation overhead. Tensor parallelism can split individual weight matrices. Choose based on model size, batch size, communication bandwidth, and hardware topology.

What a strong answer covers: Cover both the memory constraint that forces model parallelism and the communication overhead that limits scaling. Mention pipeline parallelism as a hybrid approach for very deep models.

Follow-up: How would gradient checkpointing change your analysis of memory versus compute trade-offs?

Last reviewed 2026-10-07

L2 adds the sum of squared weights to the loss, shrinking all weights toward zero proportionally. L1 adds the sum of absolute weights and can set some weights exactly to zero, producing sparse models. Use L2 when you believe most features contribute and want smooth shrinkage. Use L1 when you expect many irrelevant features and want automatic feature selection. Elastic net combines both. Regularization strength is a hyperparameter tuned by cross-validation.

What a strong answer covers: The key distinction is sparsity: L1 produces it, L2 does not. Explain why in terms of the geometry of the constraint region.

Follow-up: Why might L1 regularization still leave many small but non-zero weights in practice?

Last reviewed 2026-10-07

Two-stage detectors such as Faster R-CNN propose regions then classify them, offering higher accuracy especially on small or densely packed objects. Single-stage detectors such as YOLO perform detection in one pass, offering lower latency. Choose based on latency budget, accuracy requirements on the target object size distribution, and hardware constraints. Benchmark on data representative of the deployment environment because published benchmarks rarely match production conditions. Include both speed and accuracy metrics in the evaluation, and consider anchor-free variants if class imbalance is a challenge.

What a strong answer covers: Avoid choosing based solely on benchmark numbers. Mention that the latency gap has narrowed with modern architectures and that quantization and pruning can shift the trade-off further.

Follow-up: How would you handle a detector that performs well on the test set but struggles on edge-case lighting conditions in production?

Last reviewed 2026-10-07

A list comprehension evaluates immediately and stores all values in memory. A generator expression or generator function uses yield to produce values one at a time and holds only the current state in memory. Use a generator when the sequence is large, infinite, or expensive to compute, and you only need to iterate once. Use a list when you need random access, repeated iteration, or the full collection for operations such as sorting or length checks.

What a strong answer covers: The core concept is lazy evaluation. Mention that generators are exhausted after one pass, which is a common source of bugs when the same generator is iterated twice.

Follow-up: How would you implement a generator that yields batches of rows from a large CSV file?

Last reviewed 2026-10-07

Use the STAR format: describe the context and the decision you disagreed with, the specific concern you raised and how you raised it (data, an experiment, or a clear argument), the outcome, and what you would do differently. Show that you can advocate for your position while remaining constructive, and that you can commit to a decision once it has been made even when you disagree.

What a strong answer covers: The goal is to show technical judgment and professional communication, not to relitigate old grievances. Avoid framing the story as you versus them. A strong answer includes evidence you used to make your case.

Follow-up: What would you do if the team made the same decision again and the outcome was worse than you predicted?

Last reviewed 2026-10-07

Use STAR: explain the project goal, what you built, what happened, and what you did next. Own your share of the failure rather than attributing it entirely to data, compute, or other constraints. Name a specific technical mistake — a leaky split, a flawed evaluation metric, a mislabeled dataset — not a vague sense that the model was wrong. Describe what you learned and how you applied it on a subsequent project.

What a strong answer covers: A strong answer names a specific technical root cause, not bad luck or insufficient time. The retrospective action matters as much as the failure itself.

Follow-up: What would be the first thing you would investigate if you had three days to debug the same project now?

Last reviewed 2026-10-07

Use STAR: describe the decision, what information was missing, what assumptions you made and why, how you documented those assumptions, and what you did to limit downside risk. Show that you can move forward without perfect information while keeping the team informed about your uncertainty and the conditions that would change your decision.

What a strong answer covers: This tests judgment and risk management. A strong answer distinguishes between uncertainty that is worth waiting to resolve and uncertainty you can safely assume away for now.

Follow-up: How did you decide what additional information was worth waiting for versus what you could assume away?

Last reviewed 2026-10-07

Use STAR: set the scene, describe the failure and how you found it, and explain how you communicated it. Lead with the business impact first, then explain the cause at a level the audience can act on. Show that you gave them what they needed to make a decision rather than a full technical post-mortem. Include what you proposed to fix and what the outcome was.

What a strong answer covers: The best answers show empathy for what the stakeholder needs to know, not just what you know. Avoid jargon without explanation and avoid false reassurance about a fix that is not yet validated.

Follow-up: How would you set up a review process to catch similar issues before they reach stakeholders?

Last reviewed 2026-10-07

Use STAR: describe the problem you noticed, why it was not clearly owned, what you chose to do, how you involved or informed the right people, and the outcome. Show judgment about when to escalate versus act, and demonstrate that you understood the constraints and worked within or around them thoughtfully rather than bypassing important processes.

What a strong answer covers: This tests initiative and judgment. Interviewers probe whether you involved the right people at the right time. A strong answer shows you didn't silently take over someone else's work.

Follow-up: How did you decide this was your problem to solve rather than someone else's?

Last reviewed 2026-10-07

Use Welford's online algorithm, which updates the mean and the sum of squared deviations incrementally without storing all values. The variance property returns the population variance; divide by n-1 for sample variance.

class RunningStats:
    def __init__(self) -> None:
        self._n = 0
        self._mean = 0.0
        self._M2 = 0.0   # sum of squared deviations from current mean

    def update(self, x: float) -> None:
        self._n += 1
        delta = x - self._mean
        self._mean += delta / self._n
        self._M2 += delta * (x - self._mean)  # uses updated mean

    @property
    def mean(self) -> float:
        return self._mean

    @property
    def variance(self) -> float:          # population variance
        return self._M2 / self._n if self._n > 0 else 0.0

    @property
    def count(self) -> int:
        return self._n

What a strong answer covers: Welford's algorithm is numerically stable and O(1) in memory. The key is using the updated mean in the M2 accumulation step. Mention that two RunningStats instances can be merged by combining their n, mean, and M2 fields.

Follow-up: How would you merge the running statistics from two independent workers processing different data shards?

Last reviewed 2026-10-07

Primary constraints are model size (flash and RAM), inference latency, battery impact, and thermal limits. Techniques: use smaller architectures, apply quantisation and pruning, use hardware-specific kernels (Core ML on Apple, NNAPI on Android), and avoid dynamic shapes that prevent graph compilation. Test on actual devices at the target battery level and thermal state, not only on simulators. Design the feature pipeline to work without a network request.

What a strong answer covers: Thermal throttling is often overlooked: a device that has been running a demanding app may execute the model significantly slower than benchmarks suggest. Server-side numbers don't translate directly to device performance even for the same architecture.

Follow-up: How would you decide whether to run inference on-device or on a server for a new feature?

Last reviewed 2026-10-07