This article was first published in my blog smartpuffin.com.
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.
Latest comments (41)
Nice, although it's your link to the reasoning stuff that really sold it to me.
Thank you Elena. The article was really helpful. Keep writing...
Great article! Thank you for sharing.
Thanks Elena. Great article 😊😊
I want to ask something. What do you think is the most common mistake in students to apply internships? I'm in the 8 level in the University and I'm searching a good company for work how intern. What do you recommend me??
Hi Jean Karlo,
Good luck with the university! I just googled what "level 8" means, and it seems like you did a great job. Congrats!
And good luck with finding a job! I'm sure you'll do great!
Regarding common mistakes. I was thinking for a couple of minutes and couldn't really come up with a "list of mistakes". Instead, I came up with a list of great qualities that I saw them having.
In my opinion, students and recent graduates usually do very well because they're excited about the industry, the job, and are very eager to learn. It's okay if they don't know everything (no one does, really), and it's perfectly fine if they honestly admit that. I appreciate the honesty.
They also usually react well to feedback - for example, to code reviews, or if someone gives them an advice to watch for code quality, or how to organize their code better. They learn very quickly, and they have an open mind.
When I think back to when I was starting (now I sound like an ancient person, haha), I think that I could do better in understanding the requirements before building stuff. I would be excited about building a feature and would, naturally, be busy with building it, when instead I should have asked questions: why do the users need it? Is what I'm building the best for them? Do I understand the full picture? Did the product owner / business analytic / project manager / user researcher explain all details to me?
In the end I would sometimes have a great feature, which is not what the users wanted.
But again, it's perfectly fine to make mistakes and learn from them. Don't let anyone judge you for making an honest mistake. :)
Good luck in job hunting!
Thanks Elena. Your advice is so useful for me.
I said "I'm in level 8" because in my University is required pass 10 levels to complete the career. I don't belive is same to you found, or no? but Let me tell you, I'm so excited to start my career in this world and I'm goin to follow your advice especially one, "Try to understand need of user".
How do i bookmark this article?
Yeah, this is almost what I'm saying :). Although the word itself has meaning, candidates use it without understanding. How would you describe such a situation?
Anyway, thank you, happy you liked the article otherwise :)
If you use a word and don't know what it means, it's a buzzword.
Let me elaborate a bit about how it happens. People are being told they're going to go through a system design interview. They read about system design interviews. They see that load balancers are often mentioned, and they decide: to look good on the interview I should use a load balancer. And they are trying to put it in at any cost.
Now, if they never used load balancers and didn't read about them, they sometimes misunderstand the purpose of them, and it ends up looking suspicious.
I aways read this type of article in internet and all the time is the same tips, but you bring to us the "missing corner cases" in interviews. Thanks and keep posting :)
Well, I came to this post only because of puffins so I'd say the photo works ;)
Also, you seem to have pretty cool recruitment process and I envy you this - compared to what I usually experience ("hey, we have 3 candidates and we HAVE to hire two of them").
However, I would not necessarily agree with corner cases mistake. It is important in real life, however in a stressful situation such as job interview I think it's better to leave them out. If not, it usually ends up in getting in too many details and losing the big picture. This is only my experience though and our mileage may vary.
Also happy you liked my puffins :))
I see your point about too many details. Maybe if you suspect it's going to take long, it is worth asking the interviewers if they want you to list them and/or to work around them? This way you'll show your ability to think about them, even if they say to leave them out.
Great article.
Also, "I don't know, could you please explain to me?" or "I've never done that before. How does that work?" are viable answers. It shows you have a sense of humility and are willing to admit that you don't know everything.
This article showed up at the perfect time as I am preparing.
Thank you @elena .
Good luck on your interview!
Thank you Elena 😁
Thank you for those advices, about 2 weeks ago I made a mistake that you mentioned, I didn't explain well one question that my interviwer made me, and I knew that screwed up the interview.
The mistake was that my interviewer asked me "Why will you use node.js and not Java?" and I said "Honestly, I don't like Java, I hate it!" but I didn't explain with details why, after that the guy told me "everything here is written in Java", so I felt embarrassed and I also knew that I buried any opportunity, now I think that I could have used anothers words to explain why I don't like Java.
this article is fantastic!!
You really should have known their framework before taking the interview though. You sort of dodged a bullet too. Would you really want a job using a framework you dislike?
(I don't like Java either. ;) )
Great read. Thanks for sharing Elena. If you like puffins, consider visiting 🇨🇦 Newfoundland 🇨🇦. Whales and cool icebergs too. 🐋
Aw, thanks! I'd love to. Maybe one day :)
Thanks! I'll be sure to remember this for a while. :)
Wow thanks Elena, this was really timely as i am preparing for a technical interview tomorrow
Best of luck, Ogwuru!