Asa 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

I had a question that required me to track whether numbers had been seen before. I ended up achieving this with an array. In JavaScript, there’s a data structure that is similar to an array but automatically does not allow you to add duplicates.

Sets! Of course. I was familiar with the data structure but knew my program would not end up adding duplicates into the array anyway, so I went with arrays.

This was a mistake. A good strategy before picking a data structure would have been to make a quick list of what I needed to achieve (no duplicates, random access not necessary) and then a list of possible data structures (array, object/hash table, set). That quick process would have led me to a set, the superior data structure for this use case not because it was faster but because it would have been more clear to my collaborators.

Another way to follow the first piece of advice, “Write code as if you were working here” is to choose a data structure that offers other developers very obvious signals about what the program is doing.

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.