I rarely have time to look at code repos unless asked by the manager/recruiter.
You are also likely interviewing with the wrong people. Most large companies are looking for as many of the best devs they can find for generic opportunities. They have many many slots to fill.
If you are looking for something very specific then you need to find a recruiter who does placement as well. Amazon (where I work) has two major hiring processes, direct to team where they are usually looking for a specialty or generalist and take the first qualified candidate, and generalized hiring where you have to pass a standard interview but then you begin interviewing managers and finding a fit. The second may be better for you, but you still have to pass a bog standard interview.
There is of course the third way which is have a friend on the inside do the pre fit and selling.
(Maybe spend a few minutes on the phone just to verify they are really the person who wrote all that code.)
The on site interviews are checking for things like communications, soft skill, design, etc. Things that don't fully come across in a code repo and are hard to verify who did what.
We have tons of people who try and misrepresent themselves. It would be a waste of time for the 6 people on a loop to all read the repo. It would also be bad if we didn't cover the things we cover in the on-sites.
We are also required to keep loops the same for all candidates. So giving an offer to one candidates because they have a GitHub repo and a phone call and the rest don't and therefore have to come in is a no-no. Therefore they all come in.
I've also generally had very good experiences interviewing with them - tough but entirely reasonable questions focused directly on my expertise and the tech the team is using. One that stands out in contrast to OP's complaint was an interviewer that brought in a stack of printouts of screenshots of apps I'd worked on and used them to spark a discussion of the work I'd done on them.
OP's experience, while annoying, and not surprising, is also not universal at Apple.
Another point in case against overreliance on metrics. Optimizing your process for making it easier to measure can easily turn into looking for your keys under a lamp post on a street even though you've lost them in a park.
There's bound to be some confirmation bias there
I confirm that everyone that worked on my team worked out well. Some had more challenges than others, but we got the job done. The team worked well together, and we worked with our overseas compatriots in exemplary fashion.
I was very fortunate. It was a small, high-functioning, C++ team of experienced engineers. All family people, with decades of programming experience.
I'm quite aware that this was a luxury. I'm grateful for that.
I might be reading into this wrong, but it almost sounds like you're saying that you only hired people who had families. Doesn't that sound a little bit discriminatory?
I would have been fired if I had shown any bias at all. I had my differences with some folks there, and I wasn't always thrilled with the way that things were run, but it was the most diverse environment I've ever seen; and I include a lot of Silicon Valley companies in that statement.
The simple fact of the matter was, that the jobs in my team required a fairly advanced knowledge of C++, and the lions' share of applicants were men in their 30s; usually married.
Marital status, gender, race, religious or sexual orientation/gender identification mean absolutely nothing to me; unless the applicant insists that it should. In that case, I generally find that they might not work so well in the team.
Lack of drama was important to me. We had a full plate.
An almost guaranteed way to lose people with families, is to insist that they must ignore their family to work the job.
This means that things like offsites and travel need to take into account things like school schedules, childcare and time off. I would often let people travel on Sunday to Japan, taking the heat for them not being there for a Monday meeting (which usually was just a "set the agenda" meeting anyway). That was my job.
It doesn't mean that someone going through a divorce, or caring for a sick family member, can take a ton of time off when a project is melting down, but it does mean that I would work with them, to ensure that their families get cared for, and that they can leave the job where it belongs, so that they are 100% for their families.
If you do things like this, you end up with a team that will take a bullet for you, and will do things like travel to Japan for two weeks to work on an emergency integration.
It's absolutely shocking how many managers don't get that.
I was a manager for a long time. I loved long résumés and relevant material.
I was hiring expensive people to work on really important stuff, and there was no way that I wanted to rush the vetting.
Also, I never gave a single test, and I think I got it right, every time.