Posts

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

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

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!

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.

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 (ask questions), 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 peace, 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 also 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 interviews

As stated above, you don’t have the luxury of a debugger during an interview.

Online coding interviews (without an interviewer) 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, 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 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!

I started Mocki.co as I have seen candidates receiving negative answers without a chance to receive proper feedback. Little or no feedback means poor chance to get better at interviewing.

Mocki.co enables candidates to take mock interviews with engineers from top companies such as Amazon, Google, and Microsoft before a real interview. So that when the time comes, they don’t ask themselves if they are ready to interview or not.

Before requesting a mock interview with us, there are other things you can do.

Create opportunities to get feedback.

Always ask for feedback.

Having a negative answer from a company is tough. You question yourself, reassess your ability to successfully pass an interview and this may impact your self-esteem.

While conducting mock interviews on Mocki, a candidate explained that she had received a ”no” from a company. When she prompted the recruiter for feedback, all she got was: “Your logic was biased”. No proper explanation. She came to us to pass a mock interview and get truthful feedback as she had lost confidence in herself.

So why always ask for feedback even though they won’t tell you why? Because you have nothing to lose. At worst, you get nothing. At best, you get something to work on.

Suprise the interviewer by asking a hint for the next interview.

Instead of requesting feedback after you have received an answer, you can try the following:

“If you had one hint to give me for the next interview, what would it be?” This is literally what a candidate once asked me during an onsite interview at Amazon. I replied something along the lines of: “We don’t give tips to candidates, and no live feedback, but here is a tip I normally give to people: make sure to write examples when you start working on a coding question!”. At least, he knew he had to do better at writing examples for the next interview question.

Build your interview experience.

When I searched for my first job roughly 10 years ago, after I graduated, I received a lot of negative answers. Sometimes I wouldn’t even hear back from recruiters.

I took over 20 interviews in different companies at that time to build my experience as a candidate. I traveled throughout the country, by train, by bus, on foot. You’ve to be scrappy.

I built my interview skills and got better at interviewing with companies I was semi-interested in. And eventually landed a job in one of my target company. McKinsey & Company at the time.

Work on your resume.

Resumes are cultural, some people and interviewers don’t even look at them. A resume with prestigious companies opens more doors.

A resume should give answers to the following questions:

  • As a recruiter, do I want to interview you or not?
  • Do you have the right experience to do well at the job?
  • Do you have the right experience to pass the interview?

Be aware that some interviewers may expect you to ”intelligently” speak about any technology you have on your resume. Check out our behavioral questions preparation post for more details.

Reward yourself.

Accumulate interviews like you accumulate points in a game. This will motivate you.

You can also indulge yourself after every interview with a sweet treat or something you like. I got into a habit of treating myself with a good pastry in a coffee place nearby where I interviewed.

Wrap-up.

Getting better at interview takes practice. If you don’t get many interviewing opportunities, request mock interviews on Mocki.co to build that experience of yours.

Check out our other posts about coding interview tips and Amazon behavioral questions preparation.

Good luck!

Psst!
We created a free email series with 10+ Examples of Amazon Behavioral Questions.

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

Amazon behavioral questions

A Googler I recently interviewed through mocki.co 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).

STAR

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
1
2

Example of story

Nugget:

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

Action:

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

Result:

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

Wrap-up

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

Good luck!

Psst!
We created a free email series with 10+ Examples of Amazon Behavioral Questions.

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 mocki.co. 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 mocki.co have different styles and will naturally test you on this.

I candidate I interviewed online via mocki.co 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.

Wrap-up

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

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