Your Senior Engineer Uses Copilot for Everything But Can't Explain Why: Detecting Weak Judgment in AI-Augmented Hiring

The interview was going great. The candidate—let's call him Alex—solved my system design problem in 18 minutes flat. Microservices architecture, event-driven messaging, Redis caching, proper error handling. The code was clean. It worked. GitHub Copilot did most of the heavy lifting, but that's fine. That's 2026.

Then I asked the question I always ask: "Why did you choose this pattern over a monolith with background jobs?"

Silence.

Alex stared at the screen. Tried to start an answer twice. Finally: "Can I ask Copilot for the reasoning?"

That's when I knew. The code was impressive. The execution was flawless. But the judgment—the ability to explain why this approach over alternatives, given specific constraints—wasn't there.

I didn't hire Alex. Two months later, I heard through my network he accepted an offer at another startup. Four months after that, I heard he was struggling. Couldn't make architecture decisions without asking Copilot for three options and picking randomly. The team was frustrated. The CTO was looking to replace him.

From 1,000+ technical interviews spanning 2010 to 2026, I've watched something fundamental shift. In 2023, AI coding assistants crossed a threshold. Suddenly, anyone could produce code that looked like it came from a 10-year veteran. The signals I relied on for 15 years—clean code, working demos, thoughtful abstractions—stopped predicting performance.

I made four expensive hiring mistakes in 2023-2024 on "impressive" senior engineers who couldn't make architectural decisions without AI guidance. Combined salary cost: $600K. Combined lost velocity: Immeasurable.

Here's what I learned: AI amplifies judgment. It doesn't create it.

Why Smart Teams Keep Hiring AI-Dependent Engineers

Let me be direct: if you're still using 2019 interview techniques in 2026, you're going to keep making six-figure hiring mistakes.

Here's what changed.

AI democratized code execution. A 3-year engineer with GitHub Copilot produces code that looks identical to a 10-year veteran's code. Same patterns. Same abstractions. Same test coverage. The surface signals—clean code, passing tests, working features—no longer correlate with engineering judgment.

Traditional interview loops are optimized for the wrong era. We test coding speed, problem-solving on contrived algorithms, system design for generic scenarios. These were proxies for engineering judgment in 2010-2022. In 2026, they're proxies for "can you use AI tools effectively." That's not the same thing.

Everyone looks senior when AI handles execution. I've interviewed candidates who generated flawless authentication services, implemented elegant saga patterns for distributed transactions, built sophisticated caching layers—all with AI assistance. Impressive. But when I asked "why this pattern over X?" or "when would this approach fail?", 60% couldn't answer. They were AI operators, not architects.

Here's the thing I wish I understood in early 2023: the best engineers use AI to execute their judgment faster. Weak engineers use AI to avoid developing judgment altogether.

I made hiring mistakes because I was judging execution when I should have been testing judgment.

Let me tell you what that cost.

The $150K Hiring Mistake You Don't See Coming

March 2023. I hired a senior engineer—we'll call her Maria—based on one of the strongest technical interviews I'd conducted that year. She built a real-time notification system in 45 minutes. WebSockets, Redis pub/sub, graceful degradation, monitoring hooks. It was beautiful.

By September 2023, my tech lead pulled me aside. "Maria keeps asking what she should do. For everything. She shipped three features, and they all required significant rework. She doesn't seem to... make decisions."

I reviewed her pull requests. The code was fine. Sometimes excellent. But every architectural decision—service boundaries, data modeling, caching strategy—needed someone else to provide direction. When questioned about choices, she'd say "this seemed like best practice" or "this is what Copilot suggested."

She left in November. Six months of $175K salary. Worse: six months where we could have hired someone who actually made senior-level decisions.

Here's what this costs:

Financial: $150K-$200K salary for 6-12 months before you realize the mismatch. Maybe you cut losses at 6 months. Maybe you give them a year "to grow into the role." Either way, it's six figures.

Velocity: Your team waits for architecture decisions. Features stall because no one is making the call on system design. Tech leads spend 40% of their time providing direction that a true senior engineer should handle independently. Your sprint velocity drops 30% because of one weak hire.

