There is a huge pool of exceptional junior engineers

When I hire juniors, I try to give them problems that I know they likely won't be able to solve in the interview because I want to see how they think about things. The problem has become that a lot of kids coming out of college have done little more than memorize Leetcode problems and outsourced classwork to AI. I've also seen less and less passion for the career as the years go by (ie. less computer nerds).

Unless the company is doing something that requires almost no special domain knowledge, it's almost inevitable that it's going to take a good while for them to on-board. For us, it usually takes about year to get them to the point that they can contribute without some form of handholding. However, that also mostly holds true for seniors coming to us from other industries.

Interesting - I see the appeal of this approach. Equally, I do the opposite - I give easy problems which can be solved quickly. I find people either can do them pretty quickly, or not at all.

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.

> 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.

> simple ones like FizzBuzz where it's just a quick filter

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.