Steps Towards Problem Solving in a Technical Interview

While I was in college, every time the fall season would roll around, most of my friends would talk about how anxious they were for the school year to start again. For myself, I wasn't so much concerned with school as I was anxious about the beginning of Interview Season. 😱 It was a magical time when I would call up and message every technical friend I knew asking for references to their companies, and I would apply to every internship opportunity on Intern Supply, which BTW, is a great website for finding all the available applications for internships.

I was fortunate enough through the end of high school and into college that I had enough experience to get an interview, but I was never very good at performing in an interview. My first year, I landed interviews with Facebook, Google, DigitalOcean, and more, but I didn't get past the second (technical) round for any of them...I was frustrated, because I was never good at explaining my thought process on the technical problems they gave...until it dawned on me that I was overthinking everything and didn't go into the interview with any strategy.

Managing the Technical Question of an Interview

The steps below have helped me numerous times and I can attest to their ability to aid in landing that big job or internship!

It all starts with a question. The interviewer will give you whatever technical question they have in mind. Follow these steps and it should help reduce nervousness, maintain focus, and impress the interviewer.

Step 1: Clarify & Ask Questions

Once you receive the question, it is purposely going to be very vague. They'll give you something like the following:

Write a function to convert a string to a number.

That question sounds simple enough, but there's a lot we don't know yet about how they want us to solve it, so you should always clarify the question. This is when you want to think of edge cases, the general case, formatting, what are your inputs versus expected outputs...stuff like that.

Some examples for the question above would be.

• "Does this function handle whole numbers or decimals?"
• "Does this function handle positive and negative numbers?"
• "Will the input always be a properly formatted number?"
• "If a whole number, will the value be within the bounds of an int or a long?"
• And so many more...

Step 2: Create Some Examples

Now that our solution has a scope and some more meaning to it, we should come up with some useful example inputs to the problem. These will help us explain our solution, test our ideas, and ensure our code works. It is ideal in my mind that you create a few different examples.

• A basic, correct usage of the function. Come up with as simple of a usable input to showcase the algorithm you come up with. In our string -> number case, I'd pick inputs such as "25" and "-90". They are simple, but show our ideas work with positive and negative numbers, as well as with multi-digit. For a sorting algorithm, use a list of 3 numbers; few enough to be 'easy', but enough to call it sorting.
• An edge case or two usage of the function. If the function needs to worry about input, then place some weird inputs here as well. I'd use "0" by default, and maybe add "-" or "" if I needed to worry about input.

Step 3: Solve It On Your Own

Before you even start writing or thinking about any code, take your examples that you created, and solve the problem verbally. So many Computer Science students skip this part and jump straight into the code, only to wind up at a dead end or confused, which just wastes more precious time.

The advantage to this approach might become more clear with a basic sorting problem. Pretend like you don't know anything about coding or computers. If I give you three numbers, 15, 3, and -4, any reasonable person should still be able to tell me what the correct sorted order of those numbers is!

I tell people to follow the Explain Like I'm 5 mantra. Break down your solution into its smallest solvable parts.

"Well, given 15, 3, and -4, I can start with 15 as a baseline. I move on to the next number, 3, and see that it's smaller than 15, so I'll switch them. I then move onto the next number, -4, and compare it to the number next to it, 15. These two should also be switched. In the same fashion, 3 and -4 should also be switched, giving the sorted output -4, 3, 15.

The advantage to solving it without code first is that 1) it gives you fragments and solvable pieces to build your code, 2) it proves your solution works, and 3) it shows the interviewer that you do actually know how to solve the problem, which gives you some points in their book, even if you can't code it in time. It also shows the interviewer that you can hold a good conversation, solving a problem out loud.

Step 4: Write Some Code

Know that you know how to solve the problem, writing the code should be pretty easy! If you explained your solution clearly and simple enough, translating it into code should be fairly straightforward.

Just remember to talk out loud as you are writing your code, explaining what and why you are doing what you are. It will help the interviewer gauge what is in your head.

Step 5: Test Using Your Examples

Every time you think you are close to being done or finish your solution, test it out loud with the examples you came up with in Step 2. As meticulous as it is, go through every loop iteration, write down the values of variables at every step, and make sure you don't miss anything! Interviewers want to see someone who takes pride in knowing that their solution is correct!

Step 6: Explain and Optimize

Once you know you have a solution, finish explaining anything that wasn't covered in the earlier steps. This is the time to introduce and explain your solution's runtime and memory efficiency, so that the interviewer knows you are aware of those restrictions. Explain what part of the code causes the slowest or most consuming efficiency. If you don't have enough time to implement it, then explain how you can optimize certain parts of your algorithm.

Step 7: Repeat!

Go back to step 4 until you run out of time! Keep improving, testing, and optimizing your algorithm until your interviewer says that its good enough!

Hopefully you have impressed them by this point.

Some Interview Tips & Tricks

• Get used to writing on whiteboards. You'll undoubtedly end up using one, so the sooner you get adjusted to it, the better off you will be.
• The interviewer wants you to get the job, and they want to help you. This is the best tidbit I received from my friend who is a lead recruiter at a large company. Granted, some companies are more impersonal than others (looking at you Facebook), but this rings true for most interviewers and their companies. If you landed an interview, that means they are already interested in you. So just relax, and talk to the interviewer like you would a colleague.
• Technical interview questions are not meant to be crazy long problems. They are purposefully designed to be solvable within 5 - 15 minutes. This means that more than 90% of them should not be more than 30 lines long. The goal is to get you to think of an ingenious, outside the box solution, instead of coding a lot.
• Keep your cool. If you get stuck, just stay focused and interested in a problem. The interviewer is there to help you. Story time: I had a Microsoft interview where I had no clue about the answer, but I did what I would do if I was working at the company; I talked it out with the other engineer in a professional manner, taking his tips and slowly building together a solution. Although he basically gave me the answer, he still passed me, because of how well I could hold a technical conversation and learn on the spot.

Good luck on your interviews! I hope this Interview Season treats you well! Share if you land anything, and I'll be sure to congratulate you!

Comments

[Jean-Michel Plourde]

Google has amazing videos on YouTube on how to perform well in whiteboard interviews. The recruiter is an actual Google recruiter and the guy on the whiteboard is a Google engineer that did this kind of interview many times. There is a lot of valuable tips and tricks.

Great article. I myself haven't had many whiteboard interviews but I'll keep in mind these tips.