There's a quiet crisis in how we prepare for agentic systems design interviews, and it has nothing to do with a lack of intelligence or effort. The real problem is that most candidates, especially those coming from traditional data science roles, are trying to apply the same mental models they used for ML systems design to a fundamentally different beast. Agentic systems don't reward the same kind of feature engineering or model selection. They reward clarity of orchestration, explicit reasoning about tool use, and a willingness to define success in terms of outcomes rather than metrics. If you're treating an agentic interview like a scaled-up version of a recommendation system design, you're already behind.
What makes this harder is that the field itself is immature, and that's not your fault. The person who posted this is honest about their company's scattershot approach, and that honesty is the right starting point. But it also reveals a deeper issue: when the technology is young and the patterns aren't established, interviewers often don't know what they're looking for either. That's actually an opportunity. You can stand out not by pretending to have all the answers, but by showing you have a framework for asking the right questions. Instead of black-boxing the LLM, talk about when and why to delegate to it. Discuss how you'd evaluate a system where the "correct" answer is fuzzy, and propose concrete proxy signals. The candidate who says "here's how I'd think about this" will always beat the one who says "here's the architecture I'd use."
The practical takeaway is that you don't need to master every agentic pattern before the interview. You need to master the discipline of decomposing a vague problem into testable components. Start with the user's goal, then map out the decision points where an agent might act, and be explicit about what happens when it's wrong. That last part is critical. Most candidates freeze when asked about failure modes, but in agentic systems, failure is the default. The LLM will hallucinate. The tool call will return garbage. The question is whether you've built in checkpoints, fallbacks, and human escalation paths. If you can articulate that, you've already shown more systems thinking than most senior engineers.
So stop trying to predict the "right" answer and start practicing the act of reasoning out loud. Record yourself walking through a design prompt. Ask a friend to interrupt you with edge cases. Focus on the flow of your logic, not the polish of your vocabulary. The interview isn't a test of what you know; it's a test of how you think under pressure. And the only way to get better at that is to simulate it, poorly at first, then with increasing confidence. That's the framework worth mastering, and it's the one that will carry you through the interview, regardless of how mature your current company's agentic stack is.