Mehmet Erturk | Hiring Engineers - What Actually Matters

Hiring Engineers

I've interviewed hundreds of engineers. Hired dozens. Some became superstars. Some didn't work out.

Looking back, the signals I thought mattered often didn't. The signals that actually mattered, I almost missed.

What Doesn't Matter (As Much As You Think)

Prestigious Companies

"They worked at Google" doesn't mean they'll be good at your startup. Big company engineering is different from small company engineering. Some translate. Some don't.

I've hired ex-FAANG engineers who couldn't ship without fifty people supporting them. I've hired no-name engineers who built entire systems solo.

The name on the resume isn't the signal. What they did there is.

Leetcode Performance

Can they reverse a linked list? Cool. Will they ever need to? Probably not.

Algorithmic puzzles test a specific skill. That skill rarely maps to day-to-day engineering work.

I've seen brilliant puzzle-solvers who couldn't debug production issues. I've seen mediocre puzzle-solvers who were the most productive engineers on the team.

Years of Experience

Five years of experience or one year repeated five times?

Some engineers with 3 years are miles ahead of engineers with 10. Experience matters, but growth rate matters more.

Specific Technology Match

"We need a React developer."

Maybe. Or maybe you need someone who can learn any frontend framework in two weeks because they understand the fundamentals.

Technology changes constantly. Betting on specific tech skills is short-term thinking.

What Actually Matters

Problem-Solving Process

Not whether they get the right answer. How they approach problems:

Do they clarify requirements before diving in?
Do they consider edge cases?
Do they think about tradeoffs?
When stuck, do they try different approaches or just freeze?

I care less about the solution and more about the journey.

Communication

Can they explain technical concepts clearly? Can they ask good questions? Can they write comprehensibly?

Engineering is collaborative. If someone can't communicate, they'll create confusion regardless of their technical skill.

Ownership Mindset

Do they talk about "my project" or "the project"? Do they describe problems they identified, or just work they were assigned?

The best engineers take ownership. They don't wait for permission. They see problems and fix them.

Learning Ability

How do they handle something they don't know?

I often ask about technologies they're not familiar with. Not to trick them — to see how they think about learning. Do they ask clarifying questions? Do they relate it to things they know? Are they comfortable saying "I don't know, but here's how I'd figure it out"?

Collaboration Signals

How do they talk about teammates? Do they give credit? Do they acknowledge others' contributions?

Red flag: Everything is "I did X." No mention of team.

Green flag: "We built X. My part was Y. [Name] was great at Z."

Debugging Stories

My favorite interview question: "Tell me about a bug that took forever to find."

Great engineers have war stories. They light up when telling them. You can hear the problem-solving, the frustration, the eventual breakthrough.

If someone has nothing to say here, they haven't been in the trenches.

My Interview Process

1. Resume Screen (10 min)

Looking for:

Evidence of building things
Progression and growth
Anything interesting to ask about

Not looking for:

Perfect formatting
Prestigious names
Keyword matching

2. Initial Call (30 min)

Mutual fit check:

What are they looking for?
What's their background?
Do they have questions that show they've researched us?

Also: can they hold a conversation? Are they curious?

3. Technical Interview (60-90 min)

Not whiteboard puzzles. Real-ish problems:

Design a small system
Debug a problem in existing code
Walk through code they'd write for a feature

I'm looking at:

How they break down problems
How they handle ambiguity
How they communicate their thinking
Whether they ask good questions

4. Culture/Values Interview (45 min)

Assess alignment with your engineering culture. Behavioral questions:

Tell me about a conflict with a teammate
Tell me about a time you disagreed with a decision
Tell me about a project that failed

Looking for: self-awareness, growth mindset, ability to work with others.

5. Reference Checks

Actually call references. Ask specific questions:

Would you hire them again?
What would they struggle with here?
What environment do they thrive in?

The answers are often more revealing than the interview.

Red Flags

Can't explain their own work. If they can't clearly explain what they built, they either didn't build it or can't communicate.

Blames others. Every failure was someone else's fault. No self-reflection.

No questions for you. Lack of curiosity about the role, the team, the problems.

Arrogance. Confident is good. Certain they're always right is not.

Can't handle "I don't know." Nobody knows everything. People who pretend to are dangerous.

The Hire/No-Hire Decision

After interviews, I ask myself:

Would I want to work with this person?
Would they make the team better?
Can they do the job?
Will they grow?

If any of these is no, it's a no-hire.

"I'm not sure" also means no. Hiring is expensive. Firing is expensive and painful. When in doubt, don't.

The Offer Stage

Good candidates have options. To close them:

Move fast. Long processes lose good people.
Be transparent about compensation. Don't play games.
Sell the opportunity, not just the company.
Let them talk to future teammates.
Address concerns directly.

Post-Hire

Hiring doesn't end at the offer. Onboarding matters (see The First 90 Days as a Technical Leader for more):

First week should be structured
Clear expectations for first 30/60/90 days
Assigned buddy or mentor
Regular check-ins

Many good hires fail because of bad onboarding. Don't waste the effort you put into finding them.

Hiring is pattern matching. The patterns most people use are wrong. Focus on problem-solving, communication, ownership, and growth. Everything else is noise.