Skip to main content

How I Interview Engineers (Updated 2025 Edition)

Hiring isn’t about gotchas. It’s about signal.

Over the years, my process has shifted—not because the fundamentals have changed, but because I’ve grown. I now care just as much about how someone operates in their system as I do about what they can architect on paper.

Here’s how I interview others—and what I’m looking for.

🧠 Ideation & Systems Thinking​

I still love open-ended questions.

  • “How does a website work?”
  • “Walk me through what happens when you hit Enter.”
  • “Design a system that…”

This reveals their mental model, clarity of thought, and curiosity. Bonus if they ask clarifying questions. Double bonus if they sketch out flow, tradeoffs, and where they'd want to dig deeper.

I often use whiteboards or collaborative docs for this—whatever helps the thinking surface.

🖥️ CLI & Environment Mastery​

This is newer to my process, but increasingly important:

How well does someone operate inside their environment?

So I’ll do something like:

  • Drop them in a system and say “take a few minutes to explore, here is the readme”
  • Drop them into a task that requires them to get everything running based on that readme.
  • Interrupt them and say, “Can you switch to a different branch for a sec?”
  • Ask them to run a migration or inspect a log

I'm not testing for perfection—but I’m watching for:

  • Do they instinctively stash their work?
  • Do they know how to source an env file?
  • Can they recover from a broken run or permission error?
  • Do they have familiarity with Git, shells, scripting, etc?

It's not about memorizing commands—it's about fluency, adaptability, and confidence under pressure.

⚠️ One important caveat: Just because someone doesn’t have this skill doesn’t mean they’re not capable. I’ve met brilliant engineers who’ve spent their entire life up to this point in Windows-based environments—where the CLI is more of a tool launcher than a control panel. The might just be unaware of what they are missing out on... I was.

I’m not judging the tools they’ve used. I’m evaluating how they handle the shift. Are they curious? Are they thrown off? Do they start asking questions?

The key question for me: Are they willing to master their environment? Because if they can do that, they will grow quickly inside our systems and processes.

📊 Applied Tech Walkthroughs​

If someone claims strong experience in X (e.g. GraphQL, Kubernetes, Django, etc), I might ask:

  • “Could you teach me the core ideas?”
  • “Where do people usually mess up?”
  • “What’s the part that took you the longest to understand?”

I don’t need a textbook answer. I want to hear:

  • Depth of experience
  • How they debug
  • How they think about edge cases
  • What their mental stack looks like

🔀 Realistic Flow Disruption​

In real life, you're mid-task when someone Slacks you:
"Hey can you check out this branch real quick?"

So I simulate that:

  • Halfway through a migration or design task, I ask them to switch gears
  • I want to see: git stash? quick branch checkout? ability to come back and recover?

It’s not a trap. It’s a window into their operating rhythm.

🧹 Stack Agnosticism​

I don’t care what someone's current primary stack is.

But I definitely prefer candidates who’ve worked in more than one stack. It shows they’ve built transferable mental models and aren’t married to tooling.

Tools change. Awareness scales. I'm looking for people that are caoable of building the tools, not just using them

🎯 Bonus Signals​

  • Do they write things down?
  • Do they ask questions about our setup?
  • Do they challenge assumptions?
  • Do they handle awkward moments with curiosity, not panic?

🌟 What Matters Most​

I don’t care if you’ve memorized sorting algorithms.
I care if you can:

  • Think clearly
  • Navigate ambiguity
  • Understand systems
  • Move with intent inside your dev environment

And if you don’t know something—but you ask great questions and stay calm? That’s worth more than perfect answers.

This doc is a living thing. So is the process.