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.
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.
I'm always open to hearing about ideas to improve my interviewing, but I find that threads like this are repetitive and not really actionable.
One common misconception I keep seeing is the idea that the interview result revolves around solving the question. IMHO, that's a bad approach (which is unfortunately taken by many interviewers) and in fact it's an incomplete way of assessing candidates, given that most big tech companies have a list of competencies and/or values that are supposed to be evaluated. Big tech companies usually want interviewers to assess on multiple dimensions, ranging from communication quality to specialization fit.
As an interviewer, you're supposed to think of the question as a vehicle to go over these topics, not a pass/fail end goal in and of itself. In my interviews, I pace my hints with the goal of having the candidate complete the question, even if it means dictating answers to unblock them. There's nothing worse that sitting there wasting time feeling smug when the candidate gets stuck on something. Time is short, so it's much better to move on quickly to different topics than linger on something unproductive.
If you're on the interviewer side, my number one advice would be this: question the calibration of the question bank. It's usually a kitchen sink of everything the person writing it could think of, without regards for time. You might already feel that you don't have time to cover everything that the question is supposed to cover, let alone all the non technical criteria that leadership asks for. So instead, cover a few actual technical concepts (syntax, recursion, what have you) to rule out complete incompetence, and then take liberties to go into topics that do cover a wider variety of aspects. For example, discussions about testing, refactoring or debugging can all be productive ways to spend time in a coding interview.
</two-cents>