How to Interview Engineers When You're Not Technical

You're hiring your first engineer. You're not technical. You've watched coding interview videos. You think you need to ask them to reverse a linked list.

You're setting yourself up to hire the wrong person.

The engineers who ace whiteboard problems aren't always the ones who ship products. The ones who do ship products ask different questions—and you don't need to be technical to ask them.

What "Technical" Actually Means

Here's the uncomfortable truth: you can assess technical ability without understanding the technology.

You don't need to know what a hash map is. You need to understand how engineers think about tradeoffs.

An engineer who can't explain why they picked one database over another? Red flag. An engineer who picked one without considering tradeoffs? Bigger red flag.

You can spot this without reading a single line of code.

The Four Questions That Actually Predict Success

1. "Walk me through the last time you broke something in production. What happened?"

Why it matters: This tells you if they learn from failure or hide it.

What to listen for:

• Do they own it, or blame the tools/team/requirements?
• Did they change anything after? (If not, they didn't learn.)
• Can they describe what monitoring would have caught it?

Red flags:

• "It never happened to me"
• "It was someone else's fault"
• Vague blame on "the system"

Good answers sound like: "I deployed without reviewing all the migration tests. Broke the customer import. I added three new test cases immediately and built a pre-deploy checklist with another engineer. It's saved us twice since."

2. "Tell me about a time you disagreed with a decision your team made. How did you handle it?"

Why it matters: You need people who think, not people who just comply.

What to listen for:

• Did they raise it? (Good.)
• Did they argue after being overruled, or did they move on? (Moving on is good; arguing forever is bad.)
• Did they learn something from the final decision? (Ideal.)

Red flags:

• "I never disagree"
• "I just do what I'm told"
• "I sabotaged the feature because I was right" (extreme, but happens)

Good answers sound like: "We were going to build a feature with Redis. I thought our use case was simpler and didn't need it. I made my case with data, they decided to use it anyway, I implemented it well. Turns out they were right—the scaling problem showed up two months in. I was wrong, learned Redis, and that's actually where I got good at caching."

3. "What does a good code review look like to you?"

Why it matters: This predicts if they'll make your team better or just shipping faster.

What to listen for:

• Do they care about readability, or just "does it work"?
• Do they give feedback kindly, or are they the person who makes juniors cry?
• Do they learn from reviews or resist feedback?

Red flags:

• "Code reviews slow us down"
• "As long as it works, who cares"
• "I don't really do them"

Good answers sound like: "I look for: does the approach make sense? Are there edge cases they missed? Will future-me understand this? I try to give feedback on the idea, not the person. If I don't understand something, I ask. I've caught bugs but also learned why people do things differently than I would."

4. "Walk me through how you'd approach a problem you've never solved before."

Why it matters: The specific problem doesn't matter. How they think does.

What to listen for:

• Do they research? Ask for help? Break it down into smaller pieces?
• Do they have a process, or do they flail?
• Do they recognize what they don't know?

Red flags:

• "I'd just Google it and start coding"
• No process at all
• Overconfidence about things they've never done

Good answers sound like: "I'd start by understanding the constraints: timeline, existing code, team expertise. Then I'd look for similar problems we or others have solved. I'd talk to someone who knows the space. Then I'd build a small version to learn, not the final thing. Once I understand it, I'd architect the real solution."

The Meta Pattern

Notice what these questions have in common: they're all about how engineers think, not what they know.

You can assess thinking without being technical. You're looking for:

• Ownership — Do they own problems or pass blame?
• Growth — Do they learn from mistakes and disagreements?
• Humility — Do they know what they don't know?
• Process — Do they think before coding?

An engineer with all four will solve problems you haven't hired them to solve yet. An engineer missing even one will eventually blow something up.

One More Thing: The Integrity Question

Right before you make an offer, ask: "What's a time you were asked to do something that conflicted with what you thought was right? How did you handle it?"

You're looking for integrity—someone who will tell you when you're about to make a mistake, not someone who will nod and ship the broken thing.

The best engineer you can hire is one who will disagree with you when you're wrong. The worst is one who won't.

The Hiring Manager's Advantage

Here's what's wild: non-technical hiring managers often spot integrity better than technical ones. You're not distracted by language choice or algorithm knowledge. You're watching how they think and how they treat disagreement.

Use that advantage.

Forget the linked lists. Ask about production incidents. Listen for how they talk about failure. Hear whether they own it or deflect.

That's the interview that predicts who'll actually ship.