[gkoberger]

Well, that's not how I tend to manage day-to-day. I don't give engineers I manage a problem I've already figured out and solved, and then expect them to do it the way I would.

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?

[yowlingcat]

Love this attitude. It's a great attitude and it shows. A very common thing I notice with interviewers is that they do one interview over and over again until it's super polished, but paradoxically, they won't compensate for that and in effect, the bar gets higher and higher for later candidates than earlier ones. Flipping the script not only is a great way to balance things here, but it also says a lot about your own confidence. I might have to lift your approach here!

[gkoberger]

Yup, exactly! The interviewer gets annoyed, since it's "so obvious" how to solve the problem... much like anything becomes obvious if you've done it a few dozen times.

Or they tune out. Or they dismiss any variation as "wrong" rather than giving it a chance.

[OmarShehata]

I also love this attitude but I disagree about this negative effect you're talking about in reusing problems.

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)

[musingsole]

You're missing the part where the interviewer is changing with each interview (and the rest of their life in general). They phrase the problem differently, get anxious as the interviewee approaches different parts of the task. So, the interviewer thinks they're giving the same test and can fairly compare the outcomes. The GP's point is that's just not true

Whether it works out to be a harder or easier interview over time because of these changes probably depends on the individual interviewer.

[johnm]

Sorry but the pointed out problem is both way more commoin and way way more of an issue. Interviewers talk about "I just want to see how someone thinks" but the implicit biases and the overuse of problems leads to unconscious expectation setting and rigidity in the interviewers. In fact, I explicitly test for this by giving valid answers using e.g., techniques that I don't think the interviewer is familiar with precisely to see how open minded the interviewers actually are. Their response is amazingly revealing about the interviewer and the organization behind them.

[yowlingcat]

> What happens in practice is the interviewer compares candidates answers to each other, not to his/her own way of solving it.

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.

[bryanrasmussen]

So practically - do you or some of your team get added to their project so you can track what they're doing?

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.

[gkoberger]

It's all done live! The first time we hear about what they're working on is during the interview, and we never keep any of the code. It's great to see how they can articulate what they're working on, combined with actually working on it.

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 :)

[johnm]

Lots of why did you, why didn't you, what about this, how did you deal with that (and back to why). :-)

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.