How to prepare for data structures and algorithms interviews

career advice College computer science interview prep technical interviews
By Alena

When preparing for data structures and algorithms interviews, it’s crucial to put in time reviewing concepts and solving practice interview problems. However, it’s almost equally important to practice the structure of the live interview itself. Here are some tips for communicating and organizing your thought process as you’re being interviewed.

Check your understanding of the question

After the interviewer presents the problem to you, restate the problem in your own words to make sure your understanding matches the interviewer’s. If an example hasn’t been provided, consider providing your own small input and the expected output/behavior.

Now is a good time to clarify inputs and outputs. Think through special input cases (ie negative numbers, duplicates, empty inputs) and ask the interviewer about them. What is the desired output/behavior in that case?

One step at a time

It’s easy to feel overwhelmed and not know where to start. Remember, you’re not expected to think for one minute and write down a bug-free runtime-optimized solution. Interview problems are expected to be solved in stages. The next few steps describe some possible stages for thinking through the solution.

Describe the naive solution

Describing the simplest/brute force solution and its time complexity is a great place to start. The brute force solution is often a seed idea for more optimized solutions, and defining the brute force complexity gives you a benchmark to beat and demonstrates that you are already thinking about efficiency.

Think aloud through the problem

Thinking aloud is one of the hardest aspects of the coding interview process – we’re not used to narrating our own thinking process. I’d recommend that you practice thinking out loud while working on practice interview questions at home. 

If you’re not sure where to start on the problem, start simple and talk through elements you know the solution will have. Here are some things to think about (and describe out loud to the interviewer as you’re thinking about them!): 

  • What data structures could be useful?
  • Is there a related algorithm?
  • Out of common tools (for example, DFS/BFS traversal, dynamic programming, sliding windows, binary search), do you have ideas about which would be useful? Which ones won’t work, and why?

consider asking for input

If you feel you’ve stopped making meaningful progress in the interview, consider asking for input from the interviewer. Getting a hint and getting on the right track is definitely better than going down a path you suspect isn’t correct, or not making progress at all. Remember, the ability to self-correct is valuable as well! Asking for direction could look like this: “I tried to optimize the solution by keeping a list of already visited states, but I think I’m missing a more meaningful optimization. Is there an example input that might help me think of areas for further improvement?” 

Before writing code

At some point in the interview, you’ll have sketched out an idea, and your interviewer will ask you to write some code. It’s super tempting to jump in and get started as soon as possible! However, I’ve often seen candidates jump into code for a complex algorithm, then get slowed down setting up initial data structures/frameworks they discover don’t work as they progress in the solution. I recommend taking the time to define some details before coding, for example (depending on the type of problem):

  • What data structure will you be tracking visited states with? 
  • What data structure will you use to keep track of solution candidates? 
  • What are all the methods this class will need? 
  • What state does the class need to store? 
  • What is the stopping condition? 
  • How will you traverse the data structure?

 

Taking the time to lay out these details ahead of time, whether it’s in pseudocode, notes, or talking aloud, can help you avoid going down rabbit holes of unnecessary complexity.

Talk through the solution

After you’ve written the code, talk through the execution of your code on a small example input. This will help you catch bugs you’ve written or see areas of improvement.

Unit tests

If you have time at the end of the interview, think about unit tests you would write. Depending on the format of the interview, this could be verbally describing test cases, or if you’re using a coding platform, writing executable unit tests.

Remember, the coding interview is a flawed, probabilistic process, but with preparation, you can change the probability distribution. Good luck!

Comments

topicTopics
academics study skills MCAT medical school admissions SAT expository writing college admissions English MD/PhD admissions writing LSAT strategy GMAT GRE physics chemistry math biology graduate admissions ACT academic advice interview prep law school admissions test anxiety language learning MBA admissions premed career advice personal statements homework help AP exams creative writing MD study schedules Common Application test prep summer activities computer science history philosophy organic chemistry secondary applications economics mathematics supplements PSAT admissions coaching grammar research 1L law statistics & probability psychology ESL legal studies CARS SSAT covid-19 dental admissions logic games reading comprehension engineering USMLE Spanish calculus mentorship parents Latin case coaching verbal reasoning DAT PhD admissions excel political science AMCAS English literature French Linguistics MBA coursework Tutoring Approaches academic integrity chinese medical school Anki DO STEM Social Advocacy admissions advice algebra astrophysics biochemistry business classics diversity statement genetics geometry kinematics letters of recommendation mechanical engineering mental health presentations quantitative reasoning skills study abroad technical interviews time management work and activities 2L IB exams ISEE MD/PhD programs adjusting to college algorithms art history artificial intelligence athletics business skills careers cold emails data science first generation student functions gap year international students internships linear algebra logic poetry resume revising science social sciences software engineering tech industry trigonometry 3L AAMC Academic Interest DMD EMT FlexMed Fourier Series Greek Health Professional Shortage Area Italian Lagrange multipliers London MD vs PhD MMI Montessori National Health Service Corps Pythagorean Theorem Python Sentence Correction Shakespeare Step 2 TMDSAS Taylor Series Truss Analysis Zoom acids and bases amino acids analysis essay architecture argumentative writing art art and design schools art portfolios bibliographies biomedicine brain teaser campus visits cantonese capacitors capital markets cell biology central limit theorem centrifugal force chemical engineering chess chromatography class participation climate change clinical experience community service constitutional law consulting cover letters curriculum dementia demonstrated interest dental school dimensional analysis distance learning econometrics electric engineering electricity and magnetism enrichment escape velocity european history evolution executive function finance freewriting fun facts genomics graphing harmonics health policy history of medicine history of science hybrid vehicles hydrophobic effect ideal gas law induction infinite information sessions institutional actions integrated reasoning intermolecular forces intern investing investment banking lab reports linear maps mandarin chinese matrices mba medical physics meiosis microeconomics mitosis music music theory networking neurology neuroscience object-oriented programming office hours operating systems organization outlining pedagogy