Hacker News Reader

Comment by gefh | Hacker News Reader

You may well be asked how a distributed sort would work in principle, and be asked to code a small part of it. Any reasonable answer that shows you can think on your feet would be evidence in favor of hiring. It sounds like you didn't get hired, and I'm sorry about that. Interviewers' preferences are of course diverse, but for at least the last 5 years, probably 10, Google interviews favor practical solutions to problems we face every day. Some of those are theoretical CS, many are not.

View on HN

As a datapoint, a while back I was asked (for a G interview within the last 10 years) to code an RB tree from start to finish. I'll admit I was a little miffed at how distanced this seemed from anything I would potentially do; I was not interviewing for a high theory/deep algorithms group. That being said, in my other experience with a G interview, the entire process was much more mundane and as expected. For the record, I have both been hired and not hired by G and not necessarily paired with the above interviews as you'd expect.

I mention this instance largely because my friends at the big G tell me such a question is generally frowned upon, and not part of standard practice, (So I don't feel bad speaking openly about it) but more importantly it gives me a way to see how people can get a skewed perspective on a company given a... unique interview question when the overall guidance within the corp wouldn't align to asking that.

(Tedious disclaimer: not speaking for anybody else, my opinion only, etc. I'm an SRE at Google.)

"Within the last 10 years" covers several generations of refinement to the interview process. I'd suggest forgetting about anything more than a couple of years old.

The major thing to keep in mind is that these days, your recruiter will ask you up front what subject areas you are strongest in, and you should expect to get interviews about those things.

What's the process like these days?

Faster (at least it's attempting to be) without losing any quality metrics.

> I was not interviewing for a high theory/deep algorithms [...]

Implementing a well known data structure is pretty far removed from `deep algorithms' and `high theory'.

Honest question; are you able to recall or extrapolate all of the rotations on the fly in a 45 minute time slice? For what metric it is, I've been succeeding well enough at comparable positions for nearly a decade since then, and in that time I've met a single engineer who could have pulled that off without prep, I likely still would have trouble with not leaving some bits out.

I don't ask this to be dismissive, I just find this expectation that an RB tree is "well known" to be incongruous with the skill sets I've seen in a large number of thriving industry engineers in the roles that would have been relevant to me. (Thus my "high theory/deep algo" exemption statement, specialists who really have to get that deep I might expect to be familiar with something like this offhand) Broad knowledge about the algo, sure. To replicate the finer points of the implementation ad-hoc? I'm skeptical; and even if you can, the correct answer in most positions sans my exemptions would be "use a library", and as such I tend to prefer interviews that ask more relevant questions.

Keep in mind, this whole point was initially stated to contrast the RB tree question to many more "typical" interviews, and suggest that these outliers are just that, outliers; They certainly have been in my experience.

> Honest question; are you able to recall or extrapolate all of the rotations on the fly in a 45 minute time slice?

Yes, easily. The invariants are pretty simple. For extra fun, I'd try to enforce them via the type system. Though honestly, if you'd try to do red black trees in a language like Java or C++ you'd probably get a headache.

(Just follow Okasaki's simple approach there. See https://wiki.rice.edu/confluence/download/attachments/276121...

Functional languages make the typical Google / Facebook style interview much easier.)

> (Thus my "high theory/deep algo" exemption statement, specialists who really have to get that deep I might expect to be familiar with something like this offhand)

I guess my perspective is tainted there. I know some things about algorithms and datastructures, but some people I admire as `specialists' know so much more.

Thanks for the datapoint. I concur with your friends, I wouldn't ask that question. IMHO even if you get a perfect answer, all you can be sure of is that the candidate has a good memory and happened to read the right books last night. I'd be more interested in a much simpler problem but with some modifications that prove there's original thought going on.

There is a (surprising?) latitude given to interviewers to ask their own questions however, and the best advice I could give to interviewers and interviewees is that the question should really just be a seed to a good technical discussion.

Lol normal Google arrogance. Yea they only seem to ask theoretical questions basically out of that famous book

Maybe, maybe not. Most people's surface area of problems don't even approach Google's problems. The kind of things most companies aspire to solve, Google automated a decade ago. So, this esoteric CS theory may be more practical inside Google than your external vantage point can consider.

The problems being automated years ago means the vast majority of Google engineers don't ever get close to having to work on those solutions. One of things that disappointed me after joining G was that many of the problems I found fun to solve at previous employers were a) solved already and b) solved by people much smarter and senior than me.

It's a great place to work for all sorts of reasons. But working on cutting edge stuff, well, that requires that you be good at fighting on both meritocratic and political fronts. The majority of the people that came in the same acquisition as me left before their golden handcuff payouts finished, because of this.

"with more rules we have solved most of the problems in the world. That just leaves the weird events" -Steve Coast

The remaining problems are indeed weird, and succumb only after application of every available tool: "asking around", CS theory, low-level debugging, visualization, heavy logs analysis, pouring over source code, strolling aimlessly, mining commit history, politicking, brainstorming...

I think it more likely you have a bad grasp on what is and isn't theoretical for Google.

Why did i get -4 vote here....

Reply on news.ycombinator.com