Technical Debt: AI-generated solutions without long-term thinking compound. Maria's three features worked for three months. Then the caching strategy started causing data inconsistency issues. The service boundaries she chose made the next six features 3x harder to build. Her code worked. Her decisions didn't.

Team Morale: Other senior engineers resent covering for someone at their level who can't carry their weight. Your best people start interviewing elsewhere. You lose A-players because you hired a B-player who looked like an A-player in interviews.

Opportunity Cost: The position was filled. You weren't looking for a senior engineer anymore. Meanwhile, three truly strong candidates interviewed elsewhere and accepted offers. You missed them.

Total cost of my Maria mistake: Roughly $300K when I factor in salary, recruiting costs, team impact, and the replacement hire timeline.

I made this mistake four times in 2023-2024.

AI Amplifies Judgment—It Doesn't Create It

Let me tell you what AI can do in 2026.

It can write your microservice. Beautiful, idiomatic code in your language of choice. It can generate your Kubernetes configs. Correct syntax, reasonable defaults. It can implement authentication, set up CI/CD pipelines, write integration tests, create API documentation.

Here's what AI cannot do:

It cannot decide whether you need a microservice or if your 5-person team is better served by a modular monolith. It cannot balance the trade-offs between development velocity and operational complexity for your specific constraints. It cannot look at your team maturity, your deployment frequency, your debugging capabilities, and make the architecture call.

That's judgment. That's experience. That's the human layer AI cannot replace.

And here's the crisis: In 2026, the engineers who have that judgment and the engineers who don't both produce equally impressive code in interviews. Because AI handles execution for both of them.

The difference reveals itself six months into the job. When you need them to make the call on service boundaries, and they ask what they should do. When you need them to choose between eventual consistency and strong consistency, and they Google "which is better" instead of analyzing your specific constraints. When you need them to debug a distributed system failure, and they can't reason about causality because they didn't understand the architecture they implemented.

The competitive advantage in 2026 isn't speed of coding. It's quality of decisions.

AI writes the code. You still make the call. And when you hire someone for $175K to make senior architecture decisions, you need to verify they can actually make those decisions—not just execute what AI suggests.

Here's how to test for that.

The Three Questions That Reveal Weak Judgment Despite Strong Execution

After four hiring mistakes and $600K in lessons learned, I developed a simple heuristic. Before hiring any senior engineer, I ask three questions. They add 15 minutes to the interview. They predict 12-month performance with 90%+ accuracy.

Question 1: "Why This Approach Over Alternative X?"

This tests judgment, not execution.

Most candidates in 2026 can solve the problem. They use AI, they write code, it works. The question is: do they understand why their solution is appropriate for the constraints?

Strong answer pattern: Explains trade-offs, acknowledges alternatives, articulates decision criteria based on constraints.

Example: "I chose microservices over a monolith because the requirement specified independent deployment for three teams. A monolith would be faster to build initially—probably 3-4 weeks faster—but we'd lose deployment independence and risk merge conflicts across teams. The trade-off is higher operational complexity now for team autonomy later. If this were a 5-person team, I'd choose monolith."

That answer shows judgment. Acknowledges alternatives. Notes trade-offs. References constraints. Demonstrates decision-making capability.

Weak answer pattern: References "best practices" without context. No trade-off analysis. Can't explain when their solution would be wrong.

Example: "Microservices are more scalable" or "This is what modern architectures use" or "This is industry standard."

That answer is a red flag. It's cargo-culting. Copy-pasting patterns without understanding context. This is what AI dependency looks like—executing solutions without evaluating appropriateness.

From experience: I've asked this question to 47 candidates in the last six months. 28 of them (60%) gave weak answers despite writing impressive code. All 28 showed AI dependency patterns. The 19 who gave strong answers? We hired 8 of them. All 8 are performing excellently.

Question 2: "Walk Me Through a Time AI Suggested Something You Disagreed With and Why"

This tests critical thinking and independent judgment.

Strong engineers use AI as a tool. They evaluate suggestions. They override when appropriate. Weak engineers treat AI as authority. They implement whatever it generates without critical evaluation.

Strong answer pattern: Specific story. Clear reasoning. Demonstrates override decision with justification.

