On Recruiting Brilliant Software Engineers
When recruiters first contact candidates, they typically list off a string of very unimportant things. In this particular example:
- NDAs are the norm in Silicon Valley. I had a lot of NDAs at Apple. NDAs are not something to be proud of. NDAs mean either you have highly capable competitors (Google and Samsung) or you have little competitive advantage. If someone knew your idea, they could easily implement it.
- “Once in a decade”. Every company thinks its god’s gift to the universe.
- “If they can pull this off, they can change the world,” is about the same as saying “If I can pull off time travel, I can change the world.” Duh.
Tell me what problems you’ve been able to frame in a way that no one else has been able to. Tell me about the insights you have that no one else has. Tell me about the things you do that everyone disagrees with.
If you’re the CEO, I’m much less interested in your dark matter research (What does it have to do with speech analysis, please inform me), and much more interested in your integrity, transparency, and vision. I didn’t feel motivated or inspired at all by the message.
Degrees don’t signal very much. Google’s said it: We don’t see correlation between performance of hired people and the degrees they have.
Everyone who has contacted me thinks my background is relevant. Much more interesting to me were the problems Gigster posted on their website for prospective contractors. First time I solved it, I did a really shitty job. Grade A shitty. Maybe I’m not right for Gigster for that reason. The recruiters don’t even know that, though. They never asked me to solve a problem.
Great engineers love solving great problems. Impressive rosters, name dropping, high valuations, degrees, exclusivity, “innovation,” and grandiose claims should be second to that. Give us problems and see how we do. Problems and their solutions matter.
Comma.ai did just that. They open sourced their dataset and wrote:
This attracts people who are good at the right thing: solving specific problem X that we have at specific company Y. George Hotz might be the CEO from hell, but I’m going to learn that a lot better working with him on a real problem than I am on a scripted phone call with him.
The CEO of Numerai didn’t start by telling me about his vision or his background or his amazing team. He started with, “You should quit your job… Oh, and we want to [amazing, specific, concrete problem]. Can you do that?” That’s all he needed to do. Just dangle the carrot, and I voraciously went gnawing after the bait because I loved the problem he had. It was a real problem the company needed to solve, and I solved it, and I wanted to solve more things like it. Had I not been interested in or capable of solving that problem, then I wouldn’t have been the right fit no matter how eloquent I may have been over the phone or in person or on a whiteboard.
Speaking of the whiteboard: I tend to perform particularly poorly with whiteboard coding. Maybe it’s my ass burgers. It turns out, coding with no IDE, no compiler, no runtime, no reference material, and a panel of judges breathing down my neck has never actually happened during my five jobs as a software engineer. So why does it happen in interviews? You’re testing me for skills orthogonal to what I actually do on a daily basis. There appear to be a lot of engineers who’ve come to the conclusion that whiteboard coding is wrong.
You’ll find out all the cultural aspects in the process of working together to solve a problem, evaluating results, modifying plans, and iterating. Sure, there are otherwise great engineers who are assholes and will not fit into your culture, and you’re going to see that a lot better from actually working with them in their natural environment (solving problems) than chatting it up in fabricated environments that have nothing to do with their day to day job (phone/whiteboard).
Here’s another cool tactic: Read something I’ve written on my GitHub and tell me something about it. The fact that you found it interesting or that you were able to understand it is very interesting to me. Tell me how my code is shitty. Brilliant engineers will want to work with people they can learn from. Teach me something worth knowing and I’m hooked.
Read my GitHub. Invite me to a party. Let me step on your cat.
