How to Recruit Tech Talent Like an Investor
I recently received two rejections after completing technical challenges for companies I was interviewing with. The feedback I got was NOT that I did poorly on the technical challenges but that there were other candidates who are more qualified. Like other recent bootcamp grads, I’m facing a common challenge: I often don’t look as good on paper as people with Computer Science degrees or people who have professional experience as a software engineer. I grok that recruiters have something along the lines of a list of check boxes they tick off:
[x] Javascript
[ ] Typescript
[ ] +2 years of software engineering experienced
...I have been reflecting on this challenge, and I think the approach I should take is not necessarily to get more boxes checked off (although I am doing that in my spare time). Rather, I want to learn how to convince recruiters to think more like an investor. In particular, I hope to convince them that I’m less of a risky investment than they think.
That might seem like an odd thing to say. But, after running a startup for 3 years and getting schooled in how to raise money during the Matter accelerator program, it seems apt to me. Investors are people who give you money in hopes that they’ll get a return on investment. Similarly companies hire individuals (or invest in them) expecting that those individuals will add value to the company.
Now, recruiters already behave like investors in some ways. They both spend a lot of time trying to mitigate risk. As Gayle Laakmann writes in Cracking the Coding Interview, recruiters care a lot more about false positives than they do about false negatives. Similarly, when looking for investment, one of your prime goals is to prove to investors why your venture is a sure bet.
The primary area where recruiters differ from investors is in how they asses risk. Here, I gather that recruiters think more like school teachers than investors. (This is not a knock against teachers. My wife is one, and I sit on a school board). Recruiters have a checklist of things that a candidate needs to pass. In particular, recruiters often look at a static image of candidates. What I don’t see many recruiters doing is looking at rate of change over time, otherwise known as growth.
For investors, on the other hand, growth is paramount. Investors only make money if the value of an asset increases over time. A company that makes $1M/yr and will continue to make that amount year after year isn’t a good investment. But, a company that earns $100K/yr and will be earning $100M/yr in 10 years is a great investment. In the first case, the return on investment is 0. That company’s value has not increased over time. In the second, the return on investment is a factor of 1000.
My goal is to get recruiters to buy into a growth mindset when I talk to them. To be fair, a company’s investment horizon in a software engineer is generally shorter than it is for an investor in a company. Software engineers are notorious for frequently switching jobs. A quick google suggests the average change is about every two years. Furthermore betting on extreme growth is inherently risky. Few companies exhibit a return on investment with a factor of 1000 over 10 years. This would be considered a “unicorn” company.
Still, the argument I want to make is that I will add more value over the span of two years than someone who may currently have more skills than me because I will grow faster and learn more quickly than they ever will. I have a proven track record of growth and learning. I don’t suggest throwing baseline check boxes out the window. Rather, assess those check boxes side-by-side with growth potential. If you do that, you’ll see that I’m a less risky investment than someone with more boxes checked off but less potential for growth.
As case study in me
The argument I’m about to make applies broadly to coding bootcamp grads, but I’m going to focus on my experience as a startup founder. The argument is as follows:
- The technology stack changes so rapidly that no set of job requirements will ever fully cover what a software engineer will need to do to be successful.
- It is equally, if not more, important to be able to learn new things quickly as a software engineer than it is to know a bunch of things already.
- Experience founding and running a startup for 3 years has given me superior skills in learning new things quickly and effectively.
- Technology is changing fast
React, the most popular JavaScript front-end framework, is only 7 years old. A stable implementation of React Hooks was released less than 2 years ago, yet I was recently told by an Engineering Lead that he almost never uses class-based components any more. JavaScript has consistently been releasing new ECMA scripts every year since 2015. Most modern web frameworks release new versions and major updates on a regular basis.
There are notorious examples of job postings asking for more years of experience in a technology than that technology has existed for.
Even if a developer ends up working with only the technology stack they were hired for, they will likely encounter novel situations and challenges along the way. This requires, not knowledge, but the ability to quickly acquire knowledge.
2. The value of learning quickly
Given how fast technology changes, it’s important to be able to quickly pick up new skills and knowledge. How quickly can someone debug a problem they haven’t come across before? How quickly can someone find a relevant tutorial or blog post? How quickly can someone learn a new syntax or technology from scratch?
People who struggle to do these things will stay confined to their current knowledge base. They will rely on others to teach them. The don’t have the ability to figure out what they don’t know and effectively devise strategies for how to learn those things.
3. Founding a startup is like going to graduate school in learning quickly
When people ask me what it was like to found a startup, one thing that always comes to mind is the immense amount of uncertainty I had to deal with. There is so much you don’t know when you start a company. Does your customer really want your product? Will they pay for it? If so, how much? How do I make the product usable? Scalable? Secure? How will I market it and convert users?… The list goes on. 9 out of 10 startups fail. If you don’t answer these questions quickly, you fail. Startup over.
To answer these questions, I had to swim through a sea of information, quickly discern which information was and wasn’t relevant, and understand how to quickly absorb and put that information to practical use. For example, I taught myself how to code in three months, built a demo platform in another three months and then used that demo platform to raise money and recruit a dev team. I had never worked in the tech industry when I began my startup, so I was starting from scratch when answering these questions.
And I learned quickly enough build a local pilot product with 2000 beta users, acquire contracts for $66K in 6 months, and garner venture financing through the Matter accelerator program. I did this by knowing how to prioritize. The most important question is figuring out the right question to ask in the first place. I am an expert at asking good questions and devising methods to answer those questions quickly.
So, next time I am going through an interview process, I hope to show my interviewer that I can learn more quickly than any of their other candidates. Maybe I will challenge them to ask me not only what I already know but how I would approach learning something I know nothing about. Yes, other candidates might be able to check off a few more boxes than me currently. But they won’t for long, and this makes me a much less risky investment than them.
