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 abili...
For further actions, you may consider blocking this person and/or reporting abuse
I find it fascinating that people build coding tests to test what people know, to see if they are fit for a given job.
Then candidates study those tests so they can get the job.
Then people analyze their performance to see if they are fit for a given job and then continue the process with more tests.
The only issue is if the coding test is nothing like the actual job, everyone else is spending time and effort dealing with what is ultimately unrelated to the actual job.
If the actual job is very coding-test-like, then sure that's an excellent representation. If its not, isn't it a huge waste of time for everyone?
I feel exactly the same way. It's 100% appropriate if the job itself has a lot of tasks that might mimic the problems you have to tackle in a coding test, but thats seems more like the exception than the rule.
And it would be quite a tragedy if you performed extremely well on a coding test, started a job and realized that you didn't have any of the skills needed to do the job.
To think that a coding test could be a waste of time for anyone involved. Not good.
I agree with you, and I've been there.
Three years ago I applied for a company that required a JS test with tests in Jest. The test was basically to input any number and output this number's name written (102 -> one hundred and two). I nailed it, reviewed the tests and the code 20 times, refactored and so. The interviewer loved it!
I got the job and then I realized: they were expecting a much higher level dev which should do JS AND React AND Ruby/Rails (I was aware of the stack needed before interviewing, but the test level was much easier than what I was expected to deliver in the actual job).
That's tough! So sorry to hear that happened!
How did you handle it when you started working the actual job?
Had to be super discouraging to run into that!
Thank you for your kind words :)
In fact it was tough... I could handle well with the React stuff, but on the backend side I was still a junior dev. As the time passed I could feel that I was not attending their expectations, and one year later they said that they needed someone with more advanced skills in the team. However they were super kind and let me stay in the company until I find a new job, which took two months. Not everything was bad at all :D
Wow! That's incredible!
Even though I'd never wish that on anyone, I'm actually amazed by their empathy and consideration in your situation.
Really happy things worked out for you! That's an amazing story!
I personally think really a lot of abilities that help you perform well in job also help perform well in coding tests. But it of course also depends how coding interview is done from interviewer side.
I see coding interview more like a pair programming session. While problem is synthetic the methods used to problem solve and the skills that are exposed during this session are all relevant to day to day job.
I had chance to run a number of code interviews over last couple months, and most common problems were:
I think neither of this is in any way some esoteric situation. It's just daily work stuff. On top of that if problem is really more on esoteric side and has some things that candidate needs a "click" in brain to happen, I try to do my best to help guide them so that this click would happen.
When I think of daily work stuff I think of doing a feature and PR review.
A common alternative I hear to a whiteboard interview, or a coding challenge is a take home project.
A take home project can not only test more relevant skills, it also provides a more real-world experience for everyone. With PR-like feedback the experience would also provide a similar setup to a work environment, and allow you to uncover all those problems you described above.
This is all without all the stress you'd get from needing to code/solve a problem immediately while someone else watches.
I'm not saying all companies should do this, or that all companies could do this, but it does seem more reasonable and relevant than dropping someone into some "test environment" and pointing out the similarities, rather than just putting them into a real world "work environment" and having a guardrails setup (fake inputs, fake data, relevant but fake project).
With take home tasks problem is that some candidates would spend 1 hr others might spend whole day.
exactly the same will happen when they are part of your team, no matter if they work from home or sit in an office. Doesn't matter much when they deliver good quality.
Getting paid by time spent is not much better than getting paid by lines of code, but it seems to be the most common measurement in our business somehow.
I think it's the other way around. Company is much more intetested in someone who can do a task in an hour, than in one that can do same stuff in 8 hours.
The last bullet point:
have you run across companies that seem to not care about or even think programmers should be able to read and comprehend and manage bad naming and obscure code such as literal numeric constants in conditions?
It sometimes feels like I get the short end of the stick either way:
besides the fact that NO, SORRY, NOT EVERYBODY IS A GENIUS, (maybe different, maybe special but not genius) I always loved the quote:
and found arrogant and patronizing when people "judge" a person in all their complexity based on just few parameters.
But I love it only when applied in general or just to the education system.
A kid could be good at Math, and suck at art.
A kid could be good at Drawing and suck at Science.
Both are very intelligent and special kids, teachers should remember them, respect their different abilities and natures. Try to foster where they thrive and support them were they lack.
But.. If we are talking about a specific thing, a specific skill that we are assessing, this quote is meaningless.
If I visit a Music school, and I suck at anything musical, I cannot just say:
If the fish applied to a Tree Climbing competition, should we really take into account his ability to swim? Or should we, with good reason, consider him stupid for even applying?
I am sorry, but here we are talking about hiring someone to become a Software Engineer, so the ability of coding must be assessed.
We can discuss how, in which ways, with which tools, but a "coding assessment" is necessary.
It might be stressful, it might be timeconsuming, it might possibly weed out valid candidates, but it is necessary.
as everything in Software Engineering, and basically in life, IT DEPENDS, mainly
If you apply for a Solutions Architect position, you can't just say: well... I am not good a drawing diagrams and not so good at naming System Design principles..."
If you apply for Frontend Engineer with React experience, you must be able to quickly jot down a component with a couple of hooks.
If you are a Javascript Engineer I expect you to know about Currying and Partial application.
Of course there are loads of stupid companies and interviewers that fail because the apply interviewing patterns that make no sense for their company and daily job. But it is not a flaw of the coding test.
If the job deals with algorithms, performance and really complex low level stuff, you must have a CS background. (be it self taught or official). If the job envolves solving problems with code ( and namely, building some components, and connecting apis and using services already built for the job - be it a library, or a Cloud provider service) way less.
I also had interviews where i was asked to reverse a string or sorting an array without using any native methods.. which is something that makes no freaking sense in a real world scenario. I failed them miserably, but I left without any sense of defeat - either I would not be a fit for their daily tasks, or the company mindset would not be a fit for me.
The point is, hiring is hard ( and being hired too).
There is no right way to do that. So in the end, it is really up to your gut feeling, and the company that you applied for.
I really like your thoughts on this!
I think it's interesting because the issue isn't the Coding Tests in their purest form, it may be an implementation problem.
At the end of the day, Recruiters, HR professional, and development teams NEED some way to judge if a candidate is competent. And sadly, just taking a person at their word is probably NOT the way to go 😅
I think you statement really rings true:
I think it's INCREDIBLY important to trust yourself and know what is best for you and evaluating your skills. For me, it's not coding test but for others it may be.
Exactly my thoughts. No matter what companies will do, always will be someone complaining about the recruitment process. Currently is most visible as the project-based vs test-based check of experience.
This is for me, one of the best answers I have read. Personally, I agree, you cannot be a solution architect and don't know how to create diagrams. I am a "huge" fan of the C4 model.
Furthermore, I agree with the point that if you are applying for jobs working with metal or I don't know nuclear plants, I agree that you must have certain skills. However, the main issue I have experienced in Europe is that I used to have too theoretical code interviews for things you would never use. When I was searching for a job, I never applied for optimizing OSs or building Machine Learning Models positions, and I still had questions of topics I hadn't used in 10 years since I had graduated from CS.
In my first interviews I failed horribly, and I was forced to study things that I don't use, and I already forget again. I still have a crazy sticky note in my phone if I ever need it again with all potential questions that I got that I didn't remember in detail.
I can just add that I'm not against code interviews, in the only company I worked in Poland that was a large corporation, we had technical tests, but they were about a small business case that was related to your future job. We had some CRUDs and other stuff, and you could choose the .NET tech you wanted. After your solution was done in 1h more or less, you will have questions and based on that we proceed. I consider these tests fairer and with more sense.
We avoided extremely theoretical tests where people had no idea about .NET, LINQ, T-SQL, etc. but they knew all sorting algorithms ever, and we focused on the people that our business needs. Sadly, I had seen more comparably sized companies doing the same Quick Sort or related algorithms for unrelated positions that when the times come and you start your job, they tell you things like this one: "You must migrate an entire DB instance on your own for X date." This happened to me, and I succeeded, but not everyone is so lucky.
agreed 100% with you . best comment and answer
I don't think the meme really fits, because it implies answering academic "implement bubble sort" type questions is more difficult than solving real-world software engineering challenges. I don't think it's more or less difficult — it's just a different type of question altogether.
When have you ever had to sort an array in JS without using sort on a real job? When have you ever had to implement bubble sort on a real job? They're just trying to trick you because they are jealous they are not wicked smart like you. :)
Yeah the most difficult thing about sorting arrays in JavaScript is remembering which of
a - bvsb - a(ora.localeCompare(b)vsb.localeCompare(a)) means "ascending" and which means "descending" 😅As for performance, the browser implementation is already optimal (versus anything you could implement in JS itself, at least — possibly you could squeeze out some extra perf with WASM) in almost all cases.
Disagree: The meme is perfect. The difference is the very short time constraint and people watching you code. I can solve way more difficult problems given more time and space to figure things out. But in an interview even basic simple things can feel very difficult.
Exactly that! The interview is anything but a relaxed setup, no one will start cutting the code immediately when faced with a new challenge while someone else is counting his breathes! During the interview the anxiety high and the focus is low, the brain is surviving mode.
I am ok to read and explain a code, but not to cut code during an interview.
Not even a different type of question. It's highly relevant as a test.
We usually do coding tests not as a test of knowledge and skill, but more as a test of approach and methods. Applicants may ask as many questions as they want and a working solution at the end of the test is not a requirement. We'll rather have someone to ask the right questions than someone who thinks they know it all.
Totally agree with this one. When the interview is scheduled, it should be made clear that a coding test will be part of the interview, so that the interviewee isn't caught off-guard. Then, during the interview it should be made clear that the interviewee can take as much time as required and that it is advisable to ask questions which will help clarify the problem at hand. If these conditions are met, I don't see any issue in taking/conducting a coding test.
I once advised my manager against taking a senior developer who had aced the coding test with ease, but was also the most opinionated person I ever had the misfortune to meet and the quintessential antithesis to a team player. I really wouldn't have wished him on any of our teams – and the colleague who was conducting the interview with me immediately agreed.
On the other hand, an interviewee with a speech impediment who was obviously very nervous and barely managed to finish the coding test, but had asked the right questions, I could wholeheartedly recommend; he is now an estimated team member and was promoted to senior developer last year.
Oh, the gatekeepers, where would we be without them.
When hiring for jobs that have more applicants than openings, you always get gatekeepers as a necessity.
If you're lucky, they will also look for things like team dynamics and methodology. If not, I'd hope you'll find another job soon.
My argument is that if you're choosing people to run in a team for a marathon, its only fair to ask them to walk or jog on the spot first, rather than saying 'Oh he's a nice guy/gal' go through the whole process to onboard them and later find out on practice runs through office gossip that they are actually lame and they'll need a guy in the team to carry them across the finish line. Its only unfair if your tests are, dance the salsa or juggle footballs, as while it shows proficiency in foot use, but not in running.
The issue is not with code tests, but how they're designed. If you're talking about getting asked to whiteboad BST re-ordering or to write a string palindrome without google or what is cyclometric complexity of this project or whatever, then yes you're totally right to walk out of there.
We do them. We had bad experience with a senior getting fired while on probation. Not a story to tell here. Another important reason to do them is to see code and git commit quality.
I designed some of the technical tests for my employer. They're based individual actions we need to be familiar with doing our job. For example backend,to show you can understand OOL, expose a function, commit history, etc. For front end its like heres a form, an api, make it look like this in html and css. 30-60 minute stuff.
We had a guy we really liked who aced the non tech interview until we gave him a 60 min test (reality 15 min test) and with ability to google what to do. Barely did anything, blamed the test, so I did in front of him while explaining what I'm doing. I could have been typing in Sanskrit as he couldn't explain what I did to solve it.
Amount of time working in industry means nothing in software development as its so varied and tech changing all the time.
That's a good point! I think it's important to not "toss the baby out with the bath water".
Personally, coding tests have never been a good metric to test my competence BUT that doesn't mean it's not a great one for others. At a minimum, if administered correctly, it can give you some insight into the developer and how they code and what is their "technical proficiency" in a subset of skills.
Sadly, this is BEYOND the truth. I think an important question to ask any developer (especially senior level) is how their skills have progressed over the years and also to see their technical skills in a demonstrable way.
It's sad to say, but I have worked with people who are much more "seasoned" than me but REFUSE to learn how things like Git works because it's not something they like, or, the worst excuse, because they are "not interested in that technology".
Thanks for sharing your thoughts. Always love to hear different and well-thought our perspectives.
Amen to that, a voice of reason :)
Coding tests are unfortunately necessary. There are plenty of people out there who can't code their way out of a wet paper bag but have impressive looking resumes. Search for "The Brillant Paula Bean."
That said, the best coding tests are those that reflect the sort of work that will be accomplished on the job itself. The existing developers at the company should take a specific but relatively simple task that they themselves have done on several occasions (e.g. a data processing exercise), remove business-specific information from the task, and then have potential candidates submit code examples. Record how long it took each candidate to submit their solution to the problem - shortest time is not necessarily the best candidate. Since it is a company-specific exercise and pretty easily changed, it is unlikely to have a ready-made solution when searching on SO.
Companies should also have an alternative to the coding test: The GitHub account. If someone has 10 or more relatively high-quality projects on GitHub that they created and actively maintain themselves and can provide in-depth details about the structure of each project, that is more than enough information about them as a developer and they should be able to bypass the coding test altogether. It's still a good idea to take the test as a mere formality just to prove their capabilities to the other side. But both sides can roll their eyes over the necessity of the test.
Another great alternative to the coding test is having the interviewee describe how they would go about solving a specific business problem. Most software development isn't the actual writing of code, which is important, but rather interfacing with other humans to gather requirements and work through whether some requirement needs to be rigidly coded into the software OR can simply be a policy and therefore the software can be a bit more flexible to accommodate a wider variety of unforeseen use-cases. I prefer software that is minimally invasive (i.e. few enforcements) and just relies on people to use their good judgement and only occasionally apply policies as the need arises. People tend to enjoy using less restrictive software that does that.
I'm not questioning your view on whether or not this is a good or bad interview coding problem. I'm just commenting on the "supposedly that's faster" part.... The worstcase runtime of the various counting sort algorithms is O(n), whereas the best you can do in worst case with a comparison sort algorithm, like mergesort, is O(n log n). When a counting sort algorithm is applicable to the data, it can be extremely faster than mergesort and the other comparison sorts. In most common cases though, either its not applicable, or the array size isn't long enough to overcome the constant factors, or for other practical purposes.
This is probably not a good interview coding question in general though. Actually it isn't really a coding question at all. It is an algorithms question masquerading as a coding question.
Hi Bradston! I like this Einstein quote too, "I never commit to memory anything that can easily be looked up in a book" and "Never memorize what you can look up in books." (The second version is found in "Recording the Experience" (10 June 2004) at The Library of Congress, but no citation to Einstein's writings is given).
en.wikiquote.org/wiki/Albert_Einstein
This is important. I think a better test might be to present some problem to the interviewee and ask them to explain how they would go about solving it. You would get a good idea of their problem-solving approach. Asking them to regurgitate the syntax for some specific algorithm says nothing about their range of problem solving approaches, their creativity, or their willingness to ask others for help.
Leetcode - all big tech, FAANG (MAANG?) companies use it. I have the impression that generally, people hate them.
I am personally divided on this subject. Yeah, if a company gives you a HackerRank link and the feeling that "if you can't do these then don't even bother" then this sends a really bad image. However, if you are tasked with solving the puzzle together with a second engineer then it makes more sense. Sure, you can always end up with a bad interviewer (the interviewer trainings are laughable IMO), but the objective, IMO, should be to find out how the candidate thinks, how he approches problems, asking questions, reasoning - yeah, it is nice to solve the coding puzzle, but I think this should not be a pass/fail approach.
What is more, coding tests show your willingness to learn things/standards. "I don't use it at my job" is a poor excuse. Sure, maybe DFS and BFS, but memoization? Also, I've never used/touched cryptocurrencies at my work - well, I am learning this right now.
Lastly, but not least, big companies have so many candidates that they can use whichever standard they want. Most of them use their own stack, so they need more good generalists to fill the body count.
I'd rather this than taking an assignment home, especially, when I am not paid for it.
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.
In certain domains, this is the kind of thing that comes up all the time and for which you can actually cost (or save) your company a lot of money. The approach you're describing is actually a well known sort called Radix Sort. It has a far better performance, at O(n) compared to O(n log n), not "supposedly" faster. There's a well-known problem/story about Radix Sort in Jon Bentley's famous Programming Pearls.
I've heard a lot of programmers scoff at stuff like this but it is actually useful and practical knowledge.
No argument that it's not necessarily a good interview question. In most cases, that's a poor interview question because it is testing knowledge (do they know about radix sort?) rather than skill or problem-solving ability.
I am an IT professional with 40 years of experience in the industry.
I could not have described my personal experiences any better. During times when I am looking for my next project/job, I will study and get certified with the various technologies that I am accomplished with.
In the interview process, I offer a potential employers my resume, copies of my current certifications and excellent references. If they are still insisting on a coding test, I offer them the opportunity to get online with me, even to take an independent test, just not their test. In my environment, I can demonstrated my ability and capabilities. At this point, if they still insist on their "climb a tree" coding test, I skip them and move on to t he next employer.
I the same manner as described by the author, I have taken some tests and encountered questions about the subject matter that I have never used in 20 years, so how can that content even be relevant to the position I am applying for? For example, I recently took a coding test in Java. One question used the work 'dailed' in it. I almost felt stupid that I didn't know what this was in nearly 20 years of exposure to Java. I had to look up this word. Turns out it is not even a word in the English language.
So to those who take the tests and move on to the next steps, power to you, as for me, I already have enough stress in my life.
I am perfectly happy to be passed over because I won't take their "climb a tree" test.
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.
This is so, so true. I live by this too. I never prepare for interviews. This advice first came to me from my A-Level physics teacher - in this form:
For the most part, all last minute preparation does is stress you out and make you doubt your own abilities. Relax and trust yourself - that's the best plan
I feel like this describes me exactly some times. I can get into my head and then everything goes out the window. I think that's why tests in general are a struggle.
I think coding test is necessary as there's a lot of fraud out there. People are claiming things that they cannot do or did not do. Unless the employer is very certain on someone's capability, then coding test may be skipped. In fact, coding test is helpful for beginners without professional experience to enter the job market.
Great quote that matches exactly my way of thinking as well. :)
You definitely raise some interesting points in the article.
I have started doing interviews for my company some months ago, so I can see both sides now, here is my take on this:
No matter what interview process you have, it will be impossible to have a process that works for everyone. Whiteboard and leet code exercises favors candidates with CS Background or "geeks" that like to do this kind of things in their free time. Take Home exercises discriminates parents or people with lot´s of other responsibilities. Live coding discriminates against anxious persons or that cannot perform well under pressure.
Even "discussion based" interviews, can discriminate against introverts or people with vocal related disabilities for example.
So IMO, the best way to approach is to always give the candidate choice, what it works better for them. I agree in having a positive and inclusive process where the candidate can show their strengths, instead of an exclusive process or the interviews are designed for the candidates to fail.
My current company does a take home exercise as the 2nd stage of the hiring process, after a first technical interview. Personally I would gladly don´t require these if a candidate has some other code examples that they can show (like open source / personal projects or projects from his previous job, if possible.
But I have to see sort some code., if possible in a similar type of what they would do in the job.
I love great technical and architectural discussions about real world scenarios with the candidates and you can definitively get a lot of information from this, but there are some details I have not found yet a way to replicate in other form, without seeing code. And I also think these types of interviews are probably more appropriate for more senior level engineers, where we can really go deep in many topics.
Some things I access in the coding exercise, include :
Tests. The candidate might say he know all the types of tests and do TDD and all that. but what they do in practice? The coding exercise allows me to asset that. How they think about the test scenarios? what kind of tests they do? Unit? Integration? An exercise without any tests is a red flag for me.
Documentation - Does they write documentation and explain their thoughts (a Readme file indicating how to start the project is enough in most cases).
Code structure - How they structure their code? Is it readable or they like to over engineer? do they provide meaningful names on the variables/functions? How they handle errors, logging, etc.
Infrastructure - Can we run the application without errors? Candidates that provide a Dockerfile/Docker-compose or some sort of script to boot the application are appreciated.
A good example, I have from a candidate that I hired last month. The exercise my company provides, includes a "list" REST endpoint with Pagination. From like 10 candidates, I saw one, that have handled edge cases like negative numbers on the pagination for example. While definitely not a requirement, it´s a nice touch that caught my attention and shows some attention to detail and that differentiates from other candidates.
This is the kind of things I look on the code exercise. I don´t need them to solve a very complex problem or algorithm. Even an "hello world" like API project, could give me enough information.
I am of course, willing to learn new ways to make the process the better possible for the candidate and for the company.
Incredibly well said and great insight!
I love the idea of having a deep consideration about what works best for the candidate for them to shine in the interview scenario. Our goal is to hire the best candidate for the role. not the person who fails the least.
I read somewhere that one tendency that an interviewer has to try to avoid is the tendency to hire "Yourself". It's easy to sit across from a person and try to see if they pass the test of being as "good as you".
In almost every discipline that exists, diversity of thought is ALWAYS an advantage and I think overly rigid interviewing requirements or the lack of flexibility to approach candidates in a way that helps them shine is detrimental to the whole process.
It takes more works and "care" but engineering your interview process to best suit the various candidates is absolutely the best approach.
Thanks for sharing your thoughts. Gave me more insight into other's interviewing processes and things that I think every interviewer (and interviewee) should consider.
Refactoring an existing code is also a good test.
The only thing that I can think of here is that, the quote from Albert Einstein doesn’t seem to stand here. Coding tests stand to measure the ability of people coding and their problem solving. Ie. you’re judging a fish on its ability to swim. That’s kinda the way I see it. Although you do bring up a good point. I do feel that testing programmers on complex data structure problems when they’re going to be a front end developer can be a tad annoying and not needed. However if you’re hiring someone for back end and they don’t know how to store items in a data structure to optimize for efficiency. That could lead to problems.
I think you are absolutely right but how should I get a job if I reject all those companies ?
You can try until you find a company that trusts you upfront. You can make compromise and be less strict that @bradstondev , but refuse to do "homework" assignments for hours or days that give them free work even if they don't accept you, but it might be okay for you to take a small assignment.
You could try to start with a free, unpaid, intership wich might be turned into a regular, paid, employment.
You could, and should anyway, post some of your work in a public place: GitHub, a portfolio website, or even better some small app / theme / extension that has to pass external code review (like writing a WordPress plugin - code review is not very strict at all, but it still takes some effort) so you can prove that you can actually code. Use that code for interviews and explain what you did, and why, how it works, and what you would improve if you had time.
That's a GREAT question!! @yw662
@ingosteinke Makes great points. There are other avenues that can show your skillset that can be a "substitute" to what would be considered the traditional coding test methods. I didn't mention this in the blog post but one thing I did once I noticed that I was never going to be in consideration for certain roles because I wouldn't perform well on coding tests was begin to build a Github presence.
I have in the past been in the interview process that had a mandatory coding test where it was skipped because they saw my code in my Github repo and didn't feel it necessary to do it (I personally didn't even ask for the exemption). In the end, I didn't get the job (there was better candidates with more practical experience) but it accidentally "confirmed my bias" about why i don't think coding tests are required.
And just another piece of personal advice, it is ABSOLUTELY okay to ask early in the process if it is possible to do an alternative to coding tests. I have talked to recruiters in the past who when I asked, they mentioned that it was an option. You never know!
Also, sometimes there are harsh realities where you have to be subject to a system that puts you at a disadvantage until you have the "power" to change or "affect" it in a positive direction. In some ways, I was lucky to find a job opportunity that didn't require coding tests early in my career but know that I wouldn't have let that stop me either way. I truly believe that persistence takes you a long way. And as a programmer, persistence is something that really helps you be successful because sometimes you are going to run into those coding problems that require it.
I'm not sure if you are looking for a job or considering a new one, but I encourage you not got give up! Even if it does mean you have to do the thing I personally dislike (preparing for the interview beforehand), you never know what opportunities await you one the other side. And hopefully, you'll have the opportunity to be more "strict" in the future.
If you ever need counsel or advice, feel free to DM on Twitter!
I had been an employee for about ten years after leaving my startup (which had not been a great success, but I have learned a lot) and have been considering changing jobs quite often, but mostly did not apply after recruiters told me about job details. When I did apply, there were some good and some bad interview situations, including clueless interviewers and standard questions like how would your perfect day look like...
After leaving the last company and getting the feeling that it was still nearly impossible to get a part time dev job in Germany, and that company culture sucks once you rather want more freedom than climb on the career ladder, so I found out it's a good time to freelance.
Now I have everything from very small individual customers to large corporate projects. Some companies do mostly the same interview process with freelancers that they do with aspiring employees. So even without "looking for jobs", I'm still looking for jobs sometimes and find myself in a candidate situation, but it will only be for a short time.
Indiviudual customers have been totally different, like we've seen your work, we liked it, we trust you to make something similar for us, how much will it cost?
From my experience, in most of the companies, in the first round you are generally asked questions related to your skill. Questions which are easily answerable and don't need writing or practice, only to see that you know what you do.
In the second round, they just see if you are able to implement those skills in the best way possible through code - they give you a very simple or a bit complex question ( not DS or ALGORITHM ) real practical situation.
And, Done..!
In my opinion these kinds of questions are really just meant to serve as a semi-contrived roadblock/sieve to help ensure that only “certain types of candidates” make it through to the final stages. Even though it is nigh inconceivable that you would regularly deal with sorting an array of one million, let alone one thousand, elements in a JavaScript context, unless you really like to re-invent the wheel and/or your boss doesn’t mind paying several hours/days of your time to fiddle around, you’re pretty much never going to come up with a more optimized approach than what the c++ programmers have already baked into V8 or whatever engine you’re using.
Asking a question that requires you to use built in methods creatively seems a lot more useful, but I see these kinds of “in a world where you’re using React, but somehow Array.sort doesn’t exist…” (I.e. frontend roles) questions in job interviews all the time.
Meme is spot on btw 🎯
github.com/Financial-Times/polyfil... Look up the polyfill, import, done
Hi Bradston - so I think the most appropriate "test" I was given during an interview was kind of like an IQ test. It had nothing to do with coding (i.e. soring an array of 1MM numbers without sort) - but it had everything to do with being able to "think outside of the box". It had questions that had obviously more than one correct answer - and in some of the questions they asked you to list as many solutions to the question that you could come up with. This company was looking for a multi-faceted developer that had good common sense and also the ability to solve a problem that did not have a clear answer.
Rather a click-bait-esque title, though I appreciate the clarification of the use of the word "require" in the title.
Case in point, I require a technical test for all candidates.
Junior's get a "here's some code, find the bug" followed by "here's some more complicated code, find the bugs" - the first is designed to verify they know the basic language, the second is designed to tell me how quickly they'll flag up that they don't know something. Even then, for Junior's, everything is done in one Skype/Zoom/Teams call, and I tell them about the decision & why before I hang up (so they know if they're getting an offer or not, no waiting).
Seniors get a "here's some high level requirements for an API, if you're working on this for more than 2 hours, stop, but get something back to me in a git repository within the next week." That's entirely designed as talking points in an interview about WHY they made the choices they made in the implementation - I never even bother trying to compile it. Again, seniors will usually get an answer during the interview.
There was one case recently, where the guy clearly learnt a specific framework for the purposes of the technical test - it was obvious he wasn't working with the framework because it was obvious he found an old tutorial.
We did a remote interview, and I wasn't sure about the guy. So I did a second, in person interview. Between the two interviews, he'd listened to what had been said, and had gone out and bought a book that I'd talked about in his first interview (he referenced parts of it in the second interview). That tipped the balance.
The point being, as you do explain in the body of the post, is that requiring a technical interview isn't the problem, it's how many employers use the technical interview, that is the problem.
100% agree with you. From my QA experience, I have been asked a lot about coding, dsa, arrays, interfaces.. Blah blah. However, when I joined the company, it was more about manual testing the web/mobile application and updating some weird testing tools that they used.
Why not focus on core competencies and judge the candidate based on what your product/project has to offer. Stop unnecessary coding test, just because its a trend and every company is doing it!
What do you do when a company asks you to do a coding test at their office or online? Ask for an alternative take home test?
Seems like you would make yourself non-eligible for 90% of jobs out there.
Genuinely interested in how you still find work without doing coding tests. Not trying to be nit picking.
That's a really good question. And I don't see it as nit picking at all. I completely didn't even mention what I do in my personal job search in this blog. 😅
tldr; I got a lot of rejections early in my career. Got lucky to interview for a company without a code test. I also have created other technical assets that have helped me in the interview process. I ask interviewers early if I can do an alternative and I am stubbornly persistent when on the job hunt. 😅 As I've gotten more senior, interviewing teams have seemed to become more flexible because of my overall experience.
Full Story Below 😅
So one thing that I do very early in the interview process is let the recruiter or whomever I originally interact with know my background. I ask to them that if they do coding tests and if they have an alternative.
I pretty much get one of three responses:
1) We have no alternatives. Thank you for your time.
2) Let me talk to the Hiring Manager and see if they would be willing to approach it differently.
3) No Problem. We don't do coding tests. We do some other technical competency approach (Take home project, Assess your Github, Ask you technical questions directly related to job, etc).
I think one thing that works in my favor is that I have a lot of examples of code that works in the real-world environment. I have published multiple applications to different publishing platforms, I have a Github profile readily accessible, and I have performed very well in all roles I've had in the past and have "evidence"( such as job reviews, awards and other things from other technical people on previous teams that help).
I'd note that early in my career, I got lucky to get an interview with a large Tech firm (IBM) that did not require coding tests online or in-person. That interview came after MANY MANY rejections because I NEVER did well on coding tests no matter how hard I tried. 😅
I would say that you are probably correct (esp in the past) that I was ineligible for 90% of job opportunities. The truth is that I'm the type of persistent that would never give up until I found the 10% (which was IBM). I would say now that I'm a bit more senior, I find that I have a lot more "negotiating power" in the interviewing process. I have seen teams "bend" their "rules" to allow me to enter the interview process. I've alway appreciated that. It has meant a lot. I have been rejected for jobs and have turned some down but I always appreciated the opportunity.
Sorry for the long response but I hope that illuminates my personal approach to the interviewing process.
Ooh that's actually a great tip! I never thought of re-imagining the hyphen as "to" instead of "minus"!
And it has the same ordering with
localeComparetoo:a.localeCompare(z)is ascending, andz.localeCompare(a)is descending.Wow, that's genuinely amazing. And I mean it. Thank you, Luke.
Another point is that in these days we are kinda working under preassure and we should always choose the fastest tool to implement because what the client wants is to get to market asap. Sometimes you don't even have time for writing tests.
So yea I think it's good to know about different algorithms and how they work but most likely you will need to know when to use them and know the basics pretty well because that's what you will use most of the time.
@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 also am not a big fan of coding tests.
What I'd rather see is "we'll hire you as a contractor for 3 months, and if it works out we'll offer you a full time position". (Hmmm, I've seen internships turn out that way....)
But that "try-to-buy" probably would not work, since it is a gamble for the potential new hire who takes on all the risk, and of no risk to the company.
yea, the "try-to-buy" method is an interesting thought but like you said it's kinda risky.
Definitely risky for the potential hire and I do think it's risky for the company as well. They'll have to devout resources to train you, onboard you, etc and then you might be a bad fit.
Maybe it would have been better to just wait it out and find a "better" candidate. It's a difficult conundrum.
Some companies do the interview process really well while others just phone it in with coding tests (imo)
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.
NVM, I saw your other comment with the specific sorting question in it, and I get it. It's a question about "are you familiar with or can you come up with this 1 weird trick" rather than "can you implement a sorting algorithm". Yeah, I wouldn't really expect anyone I work with to come up with that solution, and while it's theoretically slower, I just tested them both, and the builtin sort was over twice as fast, and way more obvious.
I'm really confused, what kind of coding do you do? In every job I've had, I've needed to implement algorithms. Maybe not sorting algorithms, but sorting algorithms are much easier than many of the algorithms I've had to come up with. And sorting algorithms are widely studied, so rather than asking you to implement a complex esoteric algorithm, they can ask you to implement a well known algorithm that you're probably already familiar with. Sure it's not exactly equivalent to what you'll do on the job, but... IDK, if you can't implement sort, then what happens when you need to implement double entry bookkeeping?
Completely agree with this. I've been programming for 20+ years and really hate when being asked one obscure memory issue that happened to some one years ago.
Here's my message to interviewers. I understand you want some level of competency but as an interviewer, when you're tasked with coming up with a technical test, it doesn't mean you find the trickiest problem you have encountered and put that in the test. It just shows that you were out to impress your boss. The bottom line is gauge the person for who they are if that's too hard for you then get some inter personal skills training before starting to test other people. Stop coming up with more complicated hoops to jump through because as the author states you're going to miss out on a lot of good people.
I was sent a coding test on a Friday, and I said I would do it over the weekend (instead of resting and being with my family) because I was too busy at work to do it at any other time. I did the test and sent it next Monday. 5 days later, I had no answer from the company. I asked and the recruiter told me that "the guys were super busy" and that they'd review it ASAP. So I told him it wasn't necessary. Lack of respect for my own time is a red flag.
It's bad enough that I have to prove myself every time I change jobs after 20 freaking years. But that they dismiss my extra effort, me giving up my rest and playing with my kids, that something I can't forgive.
The main attribute hiring managers should look out for is character. Any test or assessment should only exist to validate the developer has the basic knowledge required for the job.
Character trumps skill ever time, because it's much easier to teach the latter than the former. And no-one wants an arsehole on their team, no matter how skilled they are.
I wish we could assess character in a few hours... That would be helpful for politicians as well...
In the meantime, coding tests are better than nothing.
Ask a developer what they think makes a good developer and you'll learn a great deal about their character very quickly.
In my first on-site interview I was asked to swap two numbers in any language of my choice, I smiled and used array destructuring in javascript to do it, the interviewer then said "nope, without using specific language features".
Couldn't agree more! I'm a self-taught frontend developer with 15 years of experience. I must know something to survive so many years, but I've been there with all kind of crazy tests where I failed with honors 😂
I want to share the top#1:
TEST: Can you code a "minesweeper" in vanilla JS, please?
On-site interview, with two interviewers in front of me watching me code on a 52" screen 🤦♂️ (spoiler: I failed)
thanks for your post :)
Dude, recently I've been through these kinds of interviews. I agree with you 💯. Recruiting process has to be reviewed and improved. They test people as if they would launch a rocket into space but in reality all we're gonna do is consuming some endpoints from an API and show it on the screen. There's no rocket science involved lol. Great article pal. Keep it up 👍
If you can't sort numbers without sort, then you don't have the requisite skills.
Agreed.
One more thing to add, if at least one of hiring tecnical person even slightly negatively biased againts you they'll find many small "mistakes" to fail you even if you when you are on point and delivered the task successfully.
A senior technical person can have understanding of candidate with verbal questions and reading through candidates comments.
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.
Couldn't agree more!
I'm an interviewer at a big company. I also interviewed a lot.
An interview works 2-ways:
You would be surprised how many candidates can't code at all once removed from their familiar, rail-roaded codebase from their current company. I also encountered "sweet talkers" able to show off on any tech yet unable to code anything after 6 month in the company. (This was an eye-opener for me)
We are lucky that programming is a "hard skill" that can be demonstrated! To candidates, train for the coding test! It's not hard, there are free websites. Train for the whiteboard interview! Ask a friend to play the interviewer!
If one can't demonstrate some coding skills, the risk is too big for both sides.
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
by the way, have anybody thought about: the Leetcode questions are just a way to have a reason to reject somebody if they don't like the person. Think the person is too old. Or the person is not good looking. Or the person doesn't look like a person who'd play video games with them to kill kill and kill. Or the person who doesn't look like would enjoy smoking weed with them. They need to have a reason. That's it.
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.
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.
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.
I agree with every single point made in the post. Coding tests are bad for all these reasons and more.
There is however one form of it that I would both happily be subjected to and maybe even administer, because I think it largely bypasses all the problems and actually provides useful information to the interviewer. I am open to being convinced otherwise though, as I only really did it once and with a person I knew already.
My setup would be like this: the two of us, interviewer and interviewee sit down (either physically or virtually) with a computer. The interviewer asks the interviewee to think of any simple problem they would like to code, or maybe just part of a bigger problem, it doesn't matter what they pick. Or here's a list if they can't think of anything suddenly, just choose one of these.
The interviewer explains that the point of this exercise ISN'T to see code, or to see the interviewee code, or algorithms, what the interviewer wants is to hear the interviewee explain what they're doing. Not to catch them out that "haha, this is the wrong solution" or "what's the name of this design pattern?", but literally to hear how they explain their thought process.
There is no hard pass or fail here, unless there is no coherent mental image behind the words, but in my experience that is rare.
I reckon (and I must stress how little data I've got to back this up) that this would take most of the unnecessary stress and awkwardness out of the situation (obviously not all because we're still technically in an interview setting, which is high stress to begin with), while giving insight into how well a developer can perform overall, but especially in a team.
The company you currently work in , how do they interview candidates without coding interview ? Home assignment or questions from github project or something else ? (I'm undergrad , no idea about job field)
My company asks of new potential employees to write a small game. They can do it at home at their own pace. We just ask when they think they estimate when they are finished. The reason we ask is that we would like to see the technical abilities of the potential employee. We want to see how the person models, if tests will be provided. We look for a proper build file and if they provide a README that will explain someone how to get started in that repository. But no we will not ask for a bubble sort; that's ridiculous.
I think you make a lot of very good points. If also add that things like intensive studying and take-home tests can be very exclusionary to great candidates who have other non-negotiable responsibilities outside of work (i.e. caring for young children or older parents). I once spent 40 hours on a take home test outside of the 40 hours I worked that week. That is utterly impossible now that I have a baby.
Really good read! I completely agree with everything that you have written. Even I have been through a lot of interviews in my time which all rejected me as I did not perform well on the coding test. Especially when I am a self-taught coder going through a massive career transition. Thank you for this article.
I agree with the points you've raised and have found some tests can be a way for the person(s) writing them to flex, rather than be useful for either side.
Most jobs I know have a probation period. Personally I think the interview process should be to understand the requirements of the job & for both parties to get a feel for each other. If things aren't working out for either side, they can be addressed in the probation period. The probation period is the test.
I think coding tests are a good way to check if a candidate has relevant exposure to tech he is being interviewed for. It also tests if candidate has good grasp on the language of work. The coding test should be relevant like a js programmer shouldnt be asked to attempt java etc.
I don't mind coding test. In the 90's they ask us coding test, and if we are smart to give a correct solution in 20 minutes, even if the solution is not optimal, they hire us. If they feel we memorized the optimal answer, they don't hire us.
But nowadays, a person who can think and can give a correct, nice solution in 20 minutes, they don't hire. They hire the person who has done the Leetcode and know the answer to the "optimal solution". So people read questions after questions, trying to crack it and crack it. And the companies want to be cracked. They don't care.
I really like how my current company does their code test: We set out a basic test, but we make it very clear to the applicant we are not looking for the 'correct' answer. We honestly just want to see how they think through something, but more importantly, are they able to translate what they are thinking into actual code. We don't care if what they build gives the correct answer or not, just that they were able to build something and ask questions when they were stuck. Communication is way more important skill than if they can figure out an algorithm on the fly.
Hey everyone, we're a small team of 3 engineers at Bansho.com and I need to quickly hire a Fullstack Developer and a Team Lead (maybe future CTO) and we don't do coding interviews 😅.
We started the company less than a year ago and reached US$1MM ARR, now we are working hard this year to sell it so the equity payoff might be in the short term!
We're an education marketplace that connects private tutors and students in K-12 and have a simple Ruby on Rails and React stack with almost everything built in-house so it's a great learning opportunity as well.
ROLE: Fullstack Engineer (fully remote)
SALARY: $70k-$100k USD + equity
Required:
Startup experience
Ruby on Rails knowledge
React knowledge + experience
Bonus:
Team lead, product or project management experience at startups
Knows how to glue together different services and ship fast
ROLE: Team Lead Engineer (fully remote)
SALARY: $90k-$120k USD + equity
Required:
Startup 5+ years of experience
Ruby on Rails and React 3+ years of experience
Bonus:
Has built stuff and can show it
Knows how to bridge Product and Engineering
Can manage a Product Roadmap, a Kanban board and enable a team to ship faster
I'm flexible with experience and looking into starting interviews this week!
PROCESS:
For whatever reason, I see a lot of the 87 comments are quite hung up on the Sorting issue and I feel the miss the focus. As I conduct interviews I strongly prefer coding questions such as "tell me if a certain value is valid according to some random rules" than logic puzzles such as "2 kids race running back and forth; one at constant speed while the other run x2 faster there but x2 slower back. Who would win?".
You'll be amazed how many candidate simply don't know how to code because they spent their decade of career writing configuration files for example or tweaking whatever. Show me you know how to translate the requirement to a comprehensible code, because this is what you're about to get paid for.
I have published a coding test here on dev.to. The purpose of the test is as a aid in the interview. Complete failure to perform the task is a fail, but most candidates will achieve the minimum. The test is really about determining whether they have understanding of antipatterns and the ability to address them. It is a starting place for a conversation. Some candidates will deliver anything which compiles. Ideally we want developers who take pride in the quality of their code.
All this said, my test was really an exercise to see if I could build something that went beyond a memory test or the university also tests. While simplified it is typical of the kinds of real world decisions real developers face.
I agree that most tests are treated as pass/fail, and are modelled on pointless memorization. They are not used in subsequent interviews as discussion points. Generally I always do a subsequent interview.
While I understand that many tests are poor, not using them makes it difficult to identify confident bovine excrement. Also, some developers are better expressing in code than interviews.
It is important not to make it high pressure or stressful, and simple enough to be completed in a short period. My son was given a test that took more than 12 has. That is well beyond a joke.
I vehemently disagree. A coding test isn’t about getting the right answer. You could arrive at the wrong conclusion and still “pass” a coding test. The reason they exist is to that someone can present a controlled problem and actually see the logic and thought process you applied to get to whatever conclusion. That’s it.
I am with you. Interviews should be you showcasing what you have in experience.
It shouldn't be treated as an exam. For me exam knowledge is lost in a month if no practical application.
I'm not against coding test. I'm not for test questions or scenarios that are no where related to the job at hand.
I agree with the assertion the author makes but that does not eliminate the need for coding tests. Coding tests work, otherwise so many companies would do them. This is similar to the user interface of an application, the which may seem difficult on occasion, but after many, many user tests the UI represents that. They could probably add a few more options but what's the chance they will? So it becomes an issue of personal style, adaptation, and doing things the same way everyone else does. As a society we are moving to more automation and away from individual characteristics of people. To me, a company requiring employment coding tests means they will not allow too much freedom of thought and would be overly authoritarian with standards that don't make much difference, though admittedly some standards are needed. That authoritarianism leads to cliquish groups and competition as people vie for attention of authority figures. I prefer small vertical-market environments where I sell myself to people that need things, giving them new ideas and functionality.
tldr - most companies just copy-paste the popular technical interviews instead of focusing on what the candidate actually needs to know for the given position.
Unfortunately it has become the norm for many large corporations to require a series of ridiculous algorithm technical interviews. I agree on many points here... it's extremely unlikely I'll ever need to reverse a binary tree in the average developer's day to day.
Therefore, the technical interview I conduct allows for creating a tiny basic working project from scratch with a specific third party requirement, which is 99% of what we deal with every day. This lets us see if the candidate has clean coding and general knowledge of the language being used, and can research dependencies in a sane manner. Almost every candidate learns something during the interview (this can work both ways - as an interviewer I have learned things from candidates), and we end up with a good expectation of what level they can be placed if hired.
The idea of ditching the technical interview entirely would cause a huge waste of time in onboarding for both parties when the supposedly-senior 10+ years of exp candidate is unable to write a simple class from scratch. Too many technical interviews end up this way (in my experience anyway) because they have become stagnant, self-sure, or are too dependent on tooling or frameworks. If you have a good grasp of a language, a framework shouldn't matter all that much.
We tell a candidate ahead of time what they need to have prepared, so as long as they actually have their environment prepared, a good grasp on the programming language itself, and good coding & research practices, I would not say they need to study at all.
The problem with a good coding test: It takes too long both for the candidate to complete and for an evaluator to judge properly.
The problem with not having a good coding test, you get "developers" who do a good job of making blah-blah-blah but can't create a maintainable solution, assuming they can make any solution at all.
I consider it a red-flag when a company does not give me a coding challenge. It tells me they probably don't care much about quality. I should expect to spend a lot of time working with (or attempting to work with) poorly developed solutions, trying to convince the management that there is too much tech debt and the solution is too fragile to do what they want in any reasonable timeline. I can also expect they may not allow reasonable amounts of time to create maintainable solutions instead of just hacks which get the job done.
Well said.
I think many of the issues in the recruiting/interviewing world really comes from the lack of competency from the interviewer's side. Especially in the tech world. Most people focus so much on become good/better at the actual work that they don't spend time learning about people and how to spot a good fit for a company.
Was planning to write my own article on this. Recently secured a contract. The interview went really well but afterwards, the agency said there was a technical test from a third-party. Now, I researched the test and there was an online repo to check out and try. Being relatively conscientious, it made sense to download their sample to understand their thought process. It involved getting the unit tests to pass. Except they were using integers rather than doubles which made no sense at all. Took me hours to understand what on earth they were trying to achieve with the test. I had to install the exact version of Visual Studio on my PC.
The next morning, the actual test. Different, and involved using SQLLite (Why? Was this being used in the role?). I use LiteDB inside my project in quite a neat way - how many coders would feel happy being given that as a test? SQL Lite which had it's own versions of ADODB connectivity, and worse the online code writer was next to useless and my visual studio version seemed incompatible. So the first 10 minutes were spent faffing around. Eventually, after seat of your pants stuff and Google, I managed to do quite a bit on the test.
The next part was a code commenting part - except the browser app didn't work. So I wrote some notes in Word and sent them to the agency.
Finally, quick-fire questions which were more of a syntax check, which was basically either you remembered it or used Google.
The minute you abdicate responsibility to a third-party, I feel whilst many may feel it gives extra assurance, I suspect it is taking you further away from understanding candidate compatibility. It isn't necessarily a failing of the hiring company, more that it can seem like the right way to do something. People feels there is a benchmark to pass and that tests are a good way to evaluate it.
All in all, I had probably committed 5-6 hours extra.
When I hire people, my approach is to have a set of questions which I suspect the candidate may fail, but care more about how they try to solve the problem. I have occasionally had to create a technical test (because a senior manager), only to understand the way they try to solve it. Indeed, hopefully they are smarter than me.
I would never go for a role again with this kind of technical test. Only because I liked the guys interviewing did I persevere.
Hmm.. for me i use TDD test questions for my freelancers. But the reason i do this is to see how would they react to me. Unless I know i had a brilliant jerk or leetcoder through my email communication with them.
Since from the start when I reach out to them till they had submitted their solution and communicating to me. I would be vetting them in their communication skills especially in writing, showing of inititative, scrappiness to get it done regardless if they know the answer or ask for help.
Since I'm hiring a remote worker, i expect them to be independent and good at communicating in writing. So that they will ask questions and there won't be much issues when i delegate work to them.
Yes, we use a coding test to weed out low-skill candidates. And there are a lot of them. And we spend a lot of time going through resumes too, most of which are junk. What you call a lack of care or concern, I call prudence. I am hiring to do a job, and that job requires certain skills, not the least of which is the ability to perform under pressure. If they can't complete a simple test in a few minutes, then I think that regardless of what other qualities they may have, they still can't do the job at hand.
I don't think I'm perfect at picking candidates, and I understand well the human element involved in hiring. But I need someone to do the job - I can't worry about who "deserves" it most. Perhaps the problem is not the test, but that we no longer teach children how to perform well on tests.
This is the very first article I ever wrote on Dev.to:
dev.to/bytebodger/your-coding-test...
I've been on both sides of the table on this as the interviewer and the interviewee. I concede that tests can feel like an incredible waste of time if you don't actually get the job. Especially if the interview goes multiple rounds. That being said, coding tests are the most efficient way to determine if a candidate knows at least some of what they say they do on their resume and how they approach difficult problems. Maybe the test isn't a specific thing you'll use in your job but problem solving skills are. Id even go as far as to say resilience in the face of uncertainty is a daily occurrence in my experience. Even researching a topic could simply be testing how well the candidate can learn about a topic they know little about. Or even how well they prepare and follow instructions. All things required to work in a professional environment.
In the tests I've given, they all were less about the answer they came to and more about how they got to it. I.E. Do they pay attention to detail by fixing spelling mistakes? Do they consider scalability or do they just go for the easiest fastest answer? What bad habits do I see in the way they code that I'll have to work with them to fix? There's just no alternative for a test that can give me those answers so immediately.
My advice would be to approach them differently. Rather than making the tests about getting the right answer, use it as an opportunity to show what it would be like to work with you. Be collaborative, ask thoughtful questions, showcase how well you receive feedback. I always appreciated that I may learn something I didn't know from a code test. Or see how other's do things differently and why. I don't think code tests are going anywhere unless companies find that the candidates that performed well on them turned out to be bad hires. I appreciate challenging what has become standard practice in most companies though. Even if they worked for a time, they may not forever and I do agree that some just do it because they read an article recommending it vs. having a purpose behind it.
You make good points but you have to think of it as a base level of proving you have some of the base concepts in place to show you do the work. A resume is nice, but the point of the interview is to pull out those experiences that make you a fit, and show you did the work you did. A coding test can show approach, knowledge, and the ability to do the job - they don't need to be esoteric concepts but even something basic with an interviewer can help show you know what you know.
In some ways it can be like a chef, you want to work in the kitchen you need to make a meal to show you know how to make food to a certain standard. Anyone can put a plate together, but making a meal that looks and tastes appetizing is another level altogether.
Great article!
I completely agree that there should be no reason to 'study' for an interview.
If the test assesses you for the job (which it should), then you will already have a good understanding on what to do because of all your experience as a dev.
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.
While I enjoy doing whiteboard interviews, I’m not convinced they offer much value, apart from showing how you solve problems. I’m a bigger fan of system design interviews, than coding tests.
That said, i think that what we do while still a “coding test” is relatively useful. We ask you to solve a problem that is relative straight forward, but we ask you to submit production ready code. Unit tests, documentation and instructions on how to run it. We aren’t that bothered about whether you can solve the problem, it’s trivial, but we are interested in how you solve it.
It’s a straightforward problem and it shouldn’t take more than a couple of hours to solve, in your own time, so no pressure and no one looking over your shoulder. You can even google the answer the the problem if you want, because that’s what you’d do on the job if you didn’t know it.
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.
I definitely agree. I'm also a full stack developer with 18yrs experience, I always struggle with online exams or live coding challenge, as I couldn't focus when im put on spot. Also, i have poor memory and don't do memorization. I personally prefer & appreciate companies who give take home coding challenge that would require me to build something. And then afterwards have a call to demo/discuss what you have built just to make sure you did build it, just like a peer-review. This type of test, for me is much comfortable as I know how to explain what i built. But nowadays, most companies use online exams.
Great meme.
I feel like some of the coding tests I had to take were discriminatory towards people like myself. I'm much older than most candidates and might not type as fast as my peers, the problem given was unfamiliar to me but common in most college classes, and solving the problem had no application to the job. Also, most of these companies never asked me about team work, or how well I worked with others. Most of my previous work was working as a team and my last job I was the scrum master in an agile environment, and went around helping other programmers to succeed!
I like your view. I think coding test is a tool and it depends how people use it.
I know few companies use it to see how candidates try to solve the problem and such coding test should be custom prepared and geared specifically for such positions.
I agree that using just random tough coding tests is completely wasting everyone's time.
I think it is true that coding tests in interviews suck, but not all of them, in my current job I was not told that I had to solve exercises and I certainly did them terrible even I could not finish many of them, but I gave ideas how to solve them based on the skills needed for the job and at the end of the interview the interviewers gave me the opportunity to present the solutions the next day and a couple of days later ta da new job, personally I think that every part of an interview is an opportunity to show who you are and what are your real and valuable skills. Just my opinion.
I administer coding exams for all candidates. But I never give academic coding exams. I only give practical exams like this where they have 2 days to finish
EXAM #1 - Consuming Web Services
Using C#, create an ASP.Net or console project that will do the ff:
This alone would require them to create a whole project. I would like to see how they structure code. How they create models. How they do exception handling etc.
Nothing academic. Purely practical. I would never accept a candidate who would not take an exam.
I agree with this. I feel like I'm a decent programmer who can do the job but I tend to freak out during coding tests or take longer than I have.
@lukaShiru, i just started following you. cant agree more
Thank you for sharing this post. It helped a lots. I thought I am the only one who is scared of coding test during interviews.
I am currently attending interviews and after answering all technical question, I could not finish any coding test(however simple it may be) during process and it has cost me lots of good opportunities.
Like you rightly said coding test does not make one incompetent do to their daily job with high standard.
I just failed one this afternoon.
I told the interviewer that math is not my cup of tea.
Never used it on the job in 40 years and never will.
I am not talking about counting stuff but using some math theory
known only to a few to solve odd problems that rarely occur
if not at all in the context of an IT job.
If I was working on software for vending machines, yes that test
means something.
But for 97% of the things software is used for, it's non sense to use that as a measure of skills.
Sadly it was not announced in advance that this was the whole point of the interview.
So f..k them for the rat race.
Next time I will end the interview myself. 😬
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.
This is all over the place. Someone should make Bloggers take writing tests.
Tale as old as time...
The most famous story in the JS world is John Resig. He dreamt of working at Yahoo (The google back then) but got rejected. But went off to create JQuery and Khan Academy.
If our job requires a candidate who can climb a tree, then fish need not apply.
perfect article
Great post, I too stopped my application as soon as I heard a test was required. If they cannot judge your skill from you CV and your previous positions and projects then it is a waste of time.
I thought so but I've changed my mind when I encounter this team. Coding test is a must to me.
Great post Bradston!
I did coding interviews on the spot and I also did takehome assignments. The latter was a far better experience hence why I also started giving takehome assignments to the people I interviewed
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.
My time is worth money. They want to pay me for taking coding tests fine, but otherwise I'll take my resume' to a more serious candidate company.