Technical interviews are always tricky unless you’re joining your uncle’s company. And the new norms and circumstances caused by the pandemic had made things a little bit different. And as an interviewer, I had experiences ranging from really good and also really bad during the interviews. So, here are my thoughts and tips in case you’re preparing for the next big step in your career.
Table of Contents
- Setting the background
- Let your CV speak
- Case Studies
- Before the interview
- During the interview
- Facing coding interviews
- Any questions for us?
- Summary
If you’re a fan of my writing (who isn’t 😆), you must have read several articles on preparing CVs, interview questions, facing interviews, and much more. I wrote them mostly from the perspective of a candidate. And for over a year, I’ve been participating in interviews, but now on the other side of the table. So, things have changed, also because the world is in chaos right now! So, what has changed in the way we should prepare for interviews? Well, I’m glad you asked! I will explain everything, not the diff, then everyone will get a better understanding.
Disclaimer 1: It’s not easy, otherwise everyone would do it. But it’s not impossible, otherwise, nobody would’ve done it. 😉
Disclaimer 2: This article is solely based on my experience. Things might be different based on the company or even the country you’re interviewing for.
Disclaimer 3: This article is NOT sponsored or influenced by trivago or any other party, and contains my personal views only.
Setting the background
If you woke up and suddenly decided to apply for a job, it most probably won’t work. Applying to a new job needs a lot of preparation, and doesn’t come overnight! So, here are some things I recommend for you to do in order to set the background and get yourself seasoned. It’s like preparing for a world championship. You can’t just go and play, you need to work hard, practice day and night, and keep doing it!
Get the basics right!
We might not be directly using all the theories we learned in our universities or colleges, but they help a lot for you to write better code. So, most interviewers check them during tech interviews, and you’ll get preference over someone who doesn’t know it. For instance, I usually ask about code optimization and runtime analysis to get an understanding of the interviewee’s perception. So, go back to the basics and recall them. And there is no point in just memorizing them or learning by heart because the interviewers will know you don’t really know stuff in an instance. So try to study and truly understand them.
And, the things you need to re-study depends totally on the type of job you’re applying for. I’m a backend engineer and it is less important for me to study how web browsers handle cross-origin content. So, I usually refresh my memory on multi-threading, databases, distributed computing, etc. So, identify what you need to work on.
Practice
Facing interviews needs skill. Just like any other skill, you need to practice a lot to make yourself better at it. If you’re applying for a tech position, you MUST prepare and practice a lot. If you’re applying for an engineering position, you most probably will have one or more coding exercises to do, both take-home and during the interview. Therefore, you must polish up your coding skills. Facing a coding interview is very different from doing a take-home assignment.
Anyone would get nervous when someone is looking at you code! So, it needs a lot of practice. You can use platforms like HackerRank, Project Euler, Codebyte, and Leetcode. You can also ask one of your friends to be the interviewer while you’re trying to solve a problem. This will get the gears tuning inside your brain and prepare you well for the actual interview.
You can also check this article to know what type of questions you’ll get asked, but of course, it’s just a smaller list, and you must do more work.
Prepare your answers
You have to prepare for all kinds of questions, not just coding or tech-related questions. You should have prepared answers for even the questions such as, “what are your strengths/weaknesses”, “what’s your salary expectation”, “how do you see yourself in 5/10 years”, etc. Yes, you MUST prepare for these questions. I’m not going to cover “how” to prepare, but there are hundreds of articles and videos on the Internet explaining this.
Online presence
This is one of the best qualifications you can ever have! Recruiters and interviewers always look for your online presence, and what type of content you produce. It shows how much you like to share your knowledge with others and keep engaged with the community.
- Keep your LinkedIn up-to-date.
Add your experience and projects to LinkedIn, and it will give more exposure. Ask people to give recommendations, and do the same in exchange. Check my LinkedIn profile if you need any inspiration. - Blog
Maintaining a blog will show a lot more about you than you think. People will know what kind of things inspire you and will be easy for them to see if you’re worth considering. It doesn’t need to be a tech blog, it can be anything you’re fond of. I have my own website as a blog and I write whatever I feel like writing: tutorials, poems, scripts for my YouTube videos, and many more. You can either use platforms like WordPress, Medium, or Blogger or even host your own blog like me, which gives me flexibility. - Stack Overflow
This is another place anyone can see what type of questions you ask and answer. I see many people are Zombies on Stack Overflow, using it as a place only to get answers. But it shows a lot about your personality when you also answer questions. So, spend a few minutes there to see if there are any questions you can answer. Trust me, there are questions you can answer! - GitHub
This is yet another portfolio you can use to show off your coding skills. Having a couple of public repositories will speak a lot about yourself. Many people think that they don’t have anything to share with the community. It doesn’t matter whether others will find it useful, but it shows your willingness to share when you publish your code openly. So, try to create some public repositories, even with the algorithms you learned at your university!
Tip: Create a GitHub profile page and it will be more attractive 😉
There are many other places you can show off your skills, such as YouTube, Udemy, Medium, and much more. But don’t force yourself to do these just because you want to get a job. Then you would rather get a negative impression. So, try to make these your hobby, where you truly honestly want to share your knowledge with others.
World has enough smart people, but we need more good humans!
Let your CV speak
Not much has changed since I wrote my article on creating a killer CV. But let me recap the important things. Your CV is representing you! The things you add as “important” tell a lot about you. So, be very careful about what you add there.
Keep it simple
It’s super tempting to go all the way and cram everything you ever did into your CV. But, the recruiters don’t really care if you won a dancing competition at grade unless you created a robot or a simulation to do it!
The rule of thumb is, just question yourself “what benefit will I gain by adding this?“, and you will see that it will leave only the significant ones. If you still have a lot, I suggest you add everything to your portfolio (i.e. LinkedIn or your personal webpage) and keep the topmost ones in the CV. If you don’t have any significant achievements except those less significant ones, then you truly need to focus more on gaining some!
And, try not to make it more than 2 pages. Okay, maximum 3 pages. I’ve heard some hiring agencies (especially in Singapore) need CVs to be 5 to 7 pages long, then they can formulate different versions of them for different companies. Other than that, try your best to keep it as short as possible. People don’t really have time to read your life story.
Experience
There is no point in adding all of your technical experience to your CV. I suggest adding the top 5 or maximum 10 technologies you’re comfortable with in descending order. Nobody really cares if you know Microsoft Office or did programming in Pascal! I mean, people do care, but it’s less significant to be added to your CV.
The same goes for projects! I would refrain from adding university assignment-type projects. And the more you’ve experienced in the industry, the less you’ll need to add those anyway. And make sure you explain your project briefly with the most important information, such as the intent, technologies, and any specialties/achievements.
I’ve also seen people adding their skills as ratings or percentages.
What does that even mean! 🤷♂️
What do you mean when you say you’re 90% experienced with Java? What is the 100% then? The entire programming language, or your full skill set? 🙄
Please don’t be that person. At least use your relative scale such as “proficient”, “intermediate”, and “beginner”. This will give a better understanding of how much confident you are with the corresponding technology.
Each character you add to your CV should be well thought. Because it’s like your portrait representing yourself. So, be cautious of what you add and don’t add.
Hyperlinks
Nobody prints CVs nowadays! So, make sure you add hyperlinks to your profiles on GitHub, LinkedIn, portfolio, etc. You can even use icons to denote the platform, and just add your username as a hyperlink.
Interests and Personal Traits
My way of thinking has changed a little bit on this topic, however, it still lies on the lines of “only add when you need to give more information about yourself”. For instance, “playing chess” will add more value than adding “swimming”, because it shows you like critical thinking and solving problems. Swimming could have added more value if you’re applying for a fitness trainer role, but I guess you’re not! The same goes for reading, blogging, playing games, etc. So, add things that will give more information about you.
There are much more we can talk about making CVs, but you can read my previous article for the moment. If you need an updated version, feel free to drop a comment.
Case Studies
Some companies will give you a coding test (in an online platform such as HackerRank), and some companies prefer case studies. They evaluate different aspects of your coding skills, where a test usually checks your speed and ability to solve problems, while a case study usually focuses on your ability to understand requirements, design a small system, implement, test, and even deploy a solution to a real-world problem. So, you might get different combinations of these depending on the company.
Read the case study
Duh! What idiot doesn’t read the case study before implementing it? Well, trust me, there are a lot of people who don’t read the case study document properly! Take your time to read and understand the problem definition. Note down all the important things including requirements, limitations, assumptions, etc. And, don’t be afraid to ask questions from your hiring manager if you have any doubts. They will either directly answer them or forward the questions to the engineers.
Do the magic, I mean the coding!
Of course, you need to implement the case study in the best possible way. Use all the theories you learned, such as Object-Oriented concepts, SOLID principles, clean code concepts, etc. But please, don’t over-engineer your code! Don’t make it too complex. I’ve seen people writing functions to hold a single line of code. The execution tree will look like a stick, rather than a tree. Your code should be easy to read, and the evaluator should be able to see if it works even without running it. Try to find a middle-ground for all the best practices, and you’ll have more chance of impressing the evaluators.
Documentation
Document your solution well, in a way even those who have no clue about the case study will understand. This is also a skill that comes with a lot of practice. If you’re used to writing, probably a blog, then you won’t find this difficult. Nevertheless, spend a decent amount of time writing and reviewing your submission. It doesn’t matter how well you have done your case study if haven’t explained it properly!
Make sure to include:
- Problem definition in your own words
Please, don’t copy-paste it from the case study document. We want to see how you understood the problem. - Suggested architecture
Use diagrams! Pictures can tell a lot more than simply explaining in raw words. - Assumptions and limitations
Of course, you can’t implement a production-ready system in a week while working on another day job. So, clearly mention the assumptions you made and the limitations of your solution. - How to run
Please 🙏 clearly explain how to run your code! If your code requires third-party libraries, please add relevant dependency configs (i.e. requirements.txt) and commands required to install them. - How to test
And, try your best to add test cases for your code. A good submission with test cases has a higher chance of getting an interview compared to an awesome submission without tests.
What (not) to submit?
Submit only the essentials! Read the case study and see what they expect in the submission. Don’t zip the entire project with all the third-party dependencies and especially the executable binaries! The latter most probably will cause your submission to be rejected because it will be caught by the anti-virus software in our systems. We can build it ourselves if you have provided clear instructions.
And please submit code that runs on a local machine! If you need special infrastructure or resources, make sure you mock them or use Docker containers! Evaluators do NOT have the whole day to deploy your code into the cloud and run it.
And I highly encourage you to have an executable script to run your code, such as a Makefile or a Shell Script, especially if it needs multiple steps! I usually spend around 30-45 mins to evaluate a case study, and trust me not everyone does that! Make it easier for the evaluators, not yourself.
Before the interview
Let’s assume that you got a slot for an interview with or without doing a case study. Then you must be well prepared for it, as you want to impress the interviewers and also you shouldn’t waste their (and your) time as well. But before we get there, there are many things we need to consider. These sound obvious, but trust me, I had many bad experiences.
Find a proper place
Please, find a place with minimum distractions. If you’re at home, ask your family to keep it quiet. If you have dogs or kids at your home, who usually can’t stay silent, or you have loud neighbors (i.e. religious places), please find another place for the interview. It could be a friend’s house, your current office (though it’s a little bit unethical), or even a quiet cafeteria. It’s super hard to conduct an interview in a noisy environment. You might not hear the noises if you’re wearing headphones, but your microphone will still burst out the ears of the interviewers.
Also, try to have a stable internet connection with fewer interruptions. If you know your Internet connection sucks, try to find a temporary solution if possible. If nothing works, please tell it beforehand to the interviewers that you might have interruptions.
Don’t listen to bullshit LinkedIn motivational speakers! You want the job? Prepare for it!
Stalk the interviewers
Usually, each interviewer has their own area of expertise and aspects they evaluate. If you already know which job posting you’re applying for, there is a high chance that you can find the potential interviewers you’ll have. You can search on LinkedIn or company website to see who might interview you. If you already know who’ll be interviewing you, then this task is much easier. Just do a simple Google search and see what type of personalities they have. Trust me, you will find really helpful tips to impress them. But of course, don’t be creepy! Don’t send messages to the interviewers before the interview and try to win them over!
When I was facing my interviews for trivago, I found a really cool article from Pascal Cremer, one of my interviewers and my first team lead at trivago, about “How to master tech interviews”, and I did exactly what it said. 😉
So, you might read this article, end up in an interview with me, and you will nail the interview!
Be prepared
Because almost all the interviews are now conducted remotely, you must be prepared for that. Check the invite and install the app the company is using and set it up properly. For example, if the company had sent a Zoom link, please install and configure it beforehand, and test it beforehand. Check if your camera and microphone work properly.
Be prepared to share your screen. If you have hundreds of windows and tabs open, close them or hide them. If you’re using a Mac, you need to restart the app in order to give permission for screen sharing. Do that beforehand!
If you have submitted a case study, you must expect the interviewers to ask questions about it. No company will simply accept a case study submission without asking face-to-face questions about it! So, please keep the documents and the project open. Read the case study and your solution again. You might be applying for multiple companies and have forgotten what you did, but don’t show it to the interviewers.
Be prepared to run the code and show it. There were cases where people weren’t prepared, probably they never had run the code in that particular machine, and we had to wait until they install all the libraries and restart the computer. So, please try running your code on the computer you’re joining the interview, and make sure it runs.
Make yourself comfortable! For most of the tech interviews, you don’t need to dress up. Something casual is enough! Sit in a comfortable place: ideally on a chair at a desk, but do whatever is comfortable to you. Keep a bottle of water, if you know you’ll need some, especially when you have to keep on talking for an hour or two.
Most of all, have a clear mind. Do whatever you do to calm your nerves. I usually meditate with some breathing exercises for a couple of minutes before the interview. It helped me to calm myself and have a clear mind.
During the interview
Finally, you’ve prepared quite well and now it’s time to show how skilled you are! Here are some aspects I and my colleagues usually check in an interview.
Be punctual
Duh!
Short-and-sweet “about yourself”
When you are asked to give an introduction about yourself, please be precise. We already have your CV, and see your profile. So, it’s just an ice-breaker question. Don’t spend 10 minutes explaining your current job role and all your expertise. Tell us something interesting about you!
Be polite
An interview is not a fight between you and the interview panel. It should be a friendly discussion to see if the candidate is eligible for the role, and vise versa. It’s just like a date between two people, except this is not romantic! It should be a friendly discussion to understand each other’s traits. So, please be polite. Interviewers are spending their time for you, and make the time worth it. Even if they’re rude to you, try your best to be polite, because it shows each other’s personality.
There are candidates, really good with the case studies and coding, but interrupt the interviewers while they’re asking questions. They already begin to answer the question, which was not even the actual question! This gives a very bad impression and most probably you won’t get selected regardless of your technical skills.
And for interviewers: it’s not a competition! When I was applying for jobs before I joined trivago, I had a really bad experience with some interviews (for well-reputed companies in Sri Lanka), where the interviewer tried to prove that they know more than me! I mean, why? Obviously, they should know more, because that’s why we’re on the opposite side of the table. It’s NOT about proving yourself (to your colleague or your boss), but to hire a new person. If the candidate got selected, they will hate you for the rest of the time!
The candidate interviews you!
Be precise and on-point
When we ask you a question, please please please, be precise! Give your answer on point. It’s okay to give some background for the answer, but don’t go around the bush. Interviewers know when you do that. I’ve heard a famous (yet false) saying, “if you’re confused with a question, confuse the interviewer“. But this doesn’t work, because interviewers usually are familiar with these kinds of candidates. And also when we try to fill our scorecards for the interview, we’ll immediately realize that the candidate was bluffing.
Be honest, don’t bluff!
If you don’t know something, admit it. It’s fine! Seriously! We don’t expect the candidate to be perfect and knows everything. Honesty and the eagerness to learn aces the other drawback, mostly. There were some candidates who said they’re really good with databases, but struggled when we asked about indexes, then admitted that they only write some SQL queries once in a while. This is a serious turn-off for the interviewers. So, please don’t lie in the interviews and it will always get caught!
But you can always approach a question like “I don’t have a lot of experience/knowledge on this topic, but according to my understanding, it’s like this…”, and it’s much more convincing than just fleeing after getting a tough question.
Facing coding interviews
When we have to do a live coding test, it’s always hard for anyone! So, it’s very important that you make the best out of the time. As I explained earlier, it should be a friendly discussion. So, ask questions and get opinions from the interviewers.
Think out loud
Something I highly recommend is to paraphrase the question and make sure you understood it correctly. It also shows the interviewers that you don’t directly jump into implementation without verifying the requirements.
Then think out loud while you’re thinking about a solution. It’s very important for the interviewers to know how you analyze a problem. The goal of a coding test is NOT to get a working solution from you but to see how you approach a problem. So, even if you couldn’t get a working solution, you’ll have a high chance of passing the interview if you were explaining your thought process.
For example, I would first present several viable solutions or approaches. Then try to compare them for pros and cons. Then the interviewers might give some hints as well. Then you pick one approach and explain the steps. At this point, the interviewers most probably will ask you to write some code. You can either use your local code editor or they might already have given you access to an online code sharing tool, such as Codility.
It’s very important that you explain your thought process throughout the process. And pay close attention to the comments and hints from the interviewers. They might give clues to know if you’re going on the correct path or not. And consider their suggestions, because they (most probably) already know how to get the solution!
There were some candidates who discarded all the comments from the interviewers and ended up with a mess. Those candidates will have less chance of getting selected since they show a lack of collaboration.
Additional steps
Then one more important thing is, you should explain how you can test your code! Even if you don’t have time to test it during the interview, you can still explain how you could’ve tested the code. And also, it’s always better to tell what limitations are there in the current code and what improvements you can make to make it better. These gestures are highly appreciated in tech interviews!
And finally, it couldn’t finish the code by the end of the interview, you still can send your finished code as soon as possible to the hiring manager, and they will forward it to the interviewers. I know it sounds weird, but it can help you because it shows your attitude towards solving the problem. Anyway, you have nothing to lose!
Regardless of the outcome, try to provide feedback to the hiring manager about the interview: constructive feedback, with what you liked and what could be improved. And they also will most probably give you feedback coming from the interviewers. But this can be very tricky due to GDPR measures, so might not get complete feedback, but it doesn’t hurt to ask.
Any questions for us?
You must know, even though you think the interview is over, it still wasn’t until the end of the call. At the end of the interview, you’ll be asked to prompt any questions if you have any. This is a great opportunity to show your curiosity. Prepare some meaningful questions beforehand. Try to avoid boring questions like “how’s the day of a software engineer in your team?”. It’s still fine, but we would like to hear more creative questions. Once there was a person who had found a bug on our website and presented it at the end of the interview. That was quite impressive!
And please, do NOT ask “how did I do?” or “did I pass the interview?” kind of questions! Not only we’re not allowed to answer that, but also it’s very unprofessional!
![Best interview questions to ask candidates [plus tips for great interviews]](https://i0.wp.com/resources.workable.com/wp-content/uploads/2019/04/interview-questions.png?ssl=1)
Anyway, I don’t want to put everything into this article and spam it. So, I will make another one explaining how to answer non-tech interview questions, and what questions to ask at the end of the interview.
Summary
Facing an interview is tough! It needs a lot of practice and endurance, to keep applying over hundreds of rejections. This has become tougher due to the pandemic as we don’t have any personal presence during the interviews, and affects both candidates and the interviewers!
This article explained what I, as an interviewer for an international company, expect from a candidate for a software engineering position. Well, this has been one of the longest articles I ever wrote, but I hope it’s worth it.
How did you like it? Did you find it informative and helpful? Why not share it and spread the love!
