[guitarbill]

I'm not 100% acquainted with the questions Google asks, but in general "knowledge about algorithms, data structures" favours memorisation strongly. In fact, sometimes it is the only option. I think it would be quite a high bar to expect someone to come up with a complex algorithm from scratch in a 60 minute interview for which researchers have needed decades. (Edit: not to mention way harder and more unreliable that just learning it off by heart).

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.

[maverick_iceman]

Who has the time to look at you and other millions of candidates' Github repos? Recruiters wouldn't understand them anyway and engineers have more important work to do.

[euyyn]

I mean, I can't even try to convince you that our method is good if you aren't acquainted with it but already found flaws in it :)

[guitarbill]

If you provide comprehensive information on the Google interviewing process, I would be very happy to respond with more certainty. I am only one person who may or may not have gone through the Google process at some stage. But I have (also?) interviewed at other companies, so I was generalising - which I pointed out.

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?

[euyyn]

If your complaints about the process were meant in a general way, about interviewing in general, I agree with them. I don't think they apply to how we do interviews. I wouldn't be happy about Google's process otherwise, as I want both the company to succeed and to work with great people.

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.