You're About to Hire a Developer. Here's How Not to Get Burned.

In the first years of my career, fresh out of Economics, I found myself at an office lunch in a tech startup surrounded by developers, nodding along to a conversation I could not follow. I remember thinking: are we from the same planet?

That feeling faded slowly. Not because I learned to code, but because I spent years sitting with developers in 1-on-1s, in post-mortems, in the kind of honest conversations that happen when a project goes sideways. You learn a lot about people that way.

When I interview a developer, I have a colleague who handles the technical part. You probably have someone too: a co-founder, a consultant, a trusted friend in the industry. Use them for that. Free yourself up for the part that’s harder to delegate: figuring out who this person actually is.

Most founders think they’re failing because they can’t judge technical skill. But technical skill is only half the hire, and usually not the half that causes problems.

Here’s what years of close work with developers taught me: the ones who burned us, almost without exception, didn’t fail on the technical side. That’s the part nobody warns you about.

There Is No Ideal Developer Type. There Is the Right One for Your Stage.

Two types come up again and again in hiring, and both can be exactly what you need.

The deep specialist. Detail-oriented, possibly introverted, not always fluent in business language. Ask them about something outside their domain and they will make it very clear that’s not why they’re here. But if something doesn’t add up and they decide to figure it out, they will go deeper than anyone else in the room.

These people write excellent code. They just need active management: don’t assume they’re happy, ask them. Don’t assume they understood the subtext, say it plainly. They’re not difficult. They’re just not going to tell you something’s wrong unless you create space for it.

The versatile generalist. Communicates well, brings energy, often interested in the business beyond their own code. This type can be incredible: solid code, lifts the team’s mood, has opinions about your product roadmap. Or they can be someone who found their way into tech because it seemed exciting, and whose expertise is more confidence than substance. Both exist. Your job is to figure out which one you’re talking to.

An early-stage startup that’s still figuring things out needs curiosity and adaptability more than stability. A senior developer who wants quiet, good salary, no drama: that’s a legitimate preference. Just make sure it matches what you’re actually offering.

One more thing worth noting: the era of the developer who could be arrogant because no one else understood code is ending. AI is closing the gap between technical and non-technical people. That shift makes soft skills and communication more important, not less, because they’re now the actual differentiator.

What the First Ten Minutes Tell You

Before you get into your prepared questions, the interview is already giving you signal.

How do they respond to small talk or an icebreaker? You’re watching for how they handle mild social ambiguity. Do they engage, or deflect?

Do they ask questions about the role, or wait to be asked? Curiosity is a signal. Passive reception is also a signal.

How do they talk about their last job or team? Listen for accountability versus blame. Almost everyone has worked somewhere that wasn’t perfect. The question is how they describe it.

Do they seem interested in what you’re building, or only in the conditions of employment? Both are legitimate things to care about. The ratio matters for an early-stage hire.

The Questions That Actually Reveal Character

“Tell me about a time something went wrong on a project. What happened?”

“If I asked you to build something and you thought it was a bad idea, what would you do?”

This tests whether they think or just execute.

“What would you need from me to do your best work?”

Tests self-awareness and communication. The deep specialist type may struggle with this one, possibly because they’ve never been asked. Help them along if needed. The willingness to engage with the question tells you more than the answer itself.

“What kind of environment do you work best in?”

This is where you find out if they want stability and structure versus speed and ambiguity. Neither is wrong. But you need to know if it matches what you’re actually offering.

“Tell me about the last product you shipped. What did users say?”

Tests connection between technical work and real outcomes. A developer who has no idea what users thought of their work is a flag.

“When was the last time you did something outside your job description? What made you do it?”

Tests initiative. In a startup, you rarely have the luxury of someone telling you exactly what to do.

Red Flags That Have Nothing to Do With Code

They can’t explain what they do in plain language. They never push back, agreeing with everything you say. They’re vague on timelines (“it depends” with no follow-up). They only talk about technology, never about the people they worked with or the problem they solved. Their portfolio shows designs and mockups, not live URLs or shipped products.

Their weaknesses answer is a disguised strength. “I work too hard.” This usually signals low self-awareness, and self-awareness is what makes a person coachable. Without it, feedback doesn’t land.

One Thing to Do After the Interview

A small paid test project. Even a few hundred euros of work tells you more than three interviews.

These are the behaviors that matter in a working relationship, and they’re almost impossible to fake over an actual project. The developer who communicates badly in a test project will communicate badly on your product. The ones who flag a blocker immediately and ask how you want to handle it are showing you who they are.

The Technical Side Still Matters

Reading people is one half of the hiring job. The technical half still matters, and it belongs with someone who can actually evaluate it.

If you’re looking at a whole development team, an agency proposal, or a codebase you’ve inherited, you need someone technical in your corner. Someone who can read what’s actually been built and tell you whether it’s solid or a problem waiting to happen.

At Hurricane, we do a free technical review of proposals, CVs, and codebases for founders who are considering working with us. If you’re in the process of hiring and want a second opinion on the technical side, talk to us.