I’ve conducted over 600 technical interviews on interviewing.io. Here are 5 common problem areas I’ve seen.

Hey, Aline (founder of interviewing.io) here. This is the second post in our Guest Author series The first post talked about red flags you might encounter while interviewing with companies. Complementarily, this post, authored by one of our prolific, long-time interviewers, explores common missteps that interviewees make.

One of the things I’m most excited about with the Guest Author series is the diversity of opinions it’s bringing to our blog. Technical interviewing and hiring is fraught with controversy, and not everything these posts contain will be in line with my opinions or the official opinions of interviewing.io. But that’s what’s great about it. After over a decade in this business, I still don’t think there’s a right way to conduct interviews, and I think hiring is always going to be a bit of a mess because it’s a fundamentally human process. Even if we don’t always agree, I do promise that the content we put forth will be curated, high quality, and written by smart people who are passionate about this space.

If you have strong opinions about interviewing or hiring that you’ve been itching to write about, we’d love to hear from you. Please email me at aline@interviewing.io to get started.

Ian Douglas

William Ian Douglas goes by “Ian”, and uses he/him pronouns. He lives in the Denver, Colorado region and graduated from a Computer Engineering program in 1996. His career spans back-end systems, API architecture, DevOps/DBA duties and security, and has been a team lead managing small teams, and Director of Engineering. Ian branched out into professional technical interview coaching in 2014, and in 2017 pivoted his entire career to teaching software development for the Turing School of Software & Design in the Denver area. He joined interviewing.io as a contract interviewer in the summer of 2017 and is a big fan of the data analytics blog posts that IIO produces to help expose and eliminate bias in our tech industry interviews. Ian writes technical coaching information at https://techinterview.guide and you can reach him on Twitter, LinkedIn and GitHub.

I recently conducted my 600th interview on interviewing.io (IIO). I’d like to share lessons learned, why I approach interviews the way that I do, and shed some light on common problem areas I see happen in technical interviews. Every interviewer on the platform is different, and so your results may vary. We have some excellent folks helping out on the platform, and have a wonderful community working to better ourselves.

The interviewing.io Mock Interview

During our interviews on IIO, we rate people on three 4-point scales. A score of 1 means they did extremely poorly, and a 4 means they did extremely well in that category. I typically start my interview where everyone gets 3 out of 4 points right away, and then earn/lose points as the interview goes on.

Every interviewer on the platform will have some aspect that they favor over others. My own bias as an interviewer tends to be around communication and problem solving, which I’ll point out below.

Technical Proficiency

In this category, I grade a candidate on how proficient they seem in their language of choice, whether they had significant problems coding an algorithm of a particular style, if I needed to give a lot of hints during coding.

Problem Solving

Here, I grade a candidate on how well they break the problem into smaller pieces, come up with a strategy for solving the smaller problems, and also debugging issues along the way. The ability to think through problems while debugging is just as important as writing the code in the first place. Are they stumped when a problem happens, or are they able to find the root cause on their own?

Communication

Interviewers really want to hear your decision-making process. This is also very important when debugging code. I tended to hire folks who would fit in well on smaller teams or clusters of developers. With that in mind, collaboration and easy communication are a good way to win me over.

Common Problem Areas I See in Interviews

Here are the top problem areas I see in interviews, not just on IIO, but in general. I hope you find this advice helpful.

Common Problem Area 1: Jumping into code too soon

I see this in developers of all types and levels, but mostly in the “intermediate” level of 2-5 years of experience. They hear a problem, talk about a high-level design for 30 seconds or less, and are eager to get coding. They feel like they’re on a timer. They want to rush to get things finished. It’s a race to the finish line. First one across the finish line is the winner.

Right?

Nope.

Please, slow down. Plan your work. And share your thought process along the way.

People who take time to think out a mid-level design, whether that’s pseudocode or just writing out notes of their approach, tend to spend less time debugging their code later. Folks who jump right into coding fall into what I call “design-as-you-go” problems, where you’re spending lots of time refactoring your code because you need to change a parameter passed or a return value, or wait, that loop is in the wrong place, etc.. This is very easy to spot as an interviewer.

Spending some time on mid-level design doesn’t guarantee your success, but it might save you time in the long run by thinking through your plan a little deeper, and that extra time you bought could be used to fix problems later.

Also, as an interviewer, I want to see you succeed. Especially if you’re “on-site” (in person, or remote nowadays) because you’re costing our company a lot more money in an on-site interview process. While I need to be fair to all candidates in the amount of help I can give, if I can see your design ahead of time, and spot a flaw in that design, I can ask leading questions to guide you to the problem and correct your approach earlier.