Example: "I was building a data access layer. Copilot suggested Prisma ORM. I went with raw SQL instead because our query patterns are complex—lots of joins, specific performance requirements—and the ORM abstraction would hide query performance issues. We need to optimize at the SQL level, and ORMs make that harder. For a CRUD app, Prisma would be great. For our analytics workload, it's the wrong tool."

That answer demonstrates judgment. Evaluated the suggestion. Understood the constraints. Made a different call. Explained reasoning.

Weak answer pattern: No examples of disagreement. Defers to AI authority. Defensive about overriding suggestions.

Example: "I usually trust Copilot. It's trained on millions of repositories, so it knows best practices" or "I don't really disagree with AI suggestions. If it's suggesting something, there's probably a good reason."

This is the AI dependency signal. No critical evaluation. No independent decision-making. Treats AI as infallible.

From experience: This question has 90%+ predictive power for 12-month performance. Candidates who can articulate AI disagreements become strong hires. Candidates who can't struggle with architecture decisions consistently.

Last month, a candidate told me: "I've never really needed to disagree with AI. It usually gets it right." I didn't hire him. A peer company did. Three months later, I heard he was struggling—implementing whatever Copilot suggested without evaluating whether it fit their system. They're now coaching him heavily. Might not work out.

Question 3: "If You Couldn't Use AI for the Next 30 Minutes, How Would This Change Your Approach?"

This tests fundamentals versus dependency.

Strong engineers think architecturally, then implement with whatever tools available. AI makes them faster. But remove AI, they're still competent—just slower. Weak engineers can't function without AI because they never developed the mental models underneath.

Strong answer pattern: "Approach stays the same, execution is slower."

Example: "I'd sketch the architecture first—draw the services, the data flow, the failure modes. Then I'd implement from my sketch. Without Copilot, I'd need to reference documentation more and type boilerplate manually, so maybe it takes 45 minutes instead of 20. But the architecture would be identical."

That shows fundamentals. The candidate thinks before coding. AI speeds up execution, doesn't replace thinking.

Weak answer pattern: Can't function without AI. Needs tools to think through problems.

Example: "I'd probably struggle without my setup" or "Can we reschedule? I need Copilot to be productive" or "I'd have to spend a lot of time looking things up."

This is complete AI dependency. Not using AI as execution accelerator—using it as cognitive crutch.

Real scenario from last year: Candidate's laptop crashed during system design interview. He asked to reschedule because "I need my setup with Copilot to code properly." Red flag. We declined to move forward. A strong candidate in the same situation would whiteboard the approach and say "I'll implement this later," or ask for a backup laptop and proceed without AI.

Trade-off to acknowledge: These three questions add 10-15 minutes per interview. But they avoid $150K+ mistakes. I'll take that trade.

Mapping Engineers: Where AI Dependency Reveals Itself

Here's a framework I use to categorize every senior engineering candidate. Two dimensions: Judgment (decision-making, trade-off analysis, architectural thinking) versus Execution (coding, implementation, feature delivery).

Plot every candidate on this matrix:

High Judgment + High Execution (AI-Amplified) ✅

This is your target hire.

These are engineers who think deeply about architecture, evaluate trade-offs, make sound decisions—and then use AI to execute those decisions 3x faster. They understand what code AI generates. They know when to override suggestions. They can debug without AI. But they choose to work with AI because it's a productivity multiplier.

Profile example: A candidate explains why they chose PostgreSQL over DynamoDB for their use case, discussing consistency requirements, query patterns, team familiarity, and operational complexity. Then they use Copilot to generate the database access layer code quickly. Speeds up execution, doesn't replace judgment.

Percentage of candidates: About 15% of "senior" candidates I interview land here. These are your A-players. Hire immediately.

Low Judgment + High Execution (AI-Dependent) ⚠️

This is the dangerous hire.

These engineers ship impressive features. Clean code. Working systems. Fast delivery. But they can't make architectural decisions independently. They implement whatever AI suggests without critical evaluation. They look senior in interviews—AI makes their code indistinguishable from truly senior engineers. But six months in, you realize they need constant direction.

Profile example: A candidate builds a beautiful microservices architecture in the interview. But when you ask "why microservices over a monolith for a 5-person team?", they can't explain the trade-off. When you ask "when would this approach fail?", they have no answer. They executed well. They didn't think strategically.

