Rather, the engineers on the team are usually building something new, and figuring out how to accomplish it is their responsibility. This way of interviewing mimics that a lot closer.
If someone can't explain to me a project they're working on, then they probably won't be able to do the same while we're working together. And that's just as important of a skill as writing code.
If I'm expecting interviewees (who are nervous!) to learn and understand my codebase/problem, why can't I do the same for theirs?
Or they tune out. Or they dismiss any variation as "wrong" rather than giving it a chance.
What happens in practice is the interviewer compares candidates answers to each other, not to his/her own way of solving it. It doesn't matter what whether the solution is "obvious" to the interviewer. If I hired someone who only did OK on this question and they ended up being a great engineer (and that happened multiple times) that lowers the bar for the test (or tells me it's not a very good test etc)
Whether it works out to be a harder or easier interview over time because of these changes probably depends on the individual interviewer.
I think that's _ideally_ what happens in practice. But as sibling comments mention, is that what happens in practice?
Interview fatigue is very real. Many interviewers are not positively incentivized to put in the substantial amount of effort to conduct a quality interview. It's something that is simply thrown on top of their usual workload. Come promotion time, there's no reward for doing it well. But, there is punishment for noticeably "screwing it up". Often, that means that interviewers put in the bare minimum effort with interviewing (as with other tasks) to not get punished.
I've seen competent leaders avoid this in the past by emphasizing that interviewing is the most highly leveraged thing you can do for your organization and your own career, because you are step-function increasing the effectiveness and capability of your own team if you do it right. But in order for that to happen, there needs to be a real culture of working as a team and not just a disembodied group of ICs: a culture which rewards increasing the effectiveness of the team (instead of merely focusing on ones own tasks) and doesn't just pay lip service to it. It's tricky. But I think the subthread GP's approach is a clever and creative kind of a lateral thinking that shows how to do just that.
do you (or others on team) ever make suggestions on how the code should be written? I think this would be an interesting way to pre-teach the hire on how you like things structured.
on edit - I guess since you ask them questions that implies making suggestions as well, but just wondering how it works.
We sometimes might make suggestions, but rarely for the sake of code quality. We'll once in a while ask for something unique just to get them out of a rut, and see if they can improvise. Otherwise, we're here to learn and listen, not teach :)
I signal a lot of things like testing by asking them. It gives room for the candidate to ask those sorts of questions back about how we do things.
Imagine you’re taking a class on a topic you don’t know. You can tell pretty quickly from how the instructor talks and explains something if they know what they’re talking about. It’s very similar! I’ve certainly interviewed people much more skilled than me in languages I’ve never used, and still got a pretty great sense of their expertise.