The technical interview process can feel like a daunting challenge for a new developer just beginning to dip her toes into the industry. Luckily for me, I recently had the good fortune of connecting with a wonderful developer, Abby Tiffany, who talked me through a great framework to reference in future technical interviews.

Side Note: I connected with Abby after hearing her awesome episode as a guest on Lauren Lee's podcast We Belong Here: Lessons from Unconventional Paths to Tech. I would highly suggest giving it a listen!

For this blog post I will be walking you through an example technical interview problem and talking you through the steps Abby outlined.

Our example problem: Given an array, remove any duplicate values and return an array that contains unique values.

Step 1: Reiterate the Question

Before diving into the problem being presented before you take a few minutes to think about what is being asked and repeat it back to your interviewer. You may have heard the interviewer ask one thing but the intent of their question might be entirely different.

Step 2: Clarify your Assumptions

This is your time to ask clarifying questions! Don't assume that you have correctly interpreted the interviewer's question and expectations.

Example questions can include:

• When you say to remove duplicate values do you mean such that each element only appears once? Or should any value that has appeared more than once be completely removed from the array?
• Will my input always be an array?
• Will I ever be given an empty input?
• What should my code return if the target is not found?
• Should I treat a -1 equal to a 1?
• How should my code treat input with a single item?
• Is the input sorted? If so - descending or ascending order?
• Should the array be updated in place?

Step 3: Create Test Cases

Now that you have an understanding of the problem itself and the input/output that you should be expecting take the time to write down a few tests cases that you can utilize to proof check against. Ideally, your test cases will cover a variety of different inputs (ex: expected input, empty array, negative numbers/etc).

Example test cases could include:
Test case 1: [0,1,1,4,9]
Test case 2: []
Test case 3: [-1,0,1,2,2,2,3,10]
Test case 4: [1]

Step 4/5: Discuss/Execute a Brute Force and/or Optimized Solution

In an ideal world you should be able to speak to a brute force solution and execute your optimized solution on the whiteboard. However, there are going to be problems you run into that are just hard. Maybe you can only think of the brute force solution - in that case execute the brute force solution and talk through how you would think of approaching it differently or optimizing it on a next iteration. Keep it mind that you should only be writing down either a brute force or optimized solution. You will not have time or whiteboard space to do both.

Now you may ask - but why would you discuss the brute force approach if maybe you know an optimized solution off the bat? Interviewers want to know what you know and they can't know it unless you speak to it. Being able to speak to both approaches shows how much you know and that you did not just memorize the answer to a problem.

Brute Force

A way to approach our provided example problem could be to iterate through each item in the array, compare it against every other item in the array and delete any duplicates.

This approach would definitely meet the requirements of the problem however it is not the most efficient way for us to approach this. Comparing every item against every other item would result in a time/space complexity of o(n^2) as the worst case scenario would be asking the computer to compare every permutation within the array. We can definitely do better!

Optimized Approach

A better way of approaching our provided problem might look like the below:

• Create a Hashtable (or Dictionary) with a default value of 0
• Iterate through the values in the array
• Check to see if the item you currently are looking at is already a key in the Hashtable
• If yes, set it equal to nil (or any other value to reference for future deletion)
• If no, add it as a key with a value of 1 to the Hashtable and move on!
• Return your adjusted array at the end of the program

def remove_duplicates(arr)
    return if arr.length <= 1
    count = Hash.new(0)
    arr.each_with_index do |number, index|
        if count[number] != 0
           arr[index] = nil
        else
           count[number] += 1
        end 
    end 
    arr.delete(nil)
end 

This is a more efficient approach to this problem because it only requires you to look through each value to check for duplicates in one loop then look for deletion in a separate loop (.delete) giving you a time/space complexity of O(n).

Step 6: Test your Test Cases

Now that you have spoken to the brute force approach and executed an optimized version it's time to reference those test cases that you took the time to brainstorm earlier. Take each test case and walk it through your optimized solution as a way of potentially uncovering any bugs in your code or proving it!

Step 7: Discuss Time/Space complexity

This can be the form of a further discussion with your interviewer on the time/space complexity of your optimized solution and if there are any opportunities for improvement. Your interviewer might even have questions on how your could adjust your code to fit a different time/space requirement.

This might sound daunting but Big-O doesn't have to be a Big-Oh No! I won't apologize for that terrible joke but I will provide you with some resources at the end of this post to supplement your understanding of Big O notation if you are a technical interview newbie like myself.

YMMV

This is only one approach and it might not fit the way you noodle out problems but that is ok! Finding what works best for you is essential and having a process for how you tackle problems in the way that works for you is a great way to help you feel confident in the technical interview.

Do you have any other tips or tricks that you like to utilize for the technical interview process? I would love to hear them!

Interview Preparation Resources

• Cracking the Coding Interview
• Base.cs
• LeetCode
  • Tip from Abby: Don't spend more than 45 minutes at a time on practice problems. Give your brain a break.
  • Note from Author: I can attest that this is good advice and that spending 5-6 hours on practice problems per day will turn your brain into mush.
• Intuitive Guide to Data Structures and Algorithms
• Looking for the Logic Behind Logarithms
• Big O cheatsheet
• GeeksforGeeks
• Meetups! There are great coding interview prep meetups available and pairing with a real person is always a plus.