Sure, they can do that. Then the average interviewer is going to recommend hiring the person who was the best at spinning a good story rather than the person who has the clearest explanation (which might easily come across as boring or simplistic). The problem here isn't getting through the interview; it is what the interviewer does next in the hiring pipeline.
Somehow this reminds me of my old physics professor, who often had simplistic, almost boring explanations of things, like jiggling atoms making friends with each other, or how a train stays on the track.
... Classic interviewing techniques of "explain how X algo works" or "write code to solve Y" will unfairly bias against interviewees that don't test well under pressure, but would otherwise be a good coworker.
... "Teach me something interesting to you" or "tell me stories about past experiences" will unfairly bias against interviewees that are shy, soft spoken, or are mildly socially awkward, but would otherwise be a good coworker.
Given the above awareness of where bias can emerge, how should the interview be done in order to get a candidate that knows what they're doing, and works well with the rest of the team?
Other comments mention relying more on recruiters and referrals, but that isn't always an option.
I don't see what useful signals are supposed to come out of an interview. If referrals and recruiters aren't an option I'd probably try to skip the interview altogether and go with a long probation period (3-6 months). Or possibly have a short 20 minute free-form interview talking about their last day job and expectations of the new one with a very short list of major red flags ("doesn't want the job", "unable to form sentences") then block candidates who raise them.
- How do they take a business problem and model it into code
- How do they debug their own code
- Is their code easy to read
- Do they name their variables/fields/methods/classes in easy to understand and consistent ways or are the names confusing or inaccurate
- How do they take constructive criticism
- How collaborative are they
- Do they think about the problem first or do they just start hacking away
- When asked to add a feature to existing code, do they start hacking or do they write out a test describing the new functionality first
- When confronted with vague requirements, how well do they ask questions to get the information they need
- How much experience do they have with algorithms, database design, systems design, building things so they scale well
If it were possible to work all that out in the interview then there wouldn't be any bad hires.
As a wishlist I like it, I just don't see how you're going to assess all that in an interview. You'll notice that the technique of the day ("teach me something") doesn't address any of the dot points and that holds for ... pretty much any technique. Interviews are a weak process for assessing anything.
The long probation approach completely ignores the very real costs of onboarding someone new.
It takes time, money and people to bring someone in, and hiring is actually quite a risk for many companies (unless they're huge and/or in a hiring frenzy).
If a candidate doesn't work out, that's a lot of time and money down the drain, and potentially lost work, and disruption to teams and timelines, etc..
Most people don't get this part, and I think that's why they don't understand why interview processes are structured the way they are.
You really want to do the best possible evaluation, on all fronts, at the start. The longer a bad candidate stays in your pipeline or company, the more expensive and disruptive it gets.
I don't know that many programmer/developer jobs where you can just put your headphones on and code without ever talking to another person.
Being able to explain/teach your work is part of "doing the job well" for a developer (IMO).