Earlier quoted context omitted.
I've done that, and during peak hiring periods it does get a bit intense, but I think it's essential it's done by a coder, not an HR person. It's also something to give your day a bit of variety. And the big plus is you get to decide who you want to work with.
Why should you get a say in who works with you? As a team lead I'm trying to find the right balance. If we hire only people the current devs like we endup having too many similiar developers with the same mindset and shortcomings. Trying to have a more diverse, balanced team means you don't get a say.
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.