I was working on the Google Slides team at the time this blog post was originally published back in 2014.
Slides and Doc are extremely closely related projects, sharing lots of code (and even sitting next to eachother, at the time at least).
Our entire team was impressed with the details of the operational transform protocols that the author was able to reverse engineer, and for the most part get correct. IIRC our engineering director ended up calling the guy up for a lunch.
Sending around protobufs encoded as JSON makes reverse engineering much easier than you might imagine. I can just imagine what the internal .proto files must look like - especially the arrangement/ordering of fields which tells you how the software design evolved. Two fields with tags next to eachother? They're probably part of the same feature and they were added by the same person as part of the same commit.
Just curious, how does Protobuf make it easier? Easier than Json? Protobuf doesn’t even include field names or readable descriptors - unless of course you are talking about reading client side JS
In that situation (let's say the boss finds his new protege or whatever) would you still have to go through the (in)famous invert a binary tree technical interviews?
I never understood why people advocate for job offers sans interviews for someone who has interesting projects. IMO any company allowing such practices opens itself up to corruption and nepotism.
I've worked for startups and even mid-sized publicly traded companies where managers with sufficient seniority were allowed to extend offers on a whim and it always resulted in friends of said employees being hired. Inevitably, entire teams and even business orgs would be filled with friends or fraternity brothers and their work performance would vary greatly.
No one likes interviews but it's crazy that I keep seeing HN users considering this an acceptable practice.
there's a difference between hiring people with a proven track record (especially in this industry, e.g. known projects through github) and hiring your nephew just because he's a great guy.
Although I do agree that knowing about people's projects doesn't say enough about the fit (e.g. teamwork). However, white board code reviews won't really help finding that out either, imo. Parent poster didn't want imply that the whole interview process should be circumvented, only the (or some of the) technical part - I agree.
I am against the principle of any individual within a company being able to extend offers at will without any interviews or input from others. A "proven track record" is often too vague and arbitrary a bar and this just lends way to allowing personal bias in hiring decisions. Having interesting experience, projects or an impressive github allows you to get your foot in the door and get to the interview stage. It should not circumvent the technical interviews.
I hire developers and researchers for my company and we are very selective in who we choose to interview (small company in a bleeding edge field). We only consider engineers with relevant, impressive expertise and academics with solid published papers. Still, many of those interviewed don't receive offers and it's not because we ask them to recite some esoteric solution to a riddle. We have called candidates in just because they have promising github projects related to our work, only for these individuals to completely flop when questioned about basic fundamentals. Our interviews were extremely lenient and informal in these cases and we gave multiple chances to some.
Slides and Doc are extremely closely related projects, sharing lots of code (and even sitting next to eachother, at the time at least).
Our entire team was impressed with the details of the operational transform protocols that the author was able to reverse engineer, and for the most part get correct. IIRC our engineering director ended up calling the guy up for a lunch.