How to fail a technical interview

As a developer, part of my job consists on interviewing new candidates, I have been doing so for about 7 years now. It does not cease to surprise me how many candidates make the same mistakes over an over in interviews, so I decided to share my experience.

Please understand that this reflects only my experiences, it is not necessarily representative of how things work generally in the software industry, also understand that I work in Sydney, it would not surprise me if there are some minor differences in other countries, or even in other cities within Australia.

Also, I would like to note something: whenever I interview a candidate, I am on his/her side, I just want that person to be the good developer we can hire, for two reasons: it is exactly what the company needs and I can go back to coding, which is what I love.

Lets begin

Do not prepare the phone screening.

The very first contact you will have with your potential new employer will be most likely a phone screening interview, I have to remark that normally those are relatively easy interviews, after all, you can only verify so much in a phone conversation, however there are a couple of things to prepare.

You should feel comfortable with the basics of the technology you are interviewing for, as an example, if you are interviewing for a Java related position, you should feel comfortable with basic data structures such as List, Set and Map. I will also expect people to be able to explain the usages of equals() and hashCode().

Additionally basic data structures are a must: Arrays, Linked lists, Hashtables, Stacks, Trees and Graphs are things I expect any candidate to understand well enough to explain how to implement them, I think it is also reasonable to be very familiar with big-oh notation.

Basic algorithms are the next must-have: I do not expect people to implement me a quick-sort, but I do expect them to know how it works, at a high level, I also expect people to be familiar with its running time, sames goes for Tree and Graph transversal, basic recursion and so on. If you do not feel familiar with all of those terms, just review them at home, it should not take more than a couple of hours.

Do not expect any coding.

So you are interviewing for a developer position and you are surprised you are asked to code during the interview? Why are people scared when they are asked to write code on a white board?

The way I see it, there are two things to be aware here: First, be wary of any company hiring developers without asking them to develop during the interview, this is as absurd as hiring a cook without seeing him cooking first. Second, we normally do not code on paper/white boards, so practice at home, if you think it will be “easy”, think again, as a small exercise, try to code a binary search on paper and feel the pain of lack of auto completion. The good news is, once you have coded a couple of algorithms in paper, coding them in a white board becomes simple enough.

When stuck, just stare at the white board, remain silent.

So, here is what is going to happen during a coding interview: you will get stuck, now the question is, how do you react? I have seen far too many candidates just staring at the white board for 5-10 minutes, saying nothing. The problem with this approach is that you are just wasting time that you might be using to explain what is going on in your head.

Sure, sometimes you need a few minutes to organize the problem in your head, but at some point you need to provide feedback to the people interviewing you, maybe you have just a brute force solution, or maybe you have only a partial solution (that does not work in some cases), well, say it, explain the problem, because if you don’t, all I know is that you are staring at a white board.

Showing how you react when faced with a complex problem is important, even if you do not manage to solve the coding problem you still have a chance if you can show what is going on your head, also it allows the interviewer to work with you, maybe hint you and so on.

Do not prepare questions for the interviewer.

Almost every interview that I have conducted has always finished with “well, we have asked you a lot of questions, do you have any questions for us?”, now this is a great opportunity for you to know how the company really works.

I got asked a lot of questions like “what’s the tech stack?” while there is nothing wrong with that question, and I am more than happy to answer it, it does not really provide the candidate any extra knowledge, in most of the cases the tech stack can be derived from the requisites of the job description (I mean, if they ask for java, spring and hibernate, I do not think they will be coding in python, will they?).

There are other questions that, while useful, are too generic, for example: do you write tests? almost 100% of the companies will answer yes, but we all know that it does not mean that they REALLY write tests, here are some examples of questions that I would ask and why.

  • What is your current test coverage? In order to answer this question, the company you interview for must not only write tests but also measure their coverage, there are plenty of tools to do so, if they are serious about testing, they should be able to provide a good approximation without much hesitation.
  • When was the last time you wrote a unit test? Normally that should have happened within a week (assuming of course the interviewer spends more than 50% of his/her time coding.
  • Which kind of machines do developers get? This is absolutely fundamental, I have rejected jobs because everybody had to work under windows, and although there is nothing wrong with windows as a desktop system, I really prefer Linux. Also this includes which IDEs developers user and whether or not they are allow to use their preferred one, after all as a coder you will spend most of your time in your computer with your IDE, so it is worth to know.
  • What is your branching strategy?: Again, fundamental, you want to know if they have a solid pipeline or if it is something like “oh, we all code against the main branch”.
  • How often do you deploy? and follow up question, when was the last time you applied a rollback? when was the last time you applied a hotfix? This will give you an idea of how serious a company is about CI/CD, if you ask them they will always say they do CI/CD, well, if that is the case they should be able to anser these questions easily.
  • What is the latest you have ever left the office? follow up by, what is the latest you have left the office this week? As you can imagine, this is related to overtime, I have never interview for a company where they admit to do overtime over a regular basis, however I have seen that more often than not. By asking these questions you are being very explicit, the answer has to be a concrete number, not some fuzzy constructions.
  • If you could change one thing in your architecture, what would it be? I love this question, because it actually allows you to peek into the current problems of the company, lets face it, EVERY company has areas where they can improve, and in fact, if they are hiring is because the need help, this question is a good way of forcing the interviewer to give you a quick tour of the technical mistakes the company might have done. Also, I think it shows that the candidate is interested on improving and learning from mistakes.

This is all, as I mentioned at the beginning of the post, this reflects only my personal experiences, and I share it with the hope of it being useful to other people, nothing more.

Happy coding.

Leave a Reply