Optimal Timeline for Data Structures and Algorithms Interview
Nirmal Thacker had a presentation at WomenWhoCode Silicon Valley about how to optimally timeline a 45-minute Data Structures and Algorithms interview. Nirmal is a software engineer with 10+ years of industry experience who’s spent in interview bootcamps and has done several sessions on this topic. He finds that despite good preparation, most candidates do not have a plan or template on how to structure the interview but finds it very useful to think of the time of an actual interview in a systematic and structured way. During his presentation, Nirmal spoke about optimal and non-optimal interviews, sequencing a 45-minute Data structures and Algorithms interview, assessing yourself, iterating and improving, and answered his presentation audience questions.
Typically the average Data Structures and Algorithms interview is 45 minutes where a candidate is asked to write an optimal function given the input and the output of the function. When preparing for the actual interview it’s good to check out online tools/programs like Leetcode and practice problems that cover such broad topics as stacks and queues, linked lists, trees, graphs, dynamic programming, recursion, greedy algorithms. Pick one language that you’re comfortable with and solve 2–3 problems each week. Don’t be anxious about coding and don’t get overwhelmed — if you do a sufficient number of interviews you’ll become comfortable with this all!
Non-optimal interviews involve such patterns as non-optimal timing, offering a solution before understanding the problem, getting rushed and trying to read the interviewer’s face. These non-optimal patterns often don’t lead a candidate to success. Whereas the optimal interviews may lead them to success. In optimal interviews a candidate is aware of time and has a stopwatch. They use conversational hooks to start coding and are ready to jump into a new conversation. The candidate is humble and decisive in determining what the next step is. The optimal timeline of an interview shows that coding happens in the later one third of the spectrum which means it happens much later in the interview and there are a lot of things that happen before it that set it up successfully for the coding section to be executed well enough. The pacing goes from medium to slow to fast. Having this timeline is very valuable and it’s important to use it in an adaptive sense!
Breakdown of the Interview
- Scoping
- Brute Force
- Optimal Solution
- Coding
- Walkthrough
- Buffer
Scoping
The first 5 minutes of the timeline is called Scoping. The goal here is to get as much data as possible about how the solution behaves under different inputs and outputs. Very often before the interview a candidate tends to make up a problem in their head that they’re going to solve in the actual interview. However, this high level of anticipation needs to be resisted and a candidate must spend those minutes thinking of the problem as a black box. Most questions that appear in these interviews have examples to them with their inputs and expected outputs. Paying attention to those examples and understanding them can be of great value. Imagine what’s going on with those inputs and make your examples!
Brute Force
The second 5 minutes of the timeline is called Brute Force. In this phase the candidate must arrive at a brute force solution using simple building blocks like loops and spell out the complexity of the problem without coding the solution. Sometimes brute force is a completely different direction from an optimal solution. It’s very hard to know that early on. If you’re familiar with a problem or have a good idea that it came up during your preparation and can directly go to an optimal solution, then you can skip the brute force. This stage is just a quick win!
Optimal Solution
The next 15 minutes of the timeline is called Optimal Solution. This phase is the hardest part. In this phase a candidate should mostly rely on some of their instincts and make small, good decisions that are incremental. Eventually, interviewers will notice that honest approach and this is when the candidate will get the clues and hints. The goal is to show a senior engineer mindset. That is, think about the problem abstractly and talk about complexity of the algorithm early on. Pseudocode the solution as much as possible on the whiteboard and visualize the solution in mind before coding. Make sure that the interviewer is able to follow every step of the solution and put the things out which will later simplify the code. The time spent for communicating the solution depends on whether the candidate is introverted or extroverted. But the communication channel is open all the time. If a candidate doesn’t have any clue about the answer, they just need to communicate efficiently and don’t ask for direct clues but trust the process. Asking questions that can give the data to help you arrive at the right solution is very good!
Coding
The next phase is the Coding phase which lasts 10 minutes. This phase actually feels like copy-paste. When the coding begins, what is happening is actually cheating as the candidate has figured out the optimal solution and wrote the solution from the ground up already. Typically, the candidate glances for bugs and fixes the minor typos, errors that he finds and moves into the next phase which is called Walkthrough.
Walkthrough
The Walkthrough phase lasts 5 minutes. The goal here is to have this unit test mentality and hit every line while walking through the code. Take the examples from the Scoping part and start slow, then speed up. Sometimes the Walkthrough discovers some test cases that the candidate missed out initially. If it is an edge case, then it’s fine. But if it’s a major case, then it needs to be refined. To avoid such cases it’s recommended to spend more time in the optimal part to discover all test cases. The optimal solution should be applicable to most of the inputs. In most cases the edge cases are going to have a simple resolution: they are either going to be a specific step that you need to perform at the optimal solution or something that needs to be done before starting computing the optimal solution.
Buffer
It’s always a great idea to assess yourself after an interview. Use self-assessment and interview worksheets to do that in your interview practice sessions. Iterate and improve — be patient and have trust in yourself!
It’s always a great idea to assess yourself after an interview. Use self-assessment and interview worksheets to do that in your interview practice sessions. Iterate and improve — be patient and have trust in yourself!
At the end of the presentation there was a short Q&A with Nirmal. One of the questions was about the kind of a situation where a candidate can’t crack the question. Nirmal said that in a scenario where a candidate is stuck, it’s valuable to have a brute force solution outline. And to the question of how much effort a candidate should put into practicing problem-solving, Nirmal suggested giving themselves 2–3 months of preparation, preparing for it with a mindset of preparing for an exam, and most importantly, having fun with the process!
This blog is a summary of an event run by the WomenWhoCode Silicon Valley on July15, 2020. You can view the recording of the event below.
🙋 View and register for our upcoming events at http://bit.ly/siliconvalley_events
