Take hiring seriously
You should consider it a key task and put in effort.
For startups, each individual hire matters a lot. If Amazon hires the wrong person, it’s of little consequence. They have thousands of others who can pick up the slack. If a startup hires the wrong employee no. 5, it’s a big problem because it means 20% of the company isn’t functioning well.
The first challenge is not hiring for tomorrow. Most of the time, if you need someone now, it means you should’ve hired them at least three months ago.
Secondly, most people aren’t good at interviewing. It’s a skill that needs to be learned and practiced. Each interview also requires preparation.
Advice on the internet hardly helps because it’s from companies that aren’t in the early stage. Instead, it’s by companies that already have significant resources. When early-stage founders follow it, it’s very harmful.
This also results in high turnover, particularly for people who aren’t suited for startups. Some people can’t work without structure. They need instructions and a rank.
The checklist for an ideal hire is:
- Ambitious and clever
- Good communication
- Has domain-specific knowledge
- Interested in improving your niche
You should heavily prefer people who’ve built their own businesses or projects.
You should always be willing to talk to potential candidates, in particular for senior roles. And you should be continuously posting vacancies.
You should be proactive in the sense that you should hire for what you’ll need next.
And you should be conservative by making sure the person you hire should be a great fit and be able to contribute as quickly as possible.
You should spend more time preparing for the interview rather than in it. That means you should look up the candidate, learn about their previous work, see where they’d slot in immediately and in the long-term. You should find out what useful skills they gained from their previous work.
Early hires must be at least partially effective from day one and with minimal training. In a startup, it’s unrealistic to have someone spend a month or two on training without contributing at all.
They should immediately contribute to things that don’t require background information. For instance, this would mean that a developer would immediately participate in code reviews, design discussions, and improving the onboarding process even if they can’t commit code yet.
The links in the related reading section have good advice. Some might are from an engineering perspective, but the advice still applies.
- The Anatomy of the Perfect Technical Interview from a Former Amazon VP
A very good overview on the interviewing process and the value of being prepared in advance
- Veteran CTO (with Multiple Successful Exits) Answers Your Top Startup-Building Questions
An overview of how to measure performance for engineering
Suggest an improvement to this page (email@example.com)