Background
There are a lot of mistakes people make while preparing for and giving technical interviews. Like everyone else, I also made a lot of mistakes during my interview journey and learned the hard way (by getting rejected). Generally speaking, rejections shouldn't hurt you because they teach you a lot. But in tech interviews, there are scenarios when things are outside your control, despite the best preparation. We'll discuss about such scenarios in the end of this post.
To start with, I'll divide this post into two parts:
Preparation mistakes (during preparation).
Execution mistakes (during interview).
During Preparation
When I started looking out, I was completely unaware of industry expectations. I got in touch with a few people who had switched roles in last few years to understand the same. Apart from industry expectations, there were many other things that I had to know, like:
How titles work in different companies?
How to prepare for the specific rounds? What sources are good (free / paid)?
How interviews are different from real work?
Will the companies hire me if my tech stack doesn't overlap much with theirs?
The more you know about all these things, the better you can prepare and manage your expectations. Let's talk about all these things one by one:
Not understanding industry expectations - There are two types of companies (or roles that are open). Some roles explicitly mention that you need to be an expert in a specific technology stack to even get shortlisted. The other category is of roles that require you to be a good problem solver who can learn the tech stack and get things done. Both the roles have their own significance and we cannot blame the hiring team for being stringent in the first case. If the product is in early stage, the company would prefer to hire someone who is familiar with the stack so that they can contribute fast without the need of ramping up. If the product is in later stage, it's upto the choice of hiring team - they could hire people from a different technology stack, or they may still prefer to hire people with the same stack only. It depends on the stack also - incase they're using something very niche (for which developers are not available easily), the hiring team relaxes the tech stack expectations. But incase hiring for that tech stack is easy, they'd prefer someone who knows the stack. In my experience, it's easier for companies to find Java developers so rather than hiring for Senior Software Engineer, they put the job title as Senior Java Engineer. For medium-large organisations, the positions are tech stack agnostic for candidates who are good at problem solving. In the first case, some interview rounds focus on specific technologies (e.g., Core Java, Spring Boot). In the second case, you can choose your favorite programming language for the coding rounds.
The above information is from my job hunt experience in the last 6-8 months. Obviously, exceptions are always there.
Strong tech stack inclination - This point is interesting because, deep down, programmers have strong opinions about languages. For example, some people hate PHP (example) while some make fun of java for it's verbosity (example 1, example 2, example 3). This could still be seen as a personal choice. The bigger issue comes when people associate themselves with one tech stack only. Let's take my example - I've been majorly writing Ruby for the past 9 years but I've also written a little bit of C, Java for Android, Powershell, Bash, jQuery, BackboneJS, and a few other languages in my current and previous role. While I too have opinions about what languages to avoid, I did not limit my job search to Ruby/Rails openings only. Limiting my job search to only Ruby/Rails positions would have been stupid, especially in the current market where openings are less. I'd recommend the same to everyone - do not call yourself a Ruby developer, Java developer or GoLang developer. Call yourself a Software Engineer who can learn syntax and be productive in any language. Having this mindset helps a lot in the long run.
Confusion in job titles - This is the most important thing to know when you're searching for a new role. Some websites allow you to search jobs with years of experience, while some websites (like LinkedIn) allow you to search with job titles. LinkedIn also helps you to set job alerts for specific titles. Based on multiple factors, you could be eligible for multiple roles. Taking my example again - I work as a Staff Software Engineer in a small team but when it comes to job search, I search for Software Engineer, Senior Software Engineer, Staff Engineer, Team lead and Engineering manager roles. All these roles overlap with my experience range based on the size of organisation where I'm applying. I've already explained this point in a detailed blog post, so I'll rather leave you with a link to read the same.
Building Resume only once - Resume building is an underrated exercise. When you're looking out, there are high chances that you're applying to many positions without a referral. In such cases, your resume is your first impression. If you've not spent enough time in build the same, there are high chances that you'll not get calls from good companies. Resume building is not a one time effort. You need to work on it continuously to reword your tasks in a more impactful manner. Just like job titles, I've already written a detailed blog post on how I did more than 5 iterations on my resume in past 8-9 months. Even today, I don't think my resume is the best it can be, so I keep improving it.
Not preparing an Introduction - In all the companies, the first thing people ask is to introduce yourself. In some companies, each interviewer asks this question (although that sounds repetitive). Generally, you get a minute or less to talk about yourself before they ask about your specific projects or give you a problem to solve. You might have built a lot of products but it's important to summarise your journey in this one minute and talk about everything that you find important. Write a long introduction of yourself, use AI to summarise it and keep improving it (just like your resume). I skipped this initially and found myself struggling while explaining my role/journey. I clearly remember that I forgot to explain to one employer that I manage a team of seven people in my current role. So my role might have sounded more of an IC than a Manager that could have good/bad impact based on what they were hiring for.
Applying directly to dream companies - If you're interviewing after a long time, do not get discouraged by rejections. Despite building a lot of things and being hands-on after 9 years of total experience (6+ in my current role), I faced a lot of rejections in the beginning. The current way of tech hiring is not the best way to hire good candidates, it's a way to filter out candidates who are not interview ready. And being interview ready means something else for technical roles. You might not have built anything in real world but if you are prepared for the interviews, you'll get the job. And the reverse is also true. For this reason, it is important to not apply for your dream companies directly (in case you are targeting some). Do many interviews at different companies to see if you can handle the questions under pressure before applying to your target company. Given the competitive nature of the market, I've heard from many experienced people that you should give a few interviews every year even if you're not looking out. It's just to bridge the gap between your current preparation and market expectations.Another way of practising to a decent level is by taking mock interviews. While there are many paid websites for the same, a free solution for the same is by using ChatGPT as your interviewer. I've tried it and it is decently good, if not the best. You need to do some initial conversation with it to explain what it is supposed to do (otherwise it will give you both question and answer). I'll share my prompt for reference:
The above screenshot is of my conversation with ChatGPT when I was preparing for my final round at Bain & Co (read the complete interview experience). It's important to set context for ChatGPT before you start the conversation. You can modify the above prompt for technical roles as well. I also prepared for System Design interview using this format.
Overconfidence - Assuming that you already know everything can be bad. It happened with me when I was learning LLD and HLD. Because the problems seemed familiar/simple, I thought I'll be able to crack the rounds (till I failed 1-2 of them initially). Everything demands your time and some practice. Tech interviews demand even more practice because you're expected to build (LLD) or talk about a MVP (HLD) within a period of 40-50 minutes. Although problems seem simple, thinking about the models, APIs, writing code, or talking about high level design, databases, protocols, challenges within this time period is very hard if you've not spent time in practising the same. I always recommend everyone to solve at least 5-10 problems for both LLD/HLD (without looking at the solutions) before appearing for any company.
These are the top six things that came to my mind from my experience. Now let's talk about mistakes during interviews.
During Interviews
Not talking enough / talking a lot - In an interview, you have an hour to talk about yourself and showcase your skills. It's important that you portray best of your skills. A good technical interview is a collaborative exercise where you and your interviewer solve a particular problem. In most of the cases, the interviewer has a fair idea around possible solution(s) because they have asked the same problem many times. A good candidate would ask questions (not cleverly seek hints) to understand the problem in depth before jumping towards the solution. There are generally three technical rounds - Data Structures, LLD and HLD. While Data structures question is a mathematical question (i.e. can be judged as right or wrong), the other two are somewhat open-ended. In many cases, ambiguities are present in the problem statement (even in DS round) to see how the candidate interprets the problem and asks questions. It's our responsibility to make sure that we're querying the interviewer to frame the problem better, scope the boundaries of the problem and present a solution that works for it. It's quite possible that some iterations are needed to tailor the solution to cover edge cases or changing requirements. I'll just recommend to keep on talking with your interviewer to make share what's going on your mind. On the opposite side, don't keep talking so much that you don't leave space for them to talk or share their feedback on your solution. A balance is important here. In my experience as an interviewer, very few candidates talk more than what is required, but talking less is a common problem.
Assuming without discussing - While you're talking, make sure that you don't assume anything in your mind. Assumptions can lead to different solutions, hence it is important to speak about your assumptions. If that assumption is wrong, your interviewer will point out the same. For example: In most of the LLD problems if I'm talking about APIs, I assume that authentication is always in place and some header is coming in all the requests that is interpreted by the server for identifying the user. While most of the interviewers agree to this assumption, one of the interviewer asked this question- What are the different authentication mechanisms you know about, and which one you'd like to use here (and why)?
(Design Interviews) Stubborn with choices - In design interviews, you try to solve a problem by using some components like Databases, Load balancers, API Gateways, Firewalls, Protocols, API Servers, etc. Let's take an example of a System Design interview. The most common discussion that happens in almost all the interviews is around the choice of database - SQL vs NoSQL (let's assume we're comparing SQL databases with Document oriented databases like Mongo/Elastic). We need to have strong reasons to choose one kind of database for the specific use case rather than this guy who is a MongoDB fan. There are many more places in a design interview where we need to make choices (eg. protocols). Just choosing one side is not enough - you need to justify your choice (or your interviewer will ask you to). Stubborn candidates leave a very bad impression on the interviewer and usually get rejected.
(Design Interviews) Finding the core problem / not catching hints - In both LLD and HLD interviews, there is one core problem that we're solving. As we talk more with our interviewer and frame the actual problem from that one liner ambiguous problem statement, we get closer to the problem. For example:
In a cab booking platform like Uber, matching the driver with rider could be a core problem because you need to choose the drivers using some algorithm (you can't just search them based on displacement as they might be a river apart).
In a movie booking platform like BookMyShow, holding the seats while user is in process of paying for the tickets, or releasing the seats when payment fails / times out could be the core problems.
Similarly, your problem statement has one core problem which you need to identity. Although other parts of the systems are also important but this is one part that interests the interviewer. While you're talking with your interviewer, try to see if they're impressed with your design or are they like - there's something more to the problem. Incase you're missing something important or are going wrong, they try to give you a hint (eg. How are you making sure that <this> problem is also addressed? ). Do not miss these inputs, they may impact your overall design.
Bad luck - In the beginning of this post, I wrote about a problem that is outside your control. That's bad luck. I'll share some scenarios to explain this:
Untrained interviewers - This usually happens in small companies where they're trying to expand the team. The interviewers might not be trained to conduct the discussion properly. Generally, some senior person shadows the new interviewer to make sure they are ready to interview but in small companies (due to multiple things running in parallel) such processes are not mature and training is not sufficient.
Stubborn interviewers - Not only candidates, interviewers can be stubborn. It's hard not only to work with them but even harder to do an interview. Such interviewers have one approach in mind and would expect you to give exactly same solution. I've faced this once where despite doing everything well, I was rejected. And this was because there was one thing that they wanted to happen in a certain way and I suggested something else (with a valid reason). This person also gave me feedback (I generally ask for the same at the end of interview) that I should have asked about scale of system (in a LLD problem) so that I had modified that one thing in my solution early. I've never seen anyone else talking about "scale of system" in a LLD interview. We generally go into details of API design, database design and the core problem.
The best part - they were junior to me by designation, years of experience, and attitude towards better solutions :)
Apart from this, many other things (like mood of the interviewer) can impact your performance. Such things are generally not in your hands. Just like for candidates, interviewers also need training and feedback. In the organisations where interview process is more formalised and where interview calls are recorded, there are high chances that the interviewer would get feedback(s) if they need to improve on certain axes. In many organisations the feedback process is completely missing, which leads to bad candidate experience. If you face such a situation, you can also share your feedback with the recruiter / hiring manager. Make sure your tone is professional and not rude if you want them to consider your feedback.
I hope the above points would help you to avoid mistakes that people (including myself) generally make. Good luck for your preparation 👍.
Incase you found this blog good, I'll suggest you to read these also:
Click here to read all blog posts around interviews, including my interview experiences.
Adopt this thought process when you're fixing exceptions.
Make sure to avoid these mistakes when you create pull requests.
