## Interview coding question checklist or canvas

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

TC:
SC:

### Solution 3

TC:
SC:

## 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.

### Constraints

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.

### Examples

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.

### Solutions

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 mocki.co 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.”

### Code

Examples:

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

}

public void append( int item) {

}

public void get(int bla){

}
}
``````

## Wrap-up

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 mocki.co.

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

## Amazon coding interview questions

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.

## Trends

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 Mocki.co and request a mock interview led by some of our Software Engineers.

You can also use Pramp.com. 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!

## 10+ Amazon coding interview tips

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

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 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 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.

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!