5 ms·

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

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.

asuffield 11y ago
(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.
- drx 11y ago
  What's the process like these days?
  - mayanksinghal 11y ago
    Faster (at least it's attempting to be) without losing any quality metrics.
eru 11y ago
> 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'.
- existencebox 11y ago
  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.
  - eru 11y ago
    > 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/2761212/Okasaki-Red-Black.pdf 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.
gefh 11y ago
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.

asuffield 11y ago

(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.

drx 11y ago
What's the process like these days?
- mayanksinghal 11y ago
  Faster (at least it's attempting to be) without losing any quality metrics.

eru 11y ago

> 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'.

existencebox 11y ago
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.
- eru 11y ago
  > 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/2761212/Okasaki-Red-Black.pdf 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.

gefh 11y ago

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.