Icon blog
Triplebyte Blog

We help engineers join great companies
Try our coding quiz

Share this article

Common Interviewing Mistakes that Engineers Make

By June Kreml on Oct 29, 2018

Common Interviewing Mistakes that Engineers Make

This blog post lists the most common mistakes that we see trip candidates up during engineering interviews.

Every engineer has bombed an interview. Sometimes even very talented engineers unexpectedly bomb them, and this can be really frustrating for all parties involved. As one of Triplebyte’s content writers, I’ve read interview notes on hundreds of successful candidates and hundreds of candidates who didn’t make it through our process.

Although we've put a lot of effort into designing a background-blind technical screen, our process is still probabilistic and sometimes things other than raw engineering talent impact outcomes. Sometimes candidates make mistakes which make it impossible for us to accurately assess their ability. What follows are my own observations and those of our interviewing team, who have been doing this for even longer than I have.

Failure to Clarify Expectations

Engineering interviews present an unusual challenge—you’re supposed to show off the skills you’ll use in the workplace, but you’re not actually in your normal workplace. Because different companies handle this challenge in different ways, it's important to check your assumptions about what’s expected during your interview.

There are two ways we sometimes see inaccurate expectations torpedo interviews:

Over-engineering: Senior engineers are particularly prone to this. It’s tempting to go above and beyond in an attempt to really wow your interviewer, even if it means paying less attention to the stated requirements. Some interviewers respond really positively to this, and it can be a good strategy under certain circumstances—but you don’t want to get so lost in the weeds that you fail to make any real progress.

You can always show off your experience by discussing the pros and cons of different approaches to a problem. If you show that you can easily produce a simple, functional solution, and then follow that up with something more complex (if time allows), it often sends a much better signal than jumping straight to overkill.

Cutting Too Many Corners: This is the opposite of over-engineering, and it’s a mistake that junior engineers are more likely to make. It’s often OK to cut a few corners for the sake of speed—especially if you point them out as you go and explain how you might do things differently if you had more time. Nobody expects your interview code to be exactly the same as what you produce on a day-to-day basis (although, again, you may want to double-check with your interviewer).

On the other hand, it’s essential that you only cut corners when you can get away with it. The worst of both worlds is to sacrifice quality for speed, only to get confused by your own code and fail to make any significant progress. High productivity can be an extremely positive signal, but it’s much better to be slow and careful than to be both slow and sloppy.

When in doubt, it’s best to ask questions. You might want to ask whether your interviewer wants to see how you’d code during a real project for work, paying lots of attention to design, or whether they’re primarily looking for speed and would be happy to see you hack something together quickly if it means you’ll finish the entire problem. Most interviewers are totally willing to answer these questions, either upfront or in the middle of the interview, and you’ll do a much better job of meeting (and exceeding) their expectations if you know what those expectations are.

Failure to Prepare

Obviously, people who prepare for interviews tend to do better. What is more interesting is our finding that junior engineers are actually often better prepared for the type of problems encountered during engineering interviews. This might seem counter-intuitive, especially for senior engineers who often assume that their real-world experience will prepare them to do well on a technical interview. However, most interviews use short coding problems as a proxy for engineering skill, and solving short coding challenges from scratch is a skill recent college graduates have been forced to practice regularly in school. Senior engineers, on the other hand, may not have created a new Rails app in years because they've been too busy solving large, important architecture problems. They may not even remember how to create a new project in their editor.

At Triplebyte, we’ve tried to create a process that doesn’t require intensive pre-interview studying, and I think we’ve mostly succeeded, but it's still a good idea to try practice programming problems from scratch if that's something you haven't done in a while (or practice thinking about large-scale architecture if you don't have much experience). If you're doing an interview with another company that hasn't spent as much time thinking about this issue, preparation is even more important. Odds are, your past skills will come right back—we’ve seen senior engineers hit their stride twenty minutes into our interview and ultimately really impress us. Still, it's best not to waste those minutes getting your bearings.

Lack of Familiarity with Chosen Technologies

Some candidates try to impress our interviewers by choosing a trendy or hardcore language for their interview. This rarely works out well. Any interviewer worth their salt is going to care much more about how you code than which language you’re using, and it’s hard to demonstrate your skills if you have to spend time looking up basic syntax. It’s OK to show off a new, cool language if you’re really good with it, but only if you’re really good.

If you are given the option, we recommend using the language you’re most comfortable with, so that you aren’t slowed down or otherwise obstructed by simple lack of fluency. If you really want to use a language that you haven’t worked with in a while, do some practice with it before the interview.

Also, make sure to double check the tools that you’ll be using during the interview. We’ve had candidates try to take our interview on brand new computers they’ve never used before, or attempt to answer questions with broken headsets (and ultimately lose time repeating themselves). These are speed bumps that you don’t need hit, as long as you make sure to check your tools and equipment beforehand.

