Technical Interview Advice for New and Aspiring Engineers

26 April 2015

New and aspiring software engineers frequently ask me for interviewing advice, and it puts me in a bind every time, since it takes 10 minutes to give a responsible answer. So here is my advice, in blog form:

I could give you advice on how to get a job at my company, but that same advice might be terrible somewhere else. Not only do most companies do a terrible job at assessing technical candidates, they all go about this terrible job in radically different ways.

Take, for example, the way you are interviewed. Google might sit you down in a face to face conversation and ask you to draw something on a whiteboard. Facebook might give you a small program to implement in an hour. Another company might do the same, but with no time limit. I’ve heard of technical ‘interviews’ in which you come and work for the company for a week, with pay! Some happen entirely through conversation. Some involve pen-and-paper intelligence tests (yes, really). At Braintree I’m proud to say you’ll actually sit down with another engineer and (gasp) write some code together on a computer.

That’s not the end of it. Not only does every company interview in different ways, but they all look for different things in the interview. Some companies won’t ask about your resume at all; others will obsess over your past accomplishments. Some companies want to make sure you know the languages, tools and APIs they use. Others could care less and assume you’ll pick it up as you go. Some companies care deeply about communication skills and personality. Others focus only on a candidate’s technical ability. Some emphasize computer science theory; others emphasize practical experience. And so on.

Given such variety in technical interviews, what should an aspiring developer do? Clearly, you can’t be amazing at everything. The short answer is: it depends on where you want to go.

If you want to work at Google, spending more time on algorithms is probably a good idea. If you’d rather go to a startup, a portfolio of projects on GitHub might be better. But it also depends on the startup and it depends on the Google. As usual, your best bet is to do some research and prepare ahead of time.

And, do you want to know a secret? All this variety is really, really good for you.

Hiring is the most important process a company has. Few other experiences provide as much direct, substantial insight into the soul of a company than going through its hiring process.

Did they want you to be smart, energetic and ready to do great things, or did they just check if you knew jQuery? Did you meet the whole team or just a single hiring manager? Were they welcoming and friendly or impersonal and cold? What did they ask about? What did they care about? These are the questions you must ask yourself after an interview.

If you don’t like the answers, don’t take the job. Once you realize that you’re interviewing them as much as they are you, the whole thing doesn’t seem as bad.

Oh, and don’t worry so much about algorithms.

(Now that you’ve read some of my advice, you might be interested in why I think most advice is problematic.)

comments powered by Disqus