Programming

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? 🙂

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?

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.

@starman real coding under real conditions is king