Yet they aren't, technical interviews are mostly bullshit CS questions which you barely use in day-to-day programming. And it isn't like CS knowledge is all you need to be a good programmer. Technical interviews are exactly what you say they are, a game.
And every game has rules that can be exploited. This guy's mistake was to try and completely break the game, which would have left Google with no alternative but to invent a different game.
I remember going through this process for internships and wondering how I was supposed to figure out all of these weird puzzles on the spot. Then I made a few friends and we all just traded questions with each other. We'd spend weeks on the problem and pretended we just figured it out.
Also the interviewers are separate from the people making the hiring decision, which I think is a good thing.
My programming hygiene and software design skills? You can see that more reliably from my Github work, but then recruiters and interviewers almost never take the time to look at that. Instead, we're stuck relying on a shitty test, not years and years of hard work and data, because it's easier for you to evaluate. Good job everybody.
You have quite elegantly avoided saying which parts I got right and which parts I got wrong. In fact, you haven't said anything specific, probably because you aren't allowed to?
I think I have a poor memory myself, yet I'd say I'm able to design efficient algorithms and evaluate their costs. Of course I wouldn't expect anybody to devise a publication-worthy algorithm within 45min. But most real world problems can be solved by standard algorithm-construction techniques, without any original research nor genius strike. It's part of the skill set of the trade, not something to learn by rote.
About recruiters and interviewers taking time to look at stuff, when I applied they even asked me for a list of all the college courses I had taken. Interviewers are encouraged to look at your past projects and enquire about their technical details.
I'm not convinced evaluating someone based on the quality of their code in GitHub is fair, though. The candidate might have improved their skills since writing that code. Or it could have been originally written by someone else for all I know. Also, not all candidates have been in a position to have code publicly available. Of course, we're not talking about evaluating Chris Lattner types here; that's not the level I interview anyway.