What I Learned From My Engineering Interview With Amazon

How failing a technical screen helped me grow as a developer

Photo: Christian Wiediger/Unsplash

As a software engineer entering the job market, I have had the opportunity to speak with dozens of companies, from two-person startups to giant companies, including Facebook and Amazon.

Companies interview technical talent in vastly different ways. I have been asked to share stories about my past experience, build a stock trading application in four days, and the classic — solve a coding problem on a whiteboard to show my chops in algorithms and data structures.

I have learned so much throughout this process.

One of my most recent interviews was a one-hour phone screen with an Amazon engineer. In addition to the behavioral component (two pieces of advice there: STAR method and Leadership Principles), we spent a little over half of the time working through a coding question on a digital whiteboard while speaking over the phone. I didn’t end up moving past this stage (aka I failed — trying to get more comfortable saying this out loud), but I learned a ton.

I asked the interviewer for feedback at the end of the call. I highly recommend doing this because even though I was not feeling super confident about my performance, I knew that interviewing at Amazon and speaking to an Amazon engineer in this context was an invaluable opportunity to learn, to grow, and to improve.

My interviewer gave me two amazing pieces of advice that have already helped me in subsequent technical screens:

1. Write code as if you were working here

I took this to mean that in an interview, you should write code as though you are working at the company and with a team. This might seem obvious, but when you’re practicing on LeetCode, it’s easy to only focus on getting your program to pass all of the tests and writing an algorithm that has the lowest space and time complexity. Accuracy, speed, and efficiency are important, but just because your code works and your algorithm is fast, does not necessarily mean that a company is going to see you as an asset. Other engineers need to be able to look at your program and very quickly understand what it is doing…