One of my less-favorite things is how many people always pop up to defend the Google approach and argue that if he couldn't pass such an interview he must by definition not be qualified.
No, but just because he created homebrew doesn't mean he's qualified either. Homebrew is one of the least reliable pieces of software I've ever used. It's popularity puzzles me and I've stopped letting it get near any machine I use. It's baffling and annoying to me that people view it as some default packaging solution for Mac, especially when the platform already has pkgutil/pkgbuild. I really wish something like Rudix [0] had taken off instead of homebrew since it's far superior.
Popularity doesn't mean quality and the entitlement of that tweet would be a red flag to me as an interviewer.
Popularity may not inherently imply quality, but enough popularity over time correlates with a gradual improvement in quality.
Homebrew has improved a ton over just a few short years. The Linux ecosystem did the same, as did many other projects that started out as a popular-but-less-featureful/reliable alternative.
If it's been awhile since you tried it, I'd check it out.
I can count the number of times I've needed to implement any binary tree algorithms on one hand. And they've all been either homework when I was in undergrad, or job interviews.
That said, I'm pretty sure that interview questions like these are not about whether or not someone is qualified to do the job they're actually doing, and 100% about companies trying to come up with a standardized, one size fits all tech interview that can be used for every position. Since the intersection of necessary skills for all kinds of developer jobs is something close to {"understands values vs. references", "knows at least 1 programming language"}, though, the result of any such endeavor is going to involve a lot of noise.
It works for Google because they're such an attractive employer that they're dealing with essentially zero risk that they accidentally filter out all their qualified applicants with stuff like this. It probably even helps company morale by fostering a perception among Google employees that they are an elect few.
yes, the goal is standardization of interviews, not hiring the best candidate, but it's also about signalling the cleverness of the interviewer and the company. if you're actually clever, it will be evident during the interview without having to plan for it with a pre-determined interview puzzle.
but your "zero risk" assessment is a common but unproven justification of such hiring practices. with good management, you can easily bound the cost of a bad hire to a few (tens of) thousands of dollars. it's hard to estimate the benefit of a good hire since that's an alternate reality not taken, but it's probably many, many times higher than the cost of a bad hire:
opportunity cost of losing a good hire >>> realized cost of a bad hire
(the probability of a bad hire is higher than of missing out on a good hire however, so you'd need real numbers to estimate the relative costs)
Binary tree questions probably come up as often as they do, relative to how often binary trees are actually used, because so many interview questions can be solved trivially with hash tables.
Just because you don’t use binary trees doesn’t mean Google or Amazon don’t, though. Maybe not binary trees themselves, but b-trees and similar data structures are widely used in file systems, databases, and other large scale systems that these companies routinely work on.
Also, everyone knows that companies ask questions about data structures and algorithms. If you’re have the ability and inclination to prepare for these interviews, that says something about you as a candidate. If you don’t prepare at all and then go on the internet to whine about it when you don’t get an offer, that also reflects on you.
> and 100% about companies trying to come up with a standardized, one size fits all tech interview that can be used for every position
Pretty much. We had a conversation at work about this recently, where folks were talking about how they were varying up the interview process depending on the applicant.
Some people pushed back saying we needed a one size fit all process to avoid things being unfair/biaised/etc.
When you push that to the extreme, the google process is what you get (and who gets hired is biased as hell anyway).
While it has its flaws, Ill always push hard for personalized interviews whenever possible. Look at someone's resume to see if its someone who would be useful to you, then test them on THAT to make sure they're not bullshitting on their resume.
Nope. It's just hazing. The geek version of fraternity pledge week.
The only standardization is the thud of hitting the floor due to all participants expending the least possible effort. Like a team building trust fall where everyone is too busy checking Messenger to be bothered to extend their arms.
I don't see the a contradiction between these two ideas. That last sentence, about this contributing to insiders' perception of being an elect few, describes the same kind of mentality that allows hazing to persist in organizations that do it.
>works for Google because they're such an attractive employer that they're dealing with essentially zero risk that they accidentally filter out all their qualified applicants with stuff like this
You know the founder of homebrew was filtered out by exactly this, right?
“Capable of writing software that solves a real world problem” isn’t necessarily Google’s bar. It’s entirely possible that the creator of Homebrew doesn’t have the level of skill that Google requires.
- He may be qualified to work at Google, but that's not apparent just because he created Homebrew, right?
- Google can afford to be picky enough to miss out on popular open-source project authors who _can't_ code on the whiteboard in favor of those who _can_ -- can we argue that they should reverse this, or just that in certain cases potentially-qualified people fall through the cracks?
I get that the response to this will be "they make $INFINITY as-is", but yes, I'd be willing to argue that they should reverse that. My basic argument would look something like:
A) Writing algos on a whiteboard is not the be-all end-all of actual programming
B) The skill set of "can identify things that people want and need and actually implement them" is a useful one that the person who created one of the most widely used pieces of OSS out there has demonstrated they have.
C) There's no evidence that I know of that indicates that whiteboard algo writing correlates with the skill set identified in B, and a fair amount of anecdotal evidence that suggests they aren't correlated. (And there are a range of other skills that are useful for an engineer or someone leading teams of engineers that are similarly not correlated with whiteboard algo writing.)
D) Firms benefit from diversity. Gender-diverse and ethnically-diverse companies are more likely to out-perform less diverse companies.[1] I don't have specific evidence for it, but I suspect that a firm that has a hiring process that brings in people with multiple diverse skill sets will eventually perform better than a firm that only brings in employees with tightly focused, highly similar skill sets.
And to respond to the "well, FB/Amazon/Google make $INFINITY as-is, so nyah-nyah", I would say that those companies are in market-dominant positions now that may make their math on hiring a diverse array of skill sets different from a theoretical firm, but I also suspect that maintaining those dominant positions will be more difficult with an engineering corps that is solely selected on a narrow band of proficiencies.
So, I'm not necessarily saying that Google should change their policy (although I do feel comfortable saying that any company that isn't in that rarified air that decides to copy that policy is making a serious mistake), but I think there's a pretty solid case for why they should at least acknowledge that there are people for whom they should make exceptions and possibly completely reverse that policy and overhaul their hiring process to achieve a broader range of skills among their engineers.
For a lot of the people Google needs to hire to write Google-scale code, maybe "can identify things that people want and need and actually implement them"" isn't a particularly useful skillset _to Google_, but the skill set of "ingrained knowledge of data structures useful to writing scalable, low-level code" is.
I do agree that the "make things people want" is a very useful/desirable skillset for a vast array of non-Google-scale companies, and I'd personally prefer to work for a company that values this.
But I'm willing to posit that at a certain software engineering scale, the problems and valued traits are very different, and may align more with "knows data structures" than "can make something people want".
I'm not saying Google should value one to the exclusion of the other. But perhaps if you have Google's talent pool, the base level is "ingrained data structure knowledge" (correlating to engineering skills they need), and they'll also get the "ingrained data structure knowledge AND ability to make something people want" applicants.
I'm not arguing that other companies should do this. Just exploring whether it makes more sense for Google than perhaps we would think.
Sure, that's what I was trying to convey in the paragraph after D. That said, I think that even for a company Google's size, having those different skill sets will be useful as your business ages. Google will probably always need a number of people that have memorized every data structure known to humanity, but they would probably be better set up to avoid stagnation and continue in a position of market dominance into the future if they also have a set of people who can come up with new things and implement them.
But also maybe it's better that those people don't end up at Google et al. and that these gigantic companies stagnate and eventually die because their corporate bureaucracy/scar tissue prevents them from hiring the people who can prevent them from stagnating and dying? I dunno, haven't really fleshed this idea out too much.
> Google will probably always need a number of people that have memorized every data structure known to humanity, but they would probably be better set up to avoid stagnation and continue in a position of market dominance into the future if they also have a set of people who can come up with new things and implement them.
Yep, agreed! But since there's probably some overlap in that candidate skillset Venn diagram, maybe they're getting the people that can do both, and the data-structure skillset's the one that's possible to consistently interview for.
Except that implies that someone who remembers how to invert a binary tree but doesn't have an open track record is a better hire than someone who couldn't remember but created, maintains and improves a popular open source project for YEARS.
Working software should be prioritised over rote memorisation of data structure theory.
It also implies that just because you can invert a binary tree on a whiteboard you’re actually good. That’s debatable but I guess it’s one of N filters.
When I interviewed at Google they asked a lot of (at the time) very specific questions about various languages but only 1 “solve this riddle” type question. It was a pretty good experience.
The best interview I ever did was with an investment bank where I was struggling to whiteboard some problem (after a string of really tough, challenging problems I did well at) and they let me use a terminal to actually code it up (which I managed to do very quickly). I got that offer. ;)
