You must log in or register to comment.
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? 🙂
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.
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.
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 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.
