5 Things Developers Say That Ruin Tech Interviews

Tech interviews are sometimes a trial by fire. Most tech pros just want to escape with their dignity intact. You can certainly accomplish that aim (and win the job), but saying the wrong thing could cut the entire process short, and make you look terrible in the process.

You may not even realize how your comments come across to the interviewer, or that your strongly held opinion is actually offensive. Yes, some things are worth discussion in an interview, but there are some absolute landmines that will detonate the entire hiring process with a prospective employer.

Here are five of our favorite phrases that can blow a tech interview.

”Check my GitHub”

Listen, hot-shot, there’s a good chance the interviewer was emailed your résumé, like, 30 minutes before locking eyes with you. Now is not the time to get cocky.

In tech interviews, the interviewer may ask questions you tried to sidestep with your cleverly crafted résumé. Maybe you listed your GitHub Gists, or noted all your cool side projects; perhaps you tried to talk up your contributions to the React JS repo. And maybe they read all those things! But while you may have tried to save time (and your patience) by listing all your side projects or accomplishments, a tech interview is a tedious process, and they want to talk about it.

Instead of rudely suggesting they shut up and “check your GitHub” if they want to know everything about your coding prowess, maybe just mention your projects or contributions, then let them know that, if they want to dig into the finer points after the interview, there’s a link to the appropriate code repositories on the electronic version of your resumé (because you 100 percent did that, right?!).

Programming Languages Programming Language Popularity
Programming Language Popularity

”That’s a Garbage Language (or Framework)”

Too cool for JavaScript? Yeah, me too, but now is not the time to stand on ceremony with your feelings. It’s lame.

Rather than sit back and extoll your belief that Node.js is stupid and JavaScript is not a great language, maybe pump the brakes. If the interviewer is asking about something you haven’t worked with (or that you outright hate), it’s because the language or framework is important to the company. Don’t badmouth a piece of technology or software just because you don’t like it much.

And spoiler alert: questions about programming languages or frameworks widely viewed as problematic are actually a good sign. It means they know it’s a sore spot for someone in your role, and they want to see how you’re going to handle it.

Instead of, “Nah, I don’t mess with JavaScript,” say something like, “I just never got into JavaScript. In my career, I just never had the opportunity to deal with it, but it’s popular, so there must be some really great use-cases for it.” At least now you’re not the close-minded applicant.

”Sorry, I Don’t *DO* Whiteboards”

Everybody knows whiteboard interviews suck, and nobody likes doing them or administering them, but they’ve got some use-cases.

We absolutely advise you avoid the whiteboard when possible, and your “refusal” may simply be a case of you trying to do just that. But if that’s their process, so be it; you have to go along with it.

If you’re uncomfortable at the whiteboard, say so. Maybe offer to pseudocode on the whiteboard; ultimately, whiteboarding is usually just a tactic to show a group of interviewers that you understand concepts. Typically, tech interviews don’t involve hand-writing extensive amounts of actual code.

There are alternatives to whiteboarding, of course. You could also ask for take-home work, or to pair-program during the interview. Alternatively, tell the interviewer(s) you’d be happy to have them look over your shoulder as you sit at your IDE of choice.

Just don’t flat-out refuse to whiteboard. If they insist, temper their expectations by telling them it’s your weak point. If you blow it, they’re more likely to admire that you know your weakness than laugh you out of the room.

whiteboard tech interviews

”I Haven’t Ever Used Your Products”

Oh wow, this is bad. Please never tell the interviewer you don’t use or are totally unfamiliar with their company’s product.

There could be several reasons why you’ve not actually used the product. It could be an enterprise service, or a subscription application you just have no use for in your daily life. Chances are, if the job you’re applying for deals with a niche product, the interviewer knows you probably haven’t used it much.

But at least familiarize yourself with it! Read every stupid page of their terrible website, and get an idea for what the product is – and does. If nothing else, you can express your level of familiarity when asked.

This shows the interviewer you’re thoughtful. Taking time to read through their site (at least what you may have access to) shows you care about the job, and it’s a good way to start a conversation about the role and the product you’ll presumably be working on.

