Clean Code and Best Practices Questions

Covers the principles and hands on practices that produce readable, maintainable, and reliable code. Core elements include intent revealing and consistent naming, small focused functions and classes that follow single responsibility, avoiding duplication through refactoring and appropriate abstractions, clear structure and separation of concerns, following language specific idioms and style guides, consistent formatting, concise comments that explain nonobvious intent, defensive programming and robust error handling, edge case handling and input validation, use of linters and static analysis, incremental refactoring techniques, and pragmatic trade offs between ideal design and delivery constraints. Interviewers will also probe involvement in code reviews, version control hygiene, code metrics, and how candidates advocate for and teach coding standards to peers.

MediumSystem Design

81 practiced

Explain how to design a training loop API that makes it easy to test individual components (data loading, forward pass, loss computation, optimizer step). Describe function/class boundaries, dependency injection choices, and how to make the loop deterministic for unit tests.

Sample Answer

Requirements (clarify): we need a training loop where each part—data loading, model forward, loss, optimizer step—can be tested in isolation, replaced by test doubles, and run deterministically in unit tests.

High-level design:- Keep the loop small and orchestrating only; implement components as small, testable units with well-defined interfaces.- Use dependency injection: pass DataLoader, Model (or forward function), LossFn, Optimizer, and Schedulers into the Trainer/Loop constructor.- Favor pure functions where possible (forward, loss) and isolate side effects (gradient updates, logging).

Core components & boundaries:1. IDataLoader (iterator) — yields batches; in tests inject a synthetic or deterministic loader.2. IModel or forward_fn(inputs, params, rng) — pure; returns logits; in frameworks use the model object but keep forward signature simple.3. ILoss(loss_inputs) — pure function returning scalar and optional metrics.4. IOptimizer — minimal interface: zero_grad(), step(), get_state(); use a stub optimizer in tests to verify step called with correct grads.5. Trainer/Loop — coordinates: for batch in dataloader: outputs = model.forward(batch); loss = loss_fn(outputs, batch); loss.backward(); optimizer.step(). Trainer should accept injections for logger, checkpoint callbacks, and RNG.

Dependency injection choices:- Constructor injection for main components (DataLoader, Model, Loss, Optimizer).- Optional strategy injection for batching/shuffling.- Use interfaces/ABCs or simple duck-typing; in Python pass callables for forward/loss to make stubbing trivial.

Making the loop deterministic:- Expose and require an explicit RNG/seed parameter for the loop and pass it to dataloader, model, augmentation functions.- Ensure DataLoader shuffling is driven by a seeded Sampler.- For PyTorch: set torch.manual_seed(seed), numpy.random.seed(seed), random.seed(seed), and set torch.backends.cudnn.deterministic=True and torch.backends.cudnn.benchmark=False.- Avoid global state inside components—accept RNG objects rather than use global random.

Example minimal signatures (Python):

python

class Trainer:
    def __init__(self, dataloader, model_fn, loss_fn, optimizer, rng):
        self.dataloader = dataloader
        self.model_fn = model_fn  # def model_fn(params, batch, rng): ...
        self.loss_fn = loss_fn    # def loss_fn(pred, batch): ...
        self.optimizer = optimizer
        self.rng = rng

    def train_epoch(self):
        for batch in self.dataloader(self.rng):
            preds = self.model_fn(batch, self.rng)
            loss = self.loss_fn(preds, batch)
            loss.backward()
            self.optimizer.step()
            self.optimizer.zero_grad()

Testing strategy:- Unit test data loading by injecting a deterministic/synthetic dataloader and asserting batch contents.- Unit test forward/loss by calling model_fn and loss_fn directly on fixed inputs.- Unit test optimizer/integration by injecting a stub optimizer that records step() calls and gradients.- End-to-end determinism test: run two short training runs with same seed and assert model parameters equal.

Trade-offs:- More interfaces/DI increases boilerplate but maximizes testability and clarity.- Full determinism across hardware (GPU/cuDNN) may require slower deterministic settings.

This design yields a small orchestration layer, injectable pure components, and deterministic behavior suitable for unit testing.

MediumTechnical

125 practiced

A production inference endpoint must be robust to unexpected inputs. Write a short Python Flask route that performs schema validation on JSON input, returns 400 with a helpful error message for invalid inputs, and uses a centralized validator function. Keep the code concise and follow clean-code best practices.

