Recruiting advice: how to think your way through a technical interview problem

“Recruiting can be tough, but keep your head up and prepare as much as you need to until you feel comfortable with expressing your approaches to the problem and writing it out in code.”

Post by Erika Tan, second year UTCS Student

Recruiting is certainly tough and can be hard to manage with your classes, but enough preparation and a bit of luck should help you be well on your way to landing that internship! Here I’m going to walk through an example problem similar to the ones you might see in a standard SWE internship technical interview. Hopefully this will help you gain some insight on how to approach interview problems in general!

Question: Remove all duplicates in an array of integers.

The very first thing you should do in a technical interview is ask your interviewer any clarifying questions you might have. This way, you can also keep in mind edge cases for later. For example, in this problem, you might ask whether only one copy of the integer should stay if there are duplicates or all of them should be eliminated in the array. Furthermore, you could clarify whether duplicates means only two of the same integer are in the array, or there could be more than two. You might also ask if you can modify the array. In this case, the interviewer could say that one copy of every integer with multiple appearances (greater or equal to 2) should stay in the array, and the array can be modified. A new array should be returned from the function you write that holds the unique integers, and the integers can be in any order.

Once you have a clear picture of what you have to do, you can start brainstorming approaches. If nothing comes to mind at first, try to just communicate what the most obvious or brute force solution would be, then you can build upon that! As well, to help look for more optimal solutions, think of different data structures you can use, even ones that might sound out of the box at first. Remember that interviews are supposed to be conversational, so you can talk about the tradeoffs about your different approaches with the interviewer, too. Some ideas for this problem that might come to mind are:

• We need some way to keep track of integers that are already seen, so maybe we can use a hashmap with the integers seen as the keys and the frequency of the integer as the values. Declare a new array called result in the beginning, then loop over each entry in the original array. For every integer in the original array, put it in the hashmap and update the frequency correspondingly. If the frequency is greater than or equal to 2, then don’t insert this integer into result, otherwise do insert it.
• You might realize that we don’t even need to keep track of the frequencies in the previous solution. Instead, we could have a hashset that keeps track of integers we’ve already seen. While looping over the original array, if we haven’t seen an integer (it isn’t in the hashset yet), insert it into the set and result. Otherwise, just continue to the next element in the original array.
• If we sort the array in place first, we can just check adjacent elements to see whether they’re the same using two pointers, then delete duplicates in place. One pointer would be traversing through all the elements, and the other one would start at the element right next to the first pointer. Every time the second pointer’s element is the same as the first pointer’s element, delete the element at the second pointer. As soon as the element at the second pointer doesn’t equal the first pointer anymore, you know you can increment the first pointer to check the next item in the array.

There are a bunch of other approaches you could take to this problem, try to see if you can think of any more and what the tradeoffs between them would be! This is actually quite an open-ended problem, which makes it a good example because it lets you think of how you could leverage your data structures and algorithms knowledge in many different ways.

Finally, once you and your interview agree on a specific implementation, it’s time for you to write out your logic in code! No matter what problem you’re doing, it’s also a good idea to keep your code clean as you go along. That means choosing descriptive yet short (if possible) variable names, having a consistent format, and grouping pieces of code that seem the most logical together. It’s fine if you have bugs in your code the first time you write the solution, it’s even expected for you to! Just make sure to express all of the parts of your solution that you talked with your interviewer about in your code.

Once you finish, your interviewer may ask you to trace through an example test case. This requires going through your code, line by line if you prefer, and making sure all the variables get set to what they’re supposed to be, checking the logic is in the right order, accounting for edge cases, and anything else that’ll lead you to the correct solution. Sometimes, if a walkthrough of your code makes it seem like it will output the correct answer, interviewers may ask you whether you want to try out more test cases. If this happens, don’t hesitate to think of your own test cases that would test out different branches of your logic!

Finally, your interviewer will ask you to evaluate the time and space complexity of your solution. This is extremely implementation dependent, but a tip that might help is to remember that you’re being asked for the worst case complexity. So, if you’re stumped on what the answer should be, you could draft out what the worst test case would look like, and then quickly go over how your code would handle that test case.

Hope this helps and gives you a better understanding of what a technical interview would look like! Although we honed in on one specific problem for today, a similar thought process can be taken for interview problems of all kinds. Recruiting can be tough, but keep your head up and prepare as much as you need to until you feel comfortable with expressing your approaches to the problem and writing it out in code. Good luck!