How to Answer Any Technical Interview Question

shutterstock_Stokkete

For most of us, technical interviews are the worst part of getting a new job: Not only does the interviewer ask challenging questions, but sometimes those questions don’t even make sense in the context of the job you want.

No matter how tough the question, however, remember that bluffing is rarely your best option. Instead of trying to fake an answer, honesty is usually best. Saying something like, “I am less familiar with [X skill], but I am familiar with [Y skill], and can share my thoughts in that context” can move the conversation forward in a productive way. (If a skill is important to the job and you really don’t have it, it’s always better to be honest from the beginning.)

Check out the latest developer jobs.

Most technical questions are designed to reveal how you think, communicate, and solve problems. That means two candidates can arrive at the same (correct) solution to a problem, yet still be judged differently based on how they arrived at that answer.

Having sat on the other side of the table and interviewed over 700 software engineering candidates, I have some strong opinions on good and bad answers. I want to share with you the best strategy for handling technical questions, especially when you don’t know the answer.

Make Sure You Understand the Question

Sometimes when you are given a challenging question, it is difficult to answer because you don’t fully understand what the interviewer wants. (To be fair, sometimes interviewers are intentionally ambiguous, in order to get you to ask clarifying questions.) When faced with a hard question, verify you understand it.

For example, if you’re asked to “traverse a tree,” you really don’t know enough yet to solve the problem. What is the structure of the tree? Should you traverse it in a particular way? Ask questions to make sure you really understand what you’re trying to solve, before you actually start solving the question.

Work Through Examples

Once you understand the question, use any available examples to help solve the problem; examples allow you to pick up on patterns and generalizations that apply to the question at hand. You should work through basic, simple examples and avoid things that could be edge cases that could throw you astray (i.e. null, 0, 1, -1, etc.).

Come Up With the Easiest, Most Obvious Solution

Sure, we’d all like to come up with brilliant solutions to problems—but if you’re on a tight deadline, sometimes the most direct one is best. The latter also shows the interviewer that you can come up with a baseline solution, atop which you can further iterate.

For example, let’s say the interviewer asks you how many golf balls would fit inside a 747. (Yes, many employers still ask those sorts of crazy questions, just to see you work the problem.) Coming up with a quick solution, just to show you’re capable of thinking things through logically, also buys you time to further optimize it. Speaking of which…

Always Look for Improvements

Never leave a “bad” solution in place. Think about how you can refine it, hopefully while doing less work computationally. Can you store intermediate results so you don’t have to recompute them? Can you use other information to your advantage so you can do less work?

Arriving at an initial solution is a great point to ask more questions of the interviewer. Are there things you might be missing? Resources you should be taking advantage of? Most interviewers are interested in whether you can ask intelligent questions.

Work Through More Examples

If you get stuck, or aren’t seeing a better way, try working through more examples—pick smaller and bigger ones to see if you can notice new patterns that can help you solve the main question.

Don’t Give Up

If you get stuck, keep iterating through more examples, and thinking about how the problem at hand (hopefully) bears similarities to ones you’ve solved in the past. If you’re given a brainteaser that stumps you, consider asking the interviewer whether you can do a similar problem to which you actually know the answer.

Even if you never land on an ideal solution, showing that you are calm and resourceful under pressure is still a good thing to demonstrate to the hiring manager.

After you arrive at a solution, talk the interviewer through your work. If you had to figure out a solution while actually on the job, what would you do? How would you verify the answer was correct?

Do your best not to get frustrated or discouraged. (Given the length of job interviews these days, you may still have a long day ahead of you.) Take a deep breath and keep trying. Most interviewers will admire your tenacity, which is a great trait in any employee.

Follow Up

If you don’t get the best answer, make a note in your notebook (you brought something to take notes on during the interview, right?) and come back to it after the interview. Don’t be afraid to keep working on it and send in the right answer that evening if you figure it out. This may not help you get the job, but it will help you learn and become a better interviewee (and if you were close, it can help you get your foot over the edge into the door of a great new job).

The key to answering hard technical questions is to focus on what you know. Do you understand the question? Can you work through some examples? Can you come up with a solution you know would work (even if it isn’t optimal)? Hopefully this strategy helps you ace your next interview.

Upload Your RésuméEmployers want candidates like you. Upload your résumé. Show them you’re awesome.

Related Articles

Image: Stokkete/Shutterstock.com

Comments

2 Responses to “How to Answer Any Technical Interview Question”

April 17, 2015 at 5:11 pm, Ragu said:

There are tons of blogs like this online as well as numerous books online on how to “crack the coding interview” the truth is, every interviewer has their own opinion as to what “a good answer” is. For instance to me I don’t care about the code in an interview I care about the algorithm and approach more than anything. In real production code you will have acceptance criteria to validate the correctness of the implementation and a set of tests.

If you want to measure programming style give the interviewer an assignment (implement an storage service ) and you will get a good sense as to how he/she writes code. If the code is horrible or if he/she doesn’t provide unit tests I would pass even though he/she might be the brightest algorithm solver. At the end of the day is about 5 or 10 or 15 people who need to be able to understand that code base to deliver a benefit to the customer. This is not possible when the code is unreadable or only one person understands it.

My point is that “cracking” is a myth as really you have to in a way convince the interviewer that you are qualified for the job with an answer that he likes or approach that he likes. Unfortunately this becomes a personality matter what’s a good answer to interviewer A might not be a good answer to interviewer B (the anti loop). It is even more troublesome when the interviewers are not even team members the candidate might work with (we hire for the company not for a specific team).
This is all great if your company receives millions of resumes and can afford to sponsor visas.

In my years of experience as interviewer and interviewee there is no formula other than approaching jobs in brute force manner which is sad, apply to 10 jobs, interview sequentially and 1 or more are bound to work or the same questions might be re-asked by and then you can “ACE” the interview.

Interviewing is a game just like dating after awhile (once in production) the real you comes out and my experience has taught me that a good interviewer not always is a good software engineer.

Reply

August 16, 2015 at 7:51 am, emilov said:

Sometimes a solution is much easier to code in a language, e.g. scripting, that most of the team may not know… yet. Should we restrict the usage of such languages… if there are not enough people who understand it?!

Reply

Post a Comment

Your email address will not be published.