Comment by nostrademons
11 years ago
Sorta ironic, but remember that the point of an interview is to determine how well you'd do in the environment that's hiring you, not how good a developer you are. Because Google tends to reinvent the wheel for basically everything, algorithmic knowledge really does matter. Package management only matters within a few very specific subteams. If you're interviewing for a general SWE position, you could be Mark Zuckerburg and still not qualify for it.
FWIW, I find Facebook turning down Jan Koum in 2009 and then spending $19B to acquire his company even more ironic.
That may well be, but if you're considering hiring a guy who's an expert at writing package management tools, don't you put him on one of the specific subteams that needs that skillset? Surely it's something Google deals with?
The problem is that Homebrew is very different from the sort of package management tasks that Google deals with. The design goals for Homebrew include: make it easy for users, make it not require root, make it work on Macs, handle dependencies robustly. If he were at Google it would be Linux-only, he'd be using Linux containerization extensively, he'd be deploying packages to thousands of machines instead of one, it'd be a virtual guarantee that some of the machines would fail during the installation process, there would be little or no user intervention and if there was a user it'd be a trained SRE, and the installation procedure would probably need to be an order of magnitude more efficient than Homebrew is.
I don't want to take away from his accomplishments as a programmer - I use Homebrew too. But my point is that it's very easy to see "Good programmer, of course he should get hired" from the outside, while the reality is that it may not be all that similar to the tasks he'd be doing.
If you are hiring the Homebrew dev, and your devs currently use Homebrew, why wouldn't you hire him to work on Homebrew for you?
6 replies →
Sure would've been nice to have a package management expert working on Go.
I might be wrong, but I'm pretty sure Mark Zuckerberg can reverse a binary tree.
Probably cheaper than starting 1000 $19M projects and dumping the ones that aren't wildly successful.
Very good point. It's like, why do you want to work for Google if you aren't into algorithms?
I failed my third google interview. My problem wasn't that I couldn't solve the problems. I just wasn't fast enough because I didn't spend 3 weeks beforehand training speed in programming brainteasers.
other then search and maps, how many of their products use algos heavily though?
many projects i have worked on over the years required very little knowledge of algos.
All of infrastructure. You end up using LSM trees, Paxos, variations on binary search trees, checksums, Reed-Solomon, bloom filters, external sorts, and all sorts of other academic algorithms when you deal with distributed systems.
Docs/Drive does a lot with operational transforms and CRDTs, ever since Wave was merged into it (c. 2011). Remember that all Google Docs are collaborative.
All logs analysis & experimentation relies heavily on statistics, as well as online algorithms for reservoir sampling, quantiles, and a number of other statistical quantities.
Machine-learning is pervasive, throughout Shopping & News (it's all over these), GMail (spam, priority inbox, categories), Search, Ads, self-driving cars, Brain, and many other areas of the company.
Chrome and Android both do a lot of traditional OS & systems programming.
The main product area that didn't use algos heavily was Google+, although even this had some interesting stuff in stream ranking and search.
3 replies →
Hey man, all that CRUD needed to make all those shovelware google apps requires a ton of algorithmic knowledge. /s