Practice 45 PyTorch interview questions on tensors, autograd, nn.Module, DataLoader, training loops, optimizers, checkpoints, TorchScript, and deployment.
45 questions with answersKey Takeaways
PyTorch is an open-source framework for building, training, and deploying machine learning models. It is popular because tensor operations feel close to Python, autograd tracks gradients dynamically, and training loops are explicit. In interviews, PyTorch questions test whether you understand tensors, modules, data loading, loss calculation, backpropagation, optimization, checkpointing, and deployment trade-offs.
Watch: Introduction to PyTorch
Video: Introduction to PyTorch (PyTorch, YouTube)
Test yourself and earn a certificate
6 quick questions. Score 70%+ to download your PyTorch certificate.
Start here. These are the definitions and first-principle checks that open most rounds.
A tensor is a multi-dimensional array with dtype, shape, and device information.
Tensors are the core data structure for inputs, weights, activations, and gradients.
Tensor changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: Introduction to PyTorch (PyTorch, YouTube)
Autograd is PyTorch's automatic differentiation system. It tracks operations on tensors and computes gradients during backward.
It builds a dynamic graph during the forward pass.
Autograd changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
requires_grad tells PyTorch to track operations on a tensor so gradients can be calculated.
Model parameters usually require gradients.
requires_grad changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
nn.Module is the base class for PyTorch models and layers.
It tracks parameters, submodules, and mode changes.
nn.Module changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
| Answer part | What to say | Evidence to mention |
|---|---|---|
| Definition | nn.Module in one direct sentence. | Official docs or course material |
| Use case | The work where it changes a decision. | Dataset, model, query, dashboard, or pipeline |
| Risk | What breaks when it is misunderstood. | Metric, log, test result, or review note |
forward defines how input tensors pass through the model to produce outputs.
Calling model(x) invokes forward through module hooks.
forward method changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: PyTorch for deep learning and machine learning (freeCodeCamp.org, YouTube)
A Dataset defines how to access individual samples and labels.
It usually implements __len__ and __getitem__.
Dataset changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
DataLoader batches, shuffles, and loads Dataset samples, often with worker processes.
Poor DataLoader settings can slow GPU training.
DataLoader changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
An optimizer updates model parameters using gradients.
SGD, Adam, and AdamW are common choices.
Optimizer changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
The loss function measures how far predictions are from targets and provides a signal for gradient updates.
Loss must match the task and output shape.
Loss function changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
zero_grad clears old gradients because PyTorch accumulates gradients by default.
Forgetting it can make updates wrong.
zero_grad changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
optimizer.zero_grad()
outputs = model(batch_x)
loss = loss_fn(outputs, batch_y)
loss.backward()
optimizer.step()loss.backward computes gradients for tensors that require gradients.
The optimizer uses those gradients in step.
backward changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
train and eval change behavior of layers such as dropout and batch normalization.
Use eval during validation and inference.
model.train and model.eval changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
torch.no_grad disables gradient tracking during inference or validation.
It saves memory and compute.
torch.no_grad changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: Learn PyTorch for deep learning (Daniel Bourke, YouTube)
state_dict is a dictionary containing model parameters and persistent buffers.
It is the common way to save and load PyTorch models.
state_dict changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Device placement controls whether tensors and models live on CPU, CUDA GPU, MPS, or another backend.
Inputs and model parameters must be on compatible devices.
Device changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
These questions test whether you can apply the topic to real data, real code, and messy constraints.
Set model.train, move data to device, run forward pass, compute loss, zero gradients, call backward, step optimizer, and record metrics.
Mention validation separately with eval and no_grad.
write training loop changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Implement __len__ and __getitem__, load or index samples, return tensors and labels, and keep heavy transforms controlled.
Do not load the whole dataset in memory unless it fits.
build Dataset changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Tune batch size, num_workers, pin_memory for CUDA, prefetching, transforms, and storage format.
Measure GPU utilization to confirm the bottleneck.
speed DataLoader changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Save model state_dict, optimizer state, epoch, best metric, config, and random seed state when needed.
Saving only weights may not support exact resume.
save checkpoint changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Create the model class, load state_dict, move to device, call eval, and run inside no_grad.
The architecture must match the saved weights.
load model changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Print tensor shapes at each layer, check batch dimension, flattening, output size, and label shape.
Most shape bugs are visible with one batch.
fix shape error changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Move model and tensors to the same device, avoid unnecessary CPU-GPU copies, and monitor memory.
Device mismatch is a common runtime error.
handle GPU changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Set eval mode, use no_grad, compute loss and metrics without optimizer steps, then return aggregate metrics.
Do not train during validation.
validate model changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Adam or AdamW often trains quickly with less tuning, while SGD with momentum can work well for some vision tasks after tuning.
The right answer depends on data, model, and metric.
choose optimizer changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Use validation, augmentation, dropout, weight decay, early stopping, smaller models, or more data.
Track train and validation curves.
prevent overfitting changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: PyTorch 101 crash course (Daniel Bourke, YouTube)
Use autocast and GradScaler where supported to reduce memory and speed training.
Watch numeric stability.
mixed precision changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Set requires_grad to false for selected parameters and pass only trainable parameters to the optimizer.
Verify frozen layers do not update.
freeze layers changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Clip gradients when training is unstable due to exploding gradients, common in some sequence models.
It is not a cure for every NaN.
clip gradients changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Choose based on serving need: state_dict for PyTorch loading, TorchScript or newer export paths for graph-style deployment, or ONNX for cross-runtime use.
Test exported output against the original model.
export model changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Set seeds, version data, log config, track environment, save checkpoints, and control nondeterministic operations where possible.
Exact reproducibility can still differ across devices.
reproduce training changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Advanced rounds test trade-offs, failure modes, and whether the decision can hold up under production pressure.
optimizer.zero_grad was likely missing or placed incorrectly.
PyTorch accumulates gradients by default.
gradients keep growing changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Check model.eval, no_grad, dropout, batch norm, data order, and metric reset.
Evaluation mode matters.
eval accuracy unstable changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
The model and input or target tensors are not on the same device.
Move all needed tensors consistently.
cpu gpu mismatch changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Check DataLoader speed, batch size, CPU transforms, disk reads, num_workers, and GPU synchronization.
The GPU may be waiting for data.
slow gpu changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Check model class changes, key names, strict loading, device map, and saved state format.
Architecture and weights must match.
checkpoint cannot load changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Check learning rate, input normalization, labels, loss function, exploding gradients, mixed precision, and invalid operations.
one batch comes first.
nan loss changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Check requires_grad, optimizer parameters, learning rate, target format, loss function, and data-label pairing.
Make sure parameters are actually updating.
no learning changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Add regularization, augmentation, early stopping, more data, or reduce model capacity.
The model is learning training noise.
overfitting changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Check train/eval mode, batch size, running stats, and distribution shift.
BatchNorm behavior changes between train and eval.
bad batch norm changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Reduce batch size, use mixed precision, gradient accumulation, smaller model, or checkpoint activations.
Also clear unused tensors and avoid retaining graphs.
memory out changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
It may hide graph lifecycle misunderstandings and increase memory use.
Use it only when multiple backward passes over the same graph are required.
retain graph misuse changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Use precision, recall, F1, PR AUC, threshold tuning, class weights, or sampling.
Accuracy is weak for imbalanced data.
wrong metric changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Check preprocessing, model mode, weights version, input dtype, shape, device, and export path.
Serving code must match training assumptions.
deployment drift changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Use it when training time or data size justifies multi-GPU or multi-node training.
It adds synchronization and operational cost.
distributed training changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Ask about data split, training loop order, metrics, device handling, checkpoints, reproducibility, validation, and export tests.
These questions reveal production quality.
senior review changes PyTorch decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Both frameworks can train and deploy deep learning models. The interview answer should focus on workflow and ecosystem fit, not brand preference.
| Area | PyTorch | TensorFlow | Interview point |
|---|---|---|---|
| Execution style | Eager and Pythonic by default | Eager with graph tools | Debugging style differs |
| Model API | nn.Module and explicit loops | Keras plus lower-level APIs | Training control differs |
| Research | Common in experiments and papers | Also used, often with Keras | Fast iteration matters |
| Deployment | TorchScript, torch.export, serving stacks | SavedModel and TensorFlow Serving | Export contract matters |
PyTorch answer signals
Training-loop clarity is the highest-value signal.
Prepare by writing a minimal training loop and explaining each line. Then add data loading, checkpointing, metrics, and deployment concerns.
PyTorch interview prep flow
Most rounds reward clear reasoning more than memorized phrasing.
A strong PyTorch answer walks through the training loop in order: move tensors to device, run forward pass, compute loss, clear old gradients, call backward, step the optimizer, and track metrics. production-ready answers mention model.train and model.eval, torch.no_grad, DataLoader bottlenecks, checkpoint contents, reproducibility, mixed precision, and how the model will be exported or served.
PyTorch accumulates gradients by default, so zero_grad must happen before backward in the usual loop.
Model and tensors must be on the same device. CPU-GPU mismatch is a common error.
Dropout and batch normalization behave differently in training and evaluation.
A useful checkpoint includes model state, optimizer state, epoch, metric, and config.
6 questions, about 4 minutes. Score 70% or higher to earn a shareable certificate.
Use this PyTorch bank for model and training-loop reasoning, then practice Python and debugging tasks with Hyring's AI Coding Interviewer.
See Hyring AI Coding Interviewer