Pretty questionable take IMO:
The truth is, there are typically a bunch of good candidates that apply for a job. There are also not-so-great candidates. As long as a company hires one of the good ones, they don’t really care if they lose all the rest of the good ones. They just need to make sure they don’t hire one of the no-so-great ones.
That’s actually a pretty bad thing. Like you could say the same thing about rejecting applicants who didn’t go to a certain set of schools, or submit a non-PDF resume, or who claims to have experince with a library/language that you don’t like (I had a colleague who said that he’d reject anyone with significant PHP experience because they probably learned “bad habits”) or any number of arbitrary filters.
If “good at leetcode” was a decent proxy for “knows how to build and scale accessible web UIs” or whatever, then okay great… But it’s not, as the author admits in the conclusion:
Coding interviews are far from perfect. They’re a terrible simulation of actual working conditions. They favor individuals who have time to do the prep work (e.g., grind leetcode). They’re subject to myriad biases of the interviewer. But there’s a reason companies still use them: they’re effective in minimizing hiring risk for the company. And to them, that’s the ball game.
So it’s unclear to me what they mean by “effective.” Are they good at evaluating how good a candidate will be at the job? No. Are they good at identifying talent that hiring teams might otherwise overlook? No. They are good at “minimizing hiring risk” by setting up another arbitrary hoop to jump through.
Let’s just call a spade a spade and admit that our hiring processes are so bad at evaluating talent that we settle for making candidates “audition” to prove that they can code at all, and then decide based on whatever entrenched biases we’ve decided constitute “culture fit.” Then the title could be “Coding interviews are the most effective tool we have, and that’s kind of a disaster.”
Thank you for reading my rant. I am available for podcasts and motivational speaking appearances.
I asked candidates to bring me some code they were proud of and teach me how it worked. Weeded out people really quickly and brought quality candidates to the top. On two separate occasions we hired devs with zero experience in the language or framework and they rocked it. Trythat with your coding interview, eh? 🙂
That sounds like a good plan in many situations… But how do you handle candidates who say something like “look, there’s heaps of code that I’m proud of and would love to walk you through, but it’s all work I’ve done for past companies and don’t have access (or the legal right) to show you?”
You might just say “well the ideal candidate has meaningful projects outside of work,” and just eliminate the others… But it seems like you’d lose out on many otherwise great candidates that way.
But how do you handle candidates who say something like “look, there’s heaps of code that I’m proud of and would love to walk you through, but it’s all work I’ve done for past companies and don’t have access (or the legal right) to show you?”
It never once happened. They always knew in advance, so they could code something up if they felt like it.
Interesting, thanks. Do you give them any ideas or guidance as to what they should whip up? Or just leave it totally open-ended for them to figure out?
I always left it open-ended and that seemed to work. Part of the interview was seeing what they’d come up with. I’m pretty sure people always brought things they’d already written.
I’ve coded for 30 years and I’m proud of NONE of it. That is, except one ugly hack where I perverted a print spool as a scheduler, which isn’t even code.
Personally, I’d love this system (I immediately thought of some code snippets I’d bring!), but I’m curious how you’d handle candidates without any open source projects or contributions who still have a substantial employment history but are unable to show any code from that because it’s all proprietary.
It never happened–since they knew in advance, they had time to whip up something cool if there wasn’t anything else. It didn’t have to be massive. I just wanted to see some clean non-trivial code and a clear understanding of how it worked. Fizzbuzz wouldn’t have impressed. :)
That’s really cool!
Do tools written in shell count?
One of my classmates years ago loved bash. They wrote a filesystem for their OS class in Bash. It was a really, really impressive and bad idea.
The claims and conclusions of this article are merely asserted rather than suported with evidence. (This is true of most of the articles I’ve seen claiming the opposite as well.)
I personally refuse live coding sessions during interviews, including whiteboard programming. If they require this during an interview the company’s not for me.
Don’t mind code challenges where I have a timeframe and can submit. It’s not how you code normally so why should it be how you’re hired?
How do you phrase your refusal? I am not looking for work right now, and my current job didn’t give me live coding sessions. I’m against them in principle.
But I can’t figure out how to phrase it in a way that doesn’t sound like you’re dodging. Do you refuse while you’re already in the interview? Or do you make a preemptive disclaimer when they invite you for a “technical interview”?
I’ve never seen a problem with asking people to code in a live session. It’s about the problems they are asked to solve. Leetcode style problems are generally unrealistic and have little to do with the skills that are actually needed.
If the problems were more focused on the day to day type of work, nobody would complain. “solve x problem without the industry standard library that solves that problem already” is just testing the ability to quickly reinvent wheels.
It’s more like asking a carpenter to build a hammer as their practical carpentry interview. It’s probably good they know about hammers, but what you actually want to know is if they can build cabinets.
Design in your head a cabinet that can be designed and built within 30 minutes with no research or preparation, and build it. We will be watching over your shoulder, so please coherently describe your process as you figure out what it is.
You wouldn’t have learned to do this at any previous workshop, so hopefully you’ve specifically practiced making this kind of shitty half-hour cabinet in preparation.
As an interviewer, you do not have the elevated role necessary to determine if your method of interview results in better candidates, especially since you didn’t try any alternatives beyond an automated code submission. This is intellectual dishonesty that serves to shelter the author from thinking critically about the affects their actions actually have.
Coding interviews are a decent way to screen out the false positives. Watching someone solve coding challenges gives you some assurance that they can, well, code.
Hahahahaha. If only. There is very big distinction between ability to priduce code that solves the problem and solving the problem. My personal experiense showed me that passing the coding interview and being a good Software engineer is a two different skills.