Percentage of candidates: About 40% of "senior" candidates in 2026 land here. This is your hiring crisis. They pass traditional interviews because we test execution, not judgment.

Personal mistake: I hired two engineers in 2023 who mapped to this quadrant. Both had stunning GitHub profiles. Both shipped features fast in the first 3 months. Both struggled when I needed them to make architectural decisions independently. One left after 8 months. One is still learning, but it's been a heavy coaching investment. Combined cost: $350K.

High Judgment + Low Execution 📈

Solid hire with upside.

These engineers make excellent architecture decisions. Strong trade-off analysis. Strategic thinking. But they're slower to code—maybe they're from the pre-AI era and still learning tools, or they overthink implementation details.

Profile example: A candidate takes 40 minutes to solve a problem that should take 20. But when you ask about their approach, their reasoning is sound. They explain trade-offs clearly. They identify edge cases. They just need to learn AI-augmented workflows to speed up execution.

Percentage of candidates: About 20% of senior candidates land here. Often these are experienced engineers (10-15 years) who built strong fundamentals pre-AI and are now learning Copilot. They're teachable. Their judgment is solid. They just need execution efficiency.

When to hire: If you have strong execution but need strategic thinking, hire here. If you need feature velocity immediately, this might not be the right fit today.

Low Judgment + Low Execution 🚫

Junior engineer, honest but mis-leveled.

These candidates struggle with both dimensions. They can't make architecture decisions AND they're slow to implement. But often, they're honest about experience gaps. They don't claim senior status—recruiters or resume screening misleveled them.

Profile example: Candidate admits they're not sure about the architectural trade-offs. Takes 60+ minutes on a 30-minute problem. But they're upfront: "I'm probably early senior or solid mid-level. Still learning distributed systems."

Percentage of candidates: About 25% of "senior" candidates land here. They're not pretending to be senior. Someone else made the leveling mistake.

What to do: Respectful pass for senior role. Maybe offer mid-level position if you're hiring. These engineers are trainable—they just need 2-3 more years.

The key insight: Quadrant 2 (Low Judgment + High Execution) is the hiring trap. They look senior. They code well. They pass interviews. But they can't make the decisions you're paying senior salary for.

Your interview process must explicitly test for judgment, not just execution.

Red Flags That Predict Production Struggles

From 47 interviews in the last six months, I've identified four signals that reliably predict AI dependency and weak judgment. If a candidate shows two or more of these signals, they're likely Low Judgment + High Execution—the dangerous hire.

Signal 1: Can't Explain Trade-Offs Without Referencing "Best Practices"

What to listen for: "This is industry standard" or "This is what Google does" or "This is best practice."

Why it matters: Cargo-culting patterns without understanding context. No critical evaluation of whether the pattern fits their constraints.

How to test: Ask "Why is this best practice for your specific situation?" Strong candidates reference their constraints (team size, load patterns, deployment frequency, budget). Weak candidates double down on "everyone does it this way."

Example from last month: Candidate proposed Kubernetes for a 6-person startup's deployment. I asked "Why Kubernetes over AWS ECS for your team size?" Answer: "Kubernetes is industry standard for cloud-native applications." No mention of operational overhead, learning curve, team expertise. That's a red flag.

Strong answer would be: "Kubernetes gives us portability across clouds, but for a 6-person team with limited DevOps experience, ECS might be better. Less operational overhead, AWS manages the control plane, and we're already committed to AWS. If we were multi-cloud or had dedicated platform team, Kubernetes makes sense. Right now, ECS is the better trade-off."

Signal 2: Struggles With Deliberately Constrained Problems

What to test: "Solve this without using framework X" or "No external libraries, just standard library."

Why it matters: Reveals fundamentals versus dependency on tools. Strong engineers can reason about problems at first principles. Weak engineers panic without their usual abstractions.

Example: I ask candidates to design a simple caching mechanism without Redis. Just in-memory data structures. Strong engineers discuss LRU eviction strategies, hash maps with linked lists for ordering, TTL implementation with timestamp checking. Weak engineers ask "But why wouldn't we just use Redis?"

That question reveals tool dependency. They can't think about the problem without reaching for existing solutions.

