Having a rigorous procedure to approach a coding question is vital to nail your tech interview.

You can think about the interview coding question canvas as a checklist to go through each time you approach a new coding problem. I divided the canvas into different sections.

I always start answering a coding interview question by writing down my canvas’s skeleton on the whiteboard or in a text editor. I am a big fan of Markdown, as it is straightforward to structure plaintext.

We use this canvas when problem solving coding questions in our posts. For example, checkout this coding question related to Amazon AWS EC2. We have another post dedicated to coding interview tips.

The canvas

# Problem name

## Constraints

`Method signature: `

- Constraint 1
- Constraint 2
- etc.

## Examples

## Solutions

### Solution 1: Naive solution

Time Complexity:
Space Complexity:

### Solution 2


### Solution 3


## Code

Problem Name

Writing down the problem name forces you to read the problem correctly. Just in case you are too excited. Maybe there is an indication of what data structure to use or something like that.


What is the input and output of the algorithm? Write your method signature.
List all the constraints you find in the problem statement. Also, include additional limitations you asked the interviewer.


Force yourself to write more examples than the one(s) provided. Write down an example as soon as you start working on the problem. For a typical onsite, you would have a whiteboard. Remote interviews are more challenging. In any case, start with at least one example.

I recently asked an array-type coding question during an onsite. The candidate came up with the following example: input = {1,2,3,4,5}. Can you identify what the issue is with that example? The numbers look exactly like array indexes! The candidate confused himself many times throughout the interview because of that. Choose your examples wisely. What about this other example? input = {190, 45, 78, 90}. Values should be small enough to compute them in your head! Except if the problem requires otherwise.

List all edge cases you can think of here.
An edge case may change your entire algorithm. Edge cases might include empty sets, single-item sets, or negative numbers.


Force yourself to write at least two ideas about how to solve the problem. Don’t reject an idea because it seems absurd, lay it down and then judge using Big-O.

Solution 1: Naïve solution

The first solution you can think of will be very often the Naïve or Brute Force solution. Mention it before explaining it to make the interviewer aware that you do realize that it may not be optimal.

How did my brain do it? Try to solve the problem by hand. After all, algorithms are just an automated way of what you could do manually, hand-written (well, if you had an infinite amount of time!). Evaluate both the time complexity and space complexity.

Solution 2: optimized solution

Now that you came up with a brute force solution go over the bottlenecks and optimize that solution.

After she came up with a naive, brute force solution, a candidate I met conducting a mock interview on told me she couldn’t optimize her solution further.

If you really cannot think of anything, say it. Your interviewer will likely give you a hint. Anyways, always back up your decisions with facts and data points. For instance: “I cannot optimize this further as you have to go through every item of the array anyway, so that’s O(array length) at the minimum.”


Start with stubs, “I will add the stubs for now.” Writing down the empty functions will help you design your algorithm on the fly.


