When I talk to people who are about to start the application process for a tech job the vast majority of them are stressing out about the technical portion of the interview. They definitely have good reason. Look at all of the marketing in the margins of any tutorial website you visit to help get you over the hump of something you’re not quite grasping: There’s a ton of ads telling you how to ace the interview – ‘These are the questions that Google interviewers ask’ – ‘If you can answer these questions you’re ready to be a software engineer’, etc. -Obviously I’m paraphrasing horribly but I think you get it (If anything, those ads are way worse about trying to sow the seeds of doubt into your own ability as a programmer). The thing is: There’s some truth to it, but it’s not nearly as tough as they’re making it out to be.

I work as a software engineer now. I’ve done interviews. I’m sure there are companies, or individuals in companies, who live up to the nightmarish picture ‘Mega-Elite Coder Prep 1000’ is painting. I’d argue that you most likely don’t want to work for that company anyway. Remember, it’s a two-way interview.

In an interview, I don’t want to see the interviewee complete the challenges we’ve laid out like they peeked at the solution before they walked in. I also don’t want to see the person sweat and stress out unnecessarily. That’s awkward fo all of us. We’re looking for how you solve problems. Not problems you’ve rehearsed dozens of times. We want you in unfamiliar territory to see how you orient yourself. What questions are you asking? Do you have a methodical approach to breaking the problem down and finding a solution? It’s far more impressive to see someone get stumped and reason their way to a partial solution than to ask a question and watch an applicant immediately code out the solution without so much as an explanation for why they’re doing what they’re doing. Why is that? Because no one, absolutely no one, knows everything. You are often going to be figuring things out as you go and we need to see that you’re capable and comfortable with that (within reason, no one likes being stumped).

So, that brings me to the real point I’m trying to make here. With all the fretting people are doing over recursion and Big O, behavioral questions often don’t get enough attention. At my company, and many companies that my friends work at, behavioral questions are just as important, if not more important than technical. I had been coding for 10 months when I applied at my company. I barely knew anything. I must’ve done well enough on the technical portion because here I am. I nailed the behavioral though and my company places a premium on cultural fits. Think about it: Do you want to have to spend 8-ish hours a day with someone who can’t carry a conversation? With someone who’s a jerk? With someone who doesn’t know how to work with a team? Hell no. It sucks and it’s bad for productivity (In a former life I was in the army).

So, here’s my advice:

You need to have canned responses to common questions like: Tell me about yourself, What is your biggest weakness?, Tell me about a time you had to deliver bad news, Tell me about a time you worked on a team. There are good resources out there for common questions. (The bad news question was a rough one for me to think of but I pulled it off fortunately) Your answer should be clear, delivered naturally and under 2 minutes. And don’t be afraid to finesse your answers while remaining as truthful as possible (helps with natural delivery). I’m not looking for you to have an experience that fits perfectly into every question I throw at you but I am looking for you to tell me that you understand what we’re looking for without explicitly telling me that. 🙂

This next one’s a big one. Remember, it’s a two way interview.

ALWAYS ASK QUESTIONS WHEN THE INTERVIEWERS ASK IF YOU HAVE QUESTIONS. Ask things like: If I was to get hired, how would I know that I’m progressing as an engineer?, How would you describe the culture of this company?, (and I’m going to put you down on some game here) If you could change one thing about this company, what would it be? (It’s their turn to sweat a little). Asking these questions does two things: It allows you to further communicate qualities that you know they are looking for and it’s your way of learning about what it’s actually like to work for that company. They may not be a fit for you, not the other way around. You’re about to be a software engineer. Know your worth.

And that’s my TED talk.