Alongside the usual questions on databases, caching, and queues, interviewers now ask you to design applications built on LLMs. And once an LLM is in the design, the first question is which model you'd use and why. This course covers how to make that choice and how to explain it, with the same rigor you'd apply to picking Postgres over DynamoDB, applied to picking a model.
Ask a candidate why they chose a particular database and you'll usually get a real answer: read patterns, consistency requirements, operational cost, team familiarity. Ask the same candidate why they chose a particular model and the answer is often "GPT is the best one" or "we'd use whatever is on top of the leaderboard."
Interviewers notice the difference. Model selection has the same structure as any other architecture decision. There are constraints, there are trade-offs, and there is a wrong answer for a given set of requirements. If you can talk about capability tiers, cost at scale, latency budgets, and data residency the way you'd talk about sharding or replication, you're demonstrating that you understand the system rather than the API.
Several lessons in this course deal with interview framing directly, including how to answer the safe model upgrade question, which has become a common follow-up.