Agree with everything the OP said but I'd add: when hiring for senior engineers, this process is even more absurd because the real skill of senior engineers is

Agree with everything the OP said but I'd add: when hiring for senior engineers, this process is even more absurd because the real skill of senior engineers is not how much horizontal knowledge they've acquired (knowing web frameworks, Linux guts, databases, distributed systems, etc) or vertical knowledge (being a domain expert in X) but their soft skills -- how good are they at convincing other people of something in a meeting? A real example: a product person once asked a team I was on for a feature that'd be difficult and time-consuming to program, probably taking the better part of a year. My teammates said no. Not, "We want to ship this software soon and we don't think that's an acceptable tradeoff," they just said no. Product became furious (not knowing how hard it'd be, since the engineers hadn't explained it) and it hurt those developers. Knowing how to invert a b-tree doesn't help you solve situations like those, which are far more common than 99% of fake problems presented in programming interviews. When I interview a candidate I ask them to tell me about projects they worked on and poke and prod about real-world stuff they actually did, not converting a singly linked list into a circular linked list. Ideally people would be offered the choice of an in-person or take-home to satisfy both those who feel like they shouldn't have to spend their free time on homework and those who don't like being forced to instantly come up with solutions to fake problems. I blame Google for introducing this scourge, hopefully it lifts before the next time I do a job search. My favorite example of this is Google turning down Max Howell for a job: https://twitter.com/mxcl/status/608682016205344768 https://twitter.com/mxcl/status/608682016205344768