I think that citing this example every time "hiring at Google/Big tech" is discussed on HN is useless.
We know that there are a lot of false negative and and lot of chance in the hiring process (so many things can fail in a process involving so many steps and people).
There are also legitimate rejections, like hm, bold statements ("90% of your engineers use my software"), fingerpointing or not being able to seek for assistance when you don't know something.
I discussed interviews with many people, and I'm convinced that solving the problem with the theoretically-optimal solution is not the only way to get a positive review. Being open about things I didn't know helped me: for instance "Hm, I'm not sure about how to do this exact thing, I'll use the function do_this_thing() and implement it later if I still have time, if that's OK for you" buys you time and allows to keep the discussion focused on the main problem.
I think both you and your parent are in violent agreement.
It's not as if many people who were in FAANG haven't admitted there are serious issues with the interview process. Even advocates of the process are open about it.
No one has found an interview process that lacks serious issues. Hiring people solely on the basis of major contributions to software has its own serious issues.
In both cases he bypassed the recruiter and leetcode stages which are common steps before the on-site interview at most companies.
https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
I also submitted patches to various projects, including some quite impactful ones that the associated companies used and that e.g. increased performance significantly. Also have written a library that one of the companies (in the extended FANG circle) needed but didn't achieve it to write on their own for a lot more time.
I have never been asked about any of those things in a typical interview loop. I think this is due to a mixture of interviewers not knowing the technologies themselves (there are actually a very low amount of developers who know their foundational technologies in detail) and interview loops mostly standardized on CS basics (extended FizzBuzz).
If the main goal is to land a good job I wouldn't recommend people to try to get recognition with open source projects. Doing Leetcode exercises, having a good network and doing some job-hopping from time to time might help a lot more.
However I still think contributing to OSS projects can be awesome, and can provide a very satisfying feel to oneself.
I think I might have said this before on another HN thread, but of course as an interviewer, I sometimes double-check the CVs and candidates to look for 'hidden qualities' such as open-source contributions. If one recruiter overlooks a candidate, I really ask them why and if the candidate DOES have significant and relevant patches, I actually bypass their decision and I bring them in onsite.
I find these technical programming tests useless for finding qualified candidates unless you are preparing for a programming olympiad or some other competitive programming competition. But open-source contributions allows me to find the patches you made on code reviewing tickets and see it in the open.
It would be better if more companies used open-source contributions as acceptable evidence of relevant experience these days.