Top Tips on Nailing the Technical Interview from ex-Amazon & ex-Google Engineers
The biggest mistake that software engineer candidates make when interviewing at top tech companies? Thinking that finding a solution is the only thing you’re being evaluated on.
We sat down with Carrus Coach Teresa Fung, ex-Amazon Interview Bar Raiser and Engineering Manager, and Carrus Coach Phil Verghese, ex-Google Engineering Manager, for insights on how to truly prepare for what interviewers at top tech companies are looking for.
Read on to learn what to expect, what interviewers are looking for, mistakes to avoid, and how to prepare!
You might be wondering how long the technical interview is, how many questions you’ll be assessed on, and how many parts are involved in the process.
And the answer is that it could vary from company to company. Some might give you a problem to solve in advance that requires time to formulate your answer, whereas others might ask you questions right on the spot.
At Amazon in particular, any candidate regardless of the role will have both soft skill and hard skill interviews as part of the “loop”, which is a full day of 4-6 interviews on site. The content of the hard skills technical interview will vary role to role, so marketers will be assessed on marketing-related skill sets in the same way that software engineers will be assessed on their skills and problem-solving capabilities.
“At Amazon, you’ll receive your question on the spot and it’s not a problem that requires an hour to solve. The technical interview is approximately one hour, which included both behavioral questions as well as the technical question. So, you can expect the technical question to be 20-25 minutes of that session, which includes receiving the question, sharing your thoughts, collaborating with your interviewer, and sharing your solution.” says Teresa.
At Google, you can expect to have an initial technical phone screen where you will write some code during a 45-minute interview. If you pass that, you’ll be invited to an onsite interview that takes place over the course of the day with 4-5 interviewers that will assess both your technical and soft skills.
“The nature of the interviews partly depends on the level of experience and job you’re going for. If you’re a junior person, you might be asked mostly coding questions. If you’re a little more senior, you might also get a system design question. For a system design question, you will be asked to design a solution that solves a difficult engineering problem (without having to write the code for it).” shares Phil.
Here are the four key elements you’re being evaluated on (as an Engineer at Google from Phil) that are good to keep in mind no matter where you apply:
“Your interview is not an exam!” Teresa reveals.
“90% of people research the interview questions from top companies, the solutions, and then practice working through problems. That’s good, but people overlook the importance of the behavioral side which is the delivery of the technical solution. Interviewers are not just wanting to receive an answer from you, but understand how you reached your solution.”
“The interview is not an exam in the sense that you do not take the question away to another room and then come back with an answer. Can you explain the problem back to the interviewer? What other alternatives did you look at? How did you evaluate the best answer? Why did you come to this specific solution?” she continues.
Phil also shared the same position. In fact, it’s even his #1 tip:
“My number one tip is don’t think of the interview as an evaluation! Try as best you can to think of the interview as an interaction with colleagues. Imagine this is a real problem and we have to solve it together. As much as you can, treat the situation as a conversation with a colleague.”
The purpose of focusing on the behavioral elements of the interview is that interviewers want to have a clear understanding of what it would be like to work with you, so they are looking beyond whether or not you can find an answer to the problem.
There are two things that can prevent you from passing your interview, even if you’re a great candidate: not asking any questions out of fear, and not clarifying the problem.
“People are so nervous and think of it as an exam and they’re getting questioned. Candidates are scared to say the wrong thing so oftentimes they won’t say anything other than, ‘Is this what you’re looking for’. The more you feel like you’re just at a regular work meeting, the higher chance for the interviewer to get good data points,” Teresa explains.
Phil has had very similar experiences:
“It’s almost 50/50 in terms of people asking/not asking questions. I feel that people think it’s that a test and that if they ask questions it shows they’re dumb or didn’t pick it up right away. But maybe the interviewer didn’t explain the question well or glossed over something and the candidate needs more explanation. Always feel empowered in making sure you understand.”
Fear aside, make sure that you don’t start solving until you’ve clarified the problem!
“Sometimes, there have been candidates who are very experienced and have high technical skills, but they jump into solving the problem based on assumptions. If they don’t initiate dialogue to validate the assumptions, they may end up solving something else. What’s important is not that you have delivered a working solution, but that you solved the right problem.” says Teresa.
As an example, let’s say that your question is, “Google wants to award 1 million dollars to the 1 millionth visitor to the website this month. How can we make the technical implementation work for that?”
Before you go about answering, think of the questions you can ask for clarification. Is this worldwide? If so, what time would it start? What exactly counts as a visit to the website?
“One other thing to keep in mind is that at the end of your interview, you’ll be asked if you have any general questions. Don’t be shy to ask about what you want to know, like what it’s like on your team, how the team makes decisions, or what their work life balance is like. It can feel awkward sometimes as an interviewer to allow time at the end for this and receive no questions.” Phil adds.
“You can practice difficult problems from these websites, but there’s no need to obsess over them. Instead, make sure that you understand data structures and algorithms really well, that you are confident in your programming language, and that you’re comfortable writing code without the help of an IDE.
“Also, one of my tips for preparing for an interview is to think out loud. Thinking out loud helps the interviewer understand your thought process and they can even help you if you’re not on the right track. If you’re silent, the interviewer might not say anything so as not to interrupt your thought process.” says Phil.
One tool you can use to help you practice thinking out loud is Rubber Duck Debugging. This is a concept where you speak your thoughts out loud (to a rubber duck) and hearing yourself talk helps you come to conclusions.
If you choose to use a person for practice – even someone who doesn’t know anything about coding – all that person has to do is ask you “Why” to help you get more detailed in your thought process.
And from Teresa,
“When people ask about what to practice, first I say to brush up on technical skills. When we meet, we discuss beyond the code. Since it’s important to focus on the delivery of your tech interview, practice doing mock interviews with a coach on your tech questions. Don’t just focus on the [Amazon] Leadership Principles, but also do a mock interview for your technical role.” says Teresa.
In a nutshell, here are the key tips our coaches recommend you keep in mind:
Ready to practice and prepare for your interview? Make sure you reach out to Carrus Coach Teresa and Carrus Coach Phil to work with them in helping you succeed! [Get matched](https://carrus.typeform.com/to/EKSupN?) with a coach today.