Writing this article was very difficult. I’ve started and stopped many times because it’s a harsh reminder of a time when my hopes were raised so high and then dashed by forces far beyond my control.
Still, I’m grateful for the experiences and lessons I’ve gained, and putting them out there will go a long way in helping more engineers improve their skills and advance their careers.
Earlier this year, I received an email from a Meta recruiter asking if I wanted to join Meta. Of course the answer was yes! I had an initial phone screening, outlined the process, and set a date for the first round of interviews.
As most software engineers know, every FAANG comes with the dreaded Data Structures and Algorithms (DSA) interview round that many engineers hate. They feel that DSA is too complex, uses few algorithms in day-to-day work, and there seem to be many places where questions can be selected.
An interview is not just a blank script that you read from a leet code. It’s usually a conversational process with the interviewer, and you can ask for tips if you need them. Therefore, you are not expected to figure everything out on your own.
The most important thing is how you go about solving the problem. As you read through this article, you’ll learn why this happens and how it applies to your daily work as a software engineer.
Most engineers believe that the problems associated with DSA are far removed from those encountered in day-to-day work, but since my prep days I have always wondered how certain things are done. I now have a better understanding of how things work, and I’ve come across an algorithm that helps. Me in my daily work.
I work for a ticket sales company and often have to work around my schedule. Scheduling-related algorithms are one of the algorithms that frequently appear in meta-interviews. There’s also the fact that many engineers don’t realize how inefficient the algorithms they implement are because they haven’t been tested at all with the amount of data that most FAANG companies operate on. .
I remember a friend of mine who implemented an algorithm for a feature at a new job, but the algorithm was extremely slow due to the amount of data he was working with. After practicing for the DSA interview, he learned how to use his hash map to reduce the time complexity of the algorithm from his O(n²) time to his O(n) time.
Additionally, depending on the type of software engineer you aspire to be, you may not be able to build systems to run efficiently and serve the next million users without a thorough understanding of DSA.
Even if you don’t need an algorithm, when a problem occurs, you can solve it quickly if you know an algorithm that can solve the problem efficiently. This is better than shooting in the dark or Googling for hours.
Another dislike of DSA interviews is that interviewers prefer reading code to find errors rather than relying on a compiler to run tests. Some interviews don’t even allow you to compile code (I’ve even heard of interviews where you were asked to write code in Google Docs).
This is stressful and many people don’t understand why it happens this way. Interview preparation and procedures will be troublesome.
In my work, I don’t necessarily build systems from scratch. You will often be working on code written by other people. And of course, as more users interact with the system, the way they interact with the system will evolve as well. Therefore, you will end up with certain special cases, or bugs, that you cannot handle.
This means you need to read and refactor your code to get your system working smoothly again. Testing often doesn’t provide a deeper understanding of the cause of the problem because you don’t understand how the code is trying to work.
By reading and reviewing your code, you can understand exactly what your code is trying to do before you change anything. By running the code manually, you can get to the specific area that is causing the error and fix the problem without introducing further bugs…hopefully.
I remember having to do a lot of refactoring at my company after the technical review of the phone. I got better and faster with the following activities.
- Read and understand other people’s code
- get to the root of the problem
- Come up with a refactoring that addresses the problem without causing further problems
Reading code and running it by hand will make you a better engineer, so get used to it.
As mentioned earlier, most FAANG DSA interviews are conversational. You are not simply given a question and asked to write an algorithm without telling the interviewer. After being asked a question, you are expected to ask some clarifying questions to find out what the interviewer wants you to solve.
Because in day-to-day work, things aren’t always defined down to the last detail. Therefore, before implementing something, it’s important to discuss it to make sure you’re implementing the right thing. During the interview, the interviewer will ask for clarification. In your workplace, this might be an engineering manager or a product manager.
Once you understand the problem, you will be asked to tell the interviewer which algorithm you would like to implement and get confirmation before proceeding. It can be frustrating because your interviewer may steer you in a different direction even though you already have an algorithm that you’re familiar with.
In an interview, this is done to test the breadth of your knowledge and avoid pitfalls. How does this affect your day-to-day work? You often have a direct manager, but they are usually more experienced than you. The approach you want to take may cause problems in the future, or the trade-offs in the approach may be incompatible with the overall goals of the system.
Therefore, it is important to get feedback from your manager on your approach to avoid causing further problems or wasting time on work that is inconsistent with the system’s goals. You always need clarification and guidance to make sure you’re doing the right thing and that your work ships on time. Invest in becoming better at communicating.
