3 ms·

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 hi

by czinck 10y ago

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.

tedmiston 10y ago
I don't think so. A senior engineer role may involve no programming, more focus on architecture and design.
- jwatte 10y ago
  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.
- JamesBarney 10y ago
  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.
- bostik 10y ago
  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.

by czinck 10y ago

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.

tedmiston 10y ago

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

jwatte 10y ago
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.
JamesBarney 10y ago
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.
bostik 10y ago
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.