This is the third article of our guide to preparing for a Software Development Engineer (SDE) interview with Amazon.
In this post, we will go over a few tips for a successful coding interview at Amazon. This is based on my observations of conducting interviews for the past few years and from my own experience in interviewing with dozen of companies.
We also have a post about coding questions that can be expected for an interview at Amazon. To understand how to approach coding questions, check out our coding interview canvas.
Don’t only rely on your experience
Experience is not enough to pass a coding interview at Amazon.
I’ve recently conducted a mock interview for a candidate from New York on mocki.co. He had more than 7 years of experience in Mobile development. He struggled to come up with a naive solution to my coding question. He admitted that he had not practiced whatsoever before the mock interview. He felt like it was his first coding interview ever.
There are tons of good resources out there:
Focusing on the final solution too early on
Humor me by reading the analogy below (or just skip to the next paragraph).
The other day, my son and I left for an afternoon trip to the Vancouver Aquarium. As we were walking, he took a sharp turn and headed towards the seawall. Which led us to a green field. He paused. He played with his toy cars. He then went to contemplate a pond. Picked up flowers for mummy. Played catch with a ball. Headed straight to a playground. Observed kids playing tag amongst other things. Got a snack in the stroller towards the Aquarium.
This journey to the Aquarium lasted no less than 3 hours. We finally made it to the Aquarium 20 minutes before closure. The place was almost empty for us to relish the last precious minutes.
Beyond dawdling, to him, the journey – and everything along the way – was as exciting as the destination!
The same goes for interviews. It’s not so much about the final answer, but more about the problem-solving session itself. To understand how to make the best of this journey, let’s read further.
The right answer is not enough, be a Problem Solver
As long as an algorithm gives the right answer doesn’t mean it’s ok! As a candidate, you have to show that you want to go further and improve your initial solution, the performance.
A problem solver is what Amazon is looking for.
“Did he get the final answer right?” don’t care about that. Rather: How did he get to the answer? How did he respond to my hints? How long did he take to get to a valid solution? You don’t have to have all the questions right. Just be a Problem Solver.
Beware, fast thinkers
As a candidate, if you come up with an optimal solution and implementation in 10 minutes why a candidate usually takes 30 minutes (for the same question), that tells the interviewer either of 2 things: you are really good or you knew the answer. Regardless, the interviewer will lack data points to cast a final decision.
I have a pool of questions that I ask frequently. Some candidates cracked some of my coding questions in a matter of seconds. Where other candidates would normally struggle for minutes. Some of the candidates I met via mocki.co, admitted they knew the question and remembered the answer. They all banged the questions in a matter of minutes. Much faster than the other candidates I had the questions to.
If you encounter a question you already knew the answer to: do explain what the basic solution is and how it can be improved. Walk the interviewer through the solution as if it was the first time you were looking at it. Or just be honest and say it. The interviewer may choose to keep the question or come with another one.
The Unknown
Struggling during a coding interview is the goal expected when you are walking in a well-done interview. Don’t panic! It’s what will likely happen once you will be sitting behind your desk for the first few days. Scratching your head wondering what the hell people are talking about.
I have seen candidates fighting that feeling of not knowing the answer straight away.
“I have solved that problem before. But I cannot remember what the solution was.”
“I have done similar questions before.”
“I only practiced linked lists and graphs, not arrays!”
Embrace the uncertainty and unknown. Make sure you understand the scope of the problem (follow a rigorous procedure to approach a coding question), write down examples, draft and express any solutions you can think of.
Think out loud
Talk out loud to expose your thought process. “Ok, I am thinking about doing this and that, I have no idea if this is going to work. Let’s try using an example.”
Candidates sometimes freeze in front of the whiteboard. If you’re stuck, just say what you’re thinking. As an interviewer, it’s hard to evaluate if you need to give a hint or not. If you are given a major hint while you didn’t need any only because you were just thinking, it may penalize you. As it will seem that you weren’t resourceful enough to solve the problem on your own.
Talk to your interviewer. Share what your concerns are, any solution you can think of. Say what might work. Say what you thought could work and why it doesn’t work.
If you can’t entirely remember a concept, just explaining what you know about it may get you some of the credit. “What I am thinking about right now is: how to optimize this piece, I forgot the name of this concept, etc.”
Talking out loud while problem-solving takes practice if you don’t already do it. At mocki.co, we can help you practice by conducting a real-world mock interview led by professional software engineers.
Let’s Get Ready To Mumble
It’s better to mumble than saying nothing at all. At least it gives ideas of what’s going on in the candidate’s head! As we said, anything will do when it comes to expressing your train of thoughts.
“I don’t understand”
“I don’t understand” is a very honest, candid and powerful statement. Candidates are sometimes afraid to use it.
I have met people who never say when they don’t understand something. You can’t really be sure that they have understood the problem, the task or what you just explained.
I know I can count on someone who will clearly say, “I don’t understand”. That person will have Earned my Trust. It means that something is not clear and needs to be explained better.
The same goes for an interview. If you do not understand, do not mumble, or torture your mind in silence, speak up: “I DO NOT UNDERSTAND what you are asking, can you clarify?”.
“I don’t know”
I would use it with caution in the sense that you want to make sure that you explain to the interview what led you to conclude that you do not know something. Did you just run a dozen ideas in your head? Expose them. You can’t think of a better way to improve something? Say it.
A candidate I interviewed on mocki.co told me after minutes of struggle: I don’t know. This is a powerful statement; direct and honest. I gave him a few hints to unblock him.
Collaborate
The interviewer wants to know what it feels like to work through a problem with you. I have interviewed dozens of candidates over the past years. The best interviews I have had were with candidates who involved me in the problem-solving process. Collaborate with your interviewer like you would do with a teammate. Discuss the problem.
I’ve recently had a candidate who mentioned “SVN Externals Definitions” while answering a behavior question. He then asked me if I was familiar with this concept. He kept me engaged and included me in the conversation.
Use “We” instead of “I”
Use “We” instead of “I” as in “Ok, how can we improve this basic solution? If we use a hashmap…”. However, you shouldn’t use “we” instead of “I” when answering the behavioral questions, see our tips for answering the behavioral questions.
What if you are really stuck
It doesn’t mean you’ve failed. At that point, what matters is how you behave and react to that situation. Are you asking for help or are you just frozen? How do you react to the hint or feedback the interview gave you? If you do have gaps of any sort and you were given help, did you accept that help? Are you coachable?
An SDE II interviewed struggled to come up with a solution. He remained enthusiastic and in a positive mindset the entire time. I gave him a few hints to see the problem from a different angle.
The interviewer usually cares more about your ability to analyze the problem from different angles than your ability to bang the correct answer.
When hope seems lost, don’t give up! Get unstuck, ask questions.
Assuming that the interviewer is always right
While you would assume that interviewers are always right, it could be wrong. After all, all of us make mistakes. And sometimes they’d deliberately disagree with you to see how you respond to criticism.
No matter what the situation is, make sure you calmly explain and defend your thought process.
Here is a debrief comment I’ve heard in the past:
“He would just agree with anything his manager asked and won’t be able to propose anything new to the team.”
Disagree, challenge the status quo and propose meaningful alternatives. Always back up your argumentation with facts and data points.
Online coding assessment
As stated above, you don’t have the luxury of a debugger during an interview.
Online coding assessment platforms may record a lot of metrics during a session: how many times you try to compile the code, ratio of failure vs passed, tentatives to open a tab/window, etc. Follow our coding question canvas and make sure to keep it in the comments section. If your code is reviewed manually by an engineer because you didn’t pass all the test cases, this will help them understand what you had in mind.
Forget about your IDE
Writing code in your IDE is radically different from coding outside of it. The only way to truly appreciate the difference and to overcome the related issues is to forget about your IDE. Use a plain text editor instead.
On the whiteboard, leave spaces between the lines! That will be easier to insert extra code or comments.
No debugger
if your natural style is to write code and then immediately try to run it and see if it works on some set of test cases, it simply does not work at interviews.
Carefully think about the code you write. Then once you’ve written it, spend some time reviewing it. Read through your code, no compiler or debugger.
If you’re solving a coding challenge online, make sure you are 100% confident that your code is going to compile. This practice of carefully inspecting your code is priceless.
Draw pictures
Don’t waste time trying to think in your head, think on the board instead! Draw a couple of different test inputs. Draw how you would get the desired output by hand. Then think about translating your approach into code. For example, for tree and graphs related questions, draw them on the whiteboard.
Testing
Don’t presume that your code just works. Assume that your code is broken and try to find out why it is broken. Analyze your code, step by step. Think about the things you do. The logic. Hot spot. Check common errors. Go for 2 or 3 elements array test cases. Then, try with edge cases, one array empty, etc.
Bugfix
If you find a bug, find out why it happened. Don’t just make the first fix you see. You could also create a new one!
Programming Language
You are free to code in any programming language you want during a coding interview at Amazon. Be sure to choose a language you are proficient with.
I recently interviewed a candidate that blamed the programming language he chose for not finishing the coding question.
Choose wisely. Don’t waste that chance!
Coding style
“Engineers at Amazon shouldn’t just come up with a code review. The code review should be how best to do that implementation” says me.
This sentence speaks by itself. Cracking the coding problem is not enough. Your code has to be maintainable, readable and scalable.
As explained in our coding question canvas, a technic to approach any coding question, start by writing the method stubs and modularize your code. If you get interrupted while you are writing your code, you will get the basics of your algorithm done. Then it’s about filling in the details, the stub.
This deserves a post of its own. But basic rules of thumb that come to my mind are: separation of concern (SoC), Don’t repeat yourself (DRY), SOLID principles, KISS (Keep it simple and stupid), YAGNI (You ain’t gonna need it), etc.
N variable to describe time/space complexities
When evaluating the complexity of a solution, don’t use N as a name, strike it from your vocabulary. Use logical variable names. Example: Use “O(number of people)” instead of “O(N)”. Variables have meanings, proper naming removes ambiguity.
Proper variable naming
A candidate confused himself by naming a graph “g” and a queue “q”, at the whiteboard. Make yourself a favor, name your variables meaningfully.
Wrap-up
For more coding interview tips about how to approach coding questions in general, check out our coding interview canvas. I am frequently updating this post as I conduct mock interviews on mocki.co or real interviews.
Finally, try to view the coding interview at Amazon as a problem-solving or working session with potential teammates. Not as an assignment or homework. Have a mock interview with us at Mocki.co to boost your self-confidence. We will help you identify your mistakes and areas of improvement.
Good luck!
