From backend dev to AI engineer in 90 days: a prep story

A quick note before the story. The backend developer in this post is an illustrative composite, not a real person. The plan, the topics, and the mistakes are drawn together to show a realistic path, and nothing here reports a real company's hiring outcome.

I had spent years building APIs, queues, and database schemas. I knew how to keep a service up at three in the morning. What I did not know was how to talk about embeddings, retrieval, or evaluation without sounding like I had skimmed a thread the night before. So I gave myself 90 days and one rule: every week had to end with something I had built and could explain out loud.

Weeks 1 and 2 were about the model itself. I did not try to derive transformers from scratch. I learned enough to explain tokens, context windows, temperature, and why the same prompt can give two different answers. I wrote a tiny script that called a model API, logged every input and output, and counted tokens per request. That log became the most useful thing I built all quarter, because every later question about cost or latency went back to it.

Weeks 3 and 4 were prompting with discipline. I stopped treating prompts as magic strings and started treating them like code: versioned, tested against a fixed set of inputs, and changed one thing at a time. My first mistake showed up here. I kept tweaking the prompt until the demo looked good, then could not say whether it was better or just different. The fix was a small test set of twenty questions I wrote by hand, with the answer I expected for each.

Weeks 5 through 7 were retrieval. This is where my backend background finally paid off. Chunking documents, storing vectors, filtering by metadata, and returning the top results felt like building a search service, because it is one. I built a question-answering tool over my own engineering notes. My second mistake was blaming the model when answers were wrong. Most of the time the right passage never came back from retrieval at all. Once I started checking what was retrieved before reading what was generated, my debugging got much faster. The RAG interview guide at /blog/rag-interview-guide covers the questions I ended up practicing from this stretch.

Weeks 8 and 9 were evaluation. I learned to separate three questions: did retrieval find the right context, did the answer stay faithful to that context, and did it actually answer what was asked. I added those checks to my test set and ran them every time I changed anything. If you want the interview version of this, the LLM evaluation guide at /blog/llm-evaluation-interview-guide is the one I would read first.

Weeks 10 and 11 were agents and system design. I rebuilt my notes tool as a small agent that could search, read a file, and decide whether it had enough to answer. My third mistake was giving it too many tools and no stopping rule, so it looped. The fix was fewer tools, a step limit, and a clear state object I could print at every step. Practicing whiteboard versions of that design, with failure paths drawn in, is what the LangGraph agent system design guide at /blog/langgraph-agent-system-design-interview-guide walks through.

Week 12 was cost and latency, and it was the week my backend habits mattered most. I measured where time went: retrieval, the model call, and post-processing. I tried caching repeated questions, trimming context, and routing easy questions to a smaller model. I could now answer a question I kept hearing in mock interviews: what happens when this gets ten times more traffic. The LLM cost and latency guide at /blog/llm-cost-latency-interview-guide maps that conversation.

Week 13 was rehearsal. I picked my one project and practiced telling its story in five minutes: the problem, the first version, what broke, how I measured it, and what I changed. I did mock interviews out loud, recorded them, and listened back. The recordings were painful and worth it.

What I would tell another backend developer is simple. You are not starting from zero. Interviews for AI engineering roles still reward people who can reason about data flow, failure modes, and trade-offs. The new part is learning to measure a system whose output is not deterministic, and to explain why you trust it. Build one real project, keep a test set from the first week, and be ready to say what you would change next.