Updated: Jan 28
In his playbook on building a monopolistic startup, Zero to One, Peter Thiel states that his favourite interview question is:
“What important truth do very few people agree with you on?”
As an interview question, it’s certainly better than “what is the average case time complexity of Quick Sort”
For anyone who may find themselves in an interview with Mr Thiel (not sure I’d want to jump onto a Palantir stock package personally but to each their own) in the near future, the form of answer he’s looking for is: “Most people believe in X; but the truth is the opposite of X.” I read Zero to One the week before I started with techrutier, and have been thinking about what my recruitment “contrarian opinion” is, and I’ve concluded that it is:
“To be an excellent technical recruiter, you need to learn to code” So let’s break this down. Why don’t most recruiters believe this, and why do I believe it to be true?
Most technical recruiters don’t think they need to code Recruitment is an un / low regulated industry with minimal barriers to entry. That’s not a value statement on the people who choose to do it for a living, merely an observation. No one has to go to recruiter school to break into the industry, it’s very much “learn on the job”.
The initial triage into what industry you recruit into is also very arbitrary. My first role in recruitment was recruiting realtors. Not because of any burning passion for real estate (lunch breaks spent browsing Streeteasy aside) but because I liked my boss and liked that it was a VC backed startup where I would be hire #4.
Recruitment is also typically heavily incentivized via commission. To pull back the curtain on the way the recruitment world works: the money agency recruiters make is proportional to the money made by the people they recruit.
If a software engineer earns $150K, the fee for placing them is $30K. The recruiter who found that person is due anywhere from 10 - 40% of that depending on how aggressive their commission scheme is. At the top end, that is $12K to the recruiter. As the market for engineers heats up, and that person can command a salary of $200K, resulting in $16,000 to the recruiter.
So technical recruitment is increasingly lucrative and has a low bar to entry. The result? A lot of recruiters who like money but don’t have any knowledge about technology.
And the fast-paced results-driven nature of the job means that most recruiters are not going to take the time to learn more about the technologies they are recruiting for.
There are recruiters who would tell you “It’s just a process. I don’t need to know what the words mean, I just put the keywords into LinkedIn and message enough people”. I know because I’ve met them (although thankfully not at techruiter!)
Why they are wrong Recruitment isn’t process work, it’s knowledge work. More knowledge will make you better at it. And crucially, make you able to do less work with better results.
Let’s say you are a recruiter who has a 10% response rate to the emails you send out. In order to get 20 people to come back to you about a new opportunity, you will have to send 200 messages.
A new role comes on and you have two options. Immediately message 200 people (180 of whom don’t want to talk to you) OR spend time learning more about the technologies involved so you
can better match people and improve that response rate to 20%. Suddenly you only have to message 100 people and get this, you now permanently have that knowledge. Compounded over your entire career the time saved is huge. When you consider the time saved by the extra 100 people you didn’t have to email, and the time saved by your client who has greater confidence in the shortlist you present, we are talking a 10x improvement.
I don’t mean to sound like a trite motivational poster but it really is about working smarter. And to work smarter you need to *be* smarter, or at least better informed.
Why that means you should learn to code
So hopefully you’re onboard with the idea of learning more about what software engineers actually do, and what the technologies they use mean. But why does that mean you have to actually learn to code rather than just reading up on the topic?
One word. Empathy.
It’s not just about reading a bunch of Medium articles on static vs dynamic programming. Spending all Sunday afternoon wrestling with C’s type system makes you *feel* what those tradeoffs are like, and better understand why engineers will have strong opinions on the tools they do or don’t want to use.
When I learned Python, the first time I was able to intuitively use functionality without looking it up, I *felt* what it’s like to use a language with English-like syntax.
Why your clients will thank you In 2017 I partnered with a Seed funded startup, fresh out of Y Combinator and hiring their first engineer.
As fans of functional programming, they were keen to use Elixir. I advised that if we only considered Elixir devs we would be limited to too small a pool of talent, and that there were too few people using Elixir to build complex distributed systems.
Knowing how the Elixir syntax is similar to Ruby, I consulted with them to consider Ruby devs who like functional programming. If *I* am able to pick up new programming languages with similar syntax, then I know for sure that professional programmers are going to be able to!
This opened up a huge pool of talent (win for me), enabled the client to cast a further net than just the narrow set of people currently using Elixir (win for the client) and most importantly, allowed a whole segment of folks to be considered for a job to learn a cool new language.
How should I learn to code?
There are numerous resources out there, but I will end by pointing you towards the one that has helped me the most. Harvard and edX’s CS50. The content is engaging, the problem sets are actually graded so you can track your progress, and best of all it’s entirely free.
I urge all technical recruiters to check it out. You will learn more about what the people you talk to all day (software engineers) actually do, and who knows, you may even end up recruiting yourself into a new career as a developer!