Hacker News new | ask | show | jobs
by Bahamut 4195 days ago
I haven't seen a decent-sized shop where "everybody is pulling their weight". Different developers at are different points in their careers, and have different levels of productivity. As a junior developer, I was very slow when I first started. As a senior developer, I have produced 50% of the work for a project on a team of 8. There are only so many developers that want to work for [insert company] out in the wild.

I do sympathize with the big damage done by poor hires & problems getting rid of them - I have seen similar as well. However, a process like this will select against a lot of quality developers and not necessarily select for the ones you want to work with. It just selects for the developers that that company wants to work with who are willing to jump through such an extra set of hoops. It also tells me as a candidate that the people who are working there don't have the courage to speak out against such a process selecting against candidates not willing or able to go through the process or the leadership is too weak to figure out that this sets up a bias that isn't intended to be selected for, thus being a bad hiring mechanism.

1 comments

Right, I meant "pulling their weight" in a relative sense, with the understanding that a more experienced and talented employee will do more work or do it more quickly. Maybe my desire is simply to increase the proportion of coworkers who make roughly appropriate contributions to the team effort. I once had to explain how splines worked to a graphics programmer with 20 years of industry experience.

A trial process like this would select against lots of quality developers, true, but that isn't the real question. Instead, I want to know whether the developers who wind up being hired represent a more talented subset. I can't prove that it would, but I feel that this system would be more accurate in letting the right people through.

All that said, I like some of the gray area solutions proposed in this HN thread, including after-hours or weekend remote work on a project already in production. Not a perfect solution, given the inability to evaluate things like culture fit, but it combines many upsides of the alternatives.

>> I once had to explain how splines worked to a graphics programmer with 20 years of industry experience.

Is the knowledge of splines a major predictor of a graphics programmer's success? I don't understand why it appears to be a point of denigration here. The details of your story are foreign to me, of course, so maybe I'm missing context. But it's always helpful to remember that time is finite when compared to the seemingly infinite amount of things to learn. No one comes to work and says, "I want to suck today!"