Don't put box tickers in charge of a critical function unless you want every thing they touch to be turned into an exercise in box ticking.
IMO, that's just a symptom. The real problem is that the hiring managers/engineers find the job of "recruitment" beneath them.
All of us know the recruiter might not really understand the difference between "java", "scripting" and "javascript". But then, why should that role exist? That role exists because the engineers/managers/leads/architects (generally, the tech folks) just don't want to do the grunt work (search and source candidates, co-ordinate and schedule interviews etc). The actual folks in need of teammates/additional people want a piece of the action alright, nobody wants to miss being an interviewer where one gets to go on a power trip asking the poor candidate to balance B+ trees or some such thing, while letting out tch-tch noises like a lizard watching the poor candidate struggle on the whiteboard.
All that needs to be around is a tool/system that can make the job of searching/sourcing/co-ordination easier for the actual hiring managers/leads who are looking to add people to their teams and have got the necessary budgetary stuff covered already.
If you have time to do that, and do it well, and still hit your numbers, congrats.
What you think of the hire shouldn't matter because you are looking to perserve your place on the team and that taints your judgement. You shouldn't hire your own boss for similiar reasons. You should never hire your peer.
The feeling of autonomy is quite important for a lot of modern knowledge workers. There's more than one lever, but if you force enough of them, it becomes a crap place to work.
Two way street.
If you make it one way, it is all on you, and when that team says that, you get all the credit. Good or bad, and the team knows it. Will definitely throw you under a bus, given cause.
If you make it a balanced discussion, everyone taking shared ownership, then it is on everyone.
The difference shows up in two places:
One, bad call. The team can come together, own it, and letting the bad call go is not so rough. The follow on discussion is rational and productive.
The other one is getting that different point of view. Having that discussion sets great expectations. Being challenged, getting better, all that is welcome. A team that does this successfully tends to congeal and do extremely well.
Play it how you want to play it, but I definitely prefer to have it all on the table, open, team discussion, frank, high value.
Mix in a reluctance to blame and shame, favor choices outcomes and data and you get a team that can weather the good and bad, everyone helping everyone too.
The lead is responsible for cultivating that culture, empowering people, resolving conflicts, etc. Also owns team business meetings, data, all that.
Just saying.
If the team lead owns it they should take the blame and give credit to the team. If the team kind of owns it then everyone is off the hook or on. It also invites the owner/vp to talk directly with the programmers which undermines the lead.
No one mentions this but the lead in development is one of the rockier jobs. You rarely have power to hire/fire without a manager, all development problems come your way, credit goes to developers. You have very little power compared to other industries.
Given that in higher dimensional finite spaces all the points are close to the edges of the space you would expect the most unbalanced teams to be the most successful ones because they can explore the parts of the solution space where you have the highest chance of finding a profitable solution.
Unix was not build by well rounded people. Xanadu was.
Non-well rounded people would do less well if the decision was up to peers.
I imagine that everyone is expected to dedicate a significant chunk of their time to the recruiting process. I don’t see how else they could pull it off. I suspect the arrangement is something like “everyone must dedicate one day every (other?) week to recruitment efforts.”
Moreover, they had a fixed set of well-thought-out questions and exercises. For programmers, you write code in an actual IDE with one of their programmers sitting beside you. You can bounce ideas off them, you can consult the interwebs (as you might in real life), etc. The questions and programming challenges were relevant, and reasonable.
It was an extremely well oiled machine, and it showed.
But doesn't that support what the article says? It suggests he applies a filter with very few false positives, which generally can only be done at the expense of a lot of false negatives.
The practice is that a culture had been subscribed to across the board and there's no shortage or urgency because if there was, these positions would loosen or employers would be more aggressive and even offer training instead of leaving needed positions unfilled.
Maybe they actually aren't doing either. Perhaps they are simply building a log of candidates for a position that does not exist currently but may exist or another future hypothetical position related or unrelated. In other words doing the legwork way in advance and figuring if they dangle a large enough offer (at that time) someone will leave what they are doing and join the company.
(1) An HR employee is hired to cover certain areas (recruiting in this case) of expertise that the individual manager may not have or may be biased towards.
(2) Manager(s) may look to outsource a segment of their work.
In most cases, it is a combination of the two that leads to HR being the gatekeeper. I would argue that if there was no HR, society would simply blame the next person in charge of the hiring segment.
HR professionals (and the c-suite) are the cause of bad HR policies.
Bad HR policies perpetuate bad HR policies after that.
HR is just an easy scapegoat. I'm sure that often HR is primarily responsible, but often HR just works with what they're given.