Fine-Tuning Interview Questions for 2026 (With Sample Answers)

What Gets Asked in Fine-Tuning Interviews

Fine-tuning interview questions appear in LLM Engineer, Applied AI Engineer, and some platform-leaning loops when teams run open weights (Llama, Mistral, Qwen) or ship LoRA adapters alongside RAG. The questions below reflect phone screens, take homes, and system design discussions at teams that customize models.

Each answer uses a short direct response plus bullets you can expand verbally. For skill context and learning order, see our top GenAI skills for 2026 guide.

Think of customization as a ladder: prompt engineering first, then RAG for external knowledge, then PEFT adapters, then full fine-tuning, then alignment stacks. Interviewers probe where you would stop for a given product requirement and what metric would prove you chose correctly.

Phone screens rarely need RLHF derivations; they need dataset hygiene, held-out eval, and a clear reason you chose adapters over full fine-tuning.

Fundamentals

Interviewers map your answer onto a customization ladder: prompt, RAG, PEFT adapters, full fine-tune, then alignment. Know which rung solves which failure mode. If you only mention "we fine-tuned Llama," follow up with why prompting or retrieval was insufficient and what held-out metric improved.

Q: What is fine-tuning, and how is it different from prompt engineering and RAG?

Fine-tuning updates model weights on curated examples. Prompt engineering and RAG change inputs at inference time without changing weights.

• Prompting: fastest iteration; good for instructions and format nudges; limited by context and model prior
• RAG: injects external documents at query time; best for fresh facts and citations (RAG explained)
• Fine-tuning: bakes behavior, tone, or vocabulary into weights; better latency than long RAG prompts for stable patterns
• Production: many systems stack all three; fine-tuning is not a replacement for retrieval on volatile facts

If the failure mode is "model does not know our JSON schema," fine-tune or strong prompting; if "model does not know yesterday's price," RAG.

Q: What is the difference between full fine-tuning and parameter-efficient fine-tuning (PEFT)?

Full fine-tuning updates all (or most) weights; PEFT trains a small adapter while keeping the base model frozen.

• Full FT: maximum capacity; highest GPU memory and catastrophic forgetting risk; rare outside research or small models
• PEFT (LoRA, adapters): trains low-rank matrices or small modules; typical for 7B to 13B on one or few GPUs
• Interview default: assume LoRA-family PEFT unless they say "full fine-tune on 70B"
• Storage: ship adapter weights (MBs) instead of full checkpoint (GBs)

Q: When would you choose fine-tuning over RAG or prompting alone?

Choose fine-tuning when the base model consistently misses a stable pattern that prompting cannot fix cheaply.

• Output format or schema compliance (classification labels, ticket routing, JSON shape)
• Domain vocabulary and tone (legal phrasing, clinical shorthand) without stuffing context every call
• Latency-sensitive paths where long RAG context is too expensive
• Not for: facts that change weekly, large document corpora, or citation-heavy Q&A (use RAG)

Mention hybrid: LoRA for tone/format, RAG for facts (RAG vs fine-tuning).

LoRA, QLoRA, and PEFT

Production interviews in 2026 assume Hugging Face PEFT or TRL-style LoRA. Know rank, target modules, and memory trade-offs. Be ready to sketch a minimal training config: base model ID, LoRA rank and alpha, learning rate, batch size, and how many epochs you stopped after watching validation.

Q: Explain LoRA. What do rank and alpha control?

LoRA injects trainable low-rank matrices into selected layers while freezing original weights.

• Rank (r): adapter capacity; higher r = more expressiveness, more overfit risk; common starting points 8, 16, 32
• Alpha: scaling factor paired with rank; effective scale often discussed as alpha/r; tunes how strongly adapters influence forward pass
• Target modules: commonly q_proj, v_proj; sometimes all linear layers for harder tasks
• Eval: compare val loss or task metric across r values; do not pick rank by default alone

Q: What is QLoRA and when do you use it vs LoRA?

QLoRA loads the base model in quantized form (often 4-bit) and trains LoRA adapters on top.

