You’re in for a technical interview. They ask you a question, and you have to build a system or to write some code, either on a whiteboard (brr!), on a piece of paper, or on a laptop at home. And then you discuss it with the interviewer.
Some enjoy it, and some dread it. But if you are going through it, it means the end of the process is near! And you really want to show the best side of yourself.
I led more than 120 interviews. Here are some common mistakes I noticed the candidates make.
Mistake 1. Condescension
I ask a question about the candidate’s solution, and the candidate says: “Ah, I see you don’t understand what I did here. (Explains.) Did it clear up your confusion?”
Your interviewer wants you to demonstrate your way of thinking. They are not very likely to be confused, because they interview many people, are very familiar with the question, and have seen many possible answers. Even if they genuinely don’t understand your code, which also happens, it would be polite to explain them your results without making them feel bad.
Why it matters: when you’re hired, you will have to communicate with your team members. The interviewers want to make sure they have team members who are able to communicate nicely, both with more and less experienced people.
Mistake 2. Using buzzwords without knowledge
A trie. A NoSQL database. A load balancer. A graph. A cluster. If you’re going to use them, you’ll have to explain why. It is easy to understand if someone doesn’t really know what a hash is.
“I’m putting a load balancer here”, said the candidate and drew a rectangle next to his database cluster. “It will run once an hour and will query all database machines, process the data, and log the results.”
Hm. This is not what a load balancer does. I thought perhaps it was a slip of the tongue, and asked some more questions around this. No, they just kept calling it a load balancer all the way. Okay then.
“I’m using a trie”, said another candidate. When I asked to tell me more, they couldn’t show a small example of what it looks like.
At the same time, it’s okay not to know many details about everything. Just be honest about it. The point is not to pretend to know something you don’t.
Why it matters: if a company hires someone who “buzzworded” their way through the interview, but doesn’t have the real knowledge, they will be disappointed with the work results. This is why they interview candidates before hiring – to estimate their knowledge.
Interestingly enough, no one has tried to use blockchain on my interviews yet.
Mistake 3. No reasoning
“I’m going to use a NoSQL database here.”
“I need 50 servers in my cluster.”
“I run this once a day and retrieve 92 records.”
Great, tell me why. I’m sure you have some reasons in mind, pros and cons, and I’d love to hear them. Why not SQL? Which exact NoSQL database? There are so many of databases under this umbrella term that you really want to narrow down your answer a bit. A graph database and a document-oriented database are fit for very different purposes.
Why exactly 50 servers, and not 70? Why every day and not every hour? And where did you get this 92 number from?
Why it matters: the interviewers hope to be able to understand the decisions of their future colleagues. An explanation of the reasons for your choice would show your ability to make decisions based on logic, requirements, and data, and not on a whim. Here is my article about why reasoning is important.
Mistake 4. Not asking clarifying questions
Your interview question is likely not 100% complete. It is done intentionally: to simulate the real-world environment where you are not likely to get a full description of a task. You are expected to ask questions, so ask away!
Talk out loud about your assumptions as well. Sometimes you assume something, but the interviewer has a different idea in mind. If you don’t talk about it, you will have a mismatch between your results and their expectations.
Also you might want to ask sometimes: am I going in the right direction? Do you want me to focus on this or that? The interviewer will really appreciate that they don’t need to interrupt you to discuss what they need.
Why it matters: it is very rare that the requirements are clear and 100% complete. A developer is expected to be able to clarify them before implementing.
Mistake 5. Forgetting requirements
I tell the candidate in the beginning: “We need this as close to realtime as possible”. I repeat this throughout the interview. The candidate ends up processing data in batches every hour.
In another case, the candidate asks how many items there will be. I tell them a large number – say, 20M. The candidate designs a system fit for thousands of users.
We need multilanguage support, but the candidate’s code only supports 26 ascii letters.
The candidate needs to pay attention. The requirements listed are important and should be considered. In case you don’t have an idea how to deal with it, you can propose: “I remember there have to be other languages. At the moment I only have an idea for English. Let me solve this for English and then see how I can deal with other languages”. This shows you didn’t forget, and also demonstrates your prioritization skills.
When you’re proposing something like this, it helps to abstract this part of code away. Put it into a method or component which you can easily replace later. Here’s an article explaining why and how to do this.
Why it matters: if users have a requirement, they will not forget about it. They will not be happy if it is forgotten by developers. If you absolutely cannot support it, tell the interviewers about it explicitly. Then you can make a trade-off, just like in real work.
Mistake 6. Missing corner cases
“I run his once in 5 seconds and select records from the last 5 seconds”, says the candidate. Just a minute ago we established that the timestamp field comes with the record. This means a new record from 7 seconds ago can be inserted just now. This means we will not process this record – never ever.
The candidate solves a question about chess, forgets there are corners, accesses the “board” array at [-1,-1].
There are three worker processes, all selecting last unprocessed records. They mark the records as “done” when they’re finished. The candidate didn’t think to mark the record as “in progress”. This means one record will be processed up to three times.
Try to think logically: does your solution work in all cases? Do you validate the user input? Do you have endless loops? What if you pass 0, -1, INT_MAX? How does your system recover from a broken network connection? What if you have a peak of requests?
Try to test it in your head, or even write some tests right there. Talk out loud about your thought process. The interviewer will likely help you.
Here’s an article to help you think about corner cases better.
Why it matters: the requirements from the users will very rarely include any corner cases. Even some base cases may be missing. It is important for a developer to be able to identify them and make sure the code works all the time.
Mistake 7. Going too deep into details
Once I had a candidate start with choosing a protocol which different components of the system are going to use to talk to each other. TCP or UDP? The components were not defined yet.
It helps to ask the interviewer if they expect you to describe something in more or less details. I find a nice approach to build a high-level overview first, and then go into more details about specific parts later.
Why it matters: when presenting something, you want to make sure everyone follows. Going too deep into details distracts from the main picture. Also, from a pragmatical point of view, it doesn’t leave enough time for the interviewers to discuss all topics they want.
Mistake 8. Not providing enough details
“So we store the data here and then just select the needed records”.
Okay, in what database do we store them? In what schema or format? Which records are considered “needed”? There are hundreds of millions of rows, how do we speed up the selecting process?
I already said how it can be a problem when you explain too many details. However, glossing over an essential part also isn’t perfect. Especially if an interviewer tells you they are interested in a specific part, you should focus on that part.
Why it matters: the interviewers want to have a fairly decent picture of the solution in their heads, to be able to assess the result properly.
Also, if you don’t think about something enough, it is likely you will miss quite some corner or even base cases. Take the database example. If there are billions of rows, they will likely not fit on one machine, so you have to build something else to fix that problem.
Mistake 9. Implicit assumptions
This dialog usually goes like this.
The candidate says: “This is too much data, I’ll need a cluster with sharding, 30 nodes and 3 replicas, a load balancer, and…”
I ask: “How much data do we have here, exactly?”
The candidate pauses and asks: “Well, how many users do we have?”
See? It is unknown yet what data comes in, from how many users and how often, but we already have a cluster with 90 machines. Expensive!
Ask questions. How many users? How much data? What is the response time we can tolerate?
After some calculations, it often turns out we need to store just 200MB of data. Boom! We instantly saved lots of money on that cluster.
Why it matters: for the same reason requirements matter. The interviewers, and eventually your users, will have one picture in mind, and you – a very different one. Unless you talk about it, you might end up implementing the wrong thing.
Mistake 10. Avoiding the question
“What happens in case X?”
“Well, you know, in case Y I’m going to do Z, and if A or B, then C will fail…”
“Okay, and what about X?”
“Let’s see, if X… oh that reminds me, when we have D…”
It’s great you have so many ideas to share. Just try to answer the question first, and continue with other ideas afterwards.
Why it matters: the interviewers ask you a question for a reason. They want to understand your knowledge better and to become familiar with your thinking process. If you don’t answer, they can’t do it. When you’re hired, your manager and colleagues will also appreciate you giving them the information they want.
Mistake 11. Being impolite to an interviewer
A candidate looks at my male interview partner all the time and talks only with him, even when I ask a question. Of course, this makes us, both interviewers, very uncomfortable. How are we going to work together?
Rumor has it that some candidates ignore women interviewers altogether. Sometimes they assume all women are HRs only. Sometimes they are rude to HRs, both women and men. Sometimes they arrogantly refuse to answer a question. I really cannot imagine why, but they do.
Why it matters: I want to work with nice and polite people who respect me. Everyone else does, too. If a candidate starts their interview with a couple of rude comments about people around them, they are clearly not a good fit – for any team.
P.S. The photo of cute puffins in the beginning of the post I took during my recent vacation on Shetland islands. It doesn’t have anything to do with interviewing mistakes. I just like puffins.