Why are technical coding interviews so hard?
We all probably remember that point in our lives where we fell so much in love with programming that we started dreaming of someday working at some of the biggest tech companies, alongside some of the smartest individuals, trying to solve some of the hardest engineering problems. So we work hard all our lives chasing that one dream. We get into a good school, work on some difficult projects, get amazing grades, land that coveted interview and then when your lifelong dream is finally about to turn into reality, the dreaded coding interview comes along and spoils just about everything. And you cant help but wonder, all those years of hard work and perseverance, taken away in just one moment because you weren’t able to to do left-right rotation in an AVL tree. How could this be fair?
Should companies even do these silly coding interviews? How can they possibly be fair? I’ve conducted coding interviews for over a decade now, most of which have been the big-tech algorithms kind. I will do my best to share as much information I have on technical interviews — why most people find coding interviews so hard, why interviews are the way they are and the mental shift you need to succeed in these interviews. And based on that information, you can decide whether these interviews are actually fair or not.
Why do most people find coding interviews so hard?
Lack of data structures and algorithms knowledge
The first reason why a lot of people find coding interviews hard is because they lack the fundamental knowledge in data structures and algorithms. As software engineers, we are naturally attracted towards building real things, working on real projects, solving real problems... so it’s too easy to brush off those couple of data structures and algorithms classes in school or to ignore them altogether once you start your professional career. However, the fundamentals are the foundation for everything else that we build. You may not write complicated algorithms over and over again in your day job, but the understanding of the core concepts helps you write more efficient code, not to mention, you really can’t clear the interviews without them.
Judgement under a timed environment
The second reason why people find coding interviews daunting is because for most, it is the first time they have had this feeling of being graded by someone under a timed environment. It’s that “someone is watching over my shoulders” feeling that naturally makes a lot of people uneasy. Of course, we’ve given countless exams in school, which do grade us, and are also usually timed. But you get your own space. No one is sitting with you, 1:1, inside a room, observing just you, as you make your way through the problems. And this unusual and awkward situation makes a lot of people extremely nervous, making coding interviews even harder for them.
High stakes
Reason number three is that we somehow manage to make our interviews very high stakes. If I can give you one piece of advice that will change your interviewing performance forever, it is to always interview when you don’t need a job. When we have good jobs, the last thing we think of doing, is interviewing anywhere else. So we wait, and wait, and wait, until we either don’t like our job, get laid off, or even worse, get fired, or maybe our financial situation changes — the reason could be anything — the point is, we look to interview when we absolutely need to interview. On top of that, a lot of us have built up this mindset that we have to work at one of the cool big tech companies in order to validate our ability as software engineers. And sadly, this only raises the stakes for your interview, adding way more pressure than you ever need. Instead of, “let me see what this opportunity is about” it becomes “I have to get a job in X, Y, Z company by the end of this month”. As a result, the interviews feel way more challenging than the actually are.
Lack of understanding of what an interview is trying to test
And finally, most candidates don’t really understand what technical interviews are trying to achieve. I hear people saying — this makes no sense because who even writes a quick sort in the real world? Or, I have never had to write an interview-style algorithm in my 20 year programming career. These are fair observations, but they show a clear lack of understanding of what technical interviews are about. No one is testing your ability to do your day-to-day job with the actual technical interview question. If you think that way, you are missing the point. The point of the interview is to get valuable data points about how you are as a software engineer in the real world through a simulated scenario. These data points are called “signals” and they 100% relate to the real world. We will talk more about signals in the mental shift section of this video.
But before that, let’s look at why technical interviews are the way they are.
Why are interviews the way they are?
Data doesn’t lie
This first reason is data. Tech interviews have been largely the same for decades now, esp. in big tech. Over that period, lots of data points about interviewing has been collected and analyzed. And the data shows a strong correlation between the signals you get from a typical tech interview and the potential for the candidate to succeed as a software engineer. Simply put, as unrelated to your day-to-day work a topological sort may be, data has shown that exhibition of good at problem-solving attributes by a candidate has a strong correlation to their potential of succeeding as a software engineer in big tech. Also, it’s not that companies don’t want or try to innovate in this area — they do. We did go from “How many clowns exist in the world” or “How many planes are flying in the sky at any given moment”, to “Invert a binary tree” or “Figure out if a graph is bipartite” over the course of a few decades to make the questions more natural. And believe it or not, aside from the latter requiring the candidate to write some code, these questions aren’t really all that different from the perspective of an interviewer — they are all testing for your problem solving given an odd, uncomfortable and unusual question.
Rapidly innovating in this space with novel means of interviewing also means risking the hiring of mismatched candidates, and that can be prohibitively expensive. Hiring a wrong candidate, and then having to let them go shortly after, can cost a company over a million dollars. So essentially, outside of minor tweaks and gradual improvements, companies have no reason to radically change a system that has proven to work for the most part.
Resource limitations
The second reason is resource limitation. In an ideal world, every applicant that clears the resume screen would get a mini-internship and they would be evaluated based on that alone. Obviously, this is not possible in real life. One, it takes a surprisingly long time to ramp up to a large new project, even for experienced engineers. And companies interview a LOT of candidates, so it would be impossible to let everyone show off their skills in an internship-based approach. There are a limited number of software engineers that want to conduct interviews and are trained to conduct interviews. So, the volume of candidates needing to be interviewed, the number of interviewers available, and the amount of time it takes to conduct each interview needs to somehow add up. Or else, software engineers will either be conducting interviews full time, or applicants will be waiting forever to get an interview date. But, length of the interview isn’t the only thing. Each interview also needs to be conducted in a matter where any other qualified interviewer can evaluate the same interview and come to the same conclusion. For this to be possible, interviews need to be somewhat standardized, which is the third reason interviews are they way they are.
Standardization
The main goal of standardization is to make interviews objective. And that is the reason why coding interviews are all similar, at least for all big tech companies. The only way to conduct interviews effectively and objectively evaluate candidates is to standardize the interview process. By this, I mean, have a pool of interview questions that all qualified interviewers for that company know well. That way, everyone understands what the optimal solution is, what the near optimal solution is or what a sub optimal solution is. When an interviewer says it was a “difficult” question, every interviewer agrees on what that difficult means. Think of it like the SATs, GRE, GMAT — they are called standardized tests for a reason. If you get a 1570 out of 1600 in your GRE, every college knows that you are at the 99th percentile of scores for that test. The same idea applies to technical interviews. If a company can create a pool of interview questions that are difficult enough to challenge the candidate, but solvable in a short amount of time, and it can get all it’s interviewers to understand and agree on potential solutions, and more importantly, train them to look for the right signals, then the interview process can become standardized. And a result, the evaluation becomes objective and unbiased. A natural benefit of standard and objective interviews is that they not only help evaluate the candidate evenly, but the also interviewers. Having a subjective interview process makes it impossible to know whether it was the candidate that did not do well, or the interviewer. And as an interview panel, you always err in the side of the interviewer. This can create an environment where bad interviewers can foster. But given a standardized process ... since every interviewer for a loop understands the problem, it is easy to spot out inexperienced or bad interviewers and provide them with adequate training.
Alright, now that we have looked at why we find technical interviews hard, and also why technical interviews are done the way they are, I want to encourage you to change how you think about technical interviews and make a mental shift. I think that will immensely help you succeed in your interviews.
Mental shift required to succeed in technical interviews
Understand the signals
First, as I mentioned earlier in this video, a technical interview it NOT testing your ability to do your day-to-day job with the actual technical interview question. If you think that way, you are missing the point. So stop saying - I will never balance an AVL tree or write a radix sort from scratch in real life. I agree, you probably won’t. But again, that is not the point. The point of the interview is to get signals about how you are as a software engineer in the real world.
How do you cope with pressure?
How do you pick yourself up when you stumble?
How do you approach a problem that you have never seen, seems crazy and may not have to do anything with your real job? Do you throw your hands up and complain or do you make your best effort to solve a problem?
What do you do when you are completely stuck. Do you just quit?
How much guidance do you need when faced with ambiguity?
How good are you at not only taking hints but also extracting them out of the interviewer?
Can you communicate technical material well?
How fluent is your coding? Can you translate your thoughts into code like it’s second nature? As in, do you write code as if you are speaking English?
Do you test well? Catch edge cases? Stress test?
Do you think of scale and the what-ifs?
Do you understand the trade-offs between your choices?
So it isn’t about whether or not you can conjure up a complex algorithm that scientists figured out over multiple PhDs, it is about how you make your way through a challenging situation. And in fact, if you have already seen the problem or know it, it is much less interesting to the interviewer and they may even report the interview as “not enough signals” which isn’t good news for you. So next time you get excited about flawlessly solving an interview question in half the time, or get sad about how you struggled through the interview needed hints and guidance, think twice. The outcome of the interview may actually be the opposite of what you think. This is the reason why you hear so many people say things like — I thought I bombed the interview, but ended up getting an offer. Or, I solved all the questions flawlessly, I have no clue why they did not give me an offer. It’ because they misunderstood the purpose of the interview.
Being a good software engineer vs. being at software engineering interviews are two different things
Second, please understand that being a good software engineer and being good at software engineering interviews are two completely different things! A lot of time I see people mix these two. People are trying to learn about graphs as they are preparing for the interviews. That usually does not end well and it is ineffective at best. For example, if you keep messing up permutation problems over and over again, continuing to grind it out will not miraculously improve your performance. All you are doing is memorizing the solutions. And when you memorize, the smallest tweaks to the question and it’s game over for you. You are struggling with permutations because because you don’t understand recursion or basic probability. You need to focus on learning those first, without the context of the interview.
If you need to improve your fundamentals, go do that first. Spend 1-2-3 months, 6 months, few years, however long it takes, and master your fundamental knowledge, long before you even try to solve your first interview problem. Once you have that covered, then practice the art of being good at interviews. And, I will say it again, those are two different things - don’t mix them together! One is about being a better student of the field, being better at the concepts, being better at the core ideas. The other one is being more effective at a process. Think of it like knowing English and being great at writing in English. You need to know English to create great compositions in English. You cannot learn English and create great compositions at the same time. Learning English must happen before you polish your composition skills.
Get rid of the pressure
Third, do yourself a favor, if possible, stop cornering yourself into the “I have to succeed” situation. I mentioned this earlier in the video, on how we pressure ourselves into a situation where the interview becomes a must-win. That just makes it so much worse. Interview for fun. Do it when you already have a good job and you have no desire to leave. Imagine working at your dream company and getting an offer from another top company just for kicks. This empowers you. It gives you confidence. Also, stop thinking of interviewers as all-knowing people that are somehow superior than you. This leads to an inferiority complex and causes imposter syndrome, which seriously limits your ability to do well in the interviews. Interviewers may be in-charge of evaluating you at that given moment, and some may actually be very smart individuals, but all of them are sure are hell are not smarter than you. I’ve interviewed candidates that I thought were geniuses and that gave me even more reasons to hire them because I would learn a lot by working with them as well! Interviewers are simply doing their job, just as you are — they are there to get certain positive signals, and you are there to provide it to them. It’s a mutual exchange, there shouldn’t be any other power dynamics there. So don’t create that in your head.
And finally, stop this mentality of thinking that you have to get a certain job. A lot of you put so much pressure on yourself that you have to get a certain job at a certain company, esp. with this FAANG or DIE mindset. It’s not cancer that you have to try to beat it. It’s okay if you feel like cracking the interview at your dream company is too hard. Maybe you lack the foundations, maybe the experience, maybe you just need more time. It’s not the end of the world. You can always work your way up there. There are a million other amazing companies that will keep you happy and challenged.
So yeah, I think it is a good thing that tech interviews are the way they are. It makes them predictable and you should make that work in your favor. It would be much harder not knowing what an interview would be like. How would you even prep for that? It would be like you walking in to a room thinking you’d be dancing with BTS and instead realizing that you’d be fighting Mike Tyson. At least with the way coding interviews are, you know you will always be fighting Mike Tyson, so you can at least train accordingly. Of course, there can always be bad experiences with bad interviewers, but that is the case with any interview. At least with these objective interviews, other good interviewers can easily spot the bad ones.
Overall, I honestly think tech interviews aren’t unfair at at all. If anything, it is quite a fair system that does its best to be on point and objective and to remove any biases or favoritism. You just need to shift your thinking to understand the signals tech interviews are trying to gather and make that work in your favor!
