That's all very fair. The Q I usually ask of all candidates onsite is a design, "give-me-pseudocode/prototypes/class outlines" question which I find infinitely

That's all very fair. The Q I usually ask of all candidates onsite is a design, "give-me-pseudocode/prototypes/class outlines" question which I find infinitely more useful in probing how someone thinks than whiteboard algorithm/coding qs. And to be clear, I wouldn't want to see BS code, but if someone had contributed to an open source project or had some sort of side project that they would have done anyway, that would have been useful. I think our focus on code was based on the fact that everyone needed to write code. We were a small company so there was less of the architecture work. We may well have benefited from doing more of it, but we still needed people to ship lots of code. You do ask a very important question for which I don't really have an answer: why do we care so much about these take-homes or coding interviews for people who have been around for a while? For me I'd say because I want to have a point of comparison with all other candidates, but that's a pretty weak answer. I'll think more about it.