“Yeah, I don’t want to go through solving pointless questions for hours on end, just for a chance to get into a software engineering company.”

This is the general consensus of the group. It’s my first time trying out Coronas4CoronaVirus. I simply introduced myself and mentioned that I have been spending the “extra time” from COVID on interview prep. A few moments later, the group is coming to a unanimous conclusion on whether Leetcode is even worth it.

Why study algorithms, which you will never use on the job?

Why solve tons of Leetcode, only to forget them all after the job offer?

Why become part of a system that makes you dedicate your personal hours to studying, just for a shot at a company?

---

Hello! This is part 3 of my Amazon Interview series. If you would like to read from the beginning, you can read part 1 here.

Leetcode is a Double-Edged Sword

This system is both a blessing and a curse. And I look at the former more than the latter.

Let’s go back to the old days, where you’d need to have a stellar GPA or even a Ph.D. to get into a company like Google. In fact, just a Ph.D. won’t do. You’d still need to be able to flex your achievements such that it makes you shine across the interview table.

Okay, maybe you could’ve gotten by with a Master’s degree, but the point is that the times were different back then. And it wasn’t just the big companies; in older societies, the most prestigious people got the most prestigious jobs. It’s just the way it has always been.

But now? You can grind out Leetcode and get so good that companies are willing to overlook your other shortcomings. It’s a clear-cut path that anybody can do, and it really levels-out the playing field.

A fair chance is given to anyone that is willing to try, dedicated to put in the hours, and is resilient in times of hardship.

Isn’t that the American Dream?

COVID

For me, this Amazon on-site interview would be my first ever trip to San Francisco, let alone the West Coast. I was HYPED. I even planned on delaying my returning flight in order to travel around the area for a bit.

Then COVID happened. And remote interviews happened. And my trip didn’t happen.

I got a notice from Amazon regarding my virtual interview format.

It was basically going to be as follows:

• Video conference through Amazon Chime
• LiveCode Link for code collaboration
• 4 interviews
• 60 minutes each
• 15 minute break after 2 interviews

Study Plan

After passing my Online Assessment, my HR briefed me a little bit on what I needed to prepare for. There were two major components:

1. Technical questions (algorithms, code, runtime & space complexity analysis)
2. Behavioral questions (Amazon Leadership Principles)

Interestingly, I’m told that they are both equally important. I thought for a technical position, they would heavily weigh my technical performance, but I guess not.

For my technical questions, I had the following rough plan:

• Leetcode (on my laptop, not pen and paper, since it’s all remote)
• Mock Interviews

For my behavioral, I had the following rough plan:

• Write out sample answers to any questions that I could think of
• Record myself answering these questions
• Judge my recordings and find out what I can improve

A week to go

There’s a week to go until my “on-site” interviews. For the past 2 weeks, I had been grinding out Leetcode questions, as well as practicing my behavioral leadership principles, but I’m very far from feeling confident.

Time went really fast during the 2 weeks. Instead of learning in a structured way, I was gorging on one question after another like a homeless man at a buffet. I did Mediums. I did Easy. I did whatever was tagged as Amazon. I wasn’t even digesting them properly. I just thought the more you do, the better.

Instead of being able to critique and improve myself, I was just focused on doing as much as possible. This Leetcode question, and that one, and this one, nom nom nom burp.

“Am I getting better?” “I don’t know, maybe if I do more?.”

“Am I going the right direction?” “Uhh, let’s just do another question.”

I was running in circles, and the consequences showed up on my mock interviews.

Mock failure

I had a mock interview with a friend in Amazon. Let’s call him Go.

Go asks me a question. It’s one of those “onion” questions: once you solve the question, there’s another layer to it. You solve it again, and there’s another layer. Each layer is increasingly difficult, and just like with onions, it makes your eyes start to water

Over the next 60 minutes, I struggle with pretty much everything. I stutter and say nonsensical garbage that would make Donald Trump cry. I propose multiple solutions that ended up not working, just the like Canadian government’s solutions to skyrocketing real estate prices. I write code that is way longer than it needed to be, like the series of Breaking Bad (Season 4 ending would have done it justice).

Eventually, with hints from Go, I reach a solution. It works. It’s optimal. Finally. It’s been over an hour since we started the mock interview. I’m tired. My back is sweaty.

