When I'm conducting interviews, I'll do LC easies or mediums depending on the role we're hiring for - basically a couple easies for a new grad or someone with just a couple years of experience. One medium for a mid-level. If you're a senior we're not doing a coding exercise, we're having you teach us a system you've designed in the past, then we're going to change some of the core assumptions/requirements and see how your design changes. This has worked super well for us in the past, especially at the senior level. I would say most of the mid-levels we've hired since I've started doing this did not have a working solution at the end of the interview.
Off by one errors. Test the developers on the off by one errors.
Whatever your skillset it's truly the fairest tool in the book I think.
From a cultural side, some companies have a competency pillar that is supposed to embody the idea of being a "good person". In mine, we call it "Citizenship", it's tied to performance appraisal and interviewing is one way to develop that competency.
As for code cleanliness, I've passed candidates with messy or even broken code before, if the candidate demonstrated competence in enough other aspects and the code quality issues can be attributed to nervousness or running out of time half way through a refactor or whatever.
Is it 25% will do it properly, 75% don't? Am I too cynical about tech interviews, or too optimistic?
I'd also add, for a couple of companies, Google's approach springs to mind.
I think for places where, you know, they do search algorithms, knowing how to print the spanning tree of a graph is probably an important thing to know.
Personally I think there's a strong correlation between necessity and hiring quality (i.e. if teams really need the help, they typically engage candidates more meaningfully than the Google-style clinically impartial methodology)
Sounds a bit like what my old timer buddy says.
Google's KPI is hiring talent away from competitors who physically live in the San Francisco bay area. And the ads/ML teams that they drench in their 1%ers.
Everyone else is window dressing.
Candidates know this.
The issue is:
Interviewers who do their job, and build a broad based picture of a developer's skills and give fair ratings, are rare.
The perception is 75% interviewers don't even bother. They're tired, they're unmotivated.
Their annual bonus doesn't reflect "conducts fair and balanced job interviews."
They underclock their brain to 10% of its maximum, and at the end of the hour look at how shiny and perfect the piece of code at the end is.
Despite whatever the intentions of the system, I don't think anyone has ever hired a candidate with a messy code who spoke and reasoned well.
My extremely strong perception, having never conducted a big tech company interview, is that a candidate who submitted a shiny piece of clean code at the end of a technical interview will always be first pick. No matter how much they mumbled.
A picture is worth a thousand words.
A shiny perfect coding solution is a perfect image in the mind of the interviewer.
Interviewers are human, fallible people. When they're doing the end of day calibration on interview performance, having a shiny perfect solution changes their perception of a candidate utterly.