Sample Answer

To ensure a production inference endpoint is robust, validate request JSON against an expected schema in a centralized function, return clear 400 errors, and keep route logic focused on orchestration.

python

from flask import Flask, request, jsonify, make_response

app = Flask(__name__)

# Centralized validator: checks required keys and types; returns (valid: bool, error: str)
def validate_input(payload):
    if not isinstance(payload, dict):
        return False, "JSON body must be an object"
    required = {
        "model": str,
        "inputs": list,      # list of input records
        "metadata": dict     # optional but if present must be dict
    }
    for key, t in required.items():
        if key not in payload:
            return False, f"Missing required field: '{key}'"
        if not isinstance(payload[key], t):
            return False, f"Field '{key}' must be of type {t.__name__}"
    # validate inputs content minimally
    for i, item in enumerate(payload["inputs"]):
        if not isinstance(item, (str, dict, list, int, float)):
            return False, f"inputs[{i}] has unsupported type: {type(item).__name__}"
    return True, ""

@app.route("/infer", methods=["POST"])
def infer():
    try:
        payload = request.get_json(force=True)
    except Exception:
        return make_response(jsonify(error="Invalid JSON body"), 400)

    valid, error = validate_input(payload)
    if not valid:
        return make_response(jsonify(error=error), 400)

    # Placeholder inference logic
    result = {"predictions": ["ok" for _ in payload["inputs"]]}
    return jsonify(result), 200

if __name__ == "__main__":
    app.run()

Key points:- Central validator keeps route simple and testable.- Returns helpful, specific 400 messages for clients.- For richer schemas, use jsonschema or pydantic (better error details, type coercion).Complexity: O(n) in number of input items. Edge cases: missing/extra fields, wrong types, non-JSON body, very large payloads (rate-limit or size-check upstream).

EasyTechnical

85 practiced

As an AI engineer you must ensure reproducible experiments. List five code-level best practices that improve reproducibility when training deep learning models and explain why each matters. Include examples such as seed setting, deterministic ops, environment pinning, and artifact versioning.

Sample Answer

1) Set and document random seeds- Why: Makes sampling, weight init, shuffling deterministic across runs.- Example (PyTorch/NumPy/Python):

python

import random, numpy as np, torch
seed = 42
random.seed(seed)
np.random.seed(seed)
torch.manual_seed(seed)
if torch.cuda.is_available(): torch.cuda.manual_seed_all(seed)

2) Enable deterministic operations and control nondeterminism- Why: Some CUDA kernels are nondeterministic; forcing deterministic ops reduces run-to-run variance.- Example (PyTorch):

python

torch.use_deterministic_algorithms(True)
torch.backends.cudnn.benchmark = False

3) Pin environment and dependencies- Why: Different library versions (CUDA, cuDNN, PyTorch, TF) change behavior/precision. Pinning avoids drift.- Practice: Provide requirements.txt/conda-lock, or share Dockerfile with exact versions.

4) Version and hash artifacts (code, data, models)- Why: Ensures experiments reference exact inputs/outputs.- Practice: Store dataset checksum (SHA256), commit code to Git (tag/commit hash), version model artifacts (e.g., MLflow, DVC).

5) Log experiment metadata and random seeds; automate reproducible runs- Why: Metadata (hyperparams, seed, env, commit) lets others re-create runs; automation removes manual variance.- Practice: Use experiment trackers (MLflow, Weights & Biases) and CI scripts to run training with recorded configs.

These five practices combined significantly increase the chance that training runs can be reproduced exactly or closely replicated across machines and time.

EasyTechnical

74 practiced

Write a short Python example using dataclasses to represent a training configuration and show how immutability (frozen dataclass) helps prevent accidental mutation during training. Explain one situation where immutability could cause friction and how to handle it.

Sample Answer

Approach: use a frozen dataclass for training hyperparameters so attempts to mutate config raise an error; when updates are needed, create a new instance with dataclasses.replace.

python

from dataclasses import dataclass, replace

@dataclass(frozen=True)
class TrainConfig:
    lr: float = 1e-3
    batch_size: int = 64
    epochs: int = 10
    seed: int = 42

# create config
cfg = TrainConfig()

# accidental mutation raises
try:
    cfg.lr = 1e-4
