And yet, there are devs with that much experience that can't program their way out of a cardboard box. What do you prefer to do with them?
Ten years of bad programming may make you experienced, but it doesn't make you good.
I would question the big-picture awareness of any competent developer who refused this section of an interview. How senior can you really be if you don't recognize why this section of the interview is being given?
(By the way I'm a huge fan of your app and have used it every week for years.)
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.
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.
How would you identify these people if you don't ask for programming problems.
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.
https://news.ycombinator.com/item?id=12826364
My theory is that the state of technology is that people are able to use APIs, libraries, and Stack Overflow code to muddle through most business requirements. And if that's true, perhaps the standards of an engineer have shifted? If those people actually did work at those companies for those many years, surely they did something of business value?
Or maybe the questions being asked in technical interviews are no longer germane to the actual day to day experience of coding?
I'm not saying you should necessarily hire those people, but perhaps all of those articles that go "Why can't our programmers program???" should stop pearl-clutching and actually try to figure out why that is.
Very few programming jobs actually require the more mathy end of CS. If you want an analogy with physical science and engineering, the the algorithms-and-data-stuctures interview is like giving a candidate for a satellite engineering job an interview laden with mid to upper level undergrad physics questions. It's just nonsense.
I disagree. I'm a lowly web dev who is not in Silicon Valley, but I do know the practical benefits of applying the right data structures and algorithms, even though I don't apply this knowledge every single day.
Yes, nested for loops and a hash table will "solve" almost any problem and you can push the release out the door, but how much will that sloppiness cost the employer/customer in hardware and the maintainer and users in time?
Next to nothing in almost every case.
In fact that hash table is probably overkill most of the time. Unless you're dealing with keys that have a costly comparison, a large number of key value pairs, or a large number of lookups (for some context-specific value of "large") the most naive and "inelegant" of solutions you could imagine, an unsorted array of key value pairs, is sufficient most of the time. So in fact what you call a "sloppy" solution is probably, and quite by accident, far more powerful an algorithm than the problem truly calls for.
Understanding complexity analysis is useful when the domain has performance demands or constraints that make it necessary. "Lowly" web dev is almost never one of those domains.
I also avoid using exponential complexity all the time.
There are candidates who are more on the line, and those I'm less confident about rejecting. But we can't just hire the hundreds of applicants per position we see, and I haven't come across a filtering strategy that isn't obviously worse than what we do now (which, to be clear, is the candidate's choice between whiteboarding and coding in an editor).
The Peter principle is one thing to think about. Another is finding those developers roles that suit them better. Maybe that's some other aspect of the software pipeline like QA or testing or internal tools.
Perhaps someone with more experience interviewing and hiring (or not hiring) in this category can provide a better suggestion.
This idea of hiring everyone with experience and hoping you have a job for them doesn't seem terribly sustainable.
> Another is finding those developers roles that suit them better. Maybe that's some other aspect of the software pipeline like QA or testing or internal tools.
I'm used to QA and testing being done by developers. This results in a lot of high-quality automated tests, which are much cheaper than testing the same thing manually every few days.
Internal tools is where I would want my best developers, I would think. Dragging down the productivity of the entire department by having bad internal tooling is pretty worst-case.
As a QA professional, I regret greatly that HN's rules restrain me from giving your post the appropriately pithy response it deserves.
QA is not your dumping ground for failed devs; we do not want them either. If they couldn't hack it as a SDE, they are certainly not going to be able to hack it as a SDET either.
I don't see anything in my comment to suggest that "QA is dumping ground for failed devs", nor was that my intention.
In fact, I wouldn't label anyone a "failed dev". Rather, the idea behind my post was to find a role that better fits that person's skill set and experience. My apologies if this was unclear.