Last week we covered the three skills separating your strongest engineers right now: proactive communication, business acumen, and curiosity and adaptability.

The harder question is what comes next: knowing what to hire for is one thing. Knowing how to structure a loop that actually surfaces it, without dropping the technical bar, is a different problem entirely.

Because here's the tension worth naming: the three skills matter enormously. And you still need to know the person can actually build the thing. Technical depth doesn't get replaced by judgment. It gets paired with it. You're not testing if they can code. You're testing if they can own it. The engineers who thrive right now are technically solid and bring those other layers on top.

So the loop needs to cover both. This week: the two technical rounds. Next week: the two judgment rounds that tell you whether someone will grow into the job that's actually emerging.

Keep this round, but modernize it.

The goal isn't to test syntax recall or time someone under pressure. It's simpler: can this person solve real problems and own what comes out of the session? Let them use whatever tools they'd use on the job -Cursor, Copilot, Claude, whatever. You're not evaluating their ability to code without a net. That's not the job.

Midway through, ask: "Walk me through what the model got wrong, or what you'd change about its output." This is the question. Strong candidates have a specific answer. Great ones already fixed it before you asked.

But don't stop there. The real signal is in what they look for when they review. AI output has predictable failure modes, and the engineers who know them are the ones you want on your team. Here's what strong candidates naturally check and what you can probe for if they don't bring it up themselves.

🚧 Edge cases and error handling. AI writes for the happy path. It'll handle the input you gave it in the prompt, but not the null, the empty array, the malformed response, the network timeout. Ask: "What happens if this fails? What does the caller get back?" The engineers who instinctively ask this before shipping are worth their weight.

🔒Security. AI doesn't think about your threat model. It will write SQL queries without parameterization, log things that shouldn't be logged, or skip input validation because the prompt didn't mention it. Ask: "Is there anything here you'd flag in a security review?" You'll quickly see who has that reflex and who doesn't.

🧩 Context fit. The model doesn't know your codebase. It doesn't know you already have a utility for this, that you're on an older version of the library it just used, or that your team has a convention for handling this pattern. Ask: "How does this fit with how the rest of the codebase approaches this?" Strong candidates think about the system they're merging into, not just the function they're writing.

🎯 Business logic correctness. This is the subtle one. AI solves the literal prompt, not the underlying intent. The code can be technically correct and still be solving the wrong problem. Ask: "Does this actually do what the ticket is asking for?" and give them a slightly ambiguous spec so the question has teeth.

⚡Performance assumptions. AI doesn't know your scale. It'll write an N+1 query without hesitation, or load an entire dataset into memory because that's the simplest solution. Ask: "At what point does this start to hurt, and how would you know?"

You don't need to probe all five in every interview. But the candidates who surface two or three of these unprompted are showing you the judgment that keeps your production systems healthy.

Then shift a constraint - different scale, tighter timeline, smaller team. The engineers you want will adapt and build on what they have. That pivot tells you a lot about how they'll handle production surprises.

💡Debrief signal: did this candidate own the output, or just execute it?

This is where technical depth and judgment start to overlap, and it's one of the most useful rounds if you run it right.

Give them a design problem that mirrors something your team actually builds. Leave it underspecified on purpose. The first two minutes are already informative, do they ask clarifying questions before drawing boxes, or dive straight in? The engineers who pause to surface assumptions before committing to a direction are showing you how they handle real ambiguity.

As they work through it, keep asking: "What does that cost you?" The best architects are explicit about tradeoffs. "This buys us simplicity but we'll feel it at scale." "This is the right call now but we'll need to revisit it." That's what good sounds like. If everything is a clean win, push harder - there's always a tradeoff.

Try a pivot before you wrap up: "Now imagine this needs to handle 10x the load" or "Two engineers maintain this for two years, what changes?" The response to that pivot is often more revealing than the original design. And one more worth asking: "What's the first thing that breaks in production?" Engineers who've thought in systems have a real answer.

🤖 Let them use AI here too — and watch what happens.

This is where it gets interesting. Let the candidate use Claude or ChatGPT to help think through the design. What you're about to see is more signal than any whiteboard session.

AI is genuinely good at system design, it'll suggest reasonable architectures, surface common patterns, name the usual tradeoffs between SQL and NoSQL. The generic answer to a generic problem is basically solved. Which means your problem can't be generic anymore. Make it specific to your stack, your constraints, your actual scale. AI can tell them to use Kafka. It can't tell them whether Kafka is overkill for where your team is right now.

Now watch how they direct it. Do they use it to think faster - generating three architecture options quickly so they can compare them or do they use it to avoid thinking? The candidate who prompts Claude for an architecture, reads the output, and says "okay, but this doesn't account for our constraint around latency at the edge, let me push back on this" is showing you exactly the judgment you're hiring for.

The best question to ask after they've used AI in this round: "The model suggested X. Why didn't you go with that?" Strong candidates have a real answer. They know when the textbook solution doesn't fit the actual constraints.

This is where system design interviews are heading. Less "design a URL shortener" (AI handles that), more "here are three AI-generated architectures for our specific problem - which would you choose, what would you change, and what did the model miss?" The judgment layer gets more visible, not less. You just have to design for it.

💡 Debrief signal: did they talk about the system, or just the solution? And did they challenge the AI, or just present it?

Two rounds. Both modernized for the way engineers actually work now.

Round 1 gives you the technical floor, not whether they can code without AI, but whether they can own the output of a session with it. Round 2 gives you the architectural ceiling - how they reason about systems, tradeoffs, and constraints, with or without a model helping them think.

Next week: the two judgment rounds. Communication, business acumen, curiosity, and adaptability - the skills that separate engineers who grow from ones who plateau. Those are the rounds most loops skip entirely, and they're the ones that matter most at senior levels.

Before your next technical screen, update your debrief template with two questions, one per round:

If your panel can't answer both clearly after the loop, one of those rounds isn't pulling its weight. That's your signal to redesign it before the next hire.

Want something covered? Hit reply and tell me. I love hearing what you’re dealing with.

📬 Reply back to this email to book a 30 min session (free for subscribers!)

The technical bar isn't gone — it just looks different now. Own the output, challenge the model, and build for the system. That's what you're hiring for. 🚀

Until next time,
Sabeen 🐝

P.S.

This is part one of a two-part series building on last week's piece on the three skills your engineers actually need right now. Part 2 next week covers the judgment rounds — the ones most loops skip and the ones that matter most at senior levels. And if you're new here, welcome! Every Tuesday we go one layer deeper on what it takes to lead engineering teams in the age of AI. 👋