Signal 3: Over-Trusts AI Suggestions Without Questioning Assumptions

What to listen for: "Copilot suggested this, so I used it" or "AI knows best practices better than I do."

Why it matters: No critical evaluation of AI output. No questioning of assumptions embedded in suggestions.

How to test: Show them AI-generated code. Ask "What assumptions did the AI make that might not fit your context?"

Example: Copilot generates a microservices architecture for a problem. Strong candidate says: "This assumes high scale and team independence. For a 5-person team, this complexity might not be justified. I'd start with a modular monolith." Weak candidate says: "Looks good, this is a standard microservices pattern."

Signal 4: Can't Debug Their Own AI-Generated Code

What to test: Show them code (can be their own AI-generated code). Ask "If this fails in production, how would you debug it?"

Why it matters: No mental model of how the system works. Can't reason about cause and effect if AI isn't available to help.

Example: Candidate uses Copilot to generate distributed transaction handling with saga pattern. Beautiful code. I ask: "If one step of the saga fails to rollback, how would you trace the issue?" Strong candidate walks through the event sourcing, explains how to check each service's state, describes compensation transaction logs. Weak candidate: "I'd probably ask Copilot to help debug" or "I'd check the error logs" (vague, no systematic approach).

From experience: 28 candidates (60% of recent interviews) couldn't explain trade-offs despite impressive AI-assisted code. All 28 showed at least two of these four signals. The correlation is strong.

How to Fix Your Interview Process This Week

You don't need to rebuild your entire interview pipeline. Add these five actions to your process starting Monday:

Your Monday Morning Checklist

1. Add The Three Questions to your interview script (5 minutes to implement)

Print this and give it to every interviewer:

REQUIRED QUESTIONS FOR SENIOR CANDIDATES:
1. Why this approach over alternative X?
2. Walk me through a time AI suggested something you disagreed with and why.
3. If you couldn't use AI for 30 minutes, how would this change your approach?

STRONG ANSWERS: Explain trade-offs, reference constraints, demonstrate independent judgment.
WEAK ANSWERS: "Best practices," can't explain alternatives, defer to AI authority.

Make these mandatory for architecture/system design rounds. Train interviewers on what strong versus weak answers sound like.

2. Audit your last 3 senior hires (30 minutes)

Ask yourself: Can they explain why behind their architecture decisions? Or just what they built?

If it's mostly "what," you have an AI-dependency problem in your hiring process. The signals you're testing don't predict judgment.

3. Create a "No AI for 15 minutes" segment (Add to interview loop)

Not about speed. About mental models. Ask candidate to whiteboard their approach without coding tools. Strong candidates sketch architecture, think through trade-offs, then implement. Weak candidates struggle to think without AI assistance.

4. Train interviewers on The Judgment vs Execution Matrix (1-hour training session)

Walk your hiring team through the framework. Practice scoring past candidates. Align on what High Judgment looks like:

• Explains trade-offs without prompting
• References constraints explicitly
• Knows when their solution would be wrong
• Can reason about alternatives

5. Establish "judgment interview" as separate loop (Process change, ongoing)

Distinct from coding interview. Focused entirely on trade-off discussions, constraint analysis, decision-making. Format: 60 minutes, present 3 real architecture scenarios from your company, ask "How would you approach this?" and "Why X over Y?" for each scenario.

Time investment: About 2 hours total to implement all five actions.

Expected improvement: Hiring accuracy from ~50% to 75-85% within 6 months.

Worth it to avoid a single $150K hiring mistake.

What Changes When You Apply This

Let me show you the before/after from my own experience.

Before (Traditional Approach, 2022-Early 2023):

• Interview focused on execution: "Can you code this solution?"
• Candidates used AI tools to generate impressive demos
• Clean code, working features, thoughtful abstractions
• Hired based on demo quality and coding fluency
• Results: 6 senior hires. 3 worked out excellently. 3 struggled with independent decision-making.
• Success rate: 50% (coin flip)
• Cost of mismatches: ~$525K (salary + recruiting + lost velocity for 3 people over 6-9 months each)

After (Judgment-Focused Approach, Late 2023-2026):