If you jump straight into code, I have no idea if your implementation is even going to work, and that’s not a great place to put your interviewer. It’s much harder for me to correct a design when you have 100 lines of Java code written before I really understand what’s going on in your code.

I saw this lack of planning backfire in a horrible way in a real interview in 2012. The candidate was brought to my interview room by someone in HR, asked if they would like a bottle of water, and promised to return. We introduced ourselves and got down to the technical challenge. The candidate shared no details, no design, barely talked about a high-level approach, wrote nothing down, and started writing code on a whiteboard. (This would be my second-to-last whiteboard interview I ever conducted, I hate whiteboard interviews!) HR showed up a few minutes later, knocking loudly on the door, offering the bottle of water and leaving. The candidate, grateful for a drink, uncapped the bottle and started to take a sip when this awful, draining look came over their face. The distraction of delivering a bottle of water made them completely lose their train of thought, and I couldn’t help them recover because they hadn’t shared any details with me about their approach. They spent several minutes re-thinking the problem and starting over.

On the “other side” of this coin, however, you can spend “too long” on the design stage and run out of time to implement your genius plan. I’ve seen candidates talk through a mid-level design, then write notes, then manually walk through an example with those notes to really make sure their plan is a good one, and now they only have a few minutes left to actually implement the work. Extra points on communication, maybe, but we need to see some working code, too.

So what’s the best approach here?

I typically recommend practicing until you spend about 5 minutes thinking through high-level design choices, 5 minutes to plan and prove the mid-level design, and then get to work on code. The good news here is that “practice makes better” — the more you practice this design break-down and problem solving, the better you’ll get. More on this later.

Common Problem Area 2: Communicating “Half-thoughts”

This is a term I’ve coined over the years, where you start to say a thought out loud, finish the thought in your head, and then change something about your code. It usually sounds something like this:

“Hmm, I wonder if I could … … … no, never mind, I’ll just do this instead.”

Back to my bias for communication.

Interviewers want to know what’s going on in your thought process. It’s important that they know how you’re making decisions. How are you qualifying or disqualifying ideas? Why are you choosing to implement something in a particular way? Did you spot a potential problem in your code? What was it?

This missing information is a hidden treasure for your interviewer. It takes mere seconds to change your communication to something more like this:

“I wonder if … hmm … well, I was thinking about implementing this as a depth-first-search, but given a constraint around ___ I think a better approach might be ___, what do you think?”

That took maybe 2 or 3 extra seconds, and you’ve asked for my opinion or buy-in, we can consider possibilities together, and now we’re collaborating on the process. You already feel like my future coworker!

Common Problem Area 3: Not asking clarifying questions

An interview challenge I often ask as a warm-up question goes something like this:

You have a grouping of integer numbers. Write a method that finds two numbers that add up to a given target value, stop immediately, and report those numbers. Return two ‘null’ values if nothing is found.

This is a great question that shows me how you think about algorithms and the kinds of assumptions you make when you hear a problem.

I’ve been coding for a pretty long time. Since 1982, actually. There’s no data structure called “a grouping” in any language I’ve ever used. So what assumptions are you going to make about the problem?

Most candidates immediately assume the “grouping” of numbers is in an array. You can successfully solve this problem by using an array to store your numbers. Your algorithm will likely be an O(n^2) (n-squared) algorithm because you’ll be iterating over the data in an exponential way: for each value, iterate through the rest of the values. There’s a more efficient way to solve this in O(n) time by choosing a different data structure.

Go ahead and ask your interviewer questions about the problem. If they tell you to make your own assumptions that’s different, but ask if they’re good assumptions. Ask if there are alternate data sets that you’ll be using as test cases which could impact your algorithm.

Common Problem Area 4: Assuming your interviewer sets all the rules

Wait, what?

Yeah, you read me right.

Yes, you’re there for the interview, but you’re there to show them how you’ll work on the team, and teams work best when there is clear, open communication and a sense of collaboration. Spend the first few minutes of the interview setting expectations, especially around communication and work process.

There’s nothing wrong with having this kind of chat with your interviewer: “My typical work process in a technical challenge like this is to spend a minute or two thinking quietly about the problem and writing down notes, I’ll share those thoughts with you in a moment to get your input. Then, while I code, I tend to work quietly as well, but I’ll be sure to pause now and then to share my thought process as I go, and then walk you through the code more thoroughly before we run it the first time. Would that be okay with you, or do you have different expectations of how you’d like me to communicate or work through the problem?”

I promise you’ll blow their mind. Most interviewers won’t be ready for you to take their expectations into consideration like this. It shows that you’ll work well on a team. You’re setting the environment where you’re advocating for yourself, but also being considerate of others. You’re stating your intentions up front, and giving them the opportunity to collaborate on the process.

