The "Merge intervals" question, or variations in particular are such a good interview question.
Off by one errors. Test the developers on the off by one errors.
Whatever your skillset it's truly the fairest tool in the book I think.
That sounds even worse in terms of setting realistic expectations for what the job will involve day-to-day. How many times is someone actually going to redesign a system like that?
Respectfully disagree. Teaching and explaining the current system to new and lower-level folks is arguably one of the most important skills for a senior developer. As for the system, they're not redesigning anything, they're teaching something that (as a senior) they should already know, as if we're juniors. Think typical box-arrow system architecture diagram, DB schema, that sort of thing.
Explaining the system is certainly something that happens, but in terms of hours/month I'd say it's something you do less of than leetcode-like coding work. Actually reconsidering your core design in response to some changing fundamentals, which sounded like it's what you're testing in this interview, is something that you do a few times a year at best.
When I'm conducting interviews, I'll do LC easies or mediums depending on the role we're hiring for - basically a couple easies for a new grad or someone with just a couple years of experience. One medium for a mid-level. If you're a senior we're not doing a coding exercise, we're having you teach us a system you've designed in the past, then we're going to change some of the core assumptions/requirements and see how your design changes. This has worked super well for us in the past, especially at the senior level. I would say most of the mid-levels we've hired since I've started doing this did not have a working solution at the end of the interview.