You may be familiar with a famous quote thats has been attributed to Albert Einstein:
"Everyone is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid."
Now there is some debate if Einstein actually said or wrote this BUT the wisdom, nonetheless, rings true:
If you judge everyone by the same metric, there is a chance that you may not get an accurate measure of success.
Sadly, during my 7+ years working as a professional developer in the tech industry, I have seen a metric used to measure developer and programmer success that in MOST cases does not match the actual skills needed to be successful.
And if you have at any point attempted to apply for a job or interview for a position, there is a STRONG possibility you have encountered this metric; Coding Tests.
Coding tests come in several different forms but at their core, their goal is to test your proficiency with computer science principles, algorithms, and general CS knowledge. Coding tests can be delivered in-person on a whiteboard, virtually in a coding sandbox environment or in live-virtual environment where an interviewer asks you to share your screen and watches you work.
Fundamentally, coding tests are non-problematic. They are just a tool to measure a developer or programmer's competency and can be administered to most any job applicant fairly consistently.
But as with any tool, when used inappropriately or without the proper understanding of its usefulness, they can do more harm than good.
So let me briefly summarize why I no longer interview with companies that require a coding test.
NOTE: I am specifically using the word "REQUIRE" as I do not have an issue with a company that uses coding tests as one of their many metrics to evaluate candidates. I am particularly talking about companies that evaluate all technical developer/programming candidates via a coding test and DO NOT have an alternative option for a coding test in place.
1. It Shows a Lack of Care or Concern
So I can understand in the grand scheme of things why coding tests are useful. They allow a hiring team to quickly screen a large amount of candidates and gives a fairly easy metric to judge candidates by. It it by no coincidence that most very large tech companies use them in their initial stage of the interviewing process as a means to weed out "low competency" candidates.
But it is this EXACT reason that coding tests being a requirement in an interview process shows a lack of care or concern. It shows that the goal in this interview process is to weed out candidates, regardless of their wholistic strengths.
It doesn't matter if the candidate is a self-taught programmer, a high-performing developer who has worked in the industry for decades, or a college student pursuing their first opportunity, coding tests only evaluate you on a single metric. And if you have spoken with many recruiters or HR professionals at some of the bigger companies, it acts as the ultimate gate keeper to opportunities.
Being a tech professional who has been interviewee, interviewer, and sometimes just observed technical interviews, I have found that coding tests can be used to invalidate a developers experience and skill in an instance.
I have watched as EXTREMELY competent coder crumble when they were given a coding question that they struggled to answer and that I later found out, the interviewer didn't know how to solve. The interviewer simply went online found common coding questions and presented them to candidates. Luckily, I was able to participate in the interview and "intervened". This particular story ended up having a happy ending but not every interview will have an "observer" associated to it.
I have personally been in interviews where I have done stellar on all technical questions related to the actual role (as explicitly stated by the interviewers in the process) but was no longer considered a viable candidate because I had a hiccup trying to solve an esoteric algorithm coding question that would NEVER be used on the job.
Personally, a coding test requirement in the interview process indicates to me that an employer and an hiring team aren't really in touch with what makes a quality developer and how to measure actual success. But are looking for any easy way to comb through candidates and minimize interactions with candidates until they are further down in the process.
2. Some Candidates are at a Massive Disadvantage
This point personally hits home for me, but there are circumstances that can make a coding test extremely unfair to candidates looking for an opportunity at a company.
Imagine we threw away everything I said in my first point. Imagine that all coding tests were administered by hiring professionals and teams that genuinely cared about their prospective candidates. Even if the hearts of every interviewer and person in the hiring process was absolutely pure, coding tests would still put an undue burden on otherwise competent and valuable candidates.
How so?
Well it comes down to the fact that some people are ALWAYS going to perform badly in a code "testing" setting. May it be someone with a learning disability, an individual with forms of anxiety that affect testing performance, or someone who's background makes the testing material extremely difficult. And know, this is not an exhaustive list but a representative list of limiting factors to coding test performance.
Sadly for me, I've ALWAYS struggled in high pressure testing environments (ask my college GPA about that 😅) and I've also struggled with coding tests because as a self-taught programmer, things like algorithms and CS concepts are something I didn't really encounter until later in life.
Because of those factors, it makes coding tests extremely difficult. Even in coding tests where I have done "okay", it still didn't feel good. And though I have always performed extremely well at any role I have ever had the opportunity to work in, a coding test metric would show me, in most cases, as absolutely incompetent.
There was one occasion where I was going through an interview process and performed will at almost every stage. At the very end of the process, the recruiter was giving me amazing feedback and was about to end the interviews for the day. (NOTE: This was an on-site multi-hour interview.) As I was heading out, I was asked if I'd be willing to do an "extra" interview with one of the "higher-ups" in the company and I was fine with that. What I didn't know, was that they were going to administer a "test" to me. Within the course of 15-minutes, I lost the job. My anxiety destroyed me. EVEN THOUGH, I was found to be competent and qualified by others in the process, my failure of this one "test" ended my chances.
That was a very personal experience, but I have a feeling that I may not be the only person who has been summarily disqualified from a position because of a poor performance on a test (some which don't even cover skills that would be used on the actual job).
3. It's Not Worth It!
I have a personal conviction when it comes to interviews, that goes like this:
"You already know what you know, No need to prepare!"
Once again this is a personal conviction (which I don't expect anyone else to have) so my personal mentality with interviews has always been to do no extra preparation other than maybe reviewing what I already know (and brushing my hair and looking presentable 😅). I want interviewers to have the most honest reflection of my skills. I want them to see me as I would be if I worked for them on a daily-basis.
I have on multiple occasions in the past been told I need to "study for this interview". I would then be sent a set of links or a PDF on how to prepare for this interview and necessary skills I need to learn to "pass" it.
When I was looking for my first job in the industry and I had almost no experience or knowledge that I could exemplify in a demonstrable way, I kind of got it. Companies need to know that I can learn and that I'm willing to take challenges, so fair-play. But interestingly enough, I got my first job in the industry without having to study or take an explicit test; They did test my knowledge but it was relative to the job role itself.
Now, as an experienced professional, I personally refuse to study for a job interview for skills that I will not use on the job. It's just not worth it.
With the busy-ness of life and the difficulty of finding time to study with a full-time job, in most cases, I have been asked to study concepts and materials that I almost never have and never will use in my day-to-day. There is a good chance that after I pass the test that I may NEVER use the knowledge I studied for in a meaningful way when I do land the job.
I have from time-to-time contemplated maybe studying for a coding test and then realized I'd rather spend my time learning skills that I will most likely use in the future. It many ways, I feel that asking to study for a job interview should not be the standard. You should be evaluating the candidate based on their current skill, not on a skill that they don't currently possess.
Now, at the end of the day, this is all my personal opinion and comes from my time in the industry but I'd love to hear other people's thoughts. I am not completely against "coding tests" per-say, but I do feel that they are overused and/or misused in the tech industry. At a minimum, I think there should always be an alternative to a coding test OR that it should NOT be used as a "gate-keeping" mechanism in the interview process. If anything, just like behavioral tests that are given during some job interview processes, it should be used as a frame of reference, not the deciding factor.
So do ya'll think coding tests are worth it? Do you disagree with my opinion/take on the matter? Did I get something wrong or make a point that doesn't make much sense?
Please let me know below in the comments. I'd love to hear your thoughts!
Thanks for reading, my friends,
Bradston Henry
And If you are interested in checking on what I believe to be better ways to interview, check out my blog on tech interview approaches:
===CREDITS===
- Cover Photo: Monstera from Pexels
- Education System Photo: Unknown
- Woman Shrugging Photo: Polina Zimmerman from Pexels
- Disappointed Woman Photo: Andrea Piacquadio from Pexels
- Man's Smartwatch Photo: cottonbro from Pexels
Latest comments (136)
We are responsible for this culture of leetcode style interviews. If all developers just say no for this kind of interviews this won't happen. The problem is that many people are accepting it.
Absolutely correct! Which is why I am going to bail on the test I scheduled with a major tech company. The test really measures nothing today, only that you remember how to do something you probably recently did. If this is how a company determines your worth, they got it wrong.
Many of HR and Interviewers have been pitched that Leetcode tests are so great but have been proven to be useless and a waste of many interviewee's time. Unfortunately there could be many frauds in acing these tests but not be prepared for real job. Also many of the benefits I have heard from these tests are mostly the exception to the rule and are actually false.
hey man. sign on EVERY of your words and each paragraph. HR industry in software engineering is fucked up. I am waiting when these all the hiring models will be destroyed and all of us come back to the same what was 15 years ago. So I can start working normally again.
The current models are very much suitable for new comers engineers, juniors, => which leads disproportional amount of them in the market comparing to leads and seniour=> which leads to actual fuck up of all engineering process. Once heads see it and understand they will revert process back to hiring competency.
you are not wrong. I am so sick of technical tests. And now that there is an entire business industry behind it. (hacker rank, codesignal, Leetcode etc...) you can all but guarantee it will never go away because of massive amount of lobbying. I now cancel interviews and tell the recruiter I won't do white boarding exercises.
Yeah. I passed 2 interviewers but I couldn't pass the tech "leads". They wanted me to sort and array manually. So I said, "why sort it manually?" Can you shuffle it? he asked. At that point I fingered out that they were just going through the motion. It had nothing to do with the framework for which I was being interviewed.
This is a great article and you make some excellent points. I started, self-taught, in software development (SD) in 1988. I have never gotten a job where 2 things factored in: 1) multiple interviewers, like a panel [always only 1-on-1] and 2) after taking a coding test.
Lately I found out (and think about this) that the developers who write these coding test/exam websites take literally MONTHS to write them. They have to go through ALL the process of the SD life cyce, not to mention the bugs they have to fix when it is in production.
Basically, candidates are required to take coding tests from platform that their very own developers cannot complete within the time required for us to do the test they wrote. Each time I take these test I feel heat in my head and I can't keep my eyes of the timer. I swear sometimes I hear the seconds ticking away. I tell myself one these days I would pass.
I quote from Stack Overflow: "...For the stuff I imagine that you want, the answer is that someone else probably already figured out how to do it...." So, me now, why "r_e-invent the wheel_"? The best part of SD today is "it probably already exist out there so we don't have to rewrite". Why do an array sort manually? Knowing how to find the right tools is a key part of the SDLC.
I immediately walk away from those, it’s funny I actually had a company who I walked away from as a result of those test come back to me 6 months later to say they wanted to interview again as they had removed that test from their process as it was costing them too many good candidates.
As someone who sits on the hiring side, I setup my own assessments, usually a coding test that is take home, pretty open and you have a week to get it back.
Many times in my past have I seen these pointless online test that test nothing based in reality, or even unrelated take home test like, like once for a React dev the test asked me to code an animated coffee machine. Like I could do that in my sleep in like an hour, but i don’t waste my time on irrelevant nonsense.
I expect the assessment to test the relevant skills for the job and ideally be somewhat fun.
@bradstondev Which alternatives do you consider as acceptable instead of coding interviews in some cases?
A few options come to mind as alternatives:
Project Based: Instead of a test, give the candidate a "take-home assignment". Give them a task or ask them to solve a problem similar to something they would encounter in the role their interviewing for. Great for candidates who struggle with performance anxiety and helps them to perform more closely to their competency level.
Pair Programming Session: Pair the Interviewee with an Interviewer and let them tackle a problem together. This is great way to see a developers skills and to see how they take input and guidance. This can still be a struggle for those with performance anxiety but can can be a good experience if there is a good interviewer who is patient and understands.
"How Would You Solve..." Prompt: Give the candidate a problem that actually needs to be solved in their role and let them walk through how they would solve it. I would even go as far as Role-playing out the scenario to get as close to a real world equivalent to how the candidate would respond.
Personal Project Review: If the candidate has any personal projects that they have made, ask them to share their source code and review their code with them. Ask them why they did or did not do different things and see their process. This helps you understand their thinking and also can reveal if someone is likely to copy-paste code from Stack overflow 😅 and not have understanding of what the code does.
"Take a Ticket" Approach: This one I've never personally seen live, but is very similar to the "take home project" approach. During the actually interview, give the candidate access to some code that is actually in use and give them a ticket to try and work on. Though they likely won't finish (for many reasons) in the interview process, you can get an idea of how they approach actually problems. Let them work on it in a "real work environment" and then walk through their thinking process.
My thoughts is to approach each candidate in the best way that best reveals their skills. Some of the above practices won't make sense for some teams but there is a good chance you can avoid using a code test and fight to evaluate their skills differently and get more indicators of their actual skills and how they may perform on the job.
I think in whatever process you use, you talk to the candidate about how and why they made their coding decisions. You may think a certain coding pattern is "wrong" or "bad" but after talking to the candidate you may learn that's actually the best or better method.
Hope that makes sense.
Thanks for the reply. It does make sense.
I've been through a few of these coding tests over the years and absolutely refuse to partake in them anymore. If a company cannot take the time to review my extensive portfolio, peruse my github repos or assess some of my many answers on Stack Overflow they are not worth the effort.
Every test ends up being more of a how fast can you search/read scenario than actually testing any kind of useful metric. The optimal answers are usually some unreadable leetcode that would never fly in any reasonably maintainable code base.
Programming is about solving problems, not memorizing algorithms. If I am unsure about the best way to accomplish a task, there is guaranteed to be a question posted online with 20+ answers where the real subject matter experts have hashed out every conceivable detail. I consider checking this no different than looking up API documentation. Sure, I remember commonly used expressions but should I be expected to memorize every feature of every language or library I've ever used?! By this logic a writer would never use a thesaurus either.
The problem, as I see it, is that these tests are usually administered by HR people who have never written a line of code in their life. I've been a developer since before most of them ever touched a computer. I first learned to code from a book, before the internet even existed. Yet I'm expected to validate my knowledge for their sake. No thanks.
In the freelancing world, I would never provide any code to a potential client until I'm hired for the job. Period. I may, however, whip up a proof-of-concept and send a sample video but this is my choice rather and never a requirement. If a job post demands unpaid samples or testing, the get flagged as inappropriate.
The only way we as developers can change the hiring landscape is to collectively boycott these abhorrent practices. Remember, we write the rules. We create the tools that make the world run. If they want to make use of our skills they need to prove they are worth the dedication, not the other way around.
I say, the next time an interviewer demands a coding test, ask them to provide the definition of a few obscure words and see if they can answer without a dictionary. Maybe then they'll have a better concept of the unreasonable expectations put on us... "I'm sorry, do you not know every detail about the language you use every day? hmm. And how many languages do you know? Oh, just 1 or maybe 2, pfft".
If the hiring managers really want to see some code, a take home problem seems like a good compromise to me. I can implement any arbitrary algorithm if I am allowed a little time and some reference material. In my day to day work, it's a pretty rare event where I need to implement an algorithm from scratch (I do mostly Java and Clojure). The longer I go without having to code one of these algorithms up, the harder they are for me to remember.
Can’t agree more. I personally more into practical than theory.
However, how many “good” companies out there do not practise a technical test? Especially after the rise of leetcode and all bunches of coding interviews platforms and websites. I doubt. I truly wish to look for one.
I have to full agree, I’ve been on the hiring side and I’ve found the best way is to keep it open.
I give them a take home coding assessment, a small task to complete that should not take more than 4 to 6 hours. I tell them the required end result, how they get there is up to them.
I normally give a week, maybe a bit more, that always ensure there is a weekend before the due date, gives them time to plan for it, think about it and gives them the best opportunity to shine.
As a developer myself I hate those generic tests, I refuse to take those algorithmic assessments, I’ve been a developer for 13 years worked in startups and fortune 100 companies I have been the architect for a number of projects, run half a dozen teams. I don’t even know what an algorithm looks like, after 13 years it’s done nothing to impact my abilities.
Just recently a company sent out an assessment and at the end I felt this overwhelming desire to write a mail to Oxford to request they redefine the definition of pointless to be that test.
The questions where so baseless and pointless that I quite literally just selected answers at random. I have no expectations of getting the job and quite frankly if by some bizarre twist of fate if I did, I’d require my contract to include the abolishment of that testing strategy
What about take home coding tests? The company I work for was using those up until recently, as we were getting told by recruiters that the take home tests were putting off too many candidates.
What ended up happening for us though, was a lot of candidates who weren't at the level we were looking for (or indeed asking for) and we could only find this out when we actually spent the time interviewing them.
I've had bad personal experience with on-the-spot in-person coding tests during an interview, and but I feel a lot better about take home tests. The only bad experience I had with one of those was partially my fault (I was ill and rushed through it, missing some obvious things), and partially the companies (they had no language version requirements, but then complained I wasn't using the languages latest and greatest features, even though I'd told them exactly why I hadn't when I handed the code in).
Personally, I feel that take home tests are a good thing during an interview process, as long as the test is something sensible and not another bubble sort! From a candidate perspective, they remove some of the pressure and stress, and allow for more flexibility in setting up a relaxed environment in which to take the test. For recruiters, who may be dealing with extra pressure because a colleague left, they reduce the extra time needed to assess candidates. If you consider that an interview might last an hour, that is 1 hour of candidates time, and about 1½ hours of each interviewers time, multiplied by the number of people performing that interview.
@lukaShiru, i just started following you. cant agree more