A 30-day plan to crack your first GenAI interview

Thirty days is not enough to learn everything about generative AI. It is enough to prepare well for a first GenAI interview if you spend the time on the core topics and you finish with one project you can explain end to end. This plan assumes you already write code comfortably and can give it about two hours on weekdays and a longer session on weekends. Adjust the pace to your own schedule.

Days 1 to 5 cover model basics. Learn to explain tokens, context windows, sampling settings such as temperature, and why outputs vary from run to run. Call a model API from a short script, log every request and response, and record token counts. By day 5 you should be able to explain, in plain words, what happens between sending a prompt and getting text back, and why longer prompts cost more and take longer.

Days 6 to 9 cover prompting as engineering. Write prompts for three small tasks, such as extraction, classification, and summarization. Keep a fixed set of ten to twenty test inputs for each, and change one thing at a time. Practice explaining structured output, few-shot examples, and why you version prompts. The goal is not clever wording. It is being able to say why a change made things better, with evidence.

Days 10 to 16 cover retrieval-augmented generation, the topic to give the most time. Build a small question-answering tool over documents you know well. Work through chunking, embeddings, a vector store, metadata filters, and returning sources with each answer. When an answer is wrong, check what was retrieved before blaming the model. Use the RAG interview guide at /blog/rag-interview-guide to drill the common questions in this area.

Days 17 to 20 cover evaluation. Turn your test inputs into a small evaluation set. Separate three checks: whether retrieval found the right context, whether the answer stayed faithful to it, and whether it answered the question asked. Run the set after every change and keep a short log of what moved. Practice a two-minute answer to the question of how you would know the system is ready to ship. The LLM evaluation guide at /blog/llm-evaluation-interview-guide is the companion for this week.

Days 21 to 24 cover agents and system design. Extend your project with one or two tools, a clear state object, and a step limit so it cannot loop. Then practice designing systems on paper: a support assistant, an internal search tool, a document summarizer. For each, start with users and requirements, sketch the data flow, go deep on retrieval, explain evaluation, and draw the failure paths, including a hand-off to a human. The LangGraph agent system design guide at /blog/langgraph-agent-system-design-interview-guide shows how to structure that whiteboard conversation.

Days 25 to 27 cover cost and latency. Measure where time goes in your own project: retrieval, the model call, and post-processing. Try caching repeated questions, trimming context, streaming responses, and routing easy requests to a smaller model, and note what each change did in your logs. Be ready to answer what happens when traffic grows tenfold. The LLM cost and latency guide at /blog/llm-cost-latency-interview-guide covers the trade-offs to name.

Days 28 to 30 are rehearsal. Write a five-minute story of your project: the problem, the first version, what broke, how you measured it, and what you changed. Do at least two mock interviews out loud, one technical and one system design, and record them. Listen back for vague phrases and replace them with the specific thing you did or would measure. Prepare a few honest questions to ask the interviewer about how their team evaluates and ships AI features.

A few habits hold the plan together. Keep one project and keep improving it rather than starting new ones. Write down every mistake you hit, because those become your best interview stories. When you do not know an answer, say what you would check to find out. A first GenAI interview rarely expects you to know everything. It usually rewards clear reasoning, honest trade-offs, and evidence that you have built something and measured it.