Artificial Intelligence Projects and Problem Solving Questions

Detailed discussion of artificial intelligence and machine learning projects you have designed, implemented, or contributed to. Candidates should explain the problem definition and success criteria, data collection and preprocessing, feature engineering, model selection and justification, training and validation methodology, evaluation metrics and baselines, hyperparameter tuning and experiments, deployment and monitoring considerations, scalability and performance trade offs, and ethical and data privacy concerns. If practical projects are limited, rigorous coursework or replicable experiments may be discussed instead. Interviewers will assess your problem solving process, ability to measure success, and what you learned from experiments and failures.

MediumTechnical

81 practiced

Describe how you would apply transfer learning to a small labeled image dataset (a few hundred images). Explain pretraining selection, layer freezing strategy, data augmentation choices, optimizer/learning-rate configuration, and strategies to avoid overfitting during fine-tuning.

HardSystem Design

63 practiced

Explain how you would design and deploy a computer vision model for real-time video anomaly detection on an embedded edge device (e.g., 30 FPS). Discuss model architecture choices, model compression techniques (quantization, pruning, distillation), inference engines (ONNX, TensorRT), and how you would evaluate accuracy versus latency trade-offs.

Sample Answer

Requirements & constraints:- Functional: detect anomalies in live 30 FPS video (e.g., intrusion, falls) with <150 ms end-to-end latency per frame and acceptable false positive/negative rates (specify target e.g., F1 > 0.8).- Non-functional: run on embedded device (CPU or small GPU/TPU), low power, occasional connectivity.

High-level architecture:- Camera → Preprocessing (resize, normalize, frame differencing) → Lightweight CV model → Post-processing (temporal smoothing, alert logic) → On-device telemetry + optional cloud offload.

Model architecture choices:- Frame-level vs spatio-temporal: use a balance — lightweight 2D CNN (MobileNetV3 / EfficientNet-lite) for per-frame features + a small temporal module (1D conv or GRU with short window of 5–10 frames) to capture motion/anomaly context.- For unsupervised anomaly detection: use an encoder-decoder (autoencoder / VAE) or feature-prediction model (predict next-frame features) so anomalies are large reconstruction/prediction error.- Supervised alternative: single-stage detector (YOLOv8-small) if labeled anomalies available.

Compression techniques:- Quantization: post-training static INT8 quantization (calibrate with representative dataset) to reduce memory and speed up inference. Consider QAT if accuracy drop is large.- Pruning: structured channel pruning on convolutional layers to reduce FLOPs; retrain/fine-tune after pruning.- Distillation: train a smaller student network using outputs/feature maps of a larger accurate teacher to recover accuracy after compression.- Combine: prune → distill → QAT flow yields best latency/accuracy.

Inference engines & deployment:- Export to ONNX for portability. Target device-specific runtimes: - NVIDIA Jetson: TensorRT (INT8) for fastest throughput. - Coral Edge TPU: TFLite with Edge TPU-compatible ops and INT8. - CPU-only: ONNX Runtime with OpenVINO backend or ARM NN.- Use batch size =1, enable asynchronous capture + prefetch, and pipeline GPU/CPU tasks to hide latency.

Evaluate accuracy vs latency trade-offs:- Metrics: frame-level precision/recall/F1, per-event detection latency, false alarm rate, ROC/AUC, reconstruction error distribution.- Profiling: measure end-to-end latency (capture → preprocess → inference → postprocess) and per-component FLOPs, memory.- Sweep experiments: vary model size, quantization mode (FP32/FP16/INT8), pruning ratio, distillation setups; plot accuracy vs latency curve and choose operating point that meets SLA.- Robustness tests: varied lighting, occlusion, input resolution; test calibration dataset for quantization to avoid distribution shift.- Monitoring: collect on-device metrics and periodic cloud evaluation; fallback mechanism to send uncertain frames to cloud for higher-accuracy processing.

Operational considerations:- Retraining pipeline for concept drift, lightweight on-device update mechanism, secure model signing, and power/thermal profiling.

MediumTechnical

72 practiced

Describe a reproducible ML experiment workflow you would build for a team. Cover code and environment versioning, dataset and artifact tracking, experiment logging (hyperparameters and metrics), containerization, and how auditors can rerun experiments to validate results.

Sample Answer

I’d build a reproducible experiment workflow that combines Git + DVC for code/data versioning, MLflow (or similar) for experiment logging & model registry, Docker for environment/containerization, and a CI pipeline to automate runs and artifact publication. Key principles: immutability, provenance (hashes), and automation.

