interviewing.io logo interviewing.io blog
better interviewing through data

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

Introduction

Guest Author

Guest Author


LATEST POSTS

6 red flags I saw while doing 60+ technical interviews in 30 days 15th September, 2020

Announcing the interviewing.io Technical Interview Practice Fellowship 23rd July, 2020

Navigation

Uncategorized

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

Posted on .

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.


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”.

Guest Author

Guest Author

Comments
  • user

    AUTHOR W. Ian Douglas

    Posted on 2:35 pm October 19, 2020.
    Reply

    @Alan, thanks for the feedback here. This article was about sharing my experiences as an interviewer, and having also been a candidate myself many times, felt it would be helpful to share my thoughts/perspectives.

    I’m careful not to say “you must do A, B, C”, but rather suggest things that I’ve seen work well for candidates, and work well for me as both candidate and interviewer, in various circumstances. Every interviewer, every company, will have differing opinions, different biases, etc..

    “a developer should learn what an interviewer wants (actually what this interviewer wants) because it’s the ‘right thing to do’.” — I think that having a discussion up front about expectations can certainly help, yes. About your typical work style, about how you communicate best, to see if that will meet their expectation BEFORE you find out you didn’t meet an expectation that wasn’t shared ahead of time.

    “What about sharing expectations and the way the dev will be evaluated with them beforehand?” — I agree that this can certainly help things, and could be done well ahead of arriving for an interview. Several Bay-area companies I interviewed with in the past were good about sharing topics ahead of time, but nothing more than that. Perhaps an idea of a “rubric” ahead of time could help, there are certainly companies out there that hire strictly on “scores”, but I think there are sometimes things you can’t really put a numeric score on when making a yes/no decision.

    “What you don’t explain in this article is how YOU communicate with them beforehand. Maybe it’s a bit of an interviewer’s bias, and you risk thinking that people that do what you think is right are better.” — That’s a fair point. But people who “do what I think is right” aren’t necessarily “better” candidates. I don’t agree that a hiring decision should fall on a single person, because a single person’s biases could lead to missing out on fantastic candidates.

    As for how I communicate ahead of time, on the IIO platform there’s no ability to have up-front communication other than taking a few minutes at the start of the practice interview. In the real world, I have a lot of discussion with candidates about logistics and giving them some idea of what the on-site interview will entail. I don’t think many interviewers will go into deep detail ahead of time of exact things to study. If I give you some sort of team-home challenge, chances are extremely good that the on-site will have you (at a minimum) talk about the code challenge, or (more likely) add an additional feature or bug fix to the code.

    Again, though, every company is different in their capability (and time) to handle candidates in this kind of pipeline, depending on the urgency of making a hiring decision.

    • user

      AUTHOR Alan

      Posted on 9:21 am October 20, 2020.
      Reply

      Thanks for you reply. I understand your point of view, and I think that some of the points you make are valid. But: usually the aim of an interview is to assess a candidate’s skills (both technical and soft), attitude, and so on. If a candidate fails an interview it can be a bad candidate, a bad interviewer, a bad interview process, or all things together.

      In your article you state that some behaviours are “problems”. But those behaviours are not “the candidate is unable to get to a working solution”. In the “real world” getting to a working/optimal/decent solution is usually enough. You expect different things. Ask for different things. Maybe you’ll be surprised. That has nothing to do with what the candidate needs to study or prepare, it’s not a technical issue.

      One example: I once was involved in a kind of game which should simulated project/team behaviour. There was one facilitator who explained the rules beforehand; they seemed clear enough.

      Then, while in-game we discovered that the rules were not exhaustive and we were supposed to “ask and discover” a lot of things.

      But it was far from obvious. I quickly lost interest, and I didn’t understand how it would relate to teamwork and projects.

      One “unwritten assumption” in many interviews, just like in games, is that you do what you’re asked for. The interviewer leads the interview.

      If I do something that I’m not asked to do (like, telling you what I’m thinking while I’m solving a problem), another interviewer could see me as somebody who wastes their time, and doesn’t get straight to the point. If I ask questions, they may think I’m not as confident as I should be. Asking for help? This can be a bad idea during an interview.

      Remember: it’s an interview. It’s not a casual conversation. You need to keep your candidate relaxed, otherwise they could fumble for no good reason. If you discard a good candidate, you’re not doing a good service to anybody.

  • user

    AUTHOR Travis McKinstry

    Posted on 9:28 am October 16, 2020.
    Reply

    I love this advice, I resonant with a lot of it. I also have a huge preference for communication skills (having come from a communication centered profession; sign language interpreting).

    I’ve heard it be said before that programmers really are translators/interpreters. We take what the client wants and interpret it into a language the computer understands, and vice versa. Thanks for writing this Ian, I’ll be referencing it as I do more job interviews.

  • user

    AUTHOR Alan

    Posted on 1:48 am October 16, 2020.
    Reply

    So, a developer should learn what an interviewer wants (actually what this interviewer wants) because it’s the “right thing to do”.

    What about sharing expectations and the way the dev will be evaluated with them beforehand? Maybe the developer thinks they just need to solve the problem, quick and dirty, so they don’t care about sharing their thoughts with you – they believe they’re just being fizzbuzzed.

    Maybe they don’t ask clarifications because they suppose they shouldn’t, the problem is ill-defined just as many real-world problems with real customers are ill-defined.

    What you don’t explain in this article is how YOU communicate with them beforehand. Maybe it’s a bit of an interviewer’s bias, and you risk thinking that people that do what you think is right are better.

  • user

    AUTHOR W. Ian Douglas

    Posted on 2:04 pm October 15, 2020.
    Reply

    @fmt, that’s a fantastic question. Self-editing and knowing what to share is tricky. I generally tell folks to think through an idea, determine the complexity of it, and whether they want to improve on that or not. But by the second or third idea, you’re starting to get short on time, so I’d recommend just moving forward with one of your choices at that point. At least then your interviewer has heard your thought process and design process and can make some determinations there. They may also guide your design a little too, if they spot problems.

    @james, thanks for the feedback, I really do love helping folks out. Hit me up on LinkedIn or Twitter if I can help in any way!

  • user

    AUTHOR fmt

    Posted on 10:11 am October 15, 2020.
    Reply

    Ian,

    Thanks for your insight into expectations and common pitfalls of interviewees! This has come at very timely point for my current situation (between pre-screenings and pre-onsites).

    I woud classify myself in that category of “mid-level” you describe. I’m a “thinker” (perhaps, leaning towards “over-thinker”) so I struggle with keeping my beginning high-level discussion concise, and even further, understanding when enough is enough to clearly demonstrate my mid-level design. I tend to immediately know a direct/brute-force solution, but that then branches into several ideas for more optimized versions.

    Do you have advice on how to self-edit before sharing too many ideas? There is that fine line between transparency and sounding confused… And potentially, thoughts on what is *enough* once you decide to describe a mid-level design for the solution chosen so that you aren’t wasting time (as I have done too many times!), but from an interviewer’s perspective. In other words, what do you need to see in the mid-level design/how should it be shown to convey the framework of the solution and confirm its clarity?

    I really like your suggestion on frankness with the interviewer regarding how you prefer to work. (I am verbose – clearly – but prefer to think with silence at first). Is that something that should be done throughout (such as asking permission to start coding, asking whether this solution is clear)? Or is there a need to balance between directness, sounding to feable, etc.?

    Greatly appreciate any of the questions here that you can help me better address!

    Thanks again for an insightful post and sharing with this community!

    -fmt

  • user

    AUTHOR James Potts

    Posted on 9:25 am October 15, 2020.
    Reply

    What a wonderfully nuanced and insightful article. Reading through the different problem areas and resources Ian shares, it’s apparent he cares deeply for those he interviews and instructs. In particular, problem areas 2 and 4 are pure gold. As an interviewee, it’s very easy to get lost in our thoughts and speak only half of what we’re thinking. As well, perceiving the interviewer as an interrogator instead of collaborator makes it challenging to conjure the sense of camaraderie that makes working on a team a rewarding experience.

    I’m about 16 months into my journey to transition from technical product support to writing code. It’s this kind of material that helps to illuminate the breadth of communication skills necessary to succeed in writing software. I’m so grateful for this post and looking forward to more from Interviewing.io contributors.

  • View Comments (7) ...