> it is not sensitive to non-algorithmic skills and talents that interviewees have.
I work at Google and do interviews (though I don't enjoy them). We do ask questions around domain expertise, software design, etc. It's not all just coding and algorithms.
A good question:
1. Has a low enough floor that a poor candidate can still make some progress and not feel like they are doing poorly and get stressed out.
2. Has a high enough ceiling that a strong candidate doesn't blow through it in five minutes.
3. Has a smooth ramp between those points.
4. Doesn't rely on too much domain-specific knowledge so that a candidate who happens to have a random gap in their background that leaves them totally hosed.
5. Is concrete enough that the interviewer can capture that feedback in a way that the hiring committee can easily understand.
6. Isn't well-known outside of Google as stock interview question so that candidates can game us by just learning the answer.
7. Isn't asked by any of the other interviewers the candidates sees.
8. Can be explained and worked through in about twenty minutes.
In case it isn't obvious, it is really really hard to find good questions that pass that gauntlet. Questions do tend to skew towards smaller-scale algorithm coding questions because I think those tend to survive that gauntlet better than most other questions.
> unusually good at algorithm puzzles
Interviewers are trained to not ask "puzzle" or "trick" questions. Not only are trick questions a shitty experience for the candidate, they are a shitty experience for the interviewer too. My job in an interview is to get as much data as I can about a candidate in order to provide information to the hiring committee. If I ask you a trick question, I get about one bit—in the binary sense—of data from you: did you find the trick or not?
I don't think you have to be unusually good at algorithms. I basically read some Wikipedia articles and spent a few hours in the hotel cramming Algorithms in a Nutshell, and I managed to squeak through.
That time was incredibly well-spent. Since then, I have relied on that algorithm knowledge way more than I expected too, and have since spent more time learning algorithms and data structures because I can clearly see it's made me a better programmer.
> on whiteboards,
That part is hard. We allow candidates to use a laptop too, if they prefer, or both. My experience is that candidates who use the whiteboard, at least for the earlier "design" parts of the question tend to do better than the ones that go straight to typing.
We need to learn how you think, and putting a screen in front of people tends to make them clam up. If all I see is the code you write and you don't explain your thinking behind it, I don't get much data.
> under time pressure.
That part is really hard too. The reality is that interviewers
and candidates have a limited amount of time they can put into this process. Keep in mind that most candidates are currently employed and don't want their job to know they are interviewing. Many of them travel to interview. There are only so many hours.