Why DSA Interviews Are Great for Recruiting — My Experience With Meta

It has been very hard writing this article. I have started many times and stopped because it is a harsh reminder of a time when my hopes were raised so high and crushed by forces far beyond my control.

Nevertheless, I am grateful for the experience and lessons learned, and putting them out there will go a long way in helping more engineers improve their skills and progress in their careers.

Earlier this year, I received an email from a Meta recruiter asking me if I’d like to join Meta. Of course, the answer was yes! I had my initial phone screening, got a rundown overview of the process, and set the date for my initial interview rounds.

As most software engineers know, all FAANGs come with the dreaded Data Structure and Algorithm (DSA) interview rounds, which many engineers detest. They feel DSA is too complicated, they won’t use most algorithms in their day-to-day work, and there seem to be many places a question could be picked from.

The interview is not just a blank script like you are reading from Leetcode. It usually follows a conversational style with your interviewer, and if you need hints, you can ask for them. So you are not expected to figure it all out on your own.

What is most important is how you go about solving a problem. As this article progresses, you will see why it happens this way and how it translates to your day-to-day work as a software engineer.

Problem-Solving

Most engineers believe the problems related to DSA are quite far off from what they encounter in their day-to-day work, but from my time preparing, I got to understand better how certain things got done, and I did come across algorithms that helped me in my day-to-day job.

I work at a ticketing company, and we often work with schedules. Schedule-related algorithms are one of the recurring algorithms that come up in Meta interviews. There is also the fact that many engineers do not realize how inefficient the algorithms they implement are because they never get tested by the volume of data most FAANG companies operate with.

I remember a friend who implemented an algorithm for a feature at his new place of work, but it was so slow because of the volume of data he was working with. After practicing for the DSA interviews, he learned to reduce his algorithm’s time complexity from O(n²) time to O(n) time by using hash maps.

Furthermore, depending on the type of software engineer you plan to be, there are some systems you won’t be able to build to run efficiently and serve the next million users without a good grasp of DSA.

Even in cases where you might not need an algorithm, when problems come up, you can resolve them quickly when you know an algorithm that could solve them efficiently. This is better than shooting around in the dark and googling for hours.

Reading Code vs Running Tests

Another detested part about DSA interviews is that interviewers prefer you read through the code and figure out your errors rather than rely on the compiler to run tests. Some interviews don’t even give you an environment where you can compile code (I have heard of interviews where you are asked to write code in Google Docs).

This is stressful, and many people don’t understand why it’s like this; it makes prepping for and going through the interview process a hassle.

While working, you will not always be building a system from scratch. Many times, you will be working on code that has been written by someone else. And, of course, as the users that interact with the system grow, the way they interact with it will also evolve. Hence, certain edge cases not catered for will arise — aka BUGS!!

This means you must read and refactor the code to get the system working smoothly again. In many instances, running tests will not give you better insight into where the problem is coming from because you don’t understand how the code is trying to do its job.

Reading and reviewing the code ensures you understand precisely what the code is trying to do before you attempt to change anything. By running the code by hand, you can get to the specific region causing the error and fix the issue without causing more bugs to arise… hopefully.

I remember how, after my technical phone screen rounds, I had a lot of refactors to work on at my company. I had improved and gotten faster at the following activities:

• reading and understanding other people’s code
• getting to the root of the problems
• coming up with a refactor that addressed issues without causing more problems

Reading code and running it by hand will make you a better engineer, so get used to it.

Communication

Like I said earlier, DSA interviews in most FAANGs take a conversational style. You are not just given a question and expected to write an algorithm without saying a word to the interviewer. After you are given a question, you are expected to ask your interviewer a few clarifying questions to know what they want you to solve.

This is because, in your day-to-day work, things will not always be defined down to the nitty-gritty details. So, before you implement anything, it is important to discuss it to be sure you are implementing the right thing. In the interview, your interviewer asks for clarification; at your work, it could be your engineering manager or product manager.

After understanding the problem, you are expected to tell your interviewer which algorithm you want to implement and get confirmation from them before proceeding. This can be frustrating because sometimes you already have an algorithm you are familiar with, but the interviewer nudges you in a different direction.

In the interview, this is done to test the breadth of your knowledge and guide you away from pitfalls. How does this translate to your day-to-day job? You will often have a manager you report to, and they usually have more experience than you. An approach you want to go with can lead to problems in the future, or your approach’s trade-offs may be incompatible with the system’s overall goal.

Hence, it is important to get your manager’s feedback on your approach so you don’t waste time doing work that causes more problems or doesn’t align with the system’s goals. You will always need clarification and guidance to make sure you are doing the right thing and work is getting shipped on time. Invest in getting good at communicating.

While practicing for my interviews, I remember coming across an article where the author said, “What separates people who get in and those who don’t is understanding why they are practicing what they practice.” This inspired this article. Even if you don’t get into a FAANG, it will go a long way in helping you become a better engineer.

“What separates people who get in and those who don’t is understanding why they are practicing what they practice.”

Unfortunately, my system design and behavioral rounds got canceled due to the ongoing hiring freeze, but I hope this article motivates you to not just look at DSA as some complicated, unnecessary interview process to filter out applicants — but see this as an avenue to broaden your skills and get better as an engineer.

It’s great to know how to code Dijkstra’s shortest part or find related components using Disjoint Set Unions, but what you should take with you is the process of solving the question.

Communication, refactoring, and problem-solving constantly recur as you work. Getting better at these means becoming a better engineer.

Why DSA Interviews Are Great for Recruiting — My Experience With Meta was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.