You’re a great coder. You’re easy to work with. You know your data structures and algorithms backwards and forwards, you laugh at discrete math, and your methodology is so agile you can scrum while XP’ing. You know you could crush any technical interview, but no one will give you the chance. No matter how many resumes you send out, no matter what you try, you just can’t get that phone screen or first interview. Why not, and what can you do about it?
Pity the Recruiter
First, let’s take a step back and take a quick look at the sad, dark life of the technical recruiter. In any top company (a.k.a. most companies you’d want to work at) there’s going to be a deluge of resumes coming in, both over the transom and from external recruiters. There aren’t enough hours in the day to perform in-depth examinations of every resume, so each gets a quick evaluation that’s somewhere between a glance and a quick scan before being put aside for further evaluation or moved into the circular file. Approaches differ, of course, but the problem is roughly the same no matter where you go. Bottom line, you have a very limited window in which to make an impression, and the number of things your CV can say to make that impression is fairly limited.
Conceptually, let’s divide resumes into three piles. The first pile contains resumes for candidates who have a high probability of passing the technical interview and getting an offer. The second pile has resumes of people who might get an offer, and the third pile has all of the people who probably don’t have a chance. Resumes in the first pile get prioritized, the second pile gets looked at if there’s time, and the third pile gets thrown away. So what gets you into the first pile?
The key thing to remember is that a recruiter’s primary goal is making hires. Yes, hires need to be technically competent, they need to be good cultural fits, they need to be successful at the company long-term… But this is what The Process™ (i.e., resume review, interviews, etc.) has been set up to determine, and they’re looking for candidates who can pass the test. Some great candidates will be missed, some duds will get through, and the degree to which these false negatives and positives are avoided are what determine how effective a company’s process is. But ultimately, recruiters are looking for people who can make it through the interview process, and the candidate with the best chance is the one who’s done it before.
Like it or not, the school you went to as an undergraduate has a huge amount of influence during the initial evaluation. Graduating from MIT, Stanford, Brown, etc., with a BS in Computer Science will typically be enough to get you the first phone call. Why should this matter? There are some second-tier and public schools with great CS programs (e.g., Champaign-Urbana), and these might get you into the second pile, but why is an undergraduate degree from Brown so much more meaningful than a degree from UT Austin?
In short, because a candidate from a top school has already gone through an extremely difficult culling process. There’s very little way to know whether a candidate learned anything in school, and whether anything they learned has relevance to their actual coding skills – but the one thing you know about someone who graduated from Brown is that he or she got into Brown in the first place. They’ve already been vetted, and survived a brutal winnowing process. This is a meaningful piece of information, and is frequently enough to move forward on.
This is also why Master’s degrees from great schools are somewhat meaningless. Most schools treat their Masters programs as revenue centers, and the selection criteria are far less rigorous than for undergraduates. Since CS classes at Stanford and SUNY Binghamton don’t necessarily differ that much (as it happens, I’ve taken classes at both), the classes a candidate’s taken don’t necessarily give you much information. The only thing that matters was whether the application process was hard.
Having worked at a company with a tough interview process is also a great positive indicator. This could be a great, well-known company (Google, Facebook, Amazon, TripAdvisor), or a smaller company known for having a particularly tough interview process. Opinions can differ, of course, but the longer you’re involved in recruiting, the better you get to know the companies in your area, and learn what to look for. Although the work a candidate did at a company is important, once again the key point is that they’ve already gone through and succeeded at a rigorous interview process.
[As an aside, the question frequently comes up as to whether it’s better to work for a startup out of college, or go work for a big, well-known company for a couple of years first. There are many reasons for and against each option, but besides the fact that you’ll learn a tremendous amount, an important reason to at least have internships at top companies is that it gets you into the first pile if things don’t work out.]
Domain Knowledge and Cultural Fit
If you’re looking for a job in the defense industry, ten years of work at defense contractors will stand you in good stead. If you’re looking to go into a tiny web startup, however, your defense work might be a red flag that you’re used to a procurement / bidding / approval process measured in months to years, multi-year project cycles, and a more conservative work environment. And vice versa, of course. If you’re changing industry, you’re going to have to overcome the perception that, far from being a selling point, your prior experience is going to actively prevent you from being successful at the new company.
While having worked in a start-up doesn’t mean that you got through a tough interview process, it’s generally viewed positively for one important reason: starting a company is hard. You don’t have the infrastructure of a big company, there isn’t someone to take out the (metaphorical or literal) trash, and you don’t have the luxury of being Software Engineer II responsible for Foobarian Widgets. You have to do everything, work harder, and learn quickly – all on your own. Sure, if you’re applying for a job instead of retiring to your own island, then you probably failed – but from the company’s standpoint, that’s OK. You hopefully learned a lot, demonstrated dedication and initiative, and will probably be grateful to have a paycheck.
If you’re good at something, you usually like doing it. If you enjoy doing something, you tend to do it more. And, of course, you tend to get better at things you do a lot. Side projects, from iOS / Android apps, to contributions to FOSS projects, to setting up Beowulf clusters in your attic made from dozens of Raspberry Pis, are going to get you a second look. The recruiter needs something, anything that indicates that you’re extra geeky, and evidence that you fool around with (and complete) personal projects on your own time is a good sign.
Note that a side project is very different from a school project. School projects are defined for you; have due dates; have been designed to be self-contained; and are known to be possible. Side projects are defined by you; don’t have due dates; usually start out poorly defined and messy; and might very well be impossible. Finishing a side project means you had the drive to do so without the external carrot or whip, and without the knowledge that what you were doing could be done. Finishing a school project doesn’t mean much of anything.
So what are you going to do about it?
OK, so you didn’t go to MIT. And you haven’t worked for a great company – maybe you’re just graduating, or maybe the first company you worked for turned out to be a dud. What can you do to make yourself more interesting?
Without the school or the job history, your best bet is going to be to do some side projects. Writing an iPhone or Android app is easy – it just takes an idea, some determination, and the ability to work through a tutorial book one chapter at a time. Alternatively, you could get involved in an open-source project. For example, Linux Kernel Newbies is a good place to start if you want to get involved in Linux development (I guarantee you, being a Linux kernel or Apache project contributor with merged diffs will catch a recruiter’s eye). There are plenty of options, but the key is that you have to finish something, ideally multiple somethings, in a public way (e.g., published in an app store). Saying that you’re currently working on an app, and will be finishing it any day now is pretty weak sauce, kind of like being a waiter in Hollywood with an unfinished screenplay. Tell me what you did, and where I can find it (including a link to an app store and/or github account). If I can’t see it, it didn’t happen.
At this point, some readers are going to be upset because they were hoping for a different, more effective arrangement of words to describe their education and job history, not homework. I’m sorry if you feel cheated, but if you didn’t go to a great school, and you haven’t worked for great companies, and you don’t have side projects that you conceived of, executed, and completed on your own, then why should anyone think you’re different from the other thousand resumes that are just like yours? Why should they pick your resume out of the pile? Maybe that sounds harsh, but really, without something genuinely special on your resume, how are we to know that you’re just that awesome?
This post wouldn’t be complete unless I included a couple of anti-patterns into the mix, i.e., things that will damage your chances at an interview, no matter how great your resume might otherwise be.
- Job Hopping
So, you graduated from MIT, worked at Google and Amazon, regularly contribute patches to the Linux kernel… And you still can’t get an interview. If you’ve had five jobs in the last five years, why should the recruiter think this time will be different? Maybe you’ve been “managed out” at each of your jobs. Or maybe you’re just not going to be happy, no matter where you end up. No matter how good your resume is, a series of short stints can sink your chances unless there’s a really compelling reason for them, and you have the chance to explain.
- Ten Page Resumes
Long resumes are the equivalent of the guy at a party who thinks he’s the most interesting thing going on, and proceeds to bore you with the intimate details of a life you couldn’t care less about. We don’t have time to read long resumes, and they’re honestly nowhere near as interesting as the candidate thinks. Resumes should be summaries, with more detail for recent positions, less detail for more distant ones. If you’ve been in industry for ten years, you can have a second page. No one needs more than two.
A Final Word
I know that some of this may seem elitist, and that’s right. Hiring is meant to be elitist – companies always seek the best candidates they can get, and great companies will try to hire only great candidates. If you’re serious about your career, then I hope that this is a hopeful essay – you can set yourself apart. You can do things that will get yourself noticed. Most people, even knowing what they have to do, will be unable or unwilling to do it. But you’re different. You know now that you have a choice, and you know what you need to do to get into the top pile.
Just in case you haven’t guessed, I’m hiring! Please send resumes to daniel at my company. Thanks!
Next up: preparing for the interview