There is a huge pool of exceptional junior engineers

I used to ask harder problems, like you, but found two failure modes: either smart people who panic and can't think straight in an interview, or people who can do high level thinking but then can't swap two variables in actual code.

That said, thinking back on my recent hires, I'm not sure this method has yielded any improvements.

I've been involved in hiring panels across several companies with very different interview strategies. Before going into this I leaned heavily toward your style: Easy questions that act as a simple filter for people who can't program.

Looking back, I have to admit the simple question approach wasn't as good as I thought it would be. The companies who gave more difficult questions and pushed candidates toward harder and harder interview problems with the expectation that they would hit a wall at some point really did sort candidates better. I know there's a widespread belief that difficult interview questions are prone to too many false negatives due to anxiety in interviews and people who freeze up. However, when we tried interview do-overs or alternate take-home problems as a fallback for these candidates we didn't really see any improvement. I can think of a few candidates who we talked ourselves into giving a pass because we assumed interview anxiety was obscuring some real skill, but we got it wrong in both cases.

I still don't know the correct answer, but these days I'm leaning more toward the interview formats where the questions get hard enough that the candidate is really challenged as opposed to the simple ones like FizzBuzz where it's just a quick filter. Note that I've worked in domains where algorithmic problem solving is something we actually do, so finding interview problems that match problems we've actually solved in production is possible, not just rote LeetCode stuff.

(I also prefer easy-to-solve challenges. And usually bring up more complex topics during problem solving to assess candidates)

Then as it gets harder the interviewee is familiar with it, and I find that often people with less CS experience are still able to work through it even though they don't know the terminology. And we have a grading based on how much hinting we needed to give, which is very helpful guidance to me as an interviewer.

The problem I usually pose is a slimmed down version of one I actually tackled, so it doesn't feel like an arbitrary test that has no real application. Which again, very helpful for when I need to write a rejection email, as I can say where the candidate didn't meet expectations, which often seems appreciated. We're encouraged to reject during the interview if it's obviously not going well, which I've done but I do find very hard.

I stumbled across a thread in r/cscareerquestions or maybe r/cscareers a while ago where several people argued that fizzbuzz was too hard because: "no-one is using the modulus operator in day to day work, so it's not something one should be expected to remember."

I found it very funny and draining at the same time.

It didn’t change anything.

I usually tell them upfront that I’m not looking for the correct answer and that I just want to see how they break the problem down. I also try to reiterate that it’s okay to fail (at least at my employer) and that’s the point of having a team.

Usually, that calms them down enough to get the interview going. If they don’t calm down, I’ll try to simplify the problem or give them small ideas.

We’ve also resorted to having a follow up interview with the candidate if we get the sense that they were overly nervous. I have a couple teammates that are very good at getting people to relax and we’ve had a good amount of success with letting them lead the follow up (instead of myself since I know I can come across fairly cold).

I'd still expect a programmer to know it but that should be tempered by the fact there will be parts of the technology stack you are intimately familiar with that another person might barely use and vice versa.