• Interview added judgment layer: "Why this approach over alternatives?"
• Candidates who relied purely on AI couldn't explain trade-offs
• Strong candidates articulated decision-making clearly, even when using AI for implementation
• Hired based on judgment first, execution second
• Results: 6 senior hires. 5 working out excellently. 1 mediocre but improving with mentorship.
• Success rate: 83%
• Cost of mismatch: ~$90K (one person, identified faster, shorter tenure)

Net improvement: +33 percentage points in success rate. ~$435K savings in hiring costs over 18 months.

Real example of the shift:

I interviewed two candidates for the same senior role in November 2025.

Candidate A: Built a spectacular real-time notification system in 30 minutes. WebSockets, Redis pub/sub, reconnection logic, backpressure handling. The code was flawless. When I asked "Why WebSockets over Server-Sent Events?", she said "WebSockets are better for real-time." Pressed further: "Better in what way? When would you choose SSE instead?" Answer: "I'm not sure. WebSockets are just the standard approach."

Red flag. Great execution. Weak judgment.

Candidate B: Built a simpler real-time notification system in 45 minutes. Good code, not spectacular. When I asked "Why WebSockets over Server-Sent Events?", he said: "For this use case—server pushes to client, no client-to-server needed—SSE would actually be simpler. WebSockets give you bidirectional communication, but we don't need that here, and the protocol overhead is higher. I went with WebSockets because the requirements mentioned 'real-time chat' in future phases, and that would need bidirectional. If it's just notifications forever, SSE is the better choice."

Strong judgment. Adequate execution. Could improve execution speed with practice.

I hired Candidate B. Six months later, he's leading architecture for our notification system and made solid decisions on scaling, failure handling, and monitoring. Candidate A got an offer from another company. I heard through my network she's struggling—ships features but needs constant direction.

Judgment over execution. That's the lesson.

Anti-Patterns That Sabotage AI-Era Hiring

Don't make these mistakes. I've seen them all.

Mistake 1: Banning AI in Interviews

Why teams do this: Fear that AI makes interviews "unfair" or "everyone looks the same."

Why it's wrong: Real work involves AI tools. You want to see how candidates use them. Banning AI in interviews is like banning IDEs in 2010—you're testing for something that doesn't matter in production.

What to do instead: Allow AI. Then test judgment by asking "Why did AI suggest this?" and "Do you agree? Why or why not?" Strong candidates can articulate reasoning. Weak candidates just accept AI output uncritically.

Mistake 2: Only Testing Fundamentals (Ignoring AI Skills)

Why teams do this: Overreaction to AI dependency problem. "We need to test if they can code without AI!"

Why it's wrong: Strong engineers in 2026 should be AI power-users. You want people who leverage tools effectively. Testing only fundamentals means you miss engineers who are great at AI-augmented workflows.

What to do instead: Test both. Fundamentals (whiteboard architecture without tools) AND AI-augmented execution (implement with Copilot, then explain the output). Best engineers excel at both.

Mistake 3: Confusing Speed With Competence

Why teams do this: Fast execution looks impressive in 60-minute interviews.

Why it's wrong: Speed without judgment causes technical debt. An engineer who ships 3x faster but makes decisions that require rewrites six months later is net negative.

What to do instead: Add deliberate pauses. "Stop coding. Explain your approach. Why this over alternatives? What are you optimizing for?" Judge the thinking, not just the typing speed.

Mistake 4: Not Training Interviewers on AI-Era Signals

Why teams do this: Interview training is from the pre-AI era (2010-2020). Nobody updated the playbook.

Why it's wrong: Old interview techniques don't detect AI dependency. Your interviewers are testing for 2020 signals in a 2026 world.

What to do instead: Invest in 2-hour training session for all interviewers. Cover The Three Questions, The 4 Signals, The Judgment Matrix. Role-play with strong/weak answer examples. Update your rubrics.

From experience: Companies that invest in interviewer training see hiring success rates improve 20-30 percentage points within 6 months. Companies that don't keep making the same mistakes.

When to Use AI, When to Test Pure Judgment

Here's how I structure senior engineering interviews in 2026:

Let Candidates Use AI For:

• Syntax and boilerplate code - Who cares if they remember exact import statements?
• Looking up API documentation - Access to docs is fine, just like in real work
• Implementing standard patterns - Auth, caching, error handling—let AI speed this up
• Getting unstuck on minor errors - Typos, syntax mistakes—not worth testing

