There’s a specific moment in an AI engineering interview that tells the interviewer almost everything they need to know before you’ve said a full sentence: what word comes first when you’re asked how you’d pick a model.
Say a model name first — “I’d reach for GPT-4o” or “probably Claude Opus” — and you’ve signaled that the decision is taste. Say a constraint first — cost, latency, or quality — and you’ve signaled that the decision is engineering. Same question. Completely different interview.
Why the constraint has to come first
The reason this ordering matters isn’t interview theater — it’s that model tiers genuinely trade off against each other. We’ve laid out the actual numbers elsewhere: at one realistic workload, moving from a mid-range model to a frontier one multiplied the daily bill by roughly five, for identical requests. Nothing about the task changed. Only the tier did. An interviewer who’s actually run a production AI feature has felt that multiplier personally, and they’re listening for whether you have too.
So the framework an interviewer wants isn’t “here’s a model I like” — it’s a repeatable process: name the binding constraint, let that constraint dictate a tier, and only then get specific about which model within that tier. Skip step one and everything downstream is guesswork dressed up as an opinion.
The fine-tuning trap
A close second in this category is the model-selection question that quietly becomes a fine-tuning question: “the model isn’t quite hitting our accuracy bar — what do you do?” The wrong answer reaches for a training run. The right answer treats fine-tuning as the most expensive, least reversible lever on the shelf, and reaches for it last, not first.
The actual order interviewers expect: exhaust prompt engineering seriously — not one attempt, closer to ten meaningfully different strategies — then reach for retrieval if the gap is factual rather than stylistic, and only evaluate fine-tuning once both are genuinely spent and a specific cluster of signals is present together (persistent style drift, rare vocabulary the base model doesn’t have, a latency budget too tight for a long prompt, or genuinely high volume on a narrow task). One of those signals alone doesn’t clear the bar. The full decision tree for that question lives here if you want the mechanics, including a runnable benchmark comparing a few-shot prompt against a fine-tuned adapter on the same task.
The benchmark question that filters for depth
There’s a third question worth preparing for on purpose, because it’s the one that separates candidates who’ve only read about production AI from candidates who’ve operated it: “how much do you trust a public leaderboard score?”
The answer that lands isn’t “not at all” — leaderboards are a reasonable starting point for narrowing candidates. It’s naming the specific failure mode: benchmark contamination, where training data can include leaked examples from a benchmark’s own test set, quietly inflating a score past the model’s real capability. And even without contamination, a benchmark only measures what it was built to measure — a strong score on a general knowledge test tells you very little about performance on your specific, narrow, weirdly-shaped production task. The credible answer ends with “so I run my own eval set on my own data before I trust any of it,” because that’s the step that actually catches the gap a leaderboard can’t see.
What all of this has in common
Every one of these questions is really testing the same underlying habit: do you reach for a number, or do you reach for a name? Constraint before model. Signals before a training run. Your own eval before someone else’s leaderboard. None of it requires memorizing a specific model’s specs — it requires internalizing a small decision process and being able to walk through it out loud in under two minutes.
That’s also, not coincidentally, the exact process that turns “which model should I use” from a debate into arithmetic — which is the more useful skill to walk away with either way.