I agree that intelligence and work samples are the most critical things to look at. The trick with work samples is that most people focus too narrowly.
Yes, coding is a critical part, so don't skip it. But so is team communication (no matter how great of a programmer you are, if you won't respond to my emails, I won't think you are a great employee). So are code reviews (if you call people morons for not agreeing with your style, no matter how great of a programmer you are, I won't think you are a great employee). So is mentoring (if you can't explain concepts to people who aren't as smart/experienced/whatever as you, no matter how great of a programmer you are, I won't think you are a great employee).
I could go on. I think it is some of these softer skills that many interview questions have tried (and mostly failed) to suss out. Back to the OP, I can see it being a reasonable effort at experiencing some of the non-coding work requirements.
Much better than "how many ping-pong balls would it take to fill this room" and "design a nuclear reactor for me", both of which have been asked of me in web developer interviews.
The ping pong ball question has been used a lot to see how/if engineers will attempt to give a reasonable estimate with proper caveats. No attempt is auto-fail, as is going into too much detail, and the rest is judged by the reasoning, approach, and if decent upper and lower bounds are given.
I imagine the reactor is similar but also checks if you can say where you are not competent and should defer or delegate.
These look like Fermi problems, they are supposed to check your ability to work with assumptions, and insufficient data. The answer is not important, the thought process is.
Yes, coding is a critical part, so don't skip it. But so is team communication (no matter how great of a programmer you are, if you won't respond to my emails, I won't think you are a great employee). So are code reviews (if you call people morons for not agreeing with your style, no matter how great of a programmer you are, I won't think you are a great employee). So is mentoring (if you can't explain concepts to people who aren't as smart/experienced/whatever as you, no matter how great of a programmer you are, I won't think you are a great employee).
I could go on. I think it is some of these softer skills that many interview questions have tried (and mostly failed) to suss out. Back to the OP, I can see it being a reasonable effort at experiencing some of the non-coding work requirements.
Much better than "how many ping-pong balls would it take to fill this room" and "design a nuclear reactor for me", both of which have been asked of me in web developer interviews.