I've remained silent on this topic for far too long. But now I'm about to go off. Buckle up...
In the last few weeks I've had some experiences w...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
I feel your pain and share the same sentiment.
unfortunately it seems that the number of teams I don't want to work with is growing the more I grow old.
(and to be honest, I often would really like to be reviewing the codebase before accepting a job)
alway a pleasure reading your posts!
LOL. Good points! And thank you.
Right
This post is right about the struggle on live code during the hiring process on many companies.
Wrong
On the other hand I honestly think you got the issue completely wrong.
Just removing the unit tests in the hiring process is a patch that:
1- Does not fix the issue.
2- It makes it worse.
Suggestion:
What if we do this instead?
[From the PoV of the company]
Just send me the link of one or two public repos of you, let me review them and then let's discuss it on a "short" call just to ensure you are the one who really coded them and that you understand the basics and the details of what you did there by yourself.
Fallback:
I understand that some people decide to code only at work and it will be mostly (or at all) private repos, no issues with that, completely respectable.
If you happen to lack of any public repo, I can send you something to do (high value, short in time thinking into account the seniority required for the position) and you report back whenever you finish it (with a maximum of... 10 days? -negotiable- just so we don't get stuck in the hiring process for too long).
At the same time you'll get a public repo to improve and show to other companies, so it's not a complete waste of time even if you don't get hired.
Of course in both of those situations I'll expect tests, at least unit tests.
The why
If I cannot ensure your know-how around unit tests, and if you struggle so much with them, myself (as Tech Lead/Team Lead) or any other team member will have to dedicate extra-time on you (teaching, CR, compare your tests with the acceptance criteria to ensure you did OK, the follow-up and so on and so forth, with extra-care).
Depending on the project this is bad, OK-ish or completely OK, but for the sake of a good organisation we should know beforehand, I think this is also comprehensible to everybody.
I'm also tired on coding things I don't want on time spots in which I may better do other stuff just to comply with a technical interview, and I believe that this will solve any issue people have with technical interviews from the root of the issue.
Does that seem reasonable?
First, let me be clear before I address any other issues in your comment: Thank you. You get it. And while I've pretty much grown numb to some of the snarky comments that can occasionally accumulate on my articles from "dev bros", I do understand that it's perfectly acceptable for reasonable people to disagree with some of my points. (Or, in the most extreme examples, to believe that I'm just outright wrong in the entire post.) And you know what? That's fine! I sincerely appreciate this thoughtful response.
Second, I'll freely admit that I occasionally make bombastic statements (hey, it's my personal blog, afterall) but that sometimes there's room for... nuance in the things I'm calling for. Heck, even in this article, I'm stating in the headline that you should NOT be using unit tests in your evaluations. But then, in the middle of my own article, I state this:
So yes, even I know that unit tests shouldn't be absolutely 100% banished from evaluations. But what I'm really getting at is that, IMHO, the way that tests are used in the vast majority of evaluations is... gross. In fact, I think that they're often so gross that many companies would be better served to remove them altogether, rather than to keep deploying them in the way that they're currently doing.
I'm not gonna try to go through your response point-by-point and supply any kinda "rebuttals". But I really wanna highlight THIS:
Yes. Sooooo much... YES!
Part of my frustration is that, at this point in my career, I'm a fairly "established" dev. Does that mean I know it all, or that I've mastered every technology and library at my disposal?? Of course not. But I've been doing this a long time. And I have extensive evidence, in the public realm, of my skills. So it can be insanely exasperating when someone can't be bothered to look at the mountains of evidence that I've put out there - but they just wanna shunt me through their "standard" evaluation and then blindly disqualify me if I struggle to make something pass their built-in tests - even when those tests are poorly written or fail to properly reflect their own specs for the task.
I love your suggestion. Because A) it acknowledges the piles of code that I've already put out there for public consumption, and B) it allows me an opportunity to, as you've pointed out, talk through and explain anything that I did-or-did-not-do in those already-published repos.
I've literally told potential employers before: "Look... I have a mountain of code already out there on GitHub. Why don't we just go through that first? If you fear that I didn't actually write the code, that's OK. I get it. We can do a live screenshare session where I'll walk you through any of the coding decisions that I've made. And I'll even make some minor, incremental changes to the live code, right in front of your eyes, to demonstrate that I understand the code and that I do, in fact, 'own' it."
Unfortunately, few hiring managers wanna be bothered with anything like that.
Finally, I'll add this response to your comment:
I'm not patently against the idea that you want me to show/prove that I can write unit tests and that I know how to do it. IMHO, the best "test" to determine someone's ability to write unit tests is to give them an already finished block of code, and then say to them, "Please write some unit tests to validate this code."
What I'm against is the idea that you're gonna give me some kinda timed test, where I'm building new features or fixing legacy features - and then, once I've done everything according to your communicated instructions, you want me to turn around - within the original "tight" timeframe - and do a whole bunch of "test writing" on top of it.
In my experience, this just fosters a lot of "false negatives".
Yup to all.
Not to talk of the hassle of the technical interviews in the process being one of the main reasons for most people not to apply for open positions till they are (literal translation of a Spanish idiom) more burned than a hippie's motorcycle. 😂😅
YES!!!
This was actually one of the central points of my first article on this site (dev.to/bytebodger/your-coding-test...). Companies believe that they want to attract "top devs". But guess what? Most of those "top devs" are... already employed. And if they already have a decent gig in-hand (even if they're considering new opportunities), they probably won't be bothered to jump through all your hoops. (Meaning that you're left with a lotta applicants who are... less than "top" devs.)
I've rarely been in this position in my life. Thanks to the mass layoffs at top tech companies (in my case, I was at Amazon), I've recently had a lot more time on my hands and I've been doing something that I rarely do: complying with many companies' coding-challenge requests.
But when I'm in my "normal" mode? Well, let's just say that I've told many companies before, "Thanks, but no thanks" when they reach out to me and we have some solid initial conversations - but then they want me to complete a big chunk of "challenges" or "demo apps".
Stranger on the internet, on this one point we are aligned: I don't want you working on my dev team too.
Of course you don't.
I see your points, and both agree and disagree.
Writing good unit tests is actually quite a specific developer skill to have. I've seen plenty of developers who could crank out code that did the job, but couldn't write tests for that same code.
I've also had coding segments for interviews (take home tests) that included writing tests. Now, I was also actually failed on one of the secret requirements, because I was using a slightly older version of a language parser and was missing a specific feature they wanted (still irks me as I'd explicitly mentioned that and what I'd have done differently in a more recent version in a readme).
However, if the candidate is only given the instruction to write tests for their own code, and are given a reasonable timeframe, then I think the request is reasonable.
I don't totally disagree with you, although you highlighted my main concern when you shared your own story of failing one of these evaluations. And that's really my whole point.
It's not that I would tell anyone that tests are not important. It's just that, when someone gives me a task that they SWEAR is "easy' - but it has a buncha built-in tests attached to it, I almost always run into snags trying to satisfy their pre-written tests.
I would propose the following: If tests are very important to your dev methodology (and I'm not claiming they they shouldn't be), then give the candidate a separate task that just asks them to write quality tests against some pre-written code. But if you want me to write up some new to-do app, and you believe this should only be a quick task to prove my coding skills, then do not pile on a buncha pre-written tests designed to compare my new code to what you think should be in the solution. That approach is extremely problematic.
I disagree. Writing tests isn't just about writing tests, it's also about writing code that can be tested. I don't want a candidate that writes code that's very difficult to test, so making that a part of the original task is actually quite important.
My negative story isn't my whole experience with tests in interviews. One live interview I had contained a unit test that I had to write code for. That one was fairly simple, and I had the code for it written before the interviewers had finished leaving the room.
Whenever I've given interviews, I tend not to throw tests at the candidates. While there is a take home portion sometimes, it doesn't include tests (because I only use that as one way to get an understanding of a candidates abilities), and the in-person part is mostly open ended questions (although some of that is about code).
This is such an alien sentiment to me. 1) The only times I have ever heard tests as part of a coding exercise is back when I was running the coding exercise at Casper I used visible tests run during the exercise for real time acceptance. 2) When I am the interviewee and TDD the coding exercise then the interviewer acts like I grew another head and am speaking in Borg-ese.
Take my unicorn and my follow.
Love your rants!
LOL - thanks!
(Disclaimer: employed for 20 years - not recently submitted to unduly tough coding interviews.)
Great post. Herecy. I'd probably want you in my crappy team since you show you able to
I would be more interested in witnessing how a candidate is setting up their 'inner development loop': how can we build in speed and correctness from the start. I know how simple this is in Python, and I have experienced how hard it is to add that to an existing code base. So when I see one struggling to proceed, manually stepping through their code, refusing the help of known-good tools and practices, I have to raise my brow.
That's why I would greatly appreciate a candidate to start with a unit test. Not to blindly evaluate if they made it in time, but to assess their desire and capability to integrate tools to deliver a quality product.
I think unit tests should be used evaluations but the unit tests should be already ready when the tested individual has arrived.
That would test both if the applicant is able to write the implementation and correctly fix edge cases tested by the unit test.
Of course, that will require tester to write high quality unit tests for the task. Preferably something that passes mutation testing, too.
If you want to test the ability to write tests, that should be a task where you're given specification in English and you write the test without writing the implementation. That is, it should be tested fully separately from writing the implementation.
And the way to test the unit test is mutation testing. If the test catches ALL mutants, it's good.
If they required you to write some new features to their codebase as a "code challenge", I'm so sorry to tell you that they would never hire you, they want you to do a free job for them, which they cannot or do not want to do.
I totally get where you're coming from. But in this case I must say that the app I was given was still, clearly, a "demo app". But yeah, I totally get your point.
Also, I should point out that I actually got a job offer from them. And honestly? This surprised me. Because normally I find that the most onerous coding challenges never result in a job offer - no matter how well I complete the challenge.
This is the first article that I'm reading in your series. I must say, well written, some solid arguments. The thing I liked the most is the pragmatic touch you gave to the whole story.
Everything can be reduced to misalignment: between tests and requirements; between documentation and code; between recruiters and development teams. And the story goes on.
What I don't also get is "solve this in 45 minutes". Who decided that 45 mins is the right time? It's like when you see something like "if the API call fails, try to call it 3 times". Who decided 3 is the right number? I always think it's because 3 is the perfect number and it's very close to pi (3.14). Unless someone is hijacking a plane and you are the only React developer that is able to develop a widget to save the passengers, i think that if you complete your stuff in 50 mins it should be ok as well, right?
Last but not least. Had i team, i would gladly work with you.
Yes, this is a great point. The time restrictions are almost always arbitrary. And they almost always start from the assumption that you won't run into any hurdles.
To be fair, I do understand that, if I give someone a coding challenge that most devs finish in an hour, and the current candidate does it correctly, but... he finishes it in 12 hours, then maybe that's a bad sign. In other words, it makes some sense to communicate some type of time limit to the candidates. Because, at a certain point, they've probably blown the assessment, even if the code they're writing is correct. But the 45-minute metric is silly and arbitrary.
To complete the challenge, I had to create 3 new files (containing 45 LoC). I also had to add/update ~100 LoC code strewn across 10 existing code files. And that was all supposed to be done in... 45 minutes.
I do think that part of the inspiration for these arbitrary time limits is to misdirect potential candidates. Companies don't wanna admit that they're foisting a massive coding challenge on you. They swear that this "little" challenge will only take you 45 minutes! And what's unreasonable about that? But that's like me showing my dentist a mouth full of cavities and then insisting that this should only take 45 minutes to fix.
Found the guy who hasn't switched to thinking in TDD yet
And I found the guy who missed the entire point of the article. So I guess we're both on a roll!