| If you're a CTO for a growing startup, this might be a familiar challenge for you. On top of building the product, finding product engineers is becoming one of the hardest things for a CTO to do in 2019, especially in tech hubs like NY and London due to higher demand and competition. This problem is no longer exclusive to the Bay Area. Hiring is time-consuming and expensive, and many startups feel that they can’t compete with some of the top salaries and perks offered by deep-pocketed alternatives. It makes sense to rely on your network to hire the initial few developers, but this approach is not sustainable in the long run. Job boards are getting crowded. Recruiters are generally worse. I've read a lot of stories about using recruitment platforms. Few are great, but many are unpleasant. The flaw with many recruitment companies is they don't reliably deliver enough good candidates to build trust. Asking for profile A and getting profile B is a common frustration. For startups, this tends to be a deal-breaker because hiring the wrong candidate has a significant cost and impact on backlog and team. Is it that most recruiters or on-demand marketplaces aren't highly technical? Is it that they also suffer from talent shortage? Remote work has been getting a lot of love in recent years to bypass the talent war. Although it has come a long way, it's still hard to pull off, especially for companies that are trying to do both local and remote but are not remote-first (think infrastructure and payroll primarily). With that being said. How do startups in hubs currently find great engineers quicker? What's an approach that you have been investing in recently to hire product hackers? |
1. Don't limit your potential talent pool to the miserable and the unemployed. In theory, any developer who is currently employed might be interested in leaving their job to work for you. Perhaps you will offer them more money, or perhaps a better quality of (work) life. However, most developers won't bother to talk to you if they already have a job. Why is that? Simple, if they do talk to you, you're going to offer them a homework assignment. You're going to tell them that it shouldn't take more than an hour, but it will actually take two full days to do right. Giving someone a homework assignment isn't a way to woo them away from their current job. So you are left with a candidate pool that consists mostly of people who are desperate enough that they have to agree to jump through your hoops (i.e. unemployed, miserable in their current job, etc.)
2. Don't discard capable people. The average interview begins with a remote code challenge whereby the candidate, who is probably nervous, has to pair program a completely contrived problem with a complete stranger watching them over a webcam. There are tons of developers who are good at coding solutions to real world problems in real world situations but simply don't perform well in this type of situation. This type of scenario is not really assessing a candidate's skills. It's assessing their familiarity with specific contrived interview problems and their ability to perform under duress.
Of course, the points you raised are fair as well. Recruiters are not technical people, they are sales people. You will have to find a good recruiter. They are out there, you just have to find the right ones. But my point is, once you find the good recruiter(s) don't waste the human capital they can being to you by having a terrible interview process. Here is my advice. Once your recruiter has a handful of resumes you like, carve out half a days worth of 30-minute sessions to meet with them at the recruiter's office. Ask them about projects they've worked on. You'll find out much more about what they know and what they're like to work with than you would with the typical remote code challenge. One you narrow the pool down a bit bring them in for on-sites.
Best of luck!