Having interviewed, coached, and sat on hiring committees with many candidates during my three year tenure at Google, I’ve learned a lot about what works and what doesn’t. I conquered the interview process after failing once before and, even then, I thought it could’ve gone either way. With tons of stuff to study, it’s hard to figure out how to prepare. Even really smart people can fail if they don’t have a good plan for what to do when they get into the room with an actual software engineer and a whiteboard.
So, I’m going to share six tips I believe you absolutely need to nail your interview. After you check these out, watch this sample interview video conducted by Google engineers.
1. Repeat the question in your own words
As soon as you hear it, repeat it out loud. Do this preferably in your own words to demonstrate your comprehension. Remember, your interviewer is there to assist you, so repeating the question aloud will only serve to make their job (and yours) easier.
This will also buy you some time to think about what you’ve been asked and develop good questions or approaches. Plus, hearing yourself restate the problem might help you think through it more clearly.
2. Check assumptions
Many candidates start writing code almost immediately after hearing the question. This is a big mistake. Most coding questions have some level of ambiguity built in. Have at least two or three questions ready so that you can confirm you have all the necessary detail to solve the problem. You can also write out confirmed assumptions on the whiteboard (do it in small print to save space). Questions like “does input fit in memory?” or “can I assume input is always valid?” are good candidates if you can’t think of any at first.
3. Use real examples
You’ve got a whiteboard—use it! Draw out an example array, a binary tree, a linked list, etc. Give it real data and write out the expected output of a working solution. You should practice coming up with good examples as part of your study regime (you do have one, right?). Using a visual example also gives you opportunity to think up more questions and your interviewer a chance to correct your assumptions. Don’t forget to keep thinking out loud as you work through it.
If your interviewer provides examples, use those since they probably exist for a reason. This is also how interviewers will point you towards problems with your design or implementation.
4. Brainstorm solutions and their time/space complexity
Stop and think about various approaches. If you’ve put in time studying algorithms and data structures, this is where it really starts to pay off (Cracking the Coding Interview, anyone?). Think about trade offs using Big-O analysis and think out loud. Don’t stop with the first solution that comes to mind. Always ask yourself what’s the best you can do. Trust me, we always will!
Tips: Don’t forget the space–time tradeoff principle. Wanna go fast? Use more space. Also, hash tables people! And learn how to think graphs—including trees. If all else fails, recursion, backtracking, and memoization are useful tools on particularly difficult problems.
5. Write working code (no pseudo-code please!)
You might normally use pseudo-code to design your code, but you don’t have time for that in a 45-minute interview. Choose your strongest language and turn your thoughts into working code as quickly as possible. This should be the easiest part of the interview assuming you’ve put time into practicing without an IDE (seriously, don’t use an IDE to practice for the interview unless you’re compiling code you’ve already written out). Make sure to practice using a whiteboard or just use pen and paper.
6. Test your code, always
Now turn your brain into a compiler and execute each line of code to ensure you don’t have any logical bugs. Use the whiteboard to keep track of variable state as you iterate. Also, use the example(s) you created earlier and confirm that you get the expected output. Testing is crucial in software engineering, so never make the grave mistake of leaving this step out.
Practice makes perfect
It took nearly an hour and a half to finish a coding question when I first started using these six steps. After a month and a half of daily practice, I could solve most questions in about half an hour. Nothing takes the place of putting in the time to prepare for the interview until you’ve developed the muscle memory to execute these six steps perfectly. Is it worth it? I’d say so.
This post originally appeared on LinkedIn. Find more tips at anthonydmays.com.
Top comments (10)
Reminds me of Wargames: The only way to win is not to play.
I have promoted the idea of giving applicants tests, and you can see an example of this here in my articles. So don't get me wrong, I think seeing the output from coding is important.
However, the described approach to interviewing says something about the intellectual insecurities and immaturity of those conducting the interviews. An interviewer is in a position of power over the applicant, but at the same time experienced developers are sitting in judgement of the company and it's representatives.
For me the code portion can be done in private, that is they can be left alone to complete it in their own time. I usually give them a couple of hours to complete it, but in fact the task given is designed to be completed in just over half an hour. Generally I'm unconcerned about the time taken so long as it isn't over time.
Once completed we have a casual chat about their solution and why they decided to code it that way. It should be a relaxed environment where they are at ease. The point of the interview is to evaluate how they will function in the team, how they communicate. How well can they communicate the reasoning behind their implementation? It is most certainly not an opportunity to prove how vastly intellectually superior you are by having them answer brain teasers.
The interview is also an opportunity to show them how you function, to give them a good impression about you and the potential job they are applying for. If you make it a terrifying ordeal you are setting a poor example of how the business operates and how it treats staff.
Black Belt gradings in the martial arts are an ordeal. They are designed that way because we want to ensure they have meaning. Only those with the mental and physical fortitude can make the grade. A job interview is not the professional equivalent of a Black Belt grading.
I understand Google and other companies might behave like it is, but they are not doing themselves or their applicants a service. In fact they might be missing really awesome applicants because of this style of interview.
Thanks for the feedback, Peter. I agree that a job interview should not be a terrifying experience for anyone. It also makes sense that, if you want to see people working at their best, that they should be assessed in an environment where they are psychologically safe.
Speaking for myself, I disagree with the premise that the Google interview is inherently a terrifying experience. Google trains interviewers on how to properly conduct interviews to ensure that the experience is as positive as can be for interviewees, and interviewees are given the chance to provide feedback on the process to help ensure that things are done fairly and equitably. Interviews in generally can be a stressful experience by nature, especially if you are not well prepared. That's why Google provides prep materials and other resources like techdevguide.withgoogle.com to help people hone their skills.
I recognize that Google's hiring methodology may not work well for other companies depending on their needs. Ultimately, I see the Google interview testing the same problem solving and communication skills that I use with other Google engineers nearly every day. It is rigorous and challenging, but so is the job.
PS: Google stopped using brainteasers years ago. I made the mistake of believing they still relied on brainteasers in 2011 and failed to prepare properly as a result. Unfortunately, this myth continues to persist despite the reality.
Good to hear they stopped the brain teasers. A few years ago I had a developer tell me they had actually interviewed with me previously and failed. It seemed my own interview method resulted in a good candidate being excluded.
Developers tend to invest in their own intellect and ego, and so we must guard against an unintentional approach which signals the superiority of the interviewer over applicant.
I sincerely hope Google or others are not quite as intimidating as it appeared to be described.
Here, here. Even after I failed the interview in 2011, I still enjoyed the process and became a better engineer as a result. Of course, Google has some jerks same as any other company, but they are definitely the exception and not the norm.
I love the people I work with at Google, and that's easily the best part about working there. A non-trivial number of us either have struggled or continue to battle with imposter syndrome actually!
I know several very good developers who have rejected offers from Google, Uber and the likes for conducting interviews like the one described at the post and decided to give it a try with less known and smaller companies for conducting the interview like you have said. When I asked one of them "why reject Google?" the answer was:
After talking to people like that I changed my mind about interviews and when I was the one interviewing someone I have always tried to do like you said with extremely good results.
At the end of the day in our industry the law of supply and demand is on the side of us, software engineers, because companies need more of us than they are available and thus an interview is not only for the company to see if the person being interviewed is good for them, it is also for the one being interviewed to see if he likes the company and the people and culture there.
Thanks Anthony for sharing the know-hows.
I've summarized what I've learned below. Would you let me know if I got the gists correctly?
Repeat the question in your own words
Understand the question.
Check assumptions
Think of all edge cases
Use real examples
Walk thru your algorithm with real data manually.
Brainstorm solutions and their time/space complexity
Optimize your algorithm using data structures/algorithms and comparing tradeoffs
Write working code (no pseudo-code please!)
Get your hands dirty with real code writing.
Test your code, always
Iron out bugs and use your examples/edge cases to test your code.
btw, the Medium seems to be 404...
Yup, you got it. And link fixed!
I'll add that in step 5, you want to learn how to express your thoughts in code quickly. Come with a lot of practice or hands-on experience.
I appreciate the confirmation & clarification, Anthony~
And here is ✋5️⃣
Just my name (a-mays-ing). Grateful to serve!