"As he says himself, Homebrew is a successful product but not necessarily great computer science. He 'failed' a computer science question. "
Maybe Google is different but I usually need to do computer cine type stuff about one a year.I have used recursion on maybe 4 different occasions in my carreer, but that's the sort of thing that comes up regularly in coding tests. Why not test for things that are actually being used on the job?
Some Google engineers work on the sort of problems, and at the sort of scale, where algorithms and the science that drives them actually makes a difference. I don't think it's unreasonable for Google to ask computer science questions in interviews where that's the case.
Some do, but instead of allocating you to a correct position for your skills based on your performance in the interview, you just get outright rejected, which means you have to try again and again until you find a position which happens to give an interview which you can pass.
Yes, that's true. But how many times when they need to solve those problems are they placed in front of a whiteboard in a fairly high pressure situation? Wouldn't they rather have a chance to collaborate, think, research, and test?
So you've only used json, or html, or (insert recursive data structure here) 4 times in your career? Seriously, recursion is everywhere.
Am I flexing my electrical engineering skills when I turn the TV on with a remote control? Parsing a json tree uses recursion under the hood but unless you are writing a new json parsing library each month you won't get the chance to use those recursion skills too often when dealing with json in day to day code.
The fact that some companies use bad practises for hiring doesn't change how hard it is to judge someone's code from their Github repo. I agree that whiteboard tests are horrible, but switching to a different bad idea wouldn't help.
Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fairly high quality. Certainly higher quality than what I've had to work with in production systems that were making millions of dollars a month.
You're moving the goal posts from "Has code in public" to "Launched, contributed to, or otherwise involved with a successful open project." That's quite different, and arguably a lot of hiring managers do look at that sort of thing very favourably.
I think this is complete BS. There's people much smarter than me that are getting screwed by these terrible practices. Max Howell, Homebrew's author, was famously rejected by Google for not passing some stupid whiteboard exam, when just about everyone at Google actually uses the software he authored.
I'll defer to Max's own explanation for that: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
As he says himself, Homebrew is a successful product but not necessarily great computer science. He 'failed' a computer science question. We can question whether or not Google needed to ask that in the interview, but they clearly thought it was important enough for the role Max was applying for to ask it. So maybe rejecting him for that role was the right decision. We don't really know. We do know that he wasn't applying to Google for the job of "Homebrew Maintainer" so his work on Homebrew, while really impressive, isn't really the whole story in hiring him. Surely you're not suggesting that the author of a successful project should be able to walk in to any developer role regardless of what's needed to do the job?