I do understand that me looking at your github is faster and easier for you than me getting you to problem-solve live, and also potentially more representative of the kind of work you'd actually be doing once employed. From my POV, if I'm hiring someone to solve problems, I'd like to see how they solve a problem; and certainly your github is a record of you solving some problems.

Nevertheless.

If it's a toy problem, I'd rather it was my pick of toy problem than your pick of toy problem. If it's a hard problem or a significant open source contribution, it will take much more time to fairly evaluate than a toy problem, and so there needs to be some form of screening of candidates first because there is only so much time and there are more candidates than that.

In order to evaluate your open source contribution on github, I need to invest considerable time understanding the codebase you are working on and the problems your changes are solving before I can even begin to properly think about your changesets, then prepare myself as I would for a live code review in order to give you a fair hearing; otherwise it's just Elon Musk's "send me your best line of code" all over again. I could enter the interview without the preparation and just let you talk me through things from cold, but then what I am really evaluating is your communication skills, not your problem-solving skills; which may be appropriate for some positions, but does not help me much if what I need is someone to problem-solve.

When there are more candidates than available positions, it then takes even more investment after the interviews to compare candidates to each other, and the results are relatively subjective.

Such a process may be appropriate for some senior or specialised positions with relatively few applicants, but in general does not scale well during We Just Got New Budget So Let's Recruit All The People month.

The live interview with simple questions and toy problems, for all its faults, has the (admittedly dubious) advantage that it is self-contained and that multiple candidates get similar or identical questions, making it easier not only to agree on a shortlist but also to spot potential problems with the interview process itself. One might then go look at github repositories as well as scheduling longer meet-and-greets for the most interesting people to make the final selection.

This isn't great, but choosing whose codebases to properly look at based just on the candidates' CVs is even worse, and that (or even worse methods! - they exist!) is what we are left with if we exclude the phone screen / live interview as a tool from our hiring pipeline.

(Note that writers, when submitting their novels to publishers, also don't throw the entire novel at the publisher from cold (or if they do, they aren't likely to get very far) - they generally have a cover letter with a brief summary, and supply a representative sample for the reviewer to read; different publishers have different rules for these, but generally no more than a chapter. Moreover, many publishers don't accept direct applications, or only accept them during specific, brief, time periods - by requiring the author to get an agent to agree to represent them, they are effectively outsourcing that initial screening step)