4 ms·
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 (permanen
by tonystubblebine 10y ago
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.
- tedmiston 10y agoI 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.
- czinck 10y agoThat'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 agoI don't think so. A senior engineer role may involve no programming, more focus on architecture and design.
- jwatte 10y agoPerhaps 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 agoI'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 agoThe 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.