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.
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 would argue that "how fast can someone implement this algorithm?" is a considerably less useful question to answer than "does this person document their code?" in an interview. If time is the constraint then schedule a longer interview.
There is likely no causal effect between whiteboard/algorithm interviews and poor documentation.
As a method of finding good candidates it feels like it must suck but so few companies are willing to actually measure their hiring effectiveness (and be open about it).
As someone who has given hundreds (maybe thousands) and received dozens of these types of interviews, it's really not.
Generally speaking I'm looking for at least 2-3 of these abilities, depending on which question I'm asking:
1) Can you reason about data structures and algorithms when looking at a problem you haven't seen before? 2) Can you communicate your ideas effectively? 3) Can you integrate new information from a colleague while problem solving? 4) Can you write code that makes sense? Do you understand basic programming concepts? 5) Can you read your own code and reason about it?
There is at least two hidden attributes that I'm not testing for but do affect performance, so I try to account for them:
1) Are you comfortable with me, a relative stranger? 2) Can you do these things while dealing with a high pressure situation?
You will encounter high pressure situations at work but often interviews feel more high pressure (to some people) than most daily conversations about engineering.
That's it. If I can tell a candidate already knows "the right answer" to the problem, I'm usually disappointed because I'm more interested in watching them think.
It tells me they meet the baseline - they can learn well enough to at least be able to do this particular problem super quickly.
But it doesn't tell me any more than that, unlike the candidate who thinks for a pick, considers a few different approaches, writes something up, stops a few times to think about edge cases, satisfies themselves that they're covered, etc.
"Can you figure stuff out on the fly" is the test, not "do you have this memorized?" Fortunately, most people don't have everything memorized, so for now it's still a useful-enough filter.
The problem with alternative, past-experience-based types of questions is that most candidates are terrible at driving them. I would love someone to tell me an hour-long story of debugging something in a library, say - but usually, even with a lot of prompting, it's very hard to get much interesting stuff out of them.
So by putting some algorithmic questions on the panel too, at least they have a chance to show that they can code, even if they can't communicate much meaningful from their past experience.
I would also have serious reservations about taking a job where documentation is considered a negative during a coding interview.