Preparing For a Software Engineering Interview

Update July 2015: My company Evertoon is hiring an Unity3D engineer!
Evertoon is a mobile platform that enables users to make an animated
cartoon movie. See the job description!

You've used your killer resume to land
an interview with a great company. Now how should you go about preparing?
Of the 300+ software engineers I interviewed for Google (and previously
Microsoft), some of them really shone, and others seemed ill-prepared.
Many of the ill-prepared ones still got offers because they're obviously
stars, but it's safer and less stressful to prepare yourself beforehand. Below
are some tips that I've gathered over time:

Practice using the same medium (e.g. paper and pencil) and time limits
(e.g. 30 minutes) as the real interview.

Google and Microsoft both use whiteboard coding questions, yet often candidates
practice by coding alone at home on a computer with a compiler.
During the actual interview, they stand at the whiteboard and forget how to
initialize an array, without their trusty syntax highlighter. Or they are so
nervous having another person watch them that they panic and can't think
straight.

In real life, if you plan to swim the English Channel, would you limit your
practice to laps at the local swimming pool? No, you would go test out the
ocean waves, the salt water. Do the same here.

Ask your recruiter the format of the interview and any coding questions.
If the company gives the candidates an hour alone in a room
with an editor and no compiler, practice that at home. If the
company does whiteboard questions with an interviewer watching you, ask an
engineer friend to be your mock interviewer.
It's fine if the friend is a less experienced engineer than you -- they'll
still bring out your nervousness about making mistakes in front of others,
so you can practice getting used to that.

During the interview, don't obsess over little mistakes that happen.

On more than one occasion, when I gave a star candidate a coding
question, he zeroed in on the most optimally performant solution, identified
the boundary cases, and began writing well-designed code. Midway through
the problem, he makes a little error -- getting the order of operations wrong
on the first try, or having an off-by-1 error, or forgetting to declare a
variable.

When I point it out, the candidate responds with horror and then becomes
so nervous that it impacts his performance during the rest of the interview.

The fear is unfounded. An awesome candidate making a little error is like
a concert violinist playing a challenging Brahms concerto and hitting two
wrong notes. Sure, the audience could tell that he made mistakes, but they
don't get confused as to whether he's actually at Twinkle-Twinkle-Little-Star
level.

Even if you completely bomb one question, many interviewers ask you multiple
questions and will forgive a single mishap. Even bombing an entire interview
is recoverable if the other interviews go well.

Recently one of my coworkers (a tech lead for another project) interviewed a
candidate and was very curt because he found the candidate's
communication style irritating.
The candidate proved himself during the interview, and the tech lead
ended up being the strongest proponent for this candidate. He advocated
harder for that candidate than he has for anyone else in a year.

When things don't go well, just keep at it and don't give up hope.

Don't be rude to your interviewer.

This should be obvious, but I have been surprised. One engineering candidate
said to me, "Wow, I can't believe you're really my interviewer! You look so
young!! I thought you were 18! Once you told me your credentials, I
understand now, but at first I thought, 'This person is interviewing me?!?!'"

That wasn't very graceful.

Other things that I recommend against saying:

"You're really my interviewer? You look so old!"

"You're really my interviewer? You look so fat!"

Another time, the candidate's cell phone rang 15 minutes into the interview.
She let it go, and we were both distracted by it ringing for the next 20
seconds. 5 minutes later, it happened again. Another 5 minutes later, it
rang for a third time.

She finally reached for her purse and fumbled inside it for the phone.
"It's about time", I thought, "she should've turned it off before
coming in here." She dug the phone out of the purse and then proceeded
to take the phone call right there in the middle of the interview.

The only justification is if there is a family emergency, and in that case,
warn your interviewer explicitly at the start of the interview.

Don't hijack the interview.

I've had a couple of candidates who came into the interview with the mindset
that they MUST tell me all about their recent project Zoolander.
I start
the interview and they break in with, "I want to tell you about Zoolander.
10 years ago, this project started as a side feature..." and then go on for 5
minutes without taking a breath.

Sometimes they decide that they must tell every interviewer about Zoolander,
repeating the same description over and over during the day.

Your interviewer has specific questions that they need to get through. If
you hijack the interview, they may not have enough data from their own
questions to be able to endorse your hiring. They may also think that you
would be difficult to work with.

If you really want to talk about a project, ask your interviewer, "I
think project Zoolander really shows off my abilities. Can you or another
interviewer fit in 10 minutes for me to explain it?" The interviewer can
then refit their plan for the interview, instead of suddenly having
their schedule be shanghaied.

Sometimes I ask a question expecting a short answer, "How many people worked
with you on project Zoolander?" The candidate then gives me an
audiobook, "Well, there was Jimmy -- he did the UI and I had
to mentor him quite a bit on it. Then there was Mary who ran the backend
servers. She worked remotely from Pennsylvania. Two years later, we got
another backend person David..."

Three minutes later, the candidate is still talking, and I still don't know the
answer of how many people worked on the project.

Give an answer first, and then expound. "There were 3 when I joined, and 12
when I left. First there was Jimmy ..."

Better yet, give the answer and offer to expound. "There were 3 when
I joined, and 12 when I left. Would you like me to tell you what each one
did?"

(Not as important) Wear something comfortable to your interview.
Business casual is the most typical.

People sometimes wonder how they should dress. The most important thing
is that you feel comfortable. If you still want a recommendation, I
say a button-down shirt or even a T-shirt. A suit can come
off as too formal in some companies (e.g. Google).

This point is not as important, because people won't really care. You should
ask your recruiter about what to wear, since this differs by country and
East Coast / West Coast. A company like Google is more casual,
so if you come in a three-piece suit, your interviewers may raise an eyebrow.
If you've got the goods in terms of engineering skills, it's not a dealbreaker
though. One candidate came to an interview wearing a gothic mesh shirt with
holes through which his nipples were clearly visible. He still got the job.
(I don't recommend taking this risk.)

A final story

I'd like to leave you with a story of an unfortunate interview. Draw hope
that no matter how your interview goes, you will likely be more lucky than
this candidate.

At Microsoft, we always offered drinks to our candidates, and one candidate
"Jeff" took a pepsi. We got into my office, and he set it down on the desk.
We started discussing his experiences and then launched into the whiteboard
coding question, and he didn't get around to opening his pepsi.

We stood at the whiteboard, and Jeff started to write a line of code. He
stopped to think about the overall algorithm, and absentmindedly took a step
back in order to see the entire whiteboard. In doing so, he inadvertently
knocked against the desk, and the pepsi fell off the edge.

This pepsi was still unopened. Thus, when it hit the ground, it exploded on
impact.

Pepsi sprayed in foamy gusts in all directions from the can. It was a
slow-motion moment as beige spots of soda splashed onto my white walls, my
bookshelf, my keyboard. We both stood there frozen, our hands halfway out
(too slow to catch the pepsi), looking at the dripping liquid coating the
entire inside of my office.

We took a 5-minute break to get paper towels and mop up the mess. (Though
my books always stuck together after that day, and my walls were never the same
again.)

We then returned to the whiteboard question. Jeff was nervous by this time
(understandably). He wrote some code, erased it, wrote more. He erased
using his fingers against the board instead of using the eraser. Then sweat
formed on his forehead, and he wiped it off using the same hand. By the end
of the interview, his face was covered in streaks of red, green, and blue
whiteboard marker.

I said, "I think you have some marker on your hands. I'll show you the
restroom." and let the bathroom mirror show him the problem.