Prep Mistakes That Cost Strong Engineers the AI Engineering Offer

Strong engineers lose the AI engineering offer for a short list of predictable reasons, and almost none of them come down to raw coding ability. The four that cost the most offers: memorizing model architectures instead of learning to evaluate systems, showing up with no shipped project, being unable to reason about cost and latency, and refusing to say "I do not know". Each is avoidable once you can name it. This piece walks through the four traps, why each is fatal in an AI engineer loop specifically, and what to do instead.

Mistake 1: memorizing architectures instead of evals

The most common prep error is treating an AI engineering loop like an exam. Candidates memorize the transformer block, rehearse the difference between LoRA and full fine-tuning, and can name four vector databases. Then the interviewer asks how they would know whether their retrieval system is any good, and the room goes quiet.

Measurement is the center of the job. A model that demos well and a model that works are different things, and the whole discipline exists to tell them apart. So an engineer who cannot describe an eval is describing a gap the role exists to close. The tell is precise: a candidate lays out a clean pipeline, then says "and then I'd ship it" with nothing in between. No labeled set, no working definition of correct, no plan for when the eval score is mediocre while the demo looks great.

You still need the floor. If attention, embeddings, or the basics of fine-tuning trip you up, you are done, so put in enough time on LLM and GenAI fundamentals to stay fluent. Past that floor, redirect your marginal hours. Take one small retrieval or agent project, define what correct means for it, label even fifty examples, and measure. Then work the evaluation and failure-analysis questions in RAG and agent system design so you can talk honestly about groundedness, hallucination, and regression. An eval you ran yourself beats any volume of theory.

Mistake 2: no shipped project

The second trap is having nothing you actually built. Interviewers do not need users or scale. They need one thing you made, broke, measured, and improved, because every hard question in the loop is a follow-up to that.

Without one, you have no answer to the second-level question, and the second level is where the loop is decided. Anyone can say they built a RAG chatbot. The interviewer's real question is the next one: what was retrieving badly, how did you find out, what did you change, and did it work. A candidate who says "I noticed the model was confidently answering from the wrong chunk, so I looked at fifty failures by hand, found that my chunk boundaries were splitting tables in half, switched to structure-aware chunking, and recall at five went from mediocre to acceptable" has just passed a round that no amount of reading can fake.

Build something small and genuinely break it. A retrieval system over your own documents, an agent with a tool that fails, a fine-tune that does not beat the prompt. Failure is the raw material for the story, so keep the number you measured and the thing you got wrong.

Mistake 3: cannot reason about cost and latency

This is the trap that separates a hobbyist from an engineer, and it is the least drilled. In production, cost and latency decide the design. A candidate who cannot multiply tokens by price by volume, or who cheerfully proposes a five-step agent loop for an interactive experience with a two-second budget, is telling the panel they have never owned an AI feature that had a bill attached.

Nobody expects you to have current prices memorized, and quoting a price to three decimal places will not help you. What is expected is that you know which knobs move the numbers. That output tokens dominate generation latency while input tokens dominate retrieval-heavy cost. That model choice moves cost by roughly an order of magnitude, which is what makes routing easy queries to a small model and escalating the hard ones worth proposing by name. That every extra agent turn multiplies the whole budget. That a reranker buys precision and spends milliseconds you may not have.

The fix is arithmetic, out loud, on your own project. Work out what a request costs you and what it would cost at a thousand times the volume. Then run system design questions and force yourself to state the latency budget and the cost per request before drawing a single box.

Mistake 4: cannot say "I do not know"

The last trap is the one that gets people rejected after a technically strong loop. Asked something at the edge of their knowledge, a candidate bluffs. They invent a plausible-sounding mechanism, quote a number they never measured, or promise an accuracy figure nobody could guarantee.

In this field, that is disqualifying. AI engineering is full of genuine uncertainty: nobody knows exactly why a prompt change moved the eval, or what the model will do on the query no one anticipated. The engineers worth hiring are the ones who can hold that uncertainty out loud and then say how they would resolve it. The ones who bluff will ship an overclaim into production, and an interviewer who catches one bluff will discount everything else you said.

Rehearse the honest form, because it has two halves. Not just "I do not know," but "I do not know, and here is how I would find out." The candidate who says "I would not guess at the hallucination rate, I would build a set of a hundred real queries, check every answer for a citation in the source, and give you a number by Thursday" scores higher than the one who confidently makes something up. Interviewers are explicitly listening for this, and the behavioral and project deep-dive questions are where they set the trap.

How the four compound

The traps feed one another. Memorize instead of building, and you have no shipped project. With no shipped project, you have never seen a bill or a p95, so cost and latency stay abstract. And with nothing you have actually measured, you have no honest number to fall back on, which is exactly when candidates start to bluff.

The common thread is the one the job rests on: the model is the easy part, and everything around it (measurement, cost, failure, honesty) is the hard part. Prep that misses that lens tunes the wrong half of the loop.

How to recalibrate fast

Take one honest timed pass through the must-know set and find which trap you sit nearest to. If you have never run a real eval, build one this week. If you have no shipped project, start something small today and break it on purpose. If you have never costed a request, do that arithmetic tonight. If you catch yourself bluffing in a mock, that is the highest-value thing you learned all week.

The aim is not perfection on every axis. It is to stop losing offers you should win, by retraining the half of the loop that strong engineers so reliably neglect.