3 ms·
I don't have a one-size-fits-all solution. The Peter principle is one thing to think about. Another is finding those developers roles that suit them better.
by tedmiston 10y ago
I don't have a one-size-fits-all solution.
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.
- thedufer 10y agoI mean, I wasn't _really_ looking for a suggestion. I interview them and tell them we're not interested. Which seems like the right thing to do in this situation. 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.
- RandomOpinion 10y ago> Another is finding those developers roles that suit them better. Maybe that's some other aspect of the software pipeline like QA or testing ... 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.
- tedmiston 10y agoHi, I think perhaps you're reading into the non-exhaustive list of example alternatives to traditional developer roles more than intended. 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.