What I Learned From My Engineering Interview With Amazon

As a software engineer entering the job market, I've had the chance to speak with hundreds of firms, ranging from two-person startups to Facebook and Amazon.

Companies conduct interviews for technical expertise in a variety of ways. In order to demonstrate my expertise in algorithms and data structures, I have been requested to share anecdotes from my past experience, construct a stock trading application in four days, and — the classic — solve a coding problem on a whiteboard.

I have gained so much knowledge from this experience.

My most recent interview consisted of an hour-long phone screening with an Amazon engineer. In addition to the behavioural component (two pieces of advice: STAR technique and Leadership Principles), we spent roughly half the time working through a coding topic on a digital whiteboard while conversing on the phone. I did not advance past this step (i.e., I failed — attempting to become more comfortable expressing this aloud), but I learned a great deal.

I requested comments from the interviewer at the conclusion of the call. Even though I didn't feel particularly confident about my performance, I knew that interviewing at Amazon and speaking to an Amazon engineer in this environment would be an excellent opportunity to learn, grow, and improve.

My interviewer provided me with two essential pieces of information that have proven useful in subsequent technical screenings:

1. Write code as if you were working here

I interpreted this to indicate that you should create code in an interview as though you are working for the company and with a team. This may sound simple, but when practising for LeetCode, it's tempting to solely focus on designing an algorithm with the lowest space and time complexity and getting your programme to pass all of the tests. Accuracy, speed, and efficiency are essential, but just because your code is accurate and your algorithm is quick does not indicate that a firm will view you as an asset. Other engineers must be able to rapidly comprehend your program's functionality upon viewing it. They must be able to make modifications without difficulty. Your programme must be scalable. Using correct variable names, including comments, and generally employing the simplest functions and syntax will set you apart. Clearer and more concise logic may even be preferable to speedier but less clear reasoning.

2. Data structures are your friend

I had a question that asked me to determine if numbers had been encountered previously. I ultimately accomplished this with an array. There is a data structure in JavaScript that is comparable to an array but does not permit adding duplicates. Sets! Of course. I was familiar with the data structure and knew that my application would not create duplicates to the array, so I opted for arrays. This was an error. Before selecting a data structure, it would have been prudent to compile a list of the objectives (no duplicates, random access not required) and then a list of possible data structures (array, object/hash table, set). This rapid procedure would have led me to a set, the superior data structure for this use case, not because it was quicker, but because it would have been more transparent to my coworkers. Another strategy to adhere to the first piece of advice, "Write code as though you were working here," is to select a data structure that provides extremely clear signals to other writers regarding the program's behaviour.

This guidance has also assisted me in comprehending why organisations ask such queries. While the whiteboarding tasks may seem unconnected to a software engineer's day-to-day work, and I do believe there are better ways to assess a candidate's programming skills, I now see a much stronger relationship. Keeping these two points in mind while approaching an algorithm challenge transforms a whiteboarding problem into an opportunity to demonstrate to a company that you can create code in a clear and efficient manner as part of a team.