Not Following Directions

Very occasionally, a candidate will decide that they don’t like our assignment and merrily write up a completely different one. (We do not recommend this approach, to our interview or to any other.) Failure to follow directions makes it hard for interviewers to consistently score candidates, which, in turn, makes it difficult to determine whether they deserve to pass the interview.

Triplebyte makes an effort to evaluate candidates according to certain objective measurements. While this makes our interviews less biased than most, it also makes them less flexible. Candidates who ignore the interview setup, even if they’re really really talented, get low objective scores. Even if we feel that they showed a lot of technical strength, it’s hard to measure them with the same yardstick as everyone else (and we’ve put a lot of effort into perfecting our yardstick). This is likely to be a problem at any company that has an established, standardized interview process.

Failure to follow directions is also a negative indication of how you’ll work with others. Employers want to know that they’re hiring someone who can deliver what the company needs, even if it’s not what they want to be working on at a particular moment. They also want to know that they’re hiring someone who they can communicate with. If a candidate doesn’t follow instructions, it’s not always clear whether or not they understood the requirements or whether they just didn’t care. Both of those possibilities make people nervous.

Bonus Round: Give the Interviewer a Snapshot

Triplebyte never fails people because they strike us as boring. On the flip side, being an awesome person with cool hobbies, interesting past experiences, and a fresh perspective on life is not going to be enough to pass our interview. It will, however, help you stand out from the crowd after you pass our technical screen. (We've added extra questions to our interview process precisely so that writers like me can communicate interesting details to companies about our candidates.)

Standing out from the crowd is even more important during interviews that are less objective than our technical screen. Being memorable can be the difference between an offer and, “sorry, the position has been filled.” Unfortunately, a lot of people don’t know what makes them different from their peers, which makes it hard for them to demonstrate it to other people. If you’re not immediately sure what your comparative advantage is, it might be worth taking some time to think about it, and then to think about how you can present that information to an interviewer. A summary of companies you’ve worked with and technologies you’ve used might reassure certain recruiters, but it won’t get someone really excited about you in particular.

Conclusion

At Triplebyte, we focus on building a fair, accurate process. Our goal is to build a technical screening interview that you don't have to prepare for. However, not all companies are as careful about their hiring processes as we are. Luckily interviewing is a skill. That means engineers can get better at it with practice. Whenever you practice something, you make mistakes—that's just part of learning—but we hope this list helps you to avoid the most common missteps. Here's a recap:

Remember to ask questions about what’s expected, prepare beforehand, use technologies and tools that you’re comfortable with, and follow directions. On top of that, remember to show off your individuality and unique traits because standing out from the crowd is sometimes just as important as standing out as an engineer.

I wish you the best of luck.

Get offers from top tech companies

Take our coding quiz

Liked what you read? Here are some of our other popular posts…

How to Interview Engineers

By Ammon Bartram on Jun 26, 2017

We do a lot of interviewing at Triplebyte. Indeed, over the last 2 years, I've interviewed just over 900 engineers. Whether this was a good use of my time can be debated! (I sometimes wake up in a cold sweat and doubt it.) But regardless, our goal is to improve how engineers are hired. To that end, we run background-blind interviews, looking at coding skills, not credentials or resumes. After an engineer passes our process, they go straight to the final interview at companies we work with (including Apple, Facebook, Dropbox and Stripe). We interview engineers without knowing their backgrounds, and then get to see how they do across multiple top tech companies. This gives us, I think, some of the best available data on interviewing.

Read More

Bootcamps vs. College

By Ammon Bartram on May 19, 2016

Programming bootcamps seem to make an impossible claim. Instead of spending four years in university, they say, you can learn how to be a software engineer in a three month program. On the face of it, this sounds more like an ad for Trump University than a plausible educational model.

But this is not what we’ve found at Triplebyte. We do interviews with engineers, and match them with startups where they’ll be a good fit. Companies vary widely in what skills they look for, and by mapping these differences, we’re able to help engineers pass more interviews and find jobs they would not have found on their own. Over the last year, we’ve worked with about 100 bootcamp grads, and many have gone on to get jobs at great companies. We do our interviews blind, without knowing a candidate's background, and we regularly get through an interview and give a candidate very positive scores, only to be surprised at the end when we learn that the candidate has only been programming for 6 months.

Read More

How to pass a programming interview

By Ammon Bartram on Mar 8, 2016

Being a good programmer has a surprisingly small role in passing programming interviews. To be a productive programmer, you need to be able to solve large, sprawling problems over weeks and months. Each question in an interview, in contrast, lasts less than one hour. To do well in an interview, then, you need to be able to solve small problems quickly, under duress, while explaining your thoughts clearly. This is a different skill. On top of this, interviewers are often poorly trained and inattentive (they would rather be programming), and ask questions far removed from actual work. They bring bias, pattern matching, and a lack of standardization.

Read More