• When: single GPU, larger base model (13B, 70B) that would not fit in full precision
• Trade-off: slight quality loss from quantization vs fitting the run at all
• vs LoRA: same adapter idea; difference is quantized base weights and specialized optimizers (e.g. paged optimizers)
• Interview line: "QLoRA is a memory strategy"

Q: Which modules do you typically attach adapters to?

Attention projections are the default; MLP layers add capacity for harder format or reasoning tasks.

• Attention only (q_proj, v_proj): cheaper, often enough for style and classification
• All linear layers: more parameters trained; use when task metric plateaus with attention-only
• Avoid: training embeddings/lm_head unless you have a specific reason (vocab extension)
• Framework: PEFT target_modules config documents your choice in code review

Q: What tools would you use for a fine-tuning project?

Hugging Face stack is the interview baseline; name one higher-level trainer.

• Datasets + Transformers + PEFT: load base model, attach LoRA, train
• TRL: SFTTrainer, preference tuning hooks
• Axolotl / LLaMA-Factory / Unsloth: opinionated configs for repeatable runs
• Tracking: Weights & Biases or MLflow for loss curves and checkpoint comparison
• Eval: hold-out JSONL + task script

Data and Training Pipeline

Bad data loses to good data at any rank. Interviewers ask about leakage, format, and splits before learning rate. Describe how you would audit a JSONL export for duplicate prompts, label skew, and train or val overlap before you touch hyperparameters.

Q: How do you prepare a fine-tuning dataset?

Start from raw examples, normalize to a consistent instruction format, deduplicate, and split before any training.

• Format: instruction/input/output JSONL or chat messages (system, user, assistant)
• Cleaning: remove PII, dedup near-duplicates, filter empty or toxic rows
• Splits: train/val (90/10 or 80/20); never tune on val; optional test set frozen for final report
• Versioning: dataset ID in experiment logs; same split reproducibility with seed

Q: How many examples do you need?

Quality and task difficulty matter more than a magic number; give ranges and what you do when data is scarce.

• Many SFT tasks: roughly 500 to 5k curated pairs after cleaning
• Below ~200: prefer few-shot prompting or RAG unless task is very narrow (e.g. binary classification)
• Synthetic data: acceptable if filtered and spot-checked; disclose in interview
• Signal: val metric should improve over base; if not, data or task framing is wrong

Q: What is catastrophic forgetting and how do you mitigate it?

Fine-tuning can degrade general capabilities when the model overfits narrow data.

• Mitigations: LoRA instead of full FT; lower learning rate; fewer epochs; early stopping on val
• Mixed data: blend general instruction data with domain set (careful with distribution shift)
• Regression eval: test general benchmarks or smoke prompts after training, not only target task
• Production: keep base model serving path if adapter fails regression gate

Evaluation and Go/No-Go Decisions

Define success before training. Interviewers listen for held-out metrics and explicit "we stopped because val got worse." Name the primary metric for your task, the regression prompts you would not sacrifice, and the promotion gate that blocks a bad adapter from production traffic.

Q: How do you evaluate a fine-tuned model?

Combine automatic metrics on held-out data with spot checks for regression and safety.

• Task metrics: accuracy, F1, exact match, JSON schema pass rate, rubric score
• Compare: base model vs adapter on same val set with identical prompts
• LLM as judge: optional for open-ended generation; human review for high stakes
• Regression set: 20 to 50 general prompts to catch forgetting
• Gate: promote adapter only if primary metric improves without regression breach

Q: When would you not fine-tune?

Skip fine-tuning when cheaper layers solve the problem or data/eval discipline is missing.

• Knowledge changes frequently (daily pricing, news) → RAG
• Fewer than ~200 quality examples and no budget to collect more
• No held-out eval or owner for retraining cadence
• API-only product with no model hosting path
• Prompt + RAG already hits target metric (do not fine-tune for sport)

Q: RAG vs fine-tuning: when would you use each in production?

RAG for fresh, citeable facts; fine-tuning for stable format, vocabulary, and behavior. See RAG vs fine-tuning and LLM interview questions for broader context.

