[jacquesm]

Introduce them to the team they will be working with, have them do a code review or take a ticket and find their way through docs and discuss a potential solution.

In general teams are a much better judge of talent and ability than recruiters or your typical interviewer, especially in a normal work setting.

[empthought]

That's really expensive for the team in terms of time investment for possibly no payoff. Someone has to make sure that a candidate that gets to that point has a good chance of being hired. That person is "your typical interviewer."

[jacquesm]

Your typical interviewer, if he or she does not have relevant knowledge is just as likely to throw out the baby with the bathwater as they are to select the right candidates. There is no reason not to have the team do the pre-selection. I know this is all terrible news for recruiters and HR people alike but really there is nobody better qualified to determine who they want to work with on a particular problem than the existing team. The only situation where you would be better off with other people making that decision is when there is no team yet.

One thing I used to totally loathe during my brief stint as a programmer employed at a large organization is that when new people showed up that were already hired it was then up to us on the floor to make the best of a whole series of bad decisions preceding that moment.

So, let's involve the team in the messaging and pre-selection as well as giving them the final say.

Think about it this way: if you believe that the team you employ is the best possible group to do the work, don't you feel they are also the best possible group to determine how to expand the group?

[35bge57dtjku]

> Your typical interviewer, if he or she does not have relevant knowledge is just as likely to throw out the baby with the bathwater as they are to select the right candidates. There is no reason not to have the team do the pre-selection.

What are you talking about? The interviewers are almost always from the team.

> Think about it this way: if you believe that the team you employ is the best possible group to do the work, don't you feel they are also the best possible group to determine how to expand the group?

Yes, and that's why most companies have their devs do interviewing.

[Paul-ish]

What do you do when tons of people apply for a position?

[jacquesm]

Find a better way to reach your target audience. Getting people to self-select is the very best way to reduce the load from interviewing.

[Paul-ish]

How would you do that? Also, saying there will be a coding interview up front does cause people to self select.

[jacquesm]

It would definitely take up some team resources, but it's not more complex than the work they're already doing. So 'how would you do that' is the wrong question. The question should be 'how would they do that?' and the answer I don't know but I'm sure if you ask a team they'll be more than happy to explain, after all it is their (and not my) future that is at stake and given the fact that they are involved they'll do the best possible job to make sure they have to go through it the minimum number of times with the largest chance of success.

This is still far less effort than a wrong hire would cause. Anyway, I can see that my methods are not acceptable (yet), maybe in another decade or so?

Trust is hard. Even companies that trust their tech people with the corporate crown jewels still have a hard to impossible time trusting them with such everyday decisions such as who they want to work with. It's counterproductive to say the least but that's how we've been doing it for the last 40 years, so I don't expect any major changes in the near future.