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.