Better opportunities meaning they don't have a coding verification step for senior engineers and so some of your peers don't actually know how to code (permanently or just for awhile before they get outed and fired)? That sounds like a worse opportunity.

I have worked with good technical managers and know of good sales engineers that might not pass a coding verification test like this. I don't think it's right for every role. But that test doesn't directly correlate with the responsibilities of their job. I'm a big fan of contracted simple projects to test someone's skills beyond interview questions.

That's irrelevant. Obviously asking people who aren't expected to program to program in an interview is silly, we're talking about asking people who would be hired for a programming role to program.

I don't think so. A senior engineer role may involve no programming, more focus on architecture and design.

I've never met a great architect that didn't also understand how to code. It's hard for me to imagine being unable to structure code and design solutions at a micro level but had a good intuition for structuring code and designing solutions at the macro level.

Perhaps when you have hundreds of developers, but how many on Hacker News have that size?

Separately, how do you properly verify some library, tool, or vendor if you can't actually push it during evaluation?

How do you mentor more junior engineers if you don't know how to create working code?

And the reason everyone has to spend 30 minutes writing working code is because there is a depressing number of seemingly inflated resumes out there.

The biggest recurring issue in any production-quality programming is the handling of edge cases. (Most frequent source of production issues is config management, but let's keep that out of the scope here.)

I would expect a really good design to consider the expected edge cases up-front, and take them into account. The goal cannot be a dogmatic "eliminate all edge cases" approach - because that can only become a self-defeating exercise in frustration. Instead the edge cases should become easier to detect and, as much as possible, not cascade. Debugging a subtle concurrency related timing issue or race condition is bad enough. Debugging the cascading failure and data loss due to a chain of them is a morale destroyer.

Understanding where these edge cases can crop up is important. Even more so, understanding why they appear, and how to address them, is the mark of a really good senior engineer.

For that reason I expect a senior to be able to still program. Senior engineers may not spend their time glazing at their editor, but I do expect any senior to spend plenty of their time with both code review and mentoring.

I really don't get the attitude that its insulting to ask for someone to show you some programming. You wouldn't hire a musician without seeing them play. I have interviewed plenty of expert non-beginning programmers who couldn't do shit. You can't find that out without asking them to code something. There are tons of people from large companies in my town who cannot do anything. I also worked at some of the large companies and ran into them.

How would you identify these people if you don't ask for programming problems.

Nobody's saying you can't test their ability to program. You can ask questions about programming without having them solve some problem from freshman data structures class. You can ask them how they do their current job, and ask for specifics about code they've written. You can ask them to review pieces of code to see how they would improve or change them. You can ask them for a code sample, and then have them walk you through it to be sure they understand it as well. There are many other less insulting options that still give you the chance to "hear the musician play." As an analogy, you probably wouldn't hire Wynton Marsalis and ask him to play "Happy Birthday" in an interview. You would probably ask for some samples of his music, or links to videos of him playing, etc.

Thanks for responding. So what is insulting about specifically asking for coding? It is not that different than asking someone to look at code at the interview and asking for comments. We do both things at my company. I am not persuaded by the famous musician example, think of someone trying out that you haven't seen play. Someone famous who is active and say not recently suffered an accident is in a different category.

We interviewed some experienced people who did terrible in the in-person interview. So we tried giving experienced people a pre-interview question, that maybe took a couple of hours of focused effort. The idea was the people who couldn't do it great during that instant could sit down in their preferred environment and code something up and take their time.Some people did better with this. I personally hate pre-interview questions, so I argued against it but we still tried it.

I find the code review of bad code too easy, not persuasive. Is it a bad idea for a service to hand out ids that are memory locations of runtime structures, and take them back? Obviously, but a surprising number of people don't see that, including experienced people.