What I Learned From My Engineering Interview With Amazon
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. They need to be able to jump in and seamlessly make changes. Your program needs to scale. Using proper variable names, adding comments, and generally using the least verbose functions and syntax will make you stand out. Clearer and concise logic might even be preferable to something faster but less clear.
2. Data structures are your friend
This advice has also helped me better understand why companies ask these types of questions. While the whiteboarding exercises may seem unrelated to an engineer’s everyday work building software — and I do think there are better ways to understand how skilled your candidate is at programming — I now see much more of a connection. Approaching an algorithm problem with these two points in mind turns a whiteboarding problem into an opportunity to show a company that you can write code in a clear and efficient way as part of a team.