except Exception as e:
    print("Mutation prevented:", e)

# proper way to update: create a modified copy
new_cfg = replace(cfg, lr=5e-4)
print(cfg, "->", new_cfg)

Why this helps:- Freezing ensures reproducibility: no part of training accidentally changes hyperparameters (helps debugging and experiments).- It enforces functional-style updates: state is explicit and versionable.

When immutability causes friction:- Example: you want to adjust a nested mutable object like a scheduler dict during training. Frozen prevents in-place edits.- Solution: keep immutable top-level config but derive mutable runtime state separately (e.g., instantiate a Scheduler object from config), or use dataclasses.replace to produce updated configs. This keeps benefits of immutability while allowing controlled mutations where needed.

MediumTechnical

72 practiced

You observe long-running training jobs whose logs are hard to interpret. Propose a log and metric schema (fields, tags, and sample values) that makes it easy to correlate runs, errors, and dataset versions. Provide a JSON example of a single log entry and explain each field briefly.

Sample Answer

Proposed schema (fields = indexed metadata/tags for correlation; metrics = numeric/time-series values; message = human text):

Indexed tags/fields:- run_id (uuid): unique training run- experiment_id (string): logical experiment grouping- job_id (string): orchestration task id (K8s pod/step)- commit_sha (string): code commit used- dataset_name (string)- dataset_version (semver or hash)- model_name / model_version- env (prod/staging/dev)- host / gpu_id- trace_id (for distributed traces)

Metric fields (numeric/time-series):- epoch, step, lr- loss, val_loss, accuracy, val_accuracy- throughput_samples_per_sec- gpu_util_pct, gpu_mem_mb, cpu_pct- sample_count, batch_size

Error/debug fields:- level (INFO/WARN/ERROR)- error_code- stack_trace (if error)- batch_hash (to reproduce bad input)- hyperparams (json)

Sample JSON log entry:

json

{
  "timestamp": "2025-11-22T14:03:17.123Z",
  "level": "ERROR",
  "run_id": "d7f3a9b2-5c1e-4a9b-8f2e-0b7f1c2a9e6d",
  "experiment_id": "exp-recommender-2025-11",
  "job_id": "train-rl-xyz-57",
  "commit_sha": "a1b2c3d4",
  "dataset_name": "user_events",
  "dataset_version": "2025.11.20+sha256:9f8e7",
  "model_name": "rec-net-v4",
  "model_version": "v4.2.0",
  "env": "staging",
  "host": "gpu-node-12",
  "gpu_id": "0",
  "trace_id": "trace-8b3f",
  "epoch": 3,
  "step": 12450,
  "loss": 2.431,
  "val_loss": 2.98,
  "throughput_samples_per_sec": 512,
  "gpu_util_pct": 93.2,
  "batch_size": 256,
  "sample_count": 64000,
  "error_code": "DATA_PARSE_ERR",
  "message": "Failed to parse example: TensorProto shape mismatch",
  "stack_trace": "ValueError: Tensor shape ... at data_loader.py:78",
  "batch_hash": "sha1:3c4f...",
  "hyperparams": {"optimizer":"adam","lr":0.0003,"weight_decay":1e-5}
}

Field explanations (brief):- timestamp: event time (UTC) for ordering and correlation.- level: log severity for filtering.- run_id: primary correlation key — join logs, metrics, traces.- experiment_id/job_id: group runs and map to orchestrator.- commit_sha: tie behavior to code state.- dataset_name/dataset_version: reproduce errors due to data drift.- model_name/model_version: link artifacts to runs.- trace_id: correlate distributed operations and traces.- epoch/step/loss/val_loss/accuracy: core training metrics for charting and alert rules.- throughput/gpu_util/gpu_mem: resource telemetry to detect bottlenecks.- batch_hash/sample_count: reproducibility — identify problematic batches.- error_code/stack_trace/message: machine-parseable error triage.- hyperparams: record config for debugging and hyper-search analysis.

Why this helps:- Single run_id + trace_id links logs, time-series metrics, and traces.- Dataset version + batch_hash localizes data-caused failures.- Structured numeric fields enable dashboards/alerts; structured error fields enable automated grouping and reruns.

Unlock Full Question Bank

Get access to hundreds of Clean Code and Best Practices interview questions and detailed answers.

Join thousands of developers preparing for their dream job.