The 3 Sins of Software Engineering Interviews

In my time as a software engineer, I've interviewed hundreds of candidates for front-end, full-stack, and backend developer roles. Here are some surprisingly common mistakes that you should avoid to improve your chances of passing the interview.

1. Using a language you don't know

Forget what language is trending right now or what the company you're applying for uses—always use the language you know best. If you love Ruby, just use Ruby!

Why? Because time is of the essence in a technical interview. If you choose a language that isn't second nature to you, you're going to waste precious mental cycles trying to remember which functions to use and gloss over obvious bugs.

2. Only coding in your IDE

You may not realize how much you rely on the help of your IDE to autocomplete your code on a daily basis. Unfortunately, autocomplete doesn't work on a whiteboard. And some languages (cough Java) can be quite verbose and slow you down in an interview. This isn't a showstopper, but it means you should practice in an interview setting (in a text editor, on a whiteboard). If you want real-world practice, you should also check out Exponent's mock interviews.

3. Not taking a hint

Getting stuck in an interview isn't the worst thing, but interviewers hate it when candidates veer off track and ignore their suggestions. Learn to recognize when the interviewer is trying to help you. If you find yourself answering vague questions—like "Why do we we need to do X?" or "How do you know Y?"—your interviewer may be suggesting you try to find an alternative (or simpler) solution. Use this hint as an opportunity to step back and think about your approach. Don't forget that half of the interview is about your communication skills – how well you explain ideas and how well you listen to feedback from the interviewer.

Want more help?

Want help practicing for your interviews? Check out Exponent, where we match you with experienced mentors who've worked at top tech companies like Google, Facebook, Uber, and Dropbox. Subscribe to our YouTube channel for more helpful tips and videos.

Comments

[stereobooster]

The 3 (interviewer) Sins of Software Engineering Interviews:

• use a whiteboard for the interview
• ask theoretical questions not related to the future work
• trying to show how much smarter you are than candidate

[Josh]

As long as I live, I will never forget the interview I had with a guy who asked why I was using a relational database instead of "something NoSQL, like Mongo", and then later, asked what I would do if retrieving n rows turned out to be slow, for reasons, then when I suggested we could saving off the data we cared about as another column in the table, and do a bit of basic arithmetic to recalculate the newer value that we'd care about for the next call, he asked: "Why not just cache the n rows?"

After recovering from the stagger this question caused me, I said, "Well, because then you'd trade one database issue for about a dozen cache query issues." This was at the end of the hour I had with him, and he asked if I had any questions for him as our time was wrapping up, so I fired off: "What's the toughest bug you had to track down within a cache?" He replied, "Actually, I haven't ever done much work with caches..."

I didn't get that job. It was a company that does tech in medical care. It's fine. I'm sure doctors can continue to get work done when their unjournaled medical records suddenly vanish, and when cache refreshes don't trigger as necessary. Diabetes probably isn't a very time-sensitive illness.

[Van Ly]

When interviewer asks you "why not", it doesn't mean something better. They just want to know how you respond, how you prove your point, how far you know about that knowledge, and the ability to analyze the problem.

[Theofanis Despoudis]

Epic retaliation!

[stereobooster]

I didn't mean to argue. The title is "catchy". It is easy to do remakes: "The 3 Sins of ..."

[Bence Szabo]

This IDE thing. I think making today's developers program on a whiteboard is like taking a car on a test drive on a road that's covered with huge rocks with a driver that has never driven a manual gearbox car before and you tell them that you won't buy the thing if you spill your coffee.
It's adding more stress to an already stressful situation, whereas in the real world the company spends millions creating a comfortable office environment, pay for the coolest IDEs, employ people who coordinate work and generally try to make life easier. Simply put, that's not how we operate.
I think asking somebody to walk up to a whiteboard and solve some obscure made up problem with a marker in 20mins can lead to a false impression of one's abilities.

[Jacob Simon]

So true! Luckily the trend is moving away from whiteboard interviews these days, and instead they’re letting people bring their own laptops into interviews for coding questions. But it’s not a sure thing yet.

[Templar++]

Using a language you don't know

I strongly disagree. You have to learn new languages. Of course don't try to learn everything, but keep learning whenever you can. If you can learn something new - go for it.

Only coding in your IDE

So time is of essence, but go ahead and write code without autocomplete? Double standards anyone?

"Why do we we need to do X?" or "How do you know Y?"

Or maybe simply asking why and trying to figure out how you are thinking? And honestly how often am I suppose to change my job according to you? In my 25+ years carreer I changed my job less than 10 times and why would I if I'm happy with my job?

[Josh]

1. Be sure to also use a language your interviewers know
2. If your interview is in a Lisp, there is exactly one correct IDE you may use. Never use this IDE if your interview is not a Lisp.
3. If the hint is "What's the simplest means of representing this structure," kindly thank the interviewer for their time and try your luck elsewhere. Finding the simplest means of representing anything is usually very time-consuming, and you only have an hour.