Fine-Tuning interview questions
Fine-Tuning questions a AI engineer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
What does fine-tuning actually do to a model?
The strongest answer: It continues training a pre-trained model on your own input–output examples, so the weights shift toward that behavior — it changes how the model responds far more reliably than what it knows
Why it works: Right — more training, on examples of the behavior you want. Think style, format and task habits; it is a poor and unreliable way to store facts.
- Fine-tuning shapes behavior, not a fact store.
- More training on your example pairs.
- Expect changes in style, format, habits.
- Still verify outputs — hallucination remains.
Prompting, RAG and fine-tuning — what does each one change, and which do you reach for first?
The strongest answer: Prompting changes the instructions for a request, RAG changes which facts the model sees when it answers, fine-tuning changes the model’s default behavior. I try them in that order, cheapest first
Why it works: Exactly — instructions, knowledge, behavior. Knowing which of the three is broken tells you which lever to pull, and the cheap ones are also the quickest to undo.
- Instructions, knowledge, behavior — three levers.
- Prompt: change the instructions.
- RAG: change the facts in view.
- Fine-tune: change default behavior, last.
What does a supervised fine-tuning dataset look like, and what makes one good?
The strongest answer: Pairs of input and ideal output, in the exact format production will use, covering the real spread of cases including the hard ones — small and consistent beats large and noisy
Why it works: Exactly — the model imitates what it is shown, so every example should be an answer you would be happy to ship.
- The model imitates its examples.
- Pair each input with the ideal output.
- Match the production format exactly.
- Curate; strip personal data first.
You have 600 labeled examples for a fine-tune that should classify support tickets and write a one-line reason for each.
How do you use your 600 labeled examples so that you can prove the fine-tune was worth doing?
The strongest answer: Set a slice aside before training and never train on it. Score the base model with my best prompt on it first, then the tuned model on the same slice — the gap is the proof
Why it works: Right — a held-out set plus a baseline. Without the base model’s score you cannot say what the tuning bought.
- Held-out set and a baseline, always.
- Split before you train.
- Score the prompted base model first.
- Compare both on the same slice.
A fine-tuned model returns JSON on some requests and prose on others, and its tone swings. The training set was stitched together from three teams’ past work.
A fine-tuned model’s output format keeps changing. Where do you look first, and what do you do about it?
The strongest answer: The training data — mixed formats teach mixed formats. I’d fix one output spec, normalize or drop examples that break it, remove contradictions, confirm the training template matches the production prompt, then retrain and re-evaluate
Why it works: Exactly — the model learned what it was shown. Data preparation is most of the work in a fine-tune, and a template mismatch is the classic silent cause.
- Inconsistent data trains an inconsistent model.
- Read the training set first.
- One output spec; clean to fit it.
- Match training and production templates.
One model both classifies tickets and drafts replies. After a fine-tune on classification data, classification improved — and agents say the drafts got worse.
A fine-tune improved one task and hurt another. What happened, and what do you change?
The strongest answer: Narrow tuning cost general ability. I’d evaluate every task the model serves before and after, then mix broader examples in, tune more lightly, or route only classification to the tuned model
Why it works: Right — regression on tasks outside the training set is a known cost of narrow tuning, and you only see it if the eval covers everything the model does.
- A narrow fine-tune can break other tasks.
- Evaluate every task, before and after.
- Mix data in, or tune more lightly.
- Or route one task to the tune.
Your provider announces that the hosted base model under your fine-tune will be retired. The tuned model serves a core feature.
The base model under your fine-tune is being retired. How should you have planned for this, and what do you do now?
The strongest answer: A fine-tune is tied to its base model, so I keep the dataset, recipe and evals versioned. Now I test the new base with prompting alone, and re-tune only if it misses the bar
Why it works: Exactly — the upgrade bill is part of the price of fine-tuning, and a newer base model may make the tune unnecessary. The eval suite is what lets you find out quickly.
- Every fine-tune carries an upgrade bill.
- Version the data, recipe and evals.
- Test the new base un-tuned first.
- Re-tune only if it misses.
A team wants to fine-tune a small model to replace a large general one on a high-volume, narrow task. What must be true before you approve?
The strongest answer: The task is stable, the large model sets a measured quality bar, the tuned small model clears it on a held-out set, and at our volume the saving beats the cost of training and upkeep
Why it works: Right — this is the strong case for fine-tuning: narrow, stable, high volume, with evidence. The eval makes it a decision and not a bet.
- Narrow, stable, high-volume — and proven.
- Set the bar with the large model.
- Clear it on held-out data.
- Count training and upkeep in.