Common Problem Area 5: Not asking for help sooner

As your interviewer, I have a small amount of help that I’m likely able to provide during a technical challenge. I can’t coach you through everything, obviously, but I’d rather give you a hint, deduct a point on a rubric, and see you ultimately succeed at the problem, than to struggle silently and spin in circles and make us both feel like the interview is a waste of time.

As a professional interviewer and an instructor at a software school, I’ve become pretty good at asking leading questions to guide you to a realization or answer without me giving you the solution.

It’s okay to admit when you’re stuck. It doesn’t make you a failure, it makes you human. Let your interviewer know what you’re thinking and where you’re having problems. Listen very carefully to their response, they might be offering a clue to the problem, or might give you more thorough advice on how to proceed.

My Favorite Resources to Share

When our interviews at IIO are over, I like to dive into a lot of feedback on their process and where I think they could use extra practice to improve. Generally, I spend 10 to 20 minutes, sometimes going way beyond my one-hour expected time slot, to answer questions for someone, and going into more detail on things. I LOVE to help people on IIO.

Here are a few common areas of advice I offer to folks.

Communication

There’s nothing worse than listening to your own recorded voice. But all IIO interviews are recorded, and I often tell folks in my feedback and in the review notes I type up afterward to listen to the last few minutes of the interview recording to review the feedback I give them. You can also pause those recordings and grab a copy of your code at any time. (These recordings are of course private to your and your interviewer.)

During the playback, listen to your own thought process and how you communicate your ideas. As you work through other challenges, find a way to record yourself talking through the problem out loud if possible, and play that back for yourself. You’ll get better at articulating full and complete thoughts.

Problem Solving and Mid-Level Design

The more common practice sites like HackerRank, CodeWars, LeetCode, etc, are great for writing a coded algorithm, but don’t give you any way to exercise your design process.

I send my students to Project Euler. Euler was a mathematician, so the problems on the website will generally be pretty math-heavy, but you can change the problems to be whatever you’re comfortable building. If you don’t know how to calculate a prime number, that’s fine, swap that out for whether a number is equally divisible by 17 or something instead.

I like Project Euler because the challenges there are just word problems. You have to think of everything: the algorithm, which data structure(s) to use, and especially how to break the problem into smaller pieces.

One of my favorite problems is #19 in their archive: counting how many months between January 1901 and December 1999 began on a Sunday. They give you the number of days in each calendar month, tell you January 1st 1900 is a Monday, and how to calculate a leap year. The rest is up to you.

The more you expose yourself to different types of problems, the better you’ll get at spotting patterns.

Practice, Practice, Practice

One piece of advice we give our students is to practice each technical challenge several times. Our executive director, Jeff Casimir, tells students to practice something 10 times. That feels like a big effort. I aim more for 3 to 4 times, and here’s my reasoning:

The first time you solve a problem, all you’ve done is solve the problem. You might have struggled through certain parts, but your only real achievement here is finishing.

If you erase your work and start it a second time, you might think of a different approach to solving the problem, maybe a more efficient solution. Maybe not, but at least you’re getting practice with this kind of problem.

Now erase your work and do it a third time. Then a fourth time. These are the times when you will start to actively build a memory of the strategy it takes to solve this particular problem. This “muscle memory” will help you when you see other technical challenges, where you’ll start to spot similarities. “Oh, this looks like the knapsack problem” and because you’ve solved that several times, the time you take on high level design and mid-level design just shortened quite a lot.

One of my favorite technical challenges can be solved using a handful of different algorithms (DFS, BFS, DP, etc). If you think you can solve a problem in a similar fashion, solve it 3 or 4 times with each of those algorithms as well. You’ll get REALLY good at spotting similarities, and have a great collection of strategies to approach other technical problems.

Shameless Self-Promotion

I’ve been writing up notes for aspiring new developers at https://techinterview.guide. It’s not complete, but I have a lot of my own thoughts on preparing for technical interviews, networking and outreach, resumes and cover letters, and so on. I still have a few chapters to write about negotiation tactics and graceful resignations, but I’m happy to take feedback from others on the content.

I also have a daily email series covering several kinds of interview questions, but not from a perspective of how to answer the questions perfectly, there are plenty of resources out there to do that. Instead, I examine questions from an interviewer’s perspective — what am I really asking, what do I hope you’ll tell me, what do I hope you won’t say, and so on. A small preview, for example: when you’re asked “Tell me about yourself” they’re not really asking for your life story. They’re really asking “Tell me a summary of things about you that will make you a valuable employee here”.