Proper Prepping For DSA Interviews

13 tips on how to prepare for DSA style software engineering interviews

Welcome!

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: How To Prep For DSA Style Interviews

I dislike DSA style interview questions. A LOT!

I also understand why the big tech companies use them and I realise that whether I like it or not more and more software engineering interviews use them.

So here’s how I would tackle then and subsequently how I would prepare for them.

Doing The Interview

Following these six steps will maximise your chance of performing well in most coding interviews and in particular DSA focused interviews.

1. Listen carefully, then repeat the question - pay careful attention to the problem as your interviewer describes it. Then repeat it back to them in your own words. This will help ensure you’ve understood it and demonstrate to the interviewer that you have. Then if you haven’t they’ve got a chance to correct you before you spend time solving the wrong problem.

   Repeating the problem in your own words will also help you think through the problem more clearly, putting you in a good position to…

2. Check you assumptions - either by design or by accident (it depends on the quality of the interviewer) most of these problems are in some way ambiguous. Start writing down your assumptions and then ask questions to verify them. When you’re writing, say it out loud too - tell the interviewer what you are doing, aka ‘think out loud’ - they can’t read your mind.

   It’s always worth checking the following:

   1. Will the input fit in memory? Alternately what is the min/max/typical size of the input.

   2. Is the input always valid?

   3. Will the elements be unique / are duplicates allowed?

   4. Is there only one solution?

   5. Can I assume the input is sorted/not sorted (where appropriate)?

   6. What should it do for edge cases? For example, empty and single element inputs.

   7. What are the time/space constraints?

   8. If there is multiple outputs, should they be ordered?

3. Create some test cases - write down some example input and the expected output. This gives the interviewer another chance to spot any errors in your assumptions and some examples to work through when you begin to…

4. Sketch out some solutions - think out loud about some solutions. I’d often think about the brute force option first, the describe the time and space complexity of it. That gives you an upper bound for a target solution. Then consider a best cases (lower) bound. For example for an array based question that’s likely to be N, given you’ll need to visit every element at least once. Remember faster code often needs more space - consider the space / time tradeoff.

   Consider whether the best data structure is going to be an array, a linked list, hash table or tree. Having considered the best data structure and sketched out your solution it’s time to…

5. Write working code - Using the language you know best (more on this in preparing for the interview) start writing down working code. Implement the solution you sketched out. This should be the shortest of these six steps as you’re just writing up the solution and thinking you’ve done so far. Then when the function is done, be sure to…

6. Test your code - work through those tests cases you created in step 3. Check that your code handles the edge case and check that each example results in the right output.

Preparing For The Interview

The reality is most software engineers will fail a DSA style interview without preparation. It’s a skillset that we just don’t use regularly. So if you know it’s coming, you need to prepare. Here’s how I would prepare for the interview.

1. Use the language you know best, if in doubt use Python - you want to spend as little time as possible actually writing the code, leaving you as much time as possible to understand the problem, create tests and brainstorm solutions before writing the code, as well as leaving time to test the solution after writing the code.

   Therefore pick a language you know very well, or if in doubt pick Python as it’s fairly terse and the core data structures are all part of the language.

2. Learn Big O - Big O notation gives us a common notation to describe the limiting behaviour of a function / algorithm. Check your favourite algorithm text book for an explanation. Or hit reply and tell me I should write a post explaining it!

3. Practice - like many things in life, from building software to playing guitar we have to do the thing to get better at the thing.

4. Practice effectively - there are many people on social media boasting about doing 1000s of DSA problems, that’s wasteful. Group the problems by type, i.e. string related, two-pointer, linked list, etc. and solve enough of each type to be familiar with it then move on. Be consistent with your practice too, it’s better to do 30 minutes every other day than 3 hours once then nothing for two weeks.

5. Learn the patterns - There are common patterns and approaches. Learn what these are, i.e. two pointers for finding pairs, binary search to find something in a sorted list, sliding window to track a subset of elements.

6. Build muscle memory - return to some of the problems you’ve solved before and redo them. Get used to writing common implementations in the programming language you use.

7. Practice doing the questions as if you were doing the interview - don’t be tempted to visit one of the popular websites and read the problem, write some code and try it. Try to make your practice reflect doing the interview. Read the problem statement out loud. Reword it and make notes. Think out loud throughout.

If you do lots of DSA interviews, what other tips would you add?

Three Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I have a course on building your personal brand on LinkedIn, it explains how I’ve built an audience over over 180,000 followers on LinkedIn and changed my life.

3. I run a YouTube channel sharing advice on software engineering.