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:

1. 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.

   If you know me in real life and want me to do a mock interview for you, my going rate is dinner at Fuki Sushi if you're in industry, or at Pizza My Heart if you're a strapped-for-money student.

    

2. 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.

    

3. 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 so smart.

   Other things that I recommend against saying:

   • "Wow, you're really my interviewer? You look so old!"
   • "Wow, 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.

    

4. 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.

    

5. When answering questions expecting a specific answer, give a high-level summary first.

   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?"

6. (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

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 (do you blame him?). 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.

Original story