I added GenAI System Design to my interviews. Then I tried to pass one myself.

Anshul Prakash — Tue, 31 Mar 2026 14:00:00 +0000

I've been interviewing software engineers for a while. Recently I started incorporating GenAI system design into the loop — RAG pipelines, agent architectures, evaluation strategies. The kind of questions that are now standard at OpenAI, Anthropic, Google, and Meta.

Before I started asking candidates these questions, I wanted to make sure I understood what a strong answer actually looked like from the other side. So I went looking for reference material. That search led me to an AI-powered mock interview tool built specifically for this type of question.

I figured I'd run through a session. I've conducted hundreds of interviews. I know this material cold.

I was not expecting what happened next.

The Session

The question was a system design problem. The kind I've watched candidates struggle with dozens of times. I've sat on the other side of this exact type of question. I know what a strong answer looks like.

I started talking. I went into architecture. I covered components. I felt fine.

The session ended. The scores came back.

1/5. Across every dimension. Architecture. Scalability. Trade-off analysis. Requirement coverage. Communication. All ones.

The summary: "The candidate demonstrated minimal technical depth and failed to present any coherent system architecture or design.."

I stared at it for a while.

What Actually Happened

The feedback was right, and once I read it I knew exactly why.

I had walked in thinking about the problem the way I think about it when I'm reviewing a candidate's answer — from a position of already knowing the destination. I wasn't narrating my reasoning. I was stating conclusions and moving on, assuming the listener could follow my logic without seeing it.

That's not how interviews work. The interviewer has no access to your internal reasoning. They only have what you say out loud. And what I said out loud, apparently, didn't add up to much.

The sharpest note in the feedback: I had jumped straight into implementation without spending a single minute on requirement gathering. No clarifying questions. No scope definition. Just architecture.

*The #1 fix the tool highlighted: *"Practice the opening 2 minutes religiously — have a memorized script for requirement gathering that you can deliver even under extreme stress."

I give that exact note to candidates regularly. I had just failed to do it myself.

Why This Keeps Happening

There's a specific failure mode I see repeatedly in GenAI system design interviews, and I now realize I'm not immune to it myself.

Most engineers prepare by studying. They read papers, go through architecture blogs, maybe build a small RAG prototype. They accumulate knowledge. And then they walk into an interview and treat it like a solo design session — thinking in their head, stating conclusions out loud.

That's not what an interview is. An interview is a real-time window into your reasoning process. The interviewer isn't just evaluating what you know. They're watching how you think — how you handle ambiguity, how you weigh tradeoffs, how you respond when challenged.

Silence reads as uncertainty. Jumping to implementation without framing reads as shallow. These aren't signals that you don't know the material. They're signals that you haven't practiced communicating it.

What These Questions Actually Look Like

In case you haven't encountered them yet, here's the shape of what's showing up in AI/ML interview loops right now:

Agent design:
"Design an agent that can autonomously manage X." The follow-ups are about failure modes, escalation logic, tool interface design, and how you'd evaluate whether the agent is performing well in production.

RAG architecture: "We need a system that answers questions grounded in our internal documentation." The follow-ups are about chunking strategy, retrieval quality, handling stale data, and latency vs. accuracy tradeoffs.

Evaluation strategy: "How would you measure whether this AI system is working?" The follow-ups are about what you do when you don't have ground truth, and how you catch regressions.

Prompt engineering tradeoffs: "Should we fine-tune or use RAG here?" The follow-ups are about when each approach breaks down, and how you'd make that call given specific constraints.

None of these have a single correct answer. The interviewer is watching your reasoning, not your conclusion.

What I Changed After This

I now run through at least one practice session before any role where I'll be on the interviewer side of a new question type. Not because I don't know the material — but because there's a gap between knowing something and being able to explain it fluently under pressure, and that gap shows up faster than you expect.

If you're preparing for AI/ML roles and you've only been studying — not practicing speaking — you might have more of that gap than you think.

Try explaining your last system design out loud, to no one, for ten minutes straight. See how long it takes before you go quiet.

That's the thing to fix.

Have you tried a GenAI interview yet? Share your experience or your favorite "clarifying question" in the comments below!

Kubecon 2020: Istio Simplified

Anshul Prakash — Tue, 25 Aug 2020 00:53:21 +0000

Last week I attended Kubecon 2020 Europe and have tried to write a summary on Istio simplified session which talks about changes in Istio 1.6 and a shift from microservices design pattern to a monolith design. Please do share your views in the comment section.
Medium post