I can't has cheezburger

I routinely review résumés for engineering candidates and I wanted to share some practical tips that are guaranteed to help get you an interview in the instance of at least one person who might be reviewing it.

First and foremost, proofread the living shit out of your resume. You probably rolled your eyes at the English teachers who warned you about it, but they were right. I have thrown out resumes for really well qualified candidates for spelling and grammar errors (even when my colleagues wanted to move forward). I’m not asking that every piece of correspondence you ever have with me is perfect and free of errors. I ask merely that the one-page document that is supposed to tell me whether I should offer you an interview be free of errors.  If you think I’m being pedantic and asking too much of you, that’s fine. Go talk to an interviewer who’s less of a hard ass about that kind of thing, and celebrate your mediocrity together.

My other pet peeve is with language and technology names. It’s JavaScript, not Javascript. It’s MongoDB, not Mongodb. It’s OS X, not OSX. It’s PostgreSQL, not Postgres. Errors like these won’t get your resume thrown away, but I still hold it against you if you didn’t get it right. If you claim to be a master of one of these languages or technologies, spell its name right.

If you work with a recruiter they will probably make your resume look like shit. You’ll know they’re doing this if they ask you to send them your resume in Word doc format. If you’re working directly with the potential employer, send a PDF unless a specific format was requested.  If you are sending a PDF, play with a variety of layouts to see what reads easiest. You could even A/B test different resume layouts with different companies to see if you have better success (though you should really be selective and keep a small pool of prospective employers).

Beyond straightforward things like the above, it’s incredibly difficult to tell the story of what kind of engineer you are in the form of a resume. However, if you are working with a small company with a small engineering team and an engineer is reviewing your resume, don’t name drop every technology you’ve ever encountered in your career. I know that if your resume says you are skilled in Python, Ruby, C, C++, Objective-C, C#, VB.NET, Lua, Brainfuck, Lisp, Clojure, Erlang, Haskell, Node.js, CSS, HTML5, PHP, Java, MySQL, MongoDB, and CouchDB, I know better than to think you’re brilliantly skilled in all of them. even if you’ve done one or more projects in each of these languages throughout your career, but what I really care about is what you’ve mastered, and if you’re smart I’ll know you can learn another language if one comes along.

Don’t stick on extra languages you only had fleeting contact with. Believe me: if a language is important enough that its mere mention gets you an interview, you’ll be found out in the tech interview if it turns out you really don’t know much about that language or technology.  One exception: obscure languages relevant to the posting. If it’s super obscure, even a little experience could get you a real leg up. But your chances are better by just being smart overall.

I don’t know who started the convention of writing your resume in third person in a dry way that avoids using pronouns referring to yourself, but it dehumanizes you as a candidate and it makes the resume a freaking pain in the ass to read. Here’s a confession: I usually don’t have 30 minutes to pore over the resume, so it gets skimmed. The more I can get out of it in that time, the better. Again, this is my own opinion, but I think that as you’re describing your employment history, it works much better to tell a story. Try something like this:

Test Engineer, Acme – 2003-2007

Technologies applied: C, x86 assembly, AnvilTestKit 2.0

I helped optimize Acme’s processes for testing new anvils to bring to market. My team accomplished this by writing automation software on the AnvilTestKit platform and developed the anvil testing industry’s first interface with the Suck-O-Vac system to safely automate cleanup of debris after testing the anvil’s effectiveness. 

See how well that reads? Instead of being some dry list of technologies and buzzwords being strewn all over the place whilst awkwardly trying to avoid using the word “I”, it actually tells a story about the things you actually made (something I personally care a lot about) as well as the technologies you accomplished it with and in what capacity. This gives me a much clearer picture of how familiar you actually are with these languages and technologies. I’m not wondering whether you used C every day of your career there, or if it was just used once when you wrote some random one-off script.  

It’s really popular now to include your GitHub profile in your resume. Some companies actually require it and are using it to determine whether to hire you. I personally don’t place a ton of value in them because I think your best work is probably what you did for your employer (plus I don’t have many projects on GitHub), but if you do include it, I will look at it to see if you actually did something. If all I see are a bunch of forks of others’ projects with few changes, that doesn’t tell me much. Some employers might be using the profile to learn more, though; I don’t know. Perhaps they look at what you starred or issue discussions you’ve contributed to in order to see how you handle yourself. If your GitHub profile isn’t impressive in a way that will push the needle forward for your consideration, keep it out.

Personalize each resume you’re sending out. I sometimes read about some schmo who applied to 300 jobs and didn’t get one call back. If you carelessly fire off your resume to a bunch of employers at once without really researching, they’ll in turn fire off a nondescript rejection letter. Good companies to be an engineer for are really excited about what they do (even if they do something kind of boring) and they’ll let their company culture show in their job posting or on their web site. 

Finally, use the cover letter to your advantage. If you’re doing enough research about a company you’ll have a good understanding of the things they value and maybe even have some insight into how they work (maybe they use a particular Agile methodology, perhaps they pair, maybe they’re remote, etc.). The cover letter’s a great time to casually mention your enthusiasm for things they do. It’s also a good opportunity to be a little more human. If you’re scared to talk in first person on your resume, you can get a bit more warm and friendly in the cover letter. Stay objective, though. Don’t use bullshit descriptors like “team player,” “self starter,” “motivated,” “dynamic,” etc. Instead, talk about things like what your philosophies are on writing good code. Do you value peer review? Mention it. Do you subscribe to the church of test driven development? Mention it! It’s absolutely possible that some of these things are deal breakers for your would-be employer, and maybe they do things that would be deal breakers for you. As engineers we’re blessed right now with a very strong job market giving us the luxury of being able to be a little pickier about the jobs we take, and I consider it a luxury from an employer’s perspective too, because I don’t want workers clinging onto a job that isn’t right for them because it’s so damn hard to find another job.

Ultimately, it’s your resume’s job to get you the interview. If you’re a competent engineer your resume should reflect that (you can’t resume yourself out of incompetence or lack of experience). The tone should come off as friendly and eager to chat, but not so comfortable you seem cocky. It’s the interview’s job to determine the less tangible things, like whether you’re a good culture fit (something I can tell within about a minute of starting to talk to you), details about what you did in previous jobs, or how good you are at technical questions. But until that interview happens, you’re only as good as the resume in my inbox.