Making a good engineer résumé

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. 

7 responses to “Making a good engineer résumé”

  1. Martin says:

    Interesting blog post, I have one thing to add though. You are not always sending a CV to a technical person, most the times it’s to a recruiter who in turn sends it to HR then on to a hiring manager.

    There’s a smiley guy sitting in front of you. A recruiter, specialising in IT (why? don’t ask him, he truly doesn’t know). He will gladly grab your carefully constructed LaTeX CV, will grill you on every technology you know, nay have heard of, listing it without context, devoid of any understanding on his part. Soon you will be a dynamic, go-getter, team player who can drive and bring products into the mobile social cloud age – and god damn will you nail that somewhat junior role he has lined you up for you. Before you know it you’ll hate this one page of A4 that, apparently, defines you and your career (not to mention the smiley smug buffoon responsible for this abomination).

    This steaming pile of bull will then be delivered to HR who will ooh and aah and treat your CV like a word search – circling this and that and counting buzzwords. But at least they love that you are “mobile social cloud”.

    Now to the hire manager; you turn up and get asked how “many car salesmen live in the south of France?” or “Why are manhole covers round?” or “How to get an elephant into a refrigerator?” – important stuff – he read that Google asked these questions, how could he possibly go wrong?

    Anyhow, you’re now luckily all aboard the merry train to employment-ville, population++. You are an award-winning show dog, the master of navigating the hoops of IT recruitment. Your reward, a paycheck to maintain a badly written CRUD app for the storage industry.

    (I must say that this turned out more ranty than I expected, sorry for wasting anyone’s time – guess who is regretting their comfy contract finishing?)

  2. My friend, you have the kind of personality who made me leave the enterprise software development world and start my own company, exactly to avoid having to deal with arrogant and superficial people like you:

    > like whether you’re a good culture fit (something I can tell within about a minute of starting to talk to you)

    Try to be nicer, it pays off!

  3. Robert says:

    This is quite good. I think key words could also go right in the end of the resume so that the electronic scanners they have catch them anyway. But tailoring for each company, is a good idea I think. It is better to do extra research on a company than too little.

  4. aaron says:

    Sorry, I wasn’t trying to convey that I am making snap judgments about people when I first see them; I meant to highlight the differences between what a resume can tell me about you and what should best be left to the interview. Your resume can never truly communicate to me just how excited you’re going to sound talking about your career writing code, or how articulate you are; it’s just a piece of paper, but just a little bit of face time will, and it’s always surprised me, but usually the first minute of chat leaves me with a very similar picture to your culture fit as the whole interview.

  5. aaron says:

    Totally true. Every single person reviewing a resume has different preferences and if you ask 1000 of them for advice, you’ll get 1000 different answers. It’s entirely possible that following my advice will land you a resume that only I would like. Usually the job posting will give you a good sense of whether they’re looking for a BS-ridden resume or if they want one like I described. If you feel naturally inclined to make a corporate-stooge looking resume because that comforts you or you feel less afraid doing that, then you’d probably be more comfortable in a corporate stooge kind of job (and from the bottom of my heart there truly is nothing wrong with that).

    Recruiters are like car salesmen, in that they have a great inventory of what you want, but you have to deal with them to get to it. Right now it’s an employee’s market for software engineering so companies are going to recruiters a lot just because a recruiter can bring you half a dozen candidates in a one week timespan, saving you months. Usually means I have a shit resume to look through so I end up erring on the side of caution and interviewing.

    If you’re a really talented engineer (like 75th percentile or higher) look at a startup (I work at one). Most companies have shit software that doesn’t need to be that fancy and they can hire mediocre engineers to maintain that (no company will ever tell you that, though; every company is always allegedly on the hunt for A players!). As an engineering lead in a startup, I can tell you that I place an incredible amount of pride and importance in building my team. Granted, I don’t have thousands of resumes to filter through (yay for a tough market to find engineers!), but building a team is quite possibly the most important thing I do at a startup that’s growing, and I can’t afford to make a bad hire. As a result, my hiring process (and that of most startups I know) involves cutting out the bullshit and just figuring out if 1) you’re ridiculously smart and would be humbling to work with, and 2) that you seem like a person who I’d be willing to spend a few late nights with before a deadline working like a pit crew to ship.

  6. aaron says:

    If you’re looking to work for a company that indexes resumes like that, it would do you well to not take any of my advice (aside from the grammar stuff) because that company values entirely different things.

  7. Jon says:

    This is a perfect article. I’m glad you called out dry cut shit that most engineers write down. I will definitely be taking some of your advise and applying it.

Leave a Reply

Your email address will not be published. Required fields are marked *