Workflow outline1. Code & env versioning- All code in Git. Create annotated tags/releases for experiments (e.g., experiment/v1.2).- Environment described with conda environment.yml and a lock (pip-compile or conda-lock) plus requirements.txt with exact package versions and pip hash, committed to Git.- Store seed values and deterministic settings in config files (yaml) versioned in Git.

2. Dataset & artifact tracking- Use DVC to track large datasets and intermediate artifacts. DVC stores file hashes and pointers in Git; content stored in remote (S3/GCS/ARTIFACTORY).- Every experiment references a DVC snapshot (branch/tag) so dataset provenance is deterministic.- Compute & store checksums and schema snapshots for raw/processed data.

3. Experiment logging (hyperparams & metrics)- Use MLflow (or Weights & Biases) to log hyperparameters, metrics, and artifacts per run. Each run records: - Git commit hash - DVC data version (dvc.lock or dvc repro metadata) - Docker image tag or env lockfile hash - Random seeds, config file path- Save models and evaluation artifacts to remote artifact store; register final models in MLflow Model Registry with version and stage.

4. Containerization & reproducible runtime- Dockerfile pins base image and installs exact packages from lockfiles. Build artifacts include date and Git commit labels.- CI builds Docker image for experiment (tagged with git commit + dvc snapshot) and pushes to registry (ECR/GCR).- Optionally use GPU image variants and note nondeterministic ops (record CUDA/cuDNN versions and flags to maximize determinism).

5. CI/CD & automation- CI pipeline (GitHub Actions/GitLab/ Jenkins) triggers on PR/merge to main or when running specific experiment tags: - Runs unit tests, style checks - Runs lightweight reproducibility checks (small-sample run) - Builds Docker image, runs full experiment, logs to MLflow, pushes artifacts & DVC data.- Artifacts and metadata are immutable and referenced by hashes.

6. How an auditor reruns & validates results- Auditor checks out the Git tag/release cited in paper/report.- Pulls DVC-tracked data: dvc pull (uses the exact hashes from dvc.lock).- Pulls the Docker image (docker pull <registry>/<image:git-commit>), or rebuilds from Dockerfile and lockfile.- Runs the experiment via the same entrypoint (docker run --rm image:tag --config config.yml --seed 42). MLflow run ID and model artifact are identical if everything is correct.- Verify: compare logged metrics and model checksums, run unit benchmark scripts included in repo to validate behavior.

Practical notes & trade-offs- Record random seeds and note operations that may still be non-deterministic (multi-threading, some GPU ops). For strict audits, offer CPU-only reproducibility mode.- DVC + remote storage adds cost/maintenance but gives strong dataset provenance.- MLflow provides experiment tracking and a model registry; alternatives (W&B, neptune) are similar.- Keep README with exact rerun steps, and include a minimal “quick reproduce” script for auditors to validate in minutes.

This workflow ensures every result is tied to immutable artifacts: git commit, DVC data hashes, Docker image tag, and MLflow run ID—making reruns, audits, and model promotion reliable and transparent.

MediumTechnical

56 practiced

Compare grid search, random search, and Bayesian optimization (e.g., Optuna) for hyperparameter tuning. For a model whose training takes two hours per trial, which strategy would you choose and what stopping or multi-fidelity methods would you adopt to reduce cost while still finding good hyperparameters?

Sample Answer

Brief comparison:- Grid search: exhaustive, deterministic coverage but scales exponentially with dims — impractical when each trial costs 2 hours. Good only for very low-dimensional, discrete spaces or final fine-tuning.- Random search: simple, often surprisingly effective (covers more unique values per dimension), embarrassingly parallel, better than grid for high-dim spaces given fixed budget. Still wasteful when trials are expensive because it doesn’t learn from past results.- Bayesian optimization (e.g., Optuna): builds a surrogate (Gaussian process, TPE) and acquisition function to propose promising hyperparameters — much more sample-efficient, especially when evaluations are costly.

Choice for 2-hour trials:Use Bayesian optimization (Optuna with TPE) combined with multi-fidelity/early-stopping to avoid full 2-hour runs for poor configs. Start with a handful (10–20) random trials to seed the surrogate, then run BO. This balances exploration and exploitation and reduces total wall-clock.

Cost-reduction techniques to adopt:- Pruning/Early stopping: use Optuna’s pruners (SuccessiveHalvingPruner or AsynchronousSuccessiveHalvingPruner / ASHA) to stop underperforming trials early based on intermediate metrics (validation loss/accuracy at epochs or batches).- Multi-fidelity evaluations: evaluate on cheaper fidelities first (fewer epochs, smaller subset of data, lower-resolution features). Promote promising configs to higher fidelities. Implement via Optuna’s multi-trial scheduling or combine BO with Hyperband (BOHB) if available.- Learning-curve extrapolation: use intermediate learning-curve slopes to predict final performance; prune if prediction is poor.- Resource-aware parallelism: limit concurrent high-fidelity trials; schedule many low-fidelity evaluations in parallel.- Budgeted acquisition settings: increase n_startup_trials to gather robust priors; tune acquisition jitter to avoid premature convergence.