”Nope, No Questions From Me”

Nothing? No questions? You don’t care if they have a remote working policy, or if the company does any community outreach?

Do you also not care how many are on your team? What about the daily workflow for your position or team – wouldn’t that be handy to know?

Plan on soaking up 5-10 minutes at the end of an interview with questions, even if they’re benign. If you had to take notes, come with them queued up before you enter the room so it’s a seamless transition from interview to Q&A time. Having three to five questions of your own is a good signal to the interviewer that you’re more than a body for a seat they have to fill.

The only time you should avoid this entirely is if you are 100 percent positive you blew the interview. If you’re not getting a good feeling for the job, or decide halfway through the interview that the job is not for you (and didn’t cut the interview short), end it.

Bias Tech Jobs Job Offer Interview Bias Hiring Dice

It’s Really About What Happens After Tech Interviews

At some point, your tech interview will come to an end. You’ll leave the building, go back home, and reflect on your experience.

Your interviewer will reflect on things, as well. Really, your goal is to leave them with a good feeling about you, and confidence you’ll be a good fit at the company. Though tech is a hotbed of activity with a ton of jobs, filling those roles is almost always a seller’s market; the company where you interviewed surely has a ton of applicants.

Sometimes, just being amiable helps you stand out. Maybe you really suck at whiteboard interviews, but at least you know that about yourself and offered a solution (such as pseudocoding). Your well-defined GitHub or Stack Overflow presence might be something you hang your hat on, but at least you weren’t rude about the fact that they didn’t dig deep into your online activity before the sit-down. If you want a call-back or a job offer, these tips can only help.

5 Responses to “5 Things Developers Say That Ruin Tech Interviews”

  1. Sabbir Ahammed

    I have around two years of experience in Data Entry and Data Processing. I always work for my clients until they get cent percent satisfaction for the completed work. My purpose is to make my customer happy without adding extra charges. My Typing speed is 35 words per minute. If you are looking for data entry or search work, you can get a service from me at least one time

    • You should probably leave out the fact that you only type 35 words per minute, that’s painfully slow. You definitely need to work up to closer to 70 words per minute before saying anything.

      Also, the typos in your comment do not instill much confidence in your skills as a data entry and processing specialist. Just something to consider.

  2. I have had to ‘tech out’ many developers over the years and I’d like to add to the list
    The most annoying and off-putting thing I’ve found is when I ask a question the interviewee does not know the answer to, that rather than explaining they do not know (and perhaps mentioning something similar they do know) instead they proceed to spend 5 minutes talking in circles hoping to impress you or give you the feeling they know the answer but not actually answering it.

    Just my 2 cents

  3. Good article, though, I might make a comment about the “That’s a garbage language” section.

    You’re right that, when they bring it up, it’s best to explore why they are bringing it up before immediately reacting. That said, if I won’t work with Java or Boost or whatever, I have no problem telling them that I think it sucks and why I think it sucks. Because I’m not going to take a job where I’m going to be using what I consider to be substandard tools.

  4. Almost all of these arguments hinge on you applying for a job you shouldn’t be in the first place. If a company says that they took no time to look at my work before calling me for an interview I don’t want to work with them. They aren’t respecting that devs are busy people and they sure as heck don’t know if I’m even good enough to work with them. Just as I do my research on a company before applying, I expect the same. Imagine being brought in for an interview only to find that they’re doing something you’re completely unfamiliar with.

    I will absolutely refuse to do whiteboard interviews as well. You put me in front of a white board and I guarantee it’s sub par to my normal work. I don’t know about you buy I usually write a function here, there, erase both, and write 2 more. Coding isn’t a top down style of writing. If an interviewer continues to insist on it I simply let them know I don’t think we’re a good fit and move on.

    The problem with articles like these is the writer seems beheld to the idea that a dev should just be happy to have an interview at all and we’re at the mercy of the interviewer. If an interview doesn’t go well I’m not going to get hit by lightening when I walk out the door. Good developers are hard to find and if a company is willing to let insignificant things like these get in their way then they’re likely a bureaucratic mess that I’d want nothing to do with.