Hacker News new | ask | show | jobs
by JoshTriplett 2297 days ago
> Some companies only hire specialists. If you’re Google, it makes little sense to hire a generalist, I think.

Having been through a Google interview and offer process, this seems exactly backwards: Google selects heavily for generalists, so that they have people who can adapt to and integrate different technologies. (I'm sure they do hire specialists in various areas, but their interview process optimizes for generalists.)

9 comments

I second. Most data and anecdata says you need to be a solid generalist software engineer to be hired at Google. You may have some specialty (the vast majority don't), but a single area of expertise won't take you there.

Vide the famous tweet (https://twitter.com/mxcl/status/608682016205344768):

"Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off."

To be clear, I think that Google has a reason for that:

- They use standardized hiring procedure (they need to work at a scale).

- A startup/software/machine learning whizz kind won't be useful (or would be dangerous) if they contributed code that does not meet other software enginering criteria.

"They use standardized hiring procedure (they need to work at a scale)."

That's funny. In some HN threads that discussed exposes on awful interviewing practices at Google, time and time again Googlers would point out that Google is a big company and every team does it differently.

So which is it? Do they have a standardized procedure or does each team do things differently?

Update: Ok, maybe it wasn't per team, but the impression I got was that different parts of the company interviewed differently. Whether people you wound up working with wre the ones you interviewed with is a separate issue.

You must have misunderstood something, Google doesn't let teams interview their own candidates. At Google you are always interviewed by random engineers from random teams who you will never meet again. And the people who decides if you get hired or not will not ever meet you.

You are probably thinking of Amazon or Microsoft or some company like that, but I have never seen a Googler say that interviewing varies from team to team at Google.

Of the people who interviewed me on-site at Google, none were in any of the same teams as the roles for which I was being considered.

Only after my packet had passed the hiring committee did I speak with potential hiring managers about team fit.

When I was interviewed at Amazon, all but one of the interviewers was a future colleague. And the one who wasn't led an adjacent team.

Amazon has started doing general hire and then placement for senior engineers in some areas, international hires in consumer goods for instance. I like this better as it gives you a lot more options. In the other model if you didn't have good fit you might end up with another partial loop.

I also like this better than the Facebook model where you don't find out your real team for several months after the hire.

For these broad loops they pull people from across the company to do the interview but will have people from your role if they can. Which isn't hard, the roles for most hiring at sdm, sde, fee, TPM.

Amazon always puts one "unbiased" bar raiser on the loop to ensure hiring isn't made for local only optima like "I need someone for 3-6 month shortfall so I'll lower my standards." These people have veto power on the hire and also play the consistency in level role.

Edit: clarity

That's great.

My experience interviewing for a role at Amazon was a while ago (2012) and in a place where they don't have massive teams of people (Beijing). So I'm sure it's different in present-day Seattle.

No, they hire Competitive Programmers - this is a separate specialty, but Google assumes such programmers should be able jump into real world software engineering. They recognize the flaw but so far can't come up with a different way.
> No, they hire Competitive Programmers

More specifically, programmers who spend a lot of time learning how to solve algorithm puzzles. This heavily favors single people who have lots of time to devote to studying such things and disadvantages time-constrained people such as developers with a family life at home.

Yes, ageism is one of the consequences (or reason) of such interview practice.
Is there any evidence that older engineers are worse at these interviews than younger ones?
It's not that older engineers are worse at them (from an intelligence standpoint), it's that younger engineers have more time to study for them.

Take a standardized test like the LSAT. Young single people can spend 4-5 hours a day taking practice LSAT exams. Older married people with small children barely have 2 spare hours after work let alone 4 (without neglecting their spouse/kids).

Assuming both the older and younger devs in this scenario have identical IQs, who is likely to do better come LSAT test day? It's a war of time attrition.

Having gone through some of their algorithmic questions, about the only thing consistent between competition programming and their questions was that N was large, often larger than resources of single machine. A very practical issue, compared to many competition problems.

The first stage of the question might be very competition-like, though.

Front end, back end, games, data science, embedded etc are all very similar if you ignore the frameworks existing in each domain. So you can become a decent generalist in all of them if you do it bottom-up and become fluent at relevant algorithms first, while if you go top-down and learn each framework then you will never become good at all of them at once since there is just too much complexity in each domains frameworks.

For example, a person who only knows react, angular, vue and node is a specialist and will unlikely be successfully to transfer to a different kind of team. A person who built their own javascript frameworks on the other hand had to build and learn a lot of fundamental concepts which are transferable to any domain, I could use such a person. So personally I strongly favor algorithmic interviews over more specialized ones. I don't care if you learned how to use library X to solve narrow problem Y, no matter how many times you did it.

There are exceptions, but the vast majority of tech positions at Google are for generalists. Hiring managers, interviewers and hiring committees look for strong signal that a candidate is a good generalist and only incidentally that they have any specific skills (more as a proof that they are able to acquire a skill to a high level of mastery than out of need for that specific skill).
Big-tech interviewer here. That is case for us. One of the principles of interviews is 'use whatever language you want', and we test for skills such as 'data structures' or 'clean code'. Sometimes candidates are hired into a common pool and then matched to teams afterwards, so it would be impractical to hire specialists.
I was about to post exactly this. The author is the exact opposite of right here.
Generalists? They hire puzzle experts
How does Google "select heavily for generalists" when the interview is almost entirely comp sci? Perhaps you mean "computer science generalist".

Afaik, the only way for me to get a software offer from Google is to spend dozens or hundreds of hours studying computer science, and nothing else.

If I interview for software at Google, they don't ask about my skills in product design, economics, or strategy. If I interview for a non-software role at Google, they don't ask about my experience writing software.

Show me a Google interview that's half software and half product. That's a role to which I'd like to apply :).

I think TFA argues that Google's org structure is not optimized to benefit from or hire cross-disciplinary generalists.

Do any of these roles involve writing software?
Most of Silicon Valley ignores specialization on the level of particular languages and tools (to the point that I'm mildly suspicious of "resume driven development" claims - they genuinely don't care, as long as you can do the algorithms interview).

But I do generally see at least a backend/frontend/mobile split, with backend sometimes further subdivided into product vs. infrastructure. Does Google not even go that far?

I wonder if folks are silo'd shortly after the generalist interview?