At least when middle managers do it they're only interested in who gets credit for the work so they leave the average tech guys alone long enough to get the work done.
In that case, the key was that clumps of them had already worked together in earlier jobs, so the incompatibilities had been pruned.
If you got an interview, and did well you got another challenging programming problem to solve on-site. You were given a computer with the programming environment of your choice and as much time as you wanted, as well as someone to ask questions from.
I think it was also important that the company solved hard graph problems in Lisp, with a lot of macro-driven code. If you were a Lisp programmer, you generally wanted to work there.
You can pretty easily hire the top 1% of applicants, and still get only mediocre results. E.g. at one job, when looking for a senior-level eng position, clearly stated in the description, we easily weeded out a couple hundred applicants who had effectively zero experience whatsoever. No prior programming-related jobs, internships, side projects, open source, nothing.
Which is a waste of time for everyone involved. Hence the heavy reliance on connections :(
In reality, the applicant pool is heavily biased towards very bad engineers.
This really seems out of necessity. There are going to be a lot more qualified median engineers rather than superstar coders, so it makes sense to optimize your hiring pipeline to assess these folks.
In my experience, most of the "top 10%" hires are either through interpersonal contacts or a fast-tracked interview process for a specific candidate.