Go’s feedback? I was far from ready. Oof, but he’s right. Point taken. Hey, mock interviews are way different than just doing Leetcode, okay?

He pointed out that I rely on hints when I’m stuck. He warns me that not all interviewers are nice, and some may not be willing to give any hints.

His advice? Try to do as many questions as possible, without writing code. Read the question, think of the answer, and check the answer. His idea was that given the limited time I have left, I should focus on improving my intuition by becoming familiar with many types of questions.

Mock failure #2

I learned from another failure, with someone who we will call Jack.

A similar thing happened: Jack asks a graph question, I get the basic idea, Jack wants a more optimal answer, I struggle, sweat, and get wrecked.

Jack is a nice guy though. He kindly advises me to go back to doing Leetcode Easy (ouch), and focus first on grinding out answers. One question, bam. Another, bam. Bam bam bam. His point: I suck at translating thoughts into code. Point taken. I waste too much time and effort trying to code up an algorithm that I have in my mind.

Don’t fight a fight you are going to lose

Shortly after my mock interviews, I had a prep-call with an Amazon HR for my upcoming on-site. And I sheepishly asked for an extension on the interview date, to which she very casually accepted, as if I had just asked her if I could go use the bathroom.

We push the interview date by another 2 weeks. This gave me almost 3 weeks to straighten the f*** up.

Reflections

Reflections changed my Leetcode game. I wrote a detailed post about it here. Basically, it’s where you critique your performance on each question. You write what you did good, and what you could have done better. For each question.

Before, my reflections were like this:

After, my reflections were like this:

With each question, I was improving. I felt it.

With each reflection, I knew exactly how I f**ked up. I knew what I did good. This helped me stop banging my head on the wall and I was soon walking away from the “Dan that kept making the same mistakes”.

Bye-bye tears. Hello confidence.

Performance improvements were evident in my mock interviews.

Thanks coach

I had mock interviews again, with the same people that interviewed me before.

I didn’t do excellent in all of them, but there were notable improvements.

Improvements, not luck. Concrete. Reliable. Repeatable.

I broke down questions better.

I communicated well, even when I’m stuck.

I didn’t need hints as much. I explored solutions pretty well.

Once I thought of a solution, I could code it up in no time.

Not bad.

Each mock interview ended on a similar note.

“Dan, good luck. I hope you pass.”

“Thanks coach.”

“You know what Dan, I think you got this. You are pretty solid now and I think you will pass.”

“Don’t jinx it coach”.

Mirror mirror on the wall, how do I pass Amazon’s behavioral interviews?

Since the Amazon HR really stressed the importance of behavioral questions, I practiced it thoroughly.

First, I came up with my own list of questions that I thought they would ask.

• Tell me about yourself
• Why do you want to work at Amazon
• Tell me about a time you went beyond your call of duty
• Tell me about a time you struggled on a project
• Tell me about a time you learned a lot on a project
• Tell me about a time you had conflict with teammates

Then I also Google’d around, hoping to find some additional questions.

There a lot of sample questions out there. I advise you to do your research.

Once I had a list of questions, I wrote an answer to each one on a Google Doc.

I made sure to reflect at least one, ideally 3-4, Leadership Principles in each one of my answers.

After I wrote my answers, I began practicing them.

I began by simply saying them out loud.

Then I began recording myself on my laptop camera.

I played back the videos and began critiquing myself.

“I’m stuttering when I begin talking without thinking about how to end my sentence. Stop that. Think ahead before I speak.”

“I keep looking up and above the camera when I’m in thought, which makes me lose interest. Stop that. Keep eye contact at or below the camera.”

”My delivery is not effective here, because I spent too much time talking about X. Talk less about X and go to the point.”

“Try to use your hands to make your answer more engaging.”

I felt like I was getting better. Definitely better than when I first started.

But I wasn’t 100% confident. I’m not good at thinking on-the-spot, and tend to get flustered when I’m stumped on a question. I tried to get over this by recording myself answering new questions without getting to think about the answer, and it helped a little bit.

---

With a few days left until my on-site, I’m feeling very motivated, excited, and curious. Curious to find out if all that effort, all those hours, and all those mock interviews were enough to pass the on-site interviews at Amazon. If I fail, too bad. I tried pretty hard, so there’s not much room for regret.

In my next post, I will write about my on-site interview.