• RAG wins: large KB, citations, frequent updates
• Fine-tuning wins: consistent JSON, domain tone, lower per-query tokens vs huge retrieved context
• Hybrid: LoRA adapter + retrieval (common in enterprise support and legal tech)

State which failure mode you saw before picking a method.

Alignment and Production

Applied roles need vocabulary for SFT, RLHF, and DPO without deriving loss functions. Production questions cover adapters on serving stacks. You do not need to derive DPO loss; you do need to explain when SFT alone is enough and when preference data justifies a heavier alignment pipeline.

Q: What is the difference between SFT, RLHF, and DPO at a high level?

SFT teaches demonstrations; RLHF and DPO align outputs to preferences or safety policies.

• SFT (supervised fine-tuning): train on input/output pairs; first step for most custom behavior
• RLHF: reward model + reinforcement learning from human preferences; heavier pipeline
• DPO: direct preference optimization from chosen/rejected pairs; simpler than full RLHF in many stacks
• Interview: "Most custom apps stop at SFT + eval; alignment stacks add preference data"

Q: How do you deploy and version a fine-tuned model or LoRA adapter?

Treat adapters like versioned artifacts with eval gates, similar to model weights in MLOps.

• Registry: store adapter + base model ID + dataset hash + metrics in model registry
• Serving: load adapter on vLLM, TGI, or Ollama; or merge adapter for simpler ops (trade merge cost vs flexibility)
• Rollout: canary traffic; rollback to previous adapter version
• Docs: model card with training data summary and known limitations
• Link: MLOps for LLMs careers for platform patterns

Q: What GPU or compute constraints affect your fine-tuning choices?

Memory determines whether you use QLoRA, smaller base model, or cloud multi-GPU.

• 7B LoRA FP16: often 1x 24GB GPU; 7B QLoRA: 1x 16GB consumer GPU
• 13B+: QLoRA or multi-GPU; mention gradient checkpointing
• Time: epoch count × dataset size; use small subset for hyperparameter search first
• Cost: compare one training run vs ongoing RAG inference if budget is tight

Behavioral and Follow-Up Questions

Behavioral answers need numbers: base model, method, dataset size, metric delta, and what you would do next. Even a weekend LoRA run on a public dataset counts if you can defend splits, hyperparameters, and an honest limitation.

Q: Tell me about a fine-tuning experiment you ran.

What they're checking: credible workflow, metric, and honest limitation.

Sample answer: "Our ticket classifier needed consistent JSON labels. Base Llama 3 8B with prompting hit 58% exact match on 300 held-out tickets. LoRA rank 16 on 2k labeled examples for three epochs reached 89% exact match. Regression prompts for general chat still worked. Next step was merging RAG for policy paragraphs the model kept paraphrasing wrong."

• Base model and method (LoRA rank)
• Dataset size and eval split
• Before/after metric on held-out set
• One limitation or next step

Q: How do you explain fine-tuning trade-offs to a PM?

Translate into ship time, retrain cost, and where facts must stay in retrieval.

• Fine-tuning adds a training cycle and eval gate before launch
• Ongoing cost when labels or format change (retrain vs prompt tweak)
• Facts that change often should not be "memorized" into weights
• Hybrid roadmap: ship RAG first, add adapter when format pain is proven

Common mistakes to avoid

• Fine-tuning to store facts that belong in RAG
• Training without held-out validation
• Tuning rank/epochs without watching val metric
• Leaking test examples into training data
• Deploying adapter with no regression smoke tests
• Claiming full fine-tune on large models when you only ran LoRA (be precise)

What to Read Next

• RAG vs fine-tuning: architecture and cost
• RAG interview questions: retrieval interview depth
• LLM interview questions: general LLM loop
• Prompt engineering interview questions: prompt layer of the stack
• MLOps for LLMs careers: deploy and monitor
• Build a GenAI portfolio: LoRA portfolio project
• Fine-tuning jobs: live listings

Browse Fine-tuning jobs and note how often JDs mention LoRA, TRL, open-weight hosting, or hybrid RAG plus adapters. Teams hiring for this stack usually expect you to discuss eval gates and adapter versioning.