When an LLM (large language model) feature falls short, you have three levers. You can change the instructions the model reads (prompting), change the facts it sees on each request (RAG (retrieval-augmented generation)), or change the model's weights by training it further on your own examples (fine-tuning). The interview question "should we fine-tune for this, or is prompting or RAG enough?" is really asking whether you know which lever changes what.

Fine-tuning is the heaviest of the three. It earns its place when a stable behavior or format gap survives prompt and structured-output fixes, or when volume makes it worth training a small model to do a large one's job. It is the wrong lever for facts that change, which belong in retrieval. So the second half of the question is what it needs before you commit: data, a cheap training method, a cost case, and a plan for when the base model changes.

All of it runs on one product: a support assistant for a payroll software company. It drafts replies to customer tickets and tags each ticket with one of 60 internal categories as JSON, about 40k tickets a day. Its help-center articles on tax and overtime rules change every week.

This question usually comes up as a 5–10 minute follow-up after the first design of an LLM feature. For a mid-level role, the bar is separating knowledge from behavior and knowing that facts belong in retrieval, not in a fine-tune.

For a senior role, interviewers listen for how much data a fine-tune needs, the cost math behind distilling a large model into a small one, and what retraining costs when the provider ships a new base model. The tutorial assumes you can write a prompt with few-shot examples from Prompt Design and describe a RAG request from Retrieval-Augmented Generation.