You Must Test Pure Judgment On:

• Trade-off decisions - Monolith vs microservices, SQL vs NoSQL, caching strategies
• Architecture choices under constraints - Team size, load patterns, budget, expertise
• Debugging approach when AI fails - Can they reason about system behavior?
• Explaining why their solution works and when it wouldn't - Mental models, not execution

The Interview Format I Use:

First 20 minutes: Implementation phase. Candidate can use any tools, including AI. I want to see how they work with AI in their normal flow.

Next 15 minutes: Explanation phase. Take away AI (have them close Copilot). Ask them to walk through the code. "Why these choices? What would break this? When would you choose differently? What assumptions did you make?"

Final 10 minutes: Pure judgment. Whiteboard a related architecture problem. No code. Just boxes, arrows, and trade-off discussions. "How would you scale this? What's the failure mode? How do you decide between X and Y?"

What this reveals:

• Strong candidates: Explain everything clearly in explanation phase. AI made them faster in implementation, but they fully understand what was generated. In judgment phase, they think clearly about trade-offs.

• Weak candidates: Struggle in explanation phase. Can't articulate why AI chose certain patterns. In judgment phase, they reference "best practices" without nuance.

This format gives you signal on both execution (with AI) and judgment (pure thinking).

Key Takeaways

We're at an inflection point in technical hiring. For the first time in software history, execution skill and decision-making ability have decoupled. AI handles execution for everyone—junior and senior alike. What separates great engineers from average ones is judgment: knowing why to choose one approach over another, when to take shortcuts, and how to balance competing constraints.

Your 2019 interview process doesn't test for this. You need to update.

Here's what matters:

AI amplifies judgment—it doesn't create it. The best engineers in 2026 use AI to execute decisions 3x faster. Weak engineers use AI to avoid developing judgment altogether. Your hiring process must distinguish between these two groups.

Traditional signals are broken. Clean code, working demos, passing tests—these no longer predict senior performance when everyone has AI assistance. You must test decision-making explicitly with questions that reveal trade-off thinking.

Use The Three Questions Framework. Every senior interview should include: (1) Why this approach over alternatives? (2) When did you disagree with AI and why? (3) How would your approach change without AI? These reveal judgment despite strong execution, and they predict 12-month performance with 90%+ accuracy.

Map candidates to The Judgment vs Execution Matrix. Low Judgment + High Execution is your dangerous hire—impressive in interviews, struggles in production. High Judgment + High Execution is your target. Your process must identify the difference.

Don't ban AI—test judgment instead. Let candidates use AI tools. Then ask them to justify what AI generated. Strong candidates explain trade-offs and can override when appropriate. Weak candidates blindly accept AI output without critical evaluation.

Your Next Step

This week, add one question to every senior interview: "Why did you choose this approach over X?"

Substitute X with a real alternative: monolith if they chose microservices, SQL if they chose NoSQL, caching if they didn't, serverless if they chose containers.

Then listen carefully.

Strong candidates explain trade-offs in 2-3 minutes. They reference constraints (team size, load patterns, budget, timeline). They acknowledge when their solution would be wrong. They don't say "best practices"—they say "for our situation, here's why."

Weak candidates say "this is what works" or "this is industry standard" without nuance. Or they say "I'm not sure, this is what Copilot suggested." Or they give you theory without connecting it to specifics.

This one question predicts 12-month performance better than any coding test, any algorithm quiz, any system design exercise. It reveals judgment. And in 2026, judgment is what you're paying for.

Start using it Monday.

Remember

AI can generate the architecture diagram. It can write the microservices. It can implement the caching layer. It can create the database schema.

But deciding whether this specific architecture fits your team size, your constraints, your technical maturity, and your three-year roadmap? That requires judgment. That requires experience. That requires the human decision-making layer that AI cannot replace.

You're the decision-maker. Not the AI. Not the candidate's Copilot. You.

When you hire someone for $175K to make senior architecture decisions, make damn sure they can actually make those decisions—not just execute whatever AI suggests.

The code writes itself now. The decisions? Those are still on you.

And when you hire, make sure your new senior engineer understands that too.