My hiring bar (for coding) has gotten easier the more I interview (as the interviewer). I don't ask any kind of super tricky algo questions, because the signal

My hiring bar (for coding) has gotten easier the more I interview (as the interviewer). I don't ask any kind of super tricky algo questions, because the signal you get from those tends to be closer to "is the candidate familiar with this specific area of algorithms" than anything else. I don't ask any questions that take a really good candidate more than 20-30 minutes to solve, because then I can't scale the question down. You can always scale a question up. I used to ask questions that were fairly close to what you find on leetcode now, but the signal isn't great anymore. It used to be good at identifying candidates who can quickly figure out the right tools to solve a given problem, but now it ends up identifying candidates who spent a lot of time on leetcode. Now I mostly ask questions that involve * transforming some data using a less than stellar API (using a REALLY simple transformation) * holding a bit of state to accomplish the above transformation * throwing a few edge case wrenches at the candidate And the last part is technically baked into the question - a candidate who can fully grok the state could determine all of the edge cases on their own. But even if they don't I'll explain them and see how the candidate handles. 'cus in the real world we have unit tests, and I don't expect TC to really figure out all the edge cases in 30 minutes. A couple of them, sure. And they better be able to handle them once pointed out. Candidate forgets that a java collection can have null because you can't have a List of primitives? That literally doesn't go into my feedback at all (and depending on how recently I've written java, I might have forgotten myself). Candidate writes a function that doesn't compile because there's no return statement? I'll point it out, maybe make a note, but don't really hold it against them because we write code in IDEs. Candidate spends 10 minutes trying to figure out how to force a single variable to do the job of three different variables, despite increasingly desperate hints to just store more local data? Yea that might go poorly in feedback. But yes, I expect a candidate to be able to write 10 lines of code to answer a data transformation in 30-45 minutes. And yes, when either they figure out or I point out a couple of edge cases, I expect that 10 lines to not morph into a congealed mass of horror that cause their original solution to break.