I've Vetted 400+ Developers. Here's What Actually Separates the Good Ones.

I've personally vetted over 400 developers in the last few years. Technical interviews, code reviews, trial projects, reference calls - the whole thing. And if there's one lesson that keeps slapping me in the face, it's this:

The developers who look best on paper are often the worst hires.

I know that sounds dramatic. But I've watched it play out dozens of times. A founder comes to me after burning through $30k on a "senior full-stack engineer" with 10 years of experience and a portfolio that looked incredible. Three months in, the codebase is a mess, deadlines are fiction, and the founder has no idea what went wrong.

So let me tell you what I've learned. Not theory - patterns. Real ones. The stuff I wish someone had told me before I started this company.

The "Senior" Title Is Meaningless

Here's something that might surprise you: years of experience is a vanity metric. I've met developers with 12 years on their resume who couldn't architect a basic feature without hand-holding. And I've met developers with 3 years who could run circles around them.

The problem is that "senior" means different things at different companies. At a 500-person enterprise, a senior dev might spend years maintaining one module of a legacy system. They get the title because they stuck around. At a fast-moving startup, a mid-level dev might ship entire products solo in that same timeframe.

When a founder tells me "I need a senior developer," my first question is always: senior at what, exactly?

A title on LinkedIn tells me almost nothing. What tells me something is how a developer thinks when faced with a problem they haven't seen before.

What Looks Good on Paper but Fails in Practice

Let me give you a few examples from real vetting sessions. Names changed, obviously.

"Marko" had an impressive GitHub profile. Hundreds of contributions, several open-source projects, clean commit history. On paper, a dream hire. But when I put him through a practical exercise - not a trick question, just a realistic feature build - something weird happened. He froze. Kept asking for the "exact spec." Couldn't make a single decision without explicit instructions.

Turns out, most of his GitHub activity was forking popular repos and making tiny cosmetic changes. The open-source projects were tutorial follow-alongs dressed up as original work. Marco wasn't a bad person. He just wasn't ready to build things independently, which is exactly what a startup founder needs.

"Dominic" was the opposite. Modest resume. No flashy portfolio. But in our conversation, he immediately started asking questions about the business context of the exercise. "Who's the end user? What's the priority, speed or stability? Is this a prototype or something going to production?" He finished the exercise in half the expected time, and his code was readable, well-structured, and she left comments explaining why he made certain tradeoffs.

Dominic is exactly the kind of developer most founders would overlook because his LinkedIn doesn't scream "10x engineer."

The Red Flags I Watch For

After 400+ vetting sessions, certain patterns jump out immediately. Here are the ones that matter most:

Copy-Paste Coders

Some developers have built entire careers by stitching together Stack Overflow answers and AI-generated snippets. They can produce code that works - at least initially. But ask them why they chose a particular approach and you get blank stares or vague answers like "that's just how it's done."

If a developer can't explain their own code, they can't debug it when it breaks. And it will break. Probably at the worst possible time.

The "Yes Man" Problem

This one is subtle and honestly more dangerous than a lack of skill. Some developers agree with everything. Every timeline is fine. Every feature request is "no problem." They never push back, never flag risks, never say "hey, I think this is a bad idea."

I had a founder - let's call him David - who loved his developer because "he just gets things done without drama." Six months later, David had a product full of technical debt, security holes, and a codebase that no other developer wanted to touch. The "no drama" developer had been silently cutting corners the entire time, saying yes to every request without ever mentioning the cost.

A great developer will tell you things you don't want to hear. That's not insubordination. That's professionalism.

Can't Explain Decisions

I always ask developers: "Why did you do it this way instead of another way?" The answer reveals everything. Good developers talk about tradeoffs. They say things like "I considered X, but Y was better here because of Z." They acknowledge alternatives.

Weak developers say "it just made sense" or "that's the standard way." They don't think in tradeoffs. They think in patterns they've memorized. And memorized patterns break the moment the problem changes even slightly.

I wrote more about the 15 red flags in developer interviews that most non-technical founders miss in a separate post, if you want to dig deeper into that.

The Green Flags That Actually Matter

Now for the good stuff. These are the signals that make me confident a developer will work out, regardless of what their resume says.

They Ask Questions Before Writing Code

This is the single biggest green flag. When I describe a problem and a developer's first instinct is to ask clarifying questions rather than immediately start coding, I know I'm dealing with someone who thinks before they act.

The questions themselves matter too. "What does success look like for this feature?" is a completely different signal than "What framework should I use?" The first question shows product thinking. The second shows dependency.

They Write Code Other Developers Can Read

Speed is overrated. I know that's a controversial take, especially in the startup world where everything is "move fast and break things." But here's what I've seen play out over and over:

The developer who ships fast but writes messy code will slow your entire team down within 6 months.

Readable code is not a luxury. It's the difference between a codebase that can grow and one that becomes a prison. When I review code during vetting, I'm not looking for cleverness. I'm actually suspicious of cleverness. I'm looking for clarity. Can another developer open this file and understand what's happening without a guided tour?

They Own Their Mistakes

I sometimes introduce a small twist halfway through a vetting exercise. Something that makes their initial approach suboptimal. What I'm watching for is how they react.

The best developers say something like: "Oh, I didn't account for that. Let me rethink this part." They don't get defensive. They don't pretend they planned for it all along. They just adapt.

One developer - one of the best I've ever vetted - actually said: "I made a wrong assumption early on. Here's what I'd change and here's what I learned from it." In a job interview. That level of honesty and self-awareness is rare, and it's worth more than any certification or years-of-experience number.

They Can Say "I Don't Know"

"I don't know, but here's how I'd figure it out" is one of the most powerful things a developer can say. It signals intellectual honesty, confidence, and problem-solving ability all at once.

The developers who pretend to know everything are the ones who will silently struggle for days on something they could resolve in an hour by asking for help. I've seen this tank projects. A developer disappears for a week, claims they're "almost done," and then delivers something half-broken because they were too proud to admit they were stuck.

They're Not Scared of Using AI

This one is becoming a dealbreaker fast. Some developers treat AI tools like a threat, they refuse to use them, or they use them secretly and pretend they didn't. Both are bad signs.

The best developers I am vetting right now? They use AI openly and strategically. They'll use it to scaffold boilerplate, catch bugs, write tests, or explore approaches faster. But they understand what it's giving them and they review everything before it ships.

The difference is obvious. A developer who uses AI well ships 3-5x faster without sacrificing quality. A developer who's scared of it is writing everything by hand out of pride, and charging you for that pride.

The red flag isn't using AI. The red flag is a developer who can't tell you why the AI-generated code works or when it's wrong.

The Uncomfortable Truth

Most hiring processes for developers are broken. They optimize for the wrong things. They filter by keywords, years of experience, and brand-name companies on a resume. Then founders wonder why their expensive hire isn't working out.

The best developer for your startup is probably not the one with the most impressive CV. They're the one who asks the right questions, communicates clearly, takes ownership, and has the humility to say "I don't know" when they don't know.

That's what 400+ vetting sessions have taught me. The signal is in the soft stuff - the thinking, the communication, the character. The technical skills matter, obviously. But between two developers with solid technical ability, the one with better communication and ownership will outperform every single time.

And if you're a non-technical founder trying to evaluate this on your own, without knowing what to look for - that's where most hiring mistakes happen. Not because founders are dumb, but because they're optimizing for signals that don't actually predict success.

The good ones are out there. You just have to know what "good" actually looks like.