Concrete Optuna setup example (conceptual):- sampler = optuna.samplers.TPESampler(n_startup_trials=15)- pruner = optuna.pruners.SuccessiveHalvingPruner(min_resource=1, reduction_factor=3)- study = optuna.create_study(sampler=sampler, pruner=pruner, direction="maximize")- study.optimize(objective, n_trials=200, timeout=...) where objective reports intermediate results after each epoch and uses smaller-data quick checks first.

Trade-offs and caveats:- Ensure intermediate metric correlates with final metric (pruning only helps if early signal is predictive).- Multi-fidelity approximations can bias selection; validate top candidates with full 2-hour runs.- For highly noisy or very nonstationary objectives, BO may need more initial random samples or robust acquisition tuning.

Summary:Use Bayesian optimization (Optuna TPE) + early stopping (ASHA/Successive Halving) + multi-fidelity (fewer epochs / smaller data) to minimize cost while retaining sample efficiency; always re-evaluate top candidates at full fidelity before production.

MediumTechnical

56 practiced

You built an intent classification pipeline for support messages. Describe preprocessing (text normalization, tokenization, handling typos), labeling strategy for intents, model selection trade-offs (transformer fine-tuning vs classical models), handling class imbalance, and deployment considerations to meet low-latency inference constraints.

Sample Answer

Preprocessing- Text normalization: lowercase, unicode normalization (NFKC), strip control chars, normalize whitespace. Expand contractions and map common domain-specific shorthand (e.g., “acct”→“account”). Remove PII via regex/token masking before training.- Tokenization: use the tokenizer matching your model (WordPiece/BPE for transformers). For classical models, use whitespace + n-grams (1–3) with stopword-aware options.- Handling typos: apply a two-step approach—1) lightweight at-inference fix: character-level normalization (remove repeated chars, normalize punctuation) and a small dictionary-based spell-corrector for frequent mistakes; 2) robust modeling: include noisy examples/augmentations during training (synthetic typos, keyboard-distance swaps) so model learns invariance.

Labeling strategy- Define mutually exclusive intents with clear decision rules and examples; create hierarchy (top-level intent → sub-intent) if many classes.- Use annotation guidelines, consensus labeling, and an adjudication step for ambiguous cases. Track inter-annotator agreement (Cohen’s kappa).- For low-support classes, allow multi-label or “other” buckets plus active learning: sample uncertain/unlabeled examples for human labeling iteratively.

Model selection trade-offs- Transformer fine-tuning (e.g., DistilBERT / DeBERTa): higher accuracy, robust to language variation; better for semantic intents. Cons: larger model size, higher latency and cost.- Classical models (logistic regression, SVM with TF-IDF or fastText): fast, lightweight, predictable latency and cheaper to serve; may underperform on subtle semantics or noisy text.- Middle ground: use compact transformers (DistilBERT, MobileBERT) or sentence-transformer embeddings + a lightweight classifier. Evaluate accuracy vs latency on your data and set SLA thresholds.

Handling class imbalance- Data-level: upsample minority classes, synthesize paraphrases (back-translation, template-based), or use focused active learning to gather real examples.- Algorithm-level: class-weighted loss, focal loss, or calibrated thresholds per class. Use stratified CV and metrics beyond accuracy (macro-F1, per-class recall).- Monitoring: track drift and per-class performance; retrain when a class degrades.

Deployment & low-latency inference- Model compaction: quantization (INT8), pruning, or distillation to smaller student models.- Serving: batch small requests, but prioritize single-request latency. Use async workers, GPU for high throughput, or CPU-optimized models for lower cost.- Infrastructure: deploy with a lightweight framework (ONNX Runtime, TensorRT, or TorchScript). Use autoscaling, warm-started containers, and caching for repeated queries.- Pipeline optimizations: precompute tokenization pipeline in native code, minimize I/O, and move normalization into fast C++/Rust microservice if needed.- Fallbacks & confidence: return top intent with confidence; for low confidence, route to rule-based heuristics or human-in-the-loop. Log predictions and latencies for monitoring and continuous improvement.

This approach balances accuracy, robustness to noisy support text, and production constraints by combining careful preprocessing, pragmatic labeling, model selection based on SLA, and engineering optimizations for inference.

Unlock Full Question Bank

Get access to hundreds of Artificial Intelligence Projects and Problem Solving interview questions and detailed answers.

Join thousands of developers preparing for their dream job.