Modern tech recruiting sucks as an engineer.
In order to prepare, you spend hundreds of hours becoming incredibly good at solving toy (leetcode) problems that have very little relationship to the job you’re interviewing for, and the one you’ve probably been doing professionally for years. You then spread your net wide, not wanting to waste the effort you’ve put into preparing for technical interviews. If you get an offer you like, you then have to roll the dice on the company, team and codebase you’re joining - praying that the rosy image you’ve been presented isn’t too far from the truth. All of this then constantly cycles in the “always interviewing” culture that has recognised that switching companies every few years is generally the optimal approach to career advancement in tech.
On the flip side, things aren’t that much better as an employer.
You have a large pool of candidates that is hard to systematically filter down. It takes a huge amount of time and energy to assess and decide who should join your team. When you do, you roll the dice that they’ll be a good addition to the team on relatively little information, and suffer the massive cost to culture and product if they’re not.
Both of these dynamics emerge from a system that has relatively poor information available to both parties. You only really know whether there is a good fit by doing the job itself.
However, not every recruiting process looks like this. There are two niche types of recruiting where unnecessary effort is low, risk is negligible and the level of information both parties has is much higher.
The first is hiring someone you’ve worked with before at a previous company. You know that they’ll resonate with the culture, their technical skills are up to scratch, they’ll enjoy working with you and that it would be extremely hard for either party to fake that fit.
The second, which only occurs if your work is open source, is hiring from the pool of existing contributors to your codebase. You’ve already gone through the process of merging their PRs, which they generally haven’t been financially incentivised to create, indicating a level of technical and culture fit that significantly de-risks the hire.
Both recruiting approaches happen often, but neither one is scalable. Very few products are open source and the likelihood that there’s a perfect match between your existing network and the role you’re hiring for is generally quite small.
So what could scale? If open sourcing your product is infeasible, what about the selective open sourcing of tasks that could be completed externally? I’m not talking about intricate tasks, on esoteric environments, with privileged customer data, a high ramp up time and strong interdependency on confidential systems. I’m talking about the small self-contained tasks that a freelancer could do, but it’s too much hassle to hire one for. That equilibrium shifts drastically when you factor in using those tasks as a recruiting mechanism.
Potential future team mates get to interact with the team they could join, work on real problems the team faces and get paid for the work they do. Employers get to immediately filter out people without the necessary technical skills and without the interest in solving the type of problems that they work on daily. Making selective problems public effectively integrates recruiting into your CI/CD process and reroutes the billions of hours spent on toy problems to real work.
This seems hard to implement though, right? Nope, we’re already most of the way there. This fits neatly into a freelance development workflows that already exists. Replit bounties are a good example of making this process as frictionless as possible - the rails are already there, you just need to extend them a little.
This certainly isn’t a silver bullet. There are some applications where this type of process just isn’t possible.
Some heavily regulated businesses just can’t have external developers writing production code (government, defence, healthcare and finance are sectors which come to mind), some roles aren’t conducive to freelance type work and some teams need to keep their work private. These are all cases where you can’t refactor your recruiting approach to include others in your development process. However, where you can, you’re able to build a recruiting pipeline with much better information for all parties concerned.
You might be able to tell that this article was born from an acute sense of frustration with how tech recruiting is currently done. That being said, the frustration isn’t so keen that I want to spend the next seven years of my life fixing that problem. There are other problem spaces that I care more deeply about building for. So, if this concept piques your interest, do it, keep me updated (and let me into your pre-seed round!).