How to ace the Problem Solving, Data Structures and Algorithms Interview Round?

If you’ve never heard of Problem Solving, Data Structures and Algorithms round before, please go through our article on ‘What is the Problem Solving, Data Structures and Algorithms round?’ to understand more about it.

To learn how to prepare for the Problem Solving & Data Structures and Algorithms round, please go through our article on ‘How to prepare for DSA Round?’.

Even though a lot of candidates prepare well for the DSA round generally through Leetcoding or alternatively through competitive programming, many get rejected because they think that the interview is just about writing the most efficient code fast. The interview is more about how you approach and solve the problem rather than knowing the most efficient solution.

Before talking about how to ace interviews, let's first talk about your role as a software engineer. It will help you understand how you are judged during an interview.

A code monkey is a person who is not expected to think or design or conceptualize but whose only job is to code according to the given specifications. When working in the top companies, you do not work as a code monkey but as a smart, analytical engineer who can solve problems.

On the job, you would be given a problem or a requirement and you have to come up with a good solution to that. At a very junior level (early SDE-1), the expectations are a bit low and the requirements are generally well-defined. But that is not the case everywhere.

You are expected to properly understand the problem, think clearly about it, ask clarifying questions to make it more structured and well-defined. You need to be able to come up with simplest solutions that will work. The definition of what will "work" might vary. In some cases, it may just be about correctness and in many cases, opimality or scalability is also important. You need to figure out what works by effectively communicating and discussing with your stakeholders. Being able to articulate your thoughts properly is important here.

Once you have the problem clarified and the requirements well-defined, you start to come up with a solution. You need to make sure that your solution works properly and that you've considered the different scenarios alongwith the edge cases.

Then you discuss the solution and/or the design with others in your team or your stakeholders before you start to code. After coding, you test it well and debug when stuck instead of directly testing in production.

DSA/LLD/HLD Interviews are a simulation of how you would perform on the job. You need to have good problem-solving skills which includes everything that I talked about earlier.

Now that we've talked about what matters, let’s go through some things you should do to ace the PS/DS round.

Here ‘solution’ means the approach you’ll take to solve the problem and ‘code’ is used to signify the actual code solution.

General

• For remote interviews, avoid noisy places and make sure you have a good working internet connection and keep a pen and notebook with you. Use earphones/headphones.
• Make the interview interactive through discussion so that the interviewer can understand your solution approach better.
• You should be thinking out loud during the entire process. You’re mostly judged on how you got to the solution rather than if you got to the solution.
• During a remote interview, write everything on the shared editor and not on a notebook which the interviewer can’t see. The interviewer wants to see how you’re approaching the problem.
• Avoid letting the interviewer know that it’ll be done similar to some other interview problem. You can map a problem to a particular concept or algorithm but not to another interview problem.

After getting the question

• Repeat the question to the interviewer to avoid any miscommunication or misinterpretation.
• Ask as many clarifying questions as you can think of so as to make the requirements clear and remove any room for ambiguity or misinterpretation. Make sure to clarify the input constraints.
• Write a few test cases with both input and output including edge cases before thinking about the solution.

Getting to the solution

• Try to give a solution as soon as possible even if it is not the most efficient solution. You may start with a brute force solution and try to think of how to solve the problem more efficiently.
• Dry run your solution on the test cases before telling the solution to the interviewer. Could be avoided for brute force solution if you’re very sure about it.
• Try to give a high-level solution and only dig deeper if the interviewer asks you to. This may help you save time if the interviewer understands the solution and wants you to provide a more optimal one.
• If you’re stuck, go through your approach again with the interviewer and discuss where you’re stuck. In such cases, most interviewers would try to lead you to the solution.
• You should pick up any hint provided by the interviewer. Ignoring those is a huge red flag. Try not to directly ask for a hint unless you’ve no clue about how to approach.
• If you understand where the interviewer is leading you but you are thinking of some other approach which you think is an alternate correct and optimal solution, let the interviewer know about it.
• You should be well aware of the trade-offs you take while optimizing your solution. It is mostly about time-space trade-off.

Coding

• After discussing the solution and going back and forth until the interviewer is satisfied with the correctness and the time/space complexity of the solution, you can start coding if the interviewer asks you to.
• Be very sure about the solution before you begin to code. It is a huge red flag, if you’re changing your solution after starting to code or if you’re unable to articulate your solution to code quickly.
• Try to think about the overall structure of the code before you begin to code.
• Try to use meaningful variable and method names while coding to make the code more readable and understandable.
• Try to keep the code modular and ask the interviewer if it is ok to just write the method which takes some input and gives some output based on the problem statement. In most cases, you can avoid writing the main method.
• If there is some trivial code that is not part of the core logic, you can ask the interviewer if you can assume that there is a method that takes care of it. Ex: finding string length, sorting an array of pairs, checking if x is a substring of y, etc.
• If you’re unsure about an inbuilt function like whether push or add or insert is used for adding an element to a set, pick one and ask the interviewer if it is ok to assume that it is the inbuilt method to do the thing. Do not waste time in remembering which one of them is correct unless you’re supposed to compile the code.
• Dry run your code against the test cases before saying the interviewer that you’re done with the code. It would be good if you can find the failing test cases yourself instead of the interviewer doing it for you.

Some of these might not seem natural to you as you are not used to it. Doing peer-to-peer mock interviews and improving your interviewing skills with every mock interview is the best way to make it come naturally to you. Trust me, it is worth the time and effort. Mock interviews are a much better alternative to failing interviews because of bad interviewing skills.