public class MySolution {
    public void set (int index, int item) {


    public void append( int item) {


    public void get(int bla){



Like always, practice makes perfect. You don’t have to be perfect, work to be a good problem solver. I believe anything skill can be learned. Mistakes are allowed.

If you want to know where you stand before a real interview, request a mock interview on

There is an excellent post about Algorithm Design for Tech Interviews. Hihgly recommend!

Psst! Learn how to get free mock interviews here.

This is the fourth article of our guide to preparing for a Software Development Engineer (SDE) interview with Amazon.

A quick search on Google for “Amazon coding interview questions” yields a whole lot of results in different flavors.

Let’s get one thing straight: Interviewers at Amazon are free to ask ANY questions they want. This implies that there is NO exhaustive list that can cover every conceivable coding question.

Remember, Amazon’s interview goal is to assess one’s ability to problem solve and to work as an Amazonian. A candidate wouldn’t do himself/herself or Amazon a favor by learning solutions to coding questions by heart.

Save yourself some bucks

I have seen very respectful websites proposing to divulge specific interview questions for an Amazon interview if you pay a little extra.

Don’t fall for it. You are better off buying a copy of Cracking the Coding Interview by Gayle Laakmann McDowell to practice a range of questions (data structures, system design, behavioral questions, etc.) and brush-up various technical concepts.


Interviewers tend to ask the same questions. As an interviewer, this helps to build a baseline to evaluate candidates. So that you can compare a candidate to others.

So yes, some questions may be asked more frequently than others, but there is no way to know this upfront. I personally have a pool of ~20 coding questions I ask frequently.

Beat the odds

At best you have a list of interviewers provided before your onsite by a recruiter (never happened to me but I have seen it) and you google each interviewer to find out what they blog about and what their interests are.

How do you get prepared for an interview at Amazon

I should probably create a separate blog post for this. But the short answer is practice solving coding questions (LeetCode, etc.) and read-up on your basics.

Make sure you understand all the concepts from Cracking the Coding Interview. Make sure you can solve all easy, medium and most hard questions.

Practice makes perfect

Practice solving coding questions as much as possible. Make sure to also prepare for the behavioral questions and read our tips for a successful coding interview.

If you want a dry run, go to and request a mock interview led by some of our Software Engineers.

You can also use But it may end up being a waste of your time as there is no guarantee who your “interviewer” will be. How long he has been in the industry for and where he currently works.

Good luck!

Psst! Learn how to get free mock interviews here.

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 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, 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 the first few days. Scraching 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 thoughts 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, 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 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.


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.


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.


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.


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 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 to boost your self-confidence. We will help you identify your mistakes and areas of improvement.

Good luck!

Psst! Learn how to get free mock interviews here.

This article is the first of our guide to preparing for a Software Development Engineer (SDE) interview with Amazon.

A typical Amazon interview includes 10 to 20 minutes of behavioral questions. Preparing for the Amazon behavioral interview questions may seem intimidating and overwhelming at first.

Behavioral questions, what does it even mean? Where should you start? How to cover a variety of questions? In this article, we will go over a simple technic to facilitate the behavioral questions’ preparation.

When you are ready, you can request a mock interview led by one of our Software Engineers on

Amazon behavioral questions

A Googler I recently interviewed through took offense at the Behavioral Questions I asked. Arguing that it wasn’t how he had interviewed in the past. That it was too long and left too little time for the coding question itself.

The idea behind behavioral questions’ success is that a candidate’s past performance is a good indicator of his or her future performance. Amazonians don’t skim over those questions.

Amazon’s Leadership Principles

Amazon has publicly published its Leadership Principles. It’s an excellent opportunity for you as a candidate to get prepared for your interviews. Let’s understand how.

What are the Leadership Principles?

Leadership Principles (LP) are values or common traits that you can find in people working at Amazon (Amazonians). As a candidate, you have to demonstrate those Leadership Principles, LPs.

How to prepare for the Amazon behavioral questions?

Try to develop a list of stories where you demonstrated those Leadership Principles. Then dress a list of possible follow-up questions an interviewer may ask. Be prepared to talk about a story in detail (technically or not).


Follow the STAR approach. The STAR approach helps you to structure your answer. It helps give the context (Situation) and identify what was asked from you (Task), what you end up doing (Action) and what the outcome was (Result).

Organize everything in stories.

Assuming we are working on the following Leadership Principle: Customer Obsession.

Come up with a good story where you demonstrated that you were customer-obsessed? Where you went above and beyond for customers? What did you do? What was the result? Did you receive feedback from your customers? How?

Prepare 10-15 good stories total, across the Leadership Principles. You will be able to reuse some stories for multiple LPs.

Stories that can easily be reused for multiple Leadership Principles include:

  • An interesting technical problem you solved.
  • An interpersonal conflict you overcame.
  • A time where you demonstrated leadership or ownership.
  • A situation where you should have done differently in a past project.
  • Do you fix things that aren’t quite right, even if you don’t have to?
  • Be creative!
  • A time you acted on a piece of feedback you received.

You can organize everything in rows and columns. The nugget is just a very brief description of the story.

# Project Nugget S/T A R Note LP

Example of story


  • SaaS Silverlight application for fortune 500 companies.
  • I reduced the size of the application (XAP file) by 35%.

Situation / Task:

  • Customers Worldwide
  • Lots of complaints that the app was extremely slow to load. Up to 5 minutes to load (from India, for instance).
  • We had one single datacenter in Europe.
  • No CDN.


  • I built a script to remove duplicated dependencies from the final package. I integrated the script into our pipeline for automation.
  • POC to improve our dependency management and dependency graph.


  • Reduced the size of the application by 35%.
  • Better UX. Lighter and faster to load.
  • Fewer complaints from customers.

LPs: Customer Obsession, Think Big, Ownership, Invent and Simplify, Learn and Be Curious and Insist on the Highest Standards.

Not too many stories

A candidate I interviewed on shared with me the stories he had prepared for Amazon’s behavioral questions. A long-winded document including several distinct stories per Leadership Principle. While answering the behavior question during the mock interview, he struggled to remember the stories. This is because he had prepared too many stories.

As recommended in this best seller book, organize your stories with nuggets. As stated earlier, a nugget is just a very brief description of the story, easy to trigger through visual memory of your notes.


If you want to read examples of Amazon behavioral questions and answers, register for our free email series.

Also, check out this other article with Amazon Behavioral Interview Questions tips.

If you want to have a dry-run at an Amazon behavioral interview, take a mock interview at

Good luck!

Psst! Learn how to get free mock interviews here.

It is the second 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 to nail the Amazon behavioral interview. This is based on my experience of interviewing dozens of candidates at Amazon and on I strongly recommend you to check-out how to prepare for the behavioral questions.

A typical intreview round at Amazon starts with 10 to 20 minutes of behavioral questions. Needless to say that acing the coding doesn’t guarantee success. Let’s get into it.

Prepare your answers upfront

You have to come prepared for your interview. We explain in our other post how to prepare for Amazon behavioral questions

Practice and rehearse often

Ask a friend to randomly pickup up a question or Leadership Principle. Try to adapt and model your stories for different Leadership Principles. Tick a Leadership Principle once practiced to make sure you go over all of them. Rehearse regularly.

Be specific

Some candidates give high-level answers.

“When I work on a bug, I usually do this and this.”
“When I have a different opinion from the other team members, I do this and this.”

I asked the candidate to describe the virus scanning feature that he had designed and implemented. His description mostly stuck at a high level. I sense that he probably design very little if any of the system and that he was mostly plumbing together existing interfaces to a network proxy/filter and an anti-virus scanner.

This previous example was impressive at the surface but had low value once scratched. It results in less time for the rest of the interview (like coding). The interviewer needs a concrete example, a story based on your own experience that you can elaborate on in detail.

Don’t rely on your notes during the interview

First, ask your recruiter if you will be allowed to bring your notes during the on-site interview.

An interview is not a knowledge test. I’ve seen candidates bringing notes. I don’t mind, but I discourage bringing notes for interviews. Why?

I interviewed a candidate who had brought her notes at the interview. She was notably nervous. She couldn’t find the page/note she was looking for. She started panicking. She started reading her notes out loud as she couldn’t seem to remember anything.

Better be safe than sorry: don’t rely on your notes. Practice without any notes or cheat sheets. The conversation will be more fluid, and your interviewer will be more engaged. Remember, if anything, it’s a discussion.

Clarifying questions

When you practice for your behavioral interview questions at Amazon, ask your mock interviewer to ask clarifying questions while giving your answers. And not only afterward as follow up questions.

Our mock interviewers at have different styles and will naturally test you on this.

I candidate I interviewed online via confessed after the mock interview: “I didn’t expect you to ask questions before I had given you my full answer. It disrupted my flow.”

Your interviewer may or may not do the same thing. As an interviewer, I ask questions when something is not clear to me. I then ask probing questions to get into more details. I don’t wait until a candidate is done elaborating. Time is of the essence.

Remain positive

How do you react when you are frustrated? How do you respond to someone that doesn’t seem to understand what you are trying to convey?

I remember this one candidate: I asked that candidate to explain a c++ concept he just had mentioned (glibc). I asked him to repeat, as I did not hear him properly. He took offence and started patronizing me while giving his explanation. Increasing the tone of his voice and laughing. I seized this opportunity to test him further. The candidate became more and more impatient, to the point he became nearly rude. I stopped the conversation, thanked him for his explanation and moved on.

Remain in a positive mindset. Be personable, Earn the Trust of your interviewers.

Engage your interviewer

As a candidate, it is hard to gauge the interviewer’s technical level in front of you. Mainly during a phone screen. Engage your interviewer. If you suspect that your explanation confuses your interviewer, ask him. If you come up with acronyms and concepts, explain them briefly.

“I” is the distinction of “We.”

Use “I” and not “we” when answering a behavioral question. Don’t always talk as “we.” Advocate for yourself, don’t let your team take credit for what you did.

What’s with this title?

I happened to have seen a similar sentence in a satellite location of the Vancouver Art Gallery. I liked how it sounded and figured it would be catchy enough to remember it.

Summarize the Behavioral Question out loud

Repeat the behavioral question that was asked from you out loud. It is the best way to ensure that you understood the question correctly, and the interviewer should tell you otherwise.


Preparing for the behavioral interview questions at Amazon requires preparation. If you want to read examples of Amazon behavioral questions and answers, register for our free email series. Practice makes perfect. If you want to receive truthful feedback before a real interview, have a mock interview on

We have more articles to help you prepare for your Amazon phone screen or onsite interview.