It’s today. This is it. Today is my chance to come out on the other side, shining like the golden goose laying out golden Big-N paycheques twice a month.
Up until now, I have had interviews with Palantir, Twitch, Udemy, Stripe, and Coursera. And I got cut from all of them except Coursera, who told me that they are no longer hiring for the current quarter, after I had passed their phone interviews.
So this is my only interview left.
The only shot I have for now for a new job.
After this one, I have nothing else in my calendar.
“No pressure Dan, take it easy. Just don’t fail… or otherwise I’m gonna not have any other job PLEASE PASS DUDE.”
With 10 minutes to go before my first interview, I log onto Amazon chime.
Hello! This is part 4 of my Amazon Interview series. If you would like to read from the beginning, you can read part 1 here.
“Thank you for taking the time to interview with Amazon today…”
I’m getting interviewed by a software engineer who has been working at Amazon for about a year. He takes a couple minutes to get me comfortable and warmed up before asking a question.
It’s a pretty standard intro, but it makes me feel quite welcome.
He begins with a behavioral question. It’s a question I had prepped for. Easy, I thought. I confidently threw him an answer.
What I didn’t expect was for him to get into so much detail.
He asked enough questions to make sure he thoroughly understood the concerned project (the situation), the problem (the task), my approach (action), and the result. He asked enough questions such that he could share my story with someone else, would he ever need to.
Pro-tip: be prepared to go into details regarding your stories.
By the time he was satisfied with my story, 30 minutes had passed. Yeah, 30 minutes…
He sent me a Livecode link and asked me a coding question.
It wasn’t a Leetcode-style question, so not something I had really prepared for. But it wasn’t super hard either.
I re-iterated the question back, making sure I understood. I discussed my approach, which he liked. I began to write the code, chipping in with an explanation every now and then.
After walking through my code, I finished and confidently asked for his input. To my demise, he told me that I have an uncovered edge case. Uh-oh. I try to stay calm and walk through my code again. An edge case… I discussed a bunch of edge cases off the top of my head with him. He tells me while those cases are valid, there is a simpler edge case that I missed. A simpler one… I discuss some more off the top of my head, but he is still not satisfied. He tells me the bug is pretty obvious, but that doesn’t help me find the bug at all. I’m getting some cold sweat at this point. A simple bug, which I cannot find. Oh shizzles.
Then I see it. Yeah, dumb mistake. I didn’t see it as a programmer, but it’s pretty evident from the user’s perspective.
We have 5 minutes left, which I use to ask him a bunch of questions.
Then he logs off, leaving me with a few minutes until my next interviewer joins the call.
The second interviewer has more than 4 years of experience, works at a different team (so not Amazon Music), and is super respectful. The first two factors are used to identify what people call a “bar raiser”. It’s not an official term, but she explains that Amazon tries to have at least one of the interviews carried out by a member from a different team, in order to respect consistent standards across the company.
Simply put, if she doesn’t like me, I’m not moving on.
After making sure I’m comfortable, she also mentions “Thank you for taking the time to interview with Amazon today…” Wow, is everyone trained to say this?
She asks me a bunch of behavioral questions. She goes into enough detail to understand each one. After she’s finished with one, she asks me another. It’s pretty clear that she’s asking these questions to size me out as best as she can.
She asks me 3 behavioral questions in total, going into details on each one. 30 minutes have passed and it’s time for the technical questions.
It’s a Leetcode question!! I do as I practiced. I re-iterate the question, clear up edge cases, discuss various solutions, their trade-offs, and have her choose a solution. She tells me to choose a solution, and I code it out.
I code it out pretty quickly. I walk through the code when the interviewer interrupts me saying the output doesn’t seem right for certain cases.
Crap, I should have discussed this before I coded everything. Due to “common-sense”, I had assumed that a certain pattern of results are expected, while she expected the complete opposite. She’s very open to discussing what the “right solution” would look like. After discussing it, we agree that to go with her way, and I change up the code.
After fixing the code, she reviews it. I’m not feeling too confident at this point because my code is pretty messy, and I’m not 100% sure what the runtime is anymore. For each of X, for each of Y in Z, do this T times, break if S is true… Man, I sure hope she doesn’t ask me to clarify the runtime complexity of this.
She asks me for the runtime complexity. Dang..
I walk her through the logic. “Well for each one of these, we run this, which will end early on this condition, otherwise for each one of those, we do blah blah… So the runtime is O(nlog(m)).” I answer her pretty confidently, but in my head I’m having trouble understanding the garbage I had just spewn out of my mouth.
“Well, there is this logic here, so do you think that makes sense?” She points out a little flaw. This actually helps me quite a bit. “Oh, you’re right, in this case the runtime is actually blah” and she is happy with my answer. Woot. Went smoother than I thought.
She asks me if I could further optimize it. I think out loud on various data structures or algorithms I could use to change the runtime, but none of my ideas bring a smile to her face. Before long, time runs out, and she asks me “Do you know what a trie is?”
Dammit. Yes, I do. Why didn’t I think of this?
I tell her I know about it, but haven’t ever used it. Then the interview ends and she logs out. I have a 15 minute break at this point, so I go grab a snack.
Pro-tip: get familiar with tries
A manager logs onto the call. Software Engineering Manager at Amazon. Man, what a title.
“Thank you for taking the time to interview with Amazon today…”. Yep yep thanks.
He introduces himself. He tells me about the team, their work, their vision, etc. He runs a team that owns this product, that product, and that other product blah blah… wait, what were his two other products? I already forgot. Sounds like too many products for just one team.
Then he tells me the entire interview will be behavioral. Phew! No technical questions to make me stumped!
And that’s probably the peak of the interview - before it even began.
He asks me a situational question, to which I give him an answer. Before I talked, he was smiling and friendly and all. But while I talk, his smile goes away and his face looks dead serious. A little too serious… Is that a frown? Man, maybe my story is too shit?
Just like the previous interviewers, he asks follow-up questions. And all the time while I answer, the sterness stays on his face. If I had to guess, he doesn’t like my answers, or there’s an itch that he would like to scratch but he can’t because we are in an interview.
After 30 minutes, we enter a silent pause. He goes through his prepared list of questions, commenting that my stories were rich in content and answered multiple questions at once, so he needed to dig around for another question. After about a minute, he gives up and says “You know what, do you have any questions for me?”
Well damn, there’s still 30 minutes to go and I gotta fill it in.
But guess what? I’m prepared. I have dozens of questions that I had prepared on my notebook. I got PLENTY. Muhaha.
I ask him various questions. I actually didn’t even need a prepared list. I’m genuinely curious about his work, his life at Amazon, and various other Amazon things. And time goes by super fast.
Time runs out, the manager logs off, and I’m now waiting for my final interview.
Despite me having finished 3 interviews already, I’m feeling HYPE at this point. In fact, this is the most energetic I have been throughout the entire interview. Upon realizing that it’s almost over, I’m about to flip my desk and go drink and party… Oh wait, there’s this COVID thing. Right, nevermind.
A software engineer with 2 years of experience at Amazon logs into the call.
Of course, he starts with *“Thank you for taking the time to interview with Amazon today…“.
He’s got an accent which makes it a little hard to understand, but he’s a cheery and good-hearted fellow. I instantly like him.
He asks me a behavioral question that was already covered in a previous interview. I tell him so, but also mention that I have a good story to tell. He contemplates a little bit before throwing a different question, but man… My story to his first question would be HELLA DOPE. So, I just tell him that I will answer the previous question anyway since the story will better reflect my character, and if he is not satisifed I will answer the other one as well. The interviewer is a little hesistant but goes with it.
He ends up really liking my story and is happy with what I told him. He proceeds with two more behavioral questions, each of which I answered pretty well. He comments that he likes my stories. Yay.
Around 30 minutes have gone by and it’s time for a coding challenge. He asks me a very open-ended coding question.
As I have practiced, I re-iterate the question to make sure I get it. After narrowing down the question, I discuss edge cases, propose multiple solutions, discuss the one that makes the most sense, and have the interviewer choose a solution that I should code out. He chooses a solution and I write the code.
It goes really well. I write clean code, communicate clearly, and walk through the code to check for bugs. The interviewer likes it. He asks me for an optimization. A pretty extreme optimization, I would say. This makes me stuck for a little bit. I think out loud and consider the various data structures that could come in handy, but none of them are of much help.
As the interviewer is about to give me a hint, I land upon an idea. I propose the idea to the interviewer, to which he thinks about it for a bit and later agrees its viable use-case. He tells me he is happy with my answer.
We have less than 5 minutes left, which we use for any questions that I had. After that, he thanks me again for the interview and logs off.
I stare at the blank video conference screen for a second, then I close the tab to end my Amazon interview.
The next week, I get an email from Amazon.
- practicing with mock interviews
- practicing my behavioral questions
- transparent communication
- making sure both me and my interviewer were on the same page in regards to a problem
- being very receptive to any feedback or hints
- being genuinely curious about working at Amazon
- having fun
- I found it pretty challenging to write clean code for a complex problem on the first go. My plan was to write working code first, then clean it after. But I never got the chance to clean up my code in my first two interviews, either because of time, or because we jumped right away to another problem soon after we solved one. My advice? Think of writing code like untangling a shoelace. You first need to find the ends of the shoelace - the beginning and the end. Once you find those, untangling the middle becomes pretty straight-forward. Writing clean code at interviews is very similar. Think in your head about how your function begins (the input args) and how to end it (return value). And then try to work from both ends. Work backwards a little bit, then work forward a little bit, etc. This was what I did for my 4th interview and it worked pretty well.
Originally, I intended to end my Amazon interview series here, but I have some helpful things to say about team-matching. So, in my next post, I will write about the team-matching process.