How to Think About Startup Hiring

The Right Person in the Wrong Place is a Disaster

Someone who is brilliant at one role might be completely useless in another. I’ve seen amazing architects who couldn’t debug their way out of a paper bag. I’ve seen fantastic individual contributors who became terrible managers. Skills don’t transfer universally.

Context matters as much as capability. The senior engineer who thrived at Google might struggle at a 10-person startup where you need to wear five different hats. The scrappy startup veteran might get lost in a large company’s process-heavy environment.

Better to have the right fit than the most impressive resume. A good engineer in the right role will outperform a great engineer in the wrong one every time.

The Real Cost of Bad Hiring

Bad hires are expensive in ways you don’t expect. Sure, there’s the obvious stuff: salary, benefits, recruiting costs, training time. But the real damage is harder to measure.

Your team gets disrupted. Good people spend time covering gaps and fixing broken workflows. Projects get delayed. Morale suffers because nobody wants to carry dead weight.

Then there’s opportunity cost. While you’re dealing with the mess, what could you have built instead? What problems could you have solved?

Here’s the thing: all organizational challenges trace back to having the wrong people in the wrong roles. Bad processes, missed deadlines, technical debt, low morale — it usually comes down to people problems. And bad hires tend to hire more bad people, compounding the damage.

Think in Squads, Not Individuals

A squad is one complete unit that can solve one product problem. It’s nearly impossible to find one person who can do everything well, but you can build a squad that handles almost everything.

Complementary skills matter more than individual brilliance. You want people who naturally divide work effectively, where nothing gets neglected and everything gets done well.

There’s no generic squad composition that works everywhere. Figure out what your specific problems need. Some squads are temporary, built around a project or feature. Some people contribute to multiple squads. That’s fine.

Focus on what the team can accomplish together, not on collecting impressive individuals.

Hire for Gaps, Not Resume Appeal

Only hire against a specific need. Don’t hire someone just because they look impressive on paper.

Start by asking: what work gets neglected or done poorly? What’s your team missing? Then find people who naturally gravitate toward that kind of work.

Don’t hire more people with the same skill sets than you have work for. This creates redundancy and internal competition. When people aren’t complementary, they compete instead of collaborate.

Resume appeal often misaligns with actual needs. The person with the most impressive background might not be the person who solves your specific problems.

What Actually Matters

Technical fundamentals are non-negotiable. For engineers, the basics matter: programming languages, operating systems, networks, databases, browsers, code design, architecture, and testing. Someone might be amazing in every other way, but without solid technical foundations, they become a liability.

Hire proven capability, not potential. Startups can’t afford to be training grounds. You need people who already know what they’re doing. Experience beats inexperience every time — having actually done something is completely different from having the potential to do it.

But not all experience is equal. Some people learn more in two years of intense, challenging work than others do in ten years of routine tasks. Look for people who’ve been willing to tackle hard problems. They tend to be both knowledgeable and hardworking.

Watch for behavioral red flags. People who stay at companies for very short periods often have issues working with teams. People who don’t take things to completion or deal with the consequences of their code over time create technical debt that others have to clean up.

Avoid people who jump between completely different roles without developing competency in any. Watch out for blame deflectors who always attribute failures to external factors. Be wary of over-promisers who destroy team planning by making commitments they can’t keep.

Communication matters more than you think. People who don’t surface blockers early, work in isolation, or resist feedback become bottlenecks.

Making It Work

Reference checks are critical. Go beyond the provided references if you can. Ask specific questions about how someone actually works, not just whether they’re “nice” or “smart.”

Most interview processes test the wrong things. Whiteboard coding reveals little about day-to-day engineering effectiveness. Instead, look for signs of ownership versus just task completion. Can they think about edge cases, user impact, and long-term maintainability?

Test comfort with ambiguity. Startup requirements are often unclear, and some people thrive in that environment while others need detailed specifications.

The Hard Truth

Hiring is inherently challenging, and you will get some of it wrong no matter what you do. Accept this reality and develop systems to measure performance objectively and provide feedback. In the worst cases, you need to be able to let people go.

This correction process deserves its own discussion, but don’t ignore it. The ability to fix hiring mistakes is as important as trying to avoid them in the first place.

The complexity of building software products requires deliberately constructed teams with complementary capabilities, not just accumulating supposed talent.

PS: All thoughts are my own and not necessarily that of my employers