If a candidate isn't willing to put in the work to prepare, it's not much of a cognitive leap for me to envision them telling me that implementing this or that feature is dumb, impractical and not needed. Many developers have this "start with no" defeatist attitude as their default position on most problems of moderate complexity, and it's a real problem. Given a chance to select for candidates that instead figure out a way to make it happen I'd rather take the winners.
"This person didn't study for the interview, so what did they expect to happen?" Oh, I don't know, maybe to be asked questions directly related to the position, amongst other things.
No, I don't find it strange that I want them to prepare for something they're not going to use normally, but agree it might be confusing.
For the actual positions I'm hiring for, nobody in the world outside our teams understands the systems. The candidates are going to need to work hard to learn what's going on when they start their new job. Some of it is going to be hard to do and not always a complete pleasure. Essentially I see it as a personality test that selects for the kind of people that figure out how to overcome technical adversity.
Willingness to do the work to be prepared and eagerness to dive into technical arcana despite it being not very easy-- these things are very relevant to the positions I hire for at Microsoft.
