Breaking It Down: How to approach any technical interview problem

A safe go-to recipe to figure out how to make any problem more manageable.

1. When you get the question (before you write a single line of code)

The easiest way to make sure you understand the question is to walk through test cases.

Always think of ways you can break down the problem. Is there a smaller, easier sub-problem that you can solve? And if so, what would that solution look like?

2. Writing the code (and what to do if you get stuck)

After you figure out your algorithm and explain your logic, the next thing for you to do is translate your idea into code.

At this point, brute force is totally ok. Creating a working solution (even if its runtime and space efficiency isn’t perfect) is far better than being stuck on trying to prematurely optimize your code.

  1. Try to use obvious variable names and make your code friendly to read
  2. Talk with your interviewer through your thought process and what pros and cons might come with your solution
  3. Make your code modular when possible (helper functions are your friends!)

About handling that awkward silence if you get stuck or need some time to think …

It happens to all of us, and it is perfectly normal to encounter this during an interview. In my experience, for almost all of my technical interviews there comes a moment when I need to think to myself and am unable to keep talking with the interviewer. When this happens, I usually say something along the lines of:

The interviewer is usually on your side and wants to see you succeed — just remember if he or she gives you a hint, never ignore it!

3. Reviewing your solution and adding optimizations

Once you’re finished writing your code, trace through it with a test case to make sure your program behaves the way you expect it to.

  1. Any off by one errors (especially when indexing or using a loop)
  2. Is there any repetitiveness in your code that you can clean up?
  1. Is there any room for improvement if you used a different data structure or slightly modified your approach?

When you reviewing your code, remember that it is entirely possible that you made an unintentional error — try to trace through your program as if it’s someone else’s work you’re seeing for the first time!

Wrapping it all up

Interviewing is a skill, and like any other skill it can be improved with practice! Working through technical problems, getting comfortable with your language of choice and data structures can all be work you do beforehand to increase your chances of a strong performance during the interview.

Remember that each interview is a learning experience and regardless of the outcome you’ve gained valuable insight that you did not have prior. Staying positive and learning from feedback is a great way to continuously improve! Good luck!

Full-time cat & dog lover, part time developer 💖 I like writing to help others! @helenzhxng | Previously @Paypal & @NASA , now @Squarespace— bit.ly/connect-hz

Full-time cat & dog lover, part time developer 💖 I like writing to help others! @helenzhxng | Previously @Paypal & @NASA , now @Squarespace— bit.ly/connect-hz