Your next tech interview: Do's & dont's

Let’s do a quick round that illustrates what to do, and what not to do. I would like everybody to share one thing they like to see in technical interviews and one thing they do not like to see, like a typical mistake that people are making.

Who wants to start?

Ahmed (Zalando.de — Frontend Engineer): So, one thing that I like to see is how you approach a problem, not what is the end result of a problem. If there is an issue, I don’t care what is the result, I care what are the steps you take to solve this issue.

This includes how you think. You have to think loudly, you have to let me know what is your expectation, and you have to ask questions. If you didn’t ask questions, I immediately know you are jumping to conclusions and this could be a big, big, big mistake, and it could be a big loss for the company you are working for. You might start implementing something and it’s not what the company needs.

The bad thing is not asking questions, simply. This is the most critical one, not asking questions to understand the requirement and dive into the exact requirement the interviewer wants you to implement.

Johann: Thanks! Next?

Mohamed (Vivy.com — Mobile Engineer): So, the bad thing that you should not do: You should never, never, never answer something that you are not 100% sure of. Some people have this perception that “if I didn’t answer or I said I didn’t know — I fail”. This is completely wrong. If you say “I don’t know”, it means that you respect the other interviewer and that you understand your limits. This is a really good quality to see in applicants because you don’t want somebody to be hired in your team who can take random decisions and not know what the consequences are.

And, a good thing I would like to see in people — before they use things, they need to understand why do we have this in the very beginning. Because, sometimes, we use things and we use some methodologies and we use some pattern in the code but we don’t understand the reason why we had this in the first place. So we will start making mistakes that this pattern was meant to solve. So, just because it’s cool and a lot of people are talking about it and the community is “trending” — I have to use it. It’s not necessary, maybe it doesn’t solve your problem. Maybe it just adds a new problem to your problem.

Johann: Thank you!

Khaled (Omio.com — Backend Engineer): Okay, the first thing to do: Understand the purpose of the tools and languages, why are they made, and understand the details of the different tools that you’re using. Either technology, e.g. something that’s very fundamental such as data structures and algorithms.

The second thing is team dynamics. I like to test how people interact with whatever they haven’t worked with before. If you have been into conflicts, how have you resolved them? And I’m looking for microexpressions (like facial expressions) about how they do this because I interviewed people apart from my team and it’s very important to see how people work with others, how people are resolving problems and conflicts and that’s one of the things I’m looking for.

What not to do: I agree with Mohamed. Never explain things that you don’t understand, and don’t explain them with confidence. Instead, just say what you are assuming. If you want to do this, say beforehand that you have no idea but you can give it an educated guess. E.g. You mind if I can say that? And then the interviewer will say why not and then you would engage in a discussion instead of just throwing information at people just judging how you are working. That’s it really…

Johann: Leandro, do you want to add anything?

Leandro (Getyourguide.com — Engineering Manager): Sure. In brief: What I don’t like is when I ask which technology you choose, you sound like — “I am a PHP developer, but I don’t really know why”. It’s super important to know what the technology is good at. Another thing that I like is when I see someone with soft skills. Be aware that feedback culture is very important here in Germany. How we talk to others, and how to be assertive when you talk. So remember: your soft skills are as important as your hard skills.

Johann: Thanks, fascinating!

Mohamed (Careem.com — Data Scientist): As a data scientist, I see people being super prepared, who have spent a lot of time reading about different techniques, for example, details of machine learning. The thing is: they don’t spend enough time understanding what works well and where. There is no one thing that fits all because, for example, most of the Kaggle competitions are using automatic machine learning algorithms, so you use it and solve all the problems. You have to spend some time to understand what technique works in which problem-solving context.

Johann: Anything else?

Believe in yourself. All of us failed in interviews. We failed in a lot of interviews but we made it at one interview. So don’t judge yourself based on one interview, just keep doing it.

Johann: Thank you all for your time and detailed advice.

That’s it. We hope you enjoyed the read. Now it’s time for action. As always, we are rooting for you. Keep us posted.

— Your friends at Imagine

→ Explore our blog