[A guest blog post for Geeklist by Gayle Laakmann McDowell. Gayle is the founder / CEO of CareerCup, and the author of Cracking the Coding Interview (Amazon.com’s #1 best-selling interview book) and The Google Resume. Gayle has worked a software engineer for Microsoft, Apple and Google, and served on Google’s hiring committee. You can follow her on Twitter, Facebook, Quora, or her blog.]
We’ve all heard the scary stories about Google interview questions. What would you do if you were shrunk to the size of a nickel and stuck in a blender? A man pushed his car to a hotel and lost his fortune — what happened?
The good news is that most of these questions are fake. The bad news is that the interview questions at top tech companies can still be really tough, especially if you aren’t expecting such questions
What to Expect in a Technical Interview
A typical interview for software engineers at top tech companies will be based in coding, data structures, algorithms, and system design questions. For example:
“Given two nodes in a binary search tree, find the lowest common ancestor of the two nodes.” — Amazon interview question
“Describe how you would implement the tinyurl.com website.” — Google interview question
“Given a cube with sides length n, write code to print all possible paths from the center to the surface.” — Microsoft interview question
“Design the data structures and algorithms to detect typos in a document and then provide suggestions to the user.” — Facebook interview question
These questions are designed to test your knowledge of computer science fundamentals (namely data structures and algorithms) in addition to your problem solving and coding skills.
And yes, experienced candidates should expect to go through a very similar set of questions at the top tech companies. They will not assume that you are an excellent coder and problem solver simply because you have many years of experience doing this. Sorry!
How You Will Be Evaluated
I frequently get emails along the lines of, “I was asked only one question at Microsoft and I got it right, but I still got rejected. Why?” There are at least two major issues with this question.
First, your interview performance can rarely be evaluated on a binary correct / incorrect basis. Instead, your interviewer will look at aspects like:
- How efficient was your algorithm?
- How well did you understand the tradeoffs between different choices?
- How well did you communicate those tradeoffs?
- How long did it take you to develop your algorithm?
- How clean / readable / maintainable was your code?
- How well did you test your code? How buggy was it?
- When you found bugs in it, how did you go about fixing them?
None of these areas can be evaluated on a binary basis, let alone the entire interview.
Second, your interview performance on each of the above areas is evaluated relative to other candidates on the same question. That is, when I consider how quickly you solved the problem, I don’t ask if 15 minutes is fast or slow in general. That wouldn’t make sense. It might be really slow for one problem and really fast for another.
Instead, I compare your performance to other candidates. If it’s unusual to have a candidate take less than 20 minutes, then 15 minutes will be great performance. If most people can get the problem in 5 - 10 minutes, then 15 minutes will be considered quite slow.
So why did you get rejected even though you got your one and only interview question correct? Because “correctness” isn’t exactly an evaluation criteria, and because it might have taken you a very long time to solve the problem.
How to Answer Questions
You do not need to immediately spit out the right answer. I repeat: you do not need to immediately spit out the right answer.
When you get a technical question, try this approach:
Step 1. Ask questions
Make sure you actually understand the question you are asked. Validate any assumptions you might have. For example, is it a binary search tree or just a binary tree? What type is the array?
Step 2: Talk Out Loud
Did you read that first line? You’re not expected to immediately spit out the perfect solution. That’s just not feasible, for the vast majority of interview questions.
But you should start talking immediately, if at all possible. A brute force solution is a good place to start. Show your interviewer how you’re thinking about the problem. Brainstorm.
Step 3: Really think through your approach
Okay, you came up with an algorithm. Excellent. Is it a good one? What are the tradeoffs of your approach?
Remember that your interviewer may have asked this problem dozens of times. If there are issues with it, your interviewer knows what they are. You’re not going to be able to get away with pretending your algorithm is perfect when it’s not.
Step 4: Code (slowly and methodically)
Whiteboard coding (yes, you will more than likely have to code on a whiteboard) is not a race. You are not being judged at how quickly your hand can move across the board.
Candidates do get rejected for poor coding, but it’s not because they wrote too slowly. It’s because they stumbled through their code too much and make too many mistakes.
Start coding in the upper left hand corner (the far upper left hand corner). Write small — you’ll need the space. And watch for “line creep” — when your handwriting drifts downwards at a 15 degree angle.
Take your time. Breathe. Think about what you’re doing.
Pseudocode is not sufficient for most interviewers (though some will be okay with it). However, if it helps you, it’s fine to first write pseudocode as long as you’ll follow it up with real code. In this case, you should tell your interviewer that you’ll write real code afterwards; you don’t want them to think that you’re one of those “pseudocode-only candidates.”
Step 5: Test and Fix (Carefully!)
You wouldn’t check code in without testing it first (I hope!), so why are you avoiding testing in an interview?
After you finish your whiteboard code, test it. Run it through with base cases, extreme cases, and general cases.
When you find bugs (and you will!), that’s okay. Even the best candidates have some bugs in their code. Just take your time, think about why the bug occurred, and then fix it. Don’t race to put in just any ol’ fix. It might fix that bug at the cost of creating many new ones.
Remember: if you don’t know how to solve the problem, that’s okay. Even the best candidates don’t know how to solve most interview questions immediately. You’re not expected to – really!
When you get stumped, brainstorm and discuss different approaches, even if they’re “bad” approaches. Your interviewer wants to see how you’ll approach the problem, so walk him/her through your thought process.
Struggling does not mean you’re doing poorly. On the contrary, it could mean that you’ve been doing so well that your interviewer asked you an extra tough problem.
Breathe. Think about what you’re doing. And do your best.
- Gayle Laakmann McDowell