I can't has cheezburger

Since my post on making a great resume was so incredibly well received on Reddit, I don’t want to leave you hanging now that that kick ass resume got you an interview.

Bottom line: the best interview is going to flow a lot like a conversation between new friends. Mixed in with this conversation will be me grilling you with some technical and problem solving questions.

Feel at ease. I want this interview to go well just as badly as you do (because then it means I don’t have to do more interviews!). It’s okay if you feel a little nervous, though. In terms of attire, every person interviewing has their own tastes but as far as I’m concerned you could walk in wearing a T-shirt and jeans and I wouldn’t bat an eye. In fact, I’ll be more skeptical of a suit wearer.

Enthusiasm is a big deal to me. I want to see your eyes light up as you describe your career to me.

You need to be superior at articulating your thoughts. Most engineers are bad at this. If I ask you a hard question and ask you to talk it out, I really fucking mean talk it out because that’s what I’m evaluating. Incoherently rattling random words as you scribble on a whiteboard might yield you a correct answer to the problem, but what do I do when we’ve got a real problem on our hands and I need to talk it out with you?

If you can’t articulate your thoughts in a way that others can understand, you’re probably not a good engineer. It was Einstein who said “if you can’t explain it simply, you don’t understand it well enough.”

If you’re weak at this, practice articulating your thoughts verbally with your colleagues.  Peer review code with your colleagues and talk (or write) out your likes and dislikes. It’s not enough to see a code smell and recognize it. When you can look at the code and say “I see varying levels of abstraction being used in this method. Let’s extract the lower level stuff out for clarity,” that’s good articulation.

When I ask you for your background, don’t recite to me a chronology of your employment history. I love the objectivity, but you’ll sell me better on your ability to articulate your thoughts if you describe your career to me in trends or describe the patterns/progressions your career has taken, and interleave that with concrete instances of things like jobs or projects. Watch how it changes how you sound:

First I worked at A Corp doing C code with Project M, then I worked at B Corp doing more C code with their project MX, then I worked at AB Corp working on C#, then…zzzzzzz….

compared to

I started out with simple bug fixes to the code base at A corp, but as I moved on I really learned I have a knack for improving reliability of software through breaking the code down and into tests, so I took a job at B Corp and helped reel in project MX. I continued to apply those skills in the C# language at AB Corp, and–whoa, is that a job offer already? I just got here!

It makes a difference.

Even more important than your articulation is your ability to actually write code. I am surprised at the number of candidates with years of experience on me who trip up at the simpler programming exercises I give, like fizzbuzz. Even worse: mocking the question as if it’s beneath you (only to answer it wrong).

I often ask a bunch of trivia questions that are things you either know or you don’t. If you don’t, don’t feel bad; it probably won’t be a deal breaker. If you don’t know the answer, try to describe what you do know. For instance:

Q: Does ruby have multiple inheritance? If not, does it offer something similar in its place? # it doesn’t; but it does offer mixins

A1: lol, idk # …

A2: Hmm, I’ve never encountered it working with in Ruby. I know in Python you can do it by listing the superclasses separated by commas. I usually put shared code in modules since you can include many modules in many classes.

Oh, and remember when I said the interview should go kind of like a conversation? I do want to hear questions from you. In particular, I want you to be asking me how our team’s development cycle works. Do we do stuff in sprints? Do we pair? Do we force you to use Vim? Who deploys code? How does an idea get turned into a live feature? What works well about our development process? What doesn’t?  If you don’t care about what your work environment would be at this company, what do you care about?

Ultimately, just be yourself during the interview and that’ll help your interviewer(s) make the best decision. Don’t feel intimidated by being a newbie. Smart companies hire a good mix of junior and senior people. Regardless of skill level, culture fit is a big deal to me. Culture fit doesn’t mean it’s a popularity contest. It’s about your values and what you find important.

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.