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.
Oldest comments (41)
Great, awesome, wonderful advice! Explaining the method to your madness goes such a long way. 10+ points to the interviewee if they don't use buzzwords.
Thank you for writing this! Sharing ASAP.
I don't think there's anything wrong with buzzwords as long as you know what exactly they are and they're used correctly.
But generally speaking, the less of them, the better. Yep.
I agree: I'm fine with any technology if it's applicable and if the candidate knows it or about it at least a bit.
Interestingly enough, no one has tried to use blockchain on my interviews yet.)
The day will come when a candidate will answer "How would you sort an array of 10 numbers?" with "Well, have you heard about the blockchain? Let me mansplain it to you " 🤣
And then they start with the history of Blockchain and how great the mystery developer behind is....
Couldn't have been explained more lucidly, thanks Elena :)
Pardon me for asking a silly question but how would you recommend handling the situation if the Interviewer does all of it instead of the candidate?
Hi Vinay,
Haha, that must be funny :). Depending on what they do, sometimes I wouldn't want to work with them, whatever side of the interview they're on. I think during the interview I would do the same what I do now: politely listen, ask some questions to make sure I'm not imagining things.
Then I would weigh this problem against benefits. Is this place otherwise good to work at? Is it only one person doing that? Was it just one occasion? Maybe I could decline the offer if I decide this is too bad and is very common in that company.
For candidates you can provide feedback, saying, for example, that they didn't motivate their decisions. For interviewers, however, this is not very common practice, so I would just let it go.
And what would you do?
Hi Elena,
Yes it's funny sometimes because it leaves you wondering as to how they got selected in the first place. Most of the times, it's downright rude!
Since I believe in the theory "Do unto others what you would have them do unto you" so I always strive to listen, ask queries about the company and role I went in for and in general interact courteously during interviews. Regardless of my skills, I like to make a positive impression of myself wherever I go for an interview - in person or remote.
Also, I'd have a similar approach as your second point which needs atleast 1-2 more interviews with different team-members to determine answers to those questions but then again, you're at a company's mercy to be getting it.
Quick question - What should a person do if a company gave them a very good offer and appears to be a good place to work but they found the aforementioned interviewer would be their senior or lead?
Thank you for your reply, Vinay.
I don't know what I would do in that case, honestly. I guess I would very carefully weigh all pros and cons - just like when you encounter any other "con". I don't think there's a universal recipe.
Have you been in a situation like this? What did you do?
Thanks for the response, Elena!
While I understood that careful evaluation of all pros and cons is the way to determine whether to take the job offer however even I've never been in a scenario like the one I mentioned until now.
Assuming if I were to, I'd have a one-to-one discussion to let that person know a good professional rapport is a two-way street which I believe would do the trick :)
This is a fantastic article! Super helpful 🙌🏼
Thank you:)
Awesome as always Elena
Thanks, Ben :)
What you mentioned here is completely relatable. I admired your post, Elena :)
Thank you:)
Eleven Commandments to live by :P
Thanks a lot!
Wow thanks Elena, this was really timely as i am preparing for a technical interview tomorrow
Best of luck, Ogwuru!
Thanks! I'll be sure to remember this for a while. :)
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 :)
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. ;) )
This article showed up at the perfect time as I am preparing.
Thank you @elena .
Good luck on your interview!
Thank you Elena 😁
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.
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.
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.
Also happy you liked my puffins :))
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 :)
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.
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 :)