[gaylemcd]

Oh, no, I've asked people their suggestions all the time. I typically do in these discussions. In fact, I have elsewhere in this comment section.

I'm sort of confused by your suggestions. You've decided a pretty typical interview process. What do you think is different here?

The biggest difference I can see is that you're saying that the coding is "a relevant problem from our codebase and now just some random skyline problem." And you're specifically calling out that it's okay to miss codebases.

Let's discuss these more. 1. It shouldn't really matter whether it's from your codebase, right? If you have two problems, ProblemA from the codebase (which is worse at identifying relevant skills) and ProblemB (which is a toy problem but better at identifying relevant skills), you should go with ProblemB, right? So really the question is to find a problem that is a good predictor of whatever you care about. If I really want to hire people who are smart, is giving them a challenging problem a good predictor? I think so.

2. The edge case thing. You seem very fixated on this. Why? What interviewers should be thinking about is the signal that the candidate sends. Certainly, in many cases, missing an edge case is just a "I haven't written in certain details yet." In some cases, missing an edge case (particularly after a conversation) might actually signal a much bigger issue. For example, imagine someone didn't write in a check to see if an array is sorted. No big deal, probably. But if there's a repeated issue with this and they can't write this code correctly, then we have an issue. Saying that edge cases don't matter is too broad. They might, and they might not. I encourage interviewers to focus on the signal and not on some binary rule.