The Four Categories of Technical Interview Question (and how to ace them)

When you’re preparing for a technical interview, it can be difficult figuring out what you should study. Do you spend your time brushing up on algorithm analysis? Do you study the programming languages they have listed in the job requisition that you’re rusty on? Where do you start?

To take a page (the front page specifically) from Hitchhikers Guide to the Galaxy: Don’t Panic!

When doing a technical interview, there are 4 basic categories of technical interview question that you’ll get. Knowing what these are, and developing a strategy for answering them, will help you ace any technical interview.

The Four Categories of Technical Interview Question

1. Situational Problem Solving Question

“Tell us about a time that you were working in a team and had a conflict. How did you resolve it?”

The situational problem solving question focuses on managing situations within a team or with other people. No matter how much of a genius you are, if you make your coworkers lives a living hell, you’re probably not going to get the job.

Situational problem solving questions are designed to figure out how you work in a team and how you handle conflict. They may also be customer service questions, exploring how you handle working with clients or customers when things “aren’t going right”.

Strategies for Answering

A successful answer to this type of question demonstrates your ability to be diplomatic and compassionate. You’ll often encounter conflict in your professional life, especially if you get good at what you do, so you should be prepared to handle that.

• Show compassion and diplomacy

Nobody likes to hear “I told you so” and nobody wants their career impacted by a mistake. When resolving conflict, be sure to show compassion in your answer. Talk about how you listened to the other opinion, and how you were able to win over the team.

• Be firm but polite

If you’re right and you have evidence, don’t concede just to end the conflict. Conflict is bound to happen, and those that are willing to speak their minds and hold their ground save a business time and money in the long run.

The interviewer is looking for someone who is willing to listen to opposing viewpoints and stand by their answer when they’re right.

• If you don’t have a story, make one up

If you don’t have a compelling story, be honest with your interviewer and tell them that you haven’t encountered that particular situation. Follow that up by telling them what you would do in that situation using an illustrative story. Just don’t spend all your time trying to come up with a story and “not having a good one”. Prepare ahead of time by knowing what stories you want to tell and what soft skills you’d like to emphasize.

• Do not talk about race, politics, or being a victim

Talking about an issue that’s out of your control (a racist coworker, office politics, or how a former manager just “didn’t like you”) doesn’t make you seem like a strong, independent worker. It makes you seem like a child that will require a great deal of time and energy to resolve your conflicts.

Even if you did encounter a racially or politically sensitive issue, don’t use it to answer the situational question. Employers are interested in hearing how you’ll solve problems in their organization, and by answering with a story that involves these topics, you’re projecting to the interviewer that you expect to encounter these issues at their company.

2. Conceptual Problem Solving Question

“How many standard U.S. quarters would it take to stack to the height of the Empire State Building?”

Conceptual problem solving questions may seem odd at first if you’ve never gotten one, but they’re very common in interviews at large companies (Google and Microsoft are famous for them).

Often times in programming, you’ll have to solve problems before you have all of the information you need to solve them. Conceptual problem solving questions are designed to figure out how you solve problems when you don’t have all of the information you need to solve them.

Strategies for Answering

• Ask how precise the answer needs to be

The first question you should ask the interviewer is, “How precise do you need the answer to be?” When we (as programmers) encounter these situations in the real world, knowing the answer to this question is critical.

Most of the time, the interviewer will say something like “within an order of magnitude” or within “10x up or down from the correct answer”. This is a VERY broad range, and covers most of the assumptions you’ll need to make.

If the interviewer says the answer must be precise, ask them for specific information (i.e. how tall is a quarter, how tall is the Empire State Building). If the interviewer says you don’t have that information, you can tell them that you don’t have enough information for a precise answer.

• Document Your Assumptions and Explain Your Logic

Once you’re able to start working on the problem, solve it by filling in the parts that you don’t know with guesstimates. Using the quarter / empire state building example above, you can start by saying “I’ll make the assumption that there are 6 inches in a quarter roll of 40, so there are 2 quarter rolls in a foot which is 80 and 120 inches in 10 feet, so 800 quarters for every story”.

These are complete guesses and probably wrong, but that’s ok. You can be imprecise if they’ve given you permission to be, and you can always replace bad assumptions with more accurate data later without impacting the validity of your logic.

3. Softball Technical Question

“Explain the concept of prototypical inheritance in Javascript.”

Softball technical questions expect a specific answer in a short amount of time. These questions can usually be answered in a maximum of 5 minutes and address a specific technical issue.

Strategies for Answering

• You either know it, you don’t know it, or you kinda know it.

Prepare yourself for each of these situations: When you know the answer, when you kinda know the answer, and when you don’t know the answer.

• If you know it, talk about it (and everything around it)

If you know the answer, the first thing you’ll want to do is tell them the answer. You can also talk about other concepts if they are related. In the example above, you could explain prototypical inheritance in general and expand that into a discussion about creational design patterns.

• If you don’t know it, confess and talk about something related

If you don’t know the answer, your interviewer is going to know immediately if you try to “fake it”. Be honest and tell them you don’t know the answer.

However, even when you don’t know the answer, you can still salvage a interview by talking about everything you do know related to that topic. For example, if you don’t know about prototypical inheritance you can talk about object-oriented inheritance instead. They may interrupt you to move the interview along, but at least they understand that you know the topic and can relate it to other topics.

• If you kinda know it, say what you know and talk about everything related.

All of these strategies boil down to one thing: tell them what you know. In school you can’t get partial credit if you don’t turn in the assignment, and the same thing applies for interview questions: if you don’t tell them what you know, they have to assume you don’t know anything. Tell them what you know — even information that is tangentially related.

• If it’s on your resume, prepare to talk about it.

Anything on your resume is fair game, so don’t put a skill on your resume that you’re not ready to use in the interview.

4. Hardball Technical Question

“Write a program that takes a phone number as input and returns all of the words that you could make if used the letters printed on a telephone for that number.”

Hardball technical questions take longer to answer than softball technical questions. Typically these questions take 15–20 minutes to answer, but vary widely — from 10 minutes to a week or more.

The goal of a hardball technical question is to find out how you write code and to see that you can solve a problem using algorithmic thinking.

Strategies for Answering:

• Start with the naive implementation

The naive implementation is what you might call the “quick and dirty” implementation. If you can solve the problem using a less than optimal algorithm, do it that way first because a complete but naive answer is better than an incomplete answer.

• Talk about optimizations you would do, but DON’T do them yet

As you’re working through the naive implementation, make sure to talk about ways you could optimize your answer as you answer it. Interviewers like to know that you understand there is a better answer and that, given more time, can think about and solve the problem in a more optimal way. Just don’t optimize yet — make sure you have a complete working solution first. Explain your logic out loud so the interviewer has some insight into your thought process.

If you have time to optimize, start with optimizations that you can do easily so you can show how you optimize answers.