Google: 90% of our engineers use the software you wrote (Homebrew), but... • Hacker News Board

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#521

Post by reagency » Thu, Jun 11, 2015, 7:30 AM UTC

RogerL wrote: post #212

thethimble wrote: post #74

Earlier quoted context omitted.

Think of the problem from Google's perspective though. At some point, you have tens of thousands of candidates and you need a system to quantify how good they are. Further, it's reasonable to have false negatives (people you don't hire that should have been hired) but really bad to have false positives (people that you hire that you should not have). Together, these boil down into the de facto whiteboarding interview…

No, it doesn't. Say I pass the invert a tree question. Does that prove I am good? That I can design a product, listen to customer requirements, come up with ideas that elude others, read a research paper and turn it into something commercial, solder a circuit board, make a schedule, mentor junior engineers, write documentation? No. All inverting a tree tells them is I studied trees recently, and/or I'm at least super…

None of the things you describe are part of the job for a rank and file bigco engineer. They already have filled all the leadership roles.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#522

Post by Manishearth » Thu, Jun 11, 2015, 7:31 AM UTC

voltagex_ wrote: post #290

com2kid wrote: post #241

Earlier quoted context omitted.

(I'm at Microsoft, FWIW, every engineering team here does hiring their own way) My team does whiteboard questions, but we try to keep them practical. Typically they are the types of problems that we'd expect new engineers to have to look into on their first day. Oftentimes the questions are less "come up and an answer" and more "let's explore this problem domain and see what we can uncover." As an example, the interv…

I'd like to interview at MS next year, I have no formal CS training. Can you give me any hints?

I'm currently interning at MS (India). I am a physics student with programming as a side hobby. (Not yet sure what to do as a career)

While this may be quite different from interviews for MS Redmond/etc full time jobs, this was my experience:

In my interviews, I mentioned off the bat that I wasn't great at algorithmic stuff. Now, don't get me wrong, I can do them, I'm just far, far behind the curve. (Students, esp. CS students, in India spend lots of time on sites like SPOJ and CodeChef solving algorithmic questions; I prefer to do stuff in open source). The interviewers were understanding. I got asked fun stuff like "what do you enjoy about [project I work on]". "Walk me through some large problems you grappled with on [project] and how you solved them". I got to have great back-and-forths on these things. It wasn't easy explaining nuanced and intricate problems, but I was able to give them a rough picture which I think is what they wanted. Shifting the focus from "can he solve this puzzle" to "what work has he done in the past" was great.

There were also algorithmic-y things, but not the usual kind. For example, one interview focused on designing and optimizing a build tool. The idea was that we had a bunch of components, with dependencies on other components, and I had to efficiently generate a viable order of building. There were some other constraints which I forgot. I realized that the problem was similar to a garbage collector (not that I knew how to model that either :P), and did some sort of mark-and-sweep thing. Then, after being asked by the interviewer, I optimized out some for loops and stuff.

I didn't need to know any algorithms beforehand. Sure, if I had known how `make` does dependency management, or had read up on garbage collectors, I would have done it faster. But I didn't need to know anything, and it worked out.

My fellow interns had really rigorous algorithmic interviews. They were okay with that because they were good at them. It's understandable that "solve this puzzle" is the default since not everyone has real world projects they've worked on (students). I don't like the status quo, but I don't think the interviewers will be intent on maintaining it either. If you have stuff you've worked on that you'd prefer to talk about, I think they'd like that.

If you think the interviewer will be open to it, I suggest mentioning it. They will know you're not from CS; you can mention that you don't have much practice with algorithmic stuff.

Major YMMV though. Also I've done very few programming interviews so the advice here could be totally misguided. :)

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#523

Post by lukaslalinsky » Thu, Jun 11, 2015, 7:31 AM UTC

mikek wrote: post #15

At a certain point, your resume should speak for itself. The fact that experienced engineers with impressive resumes are put through these types of interviews is insulting and frustrating to the interviewees. Succeeding at these whiteboard questions requires weeks of preparation. You need to practice, practice, practice. After enough practice, you are pretty likely to pass. So ultimately, it is more of a test of "how…

Another way of looking at it is that they do these kinds of interviews particularly because they do want to hire fresh grads (and ideally, the best 5% of those) over experienced programmers. And if that's the case, then it's not really flawed, it's doing what it's supposed to do.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#524

Post by honest_joe » Thu, Jun 11, 2015, 7:37 AM UTC

Alupis wrote: post #120

devy wrote: post #82

Earlier quoted context omitted.

You think like a Google interviewer.

> You think like a Google interviewer. The OP is the type of person that, six months from now would be demanding special treatment because "he wrote Homebrew". Writing a package manager (been done before, a lot of times) is far different from writing machine learning algorithms (new field, blazing the trail for the industry). One requires an engineer, one requires a scientist. The OP flamed out because Google was loo…

Google hired a lot of grey/black hats and THEY ARE treated differently. All of these people from ADM,w00w00,gobbles,TESO.

And google does not care about real solutions (Grsec/PAX) and did not spend a dime on it. It's an evil hypocritical corporation.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#525

Post by TheMagicHorsey » Thu, Jun 11, 2015, 7:40 AM UTC

I've been invited to interview at Google three times. And they've declined to hire me three times. The last time I interviewed there the quality of the people that interviewed me was much lower than the earlier two times. I was still rejected, but I felt much better about working somewhere else.

I'm sure Google is still a great place to work, but its reminding me more and more of 1999 Microsoft. In fact the similarity is spooky.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#526

Post by Corrado » Thu, Jun 11, 2015, 7:46 AM UTC

thethimble wrote: post #74

kenrikm wrote: post #43

Earlier quoted context omitted.

These types of interviews work really well for the "I got 1600 on my SATs and went to {insert high profile school here} crowd" There are books out there just to prep you for Google interviews I see these as very similar to SAT test prep books. I'm not so sure Google is really interested in hiring the best engineers but rather a specific type of engineer.

Think of the problem from Google's perspective though. At some point, you have tens of thousands of candidates and you need a system to quantify how good they are. Further, it's reasonable to have false negatives (people you don't hire that should have been hired) but really bad to have false positives (people that you hire that you should not have). Together, these boil down into the de facto whiteboarding interview…

Well, my suggestion would be to use Page Rank to sift through the resumes. If you are respected by respected computer programmers then your "score" goes up. They could measure that by mentions in a blog, twitter "conversations", Github commits on the same project, etc.

"Hmmm... it looks like this guy really gets around. He's on the same project at GoodProgrammer A and GoodProgrammer B. He also tweets about functional programming and was mentioned in GoodProgrammer C's latest blog."

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#527

Post by GVIrish » Thu, Jun 11, 2015, 7:53 AM UTC

cellularmitosis wrote: post #242

mathattack wrote: post #201

Earlier quoted context omitted.

I would agree with what you said if you replaced resume with reputation . Anyone can fill out a nice resume. One of the challenges with Google's interview process [0] is they are very worried about hiring mistakes, and also know that the process is very noisy. As such, they interview a tremendous amount of people for hiring. In addition, they've found it more efficient to just keep a high bar (missing many good hires…

Ah, they are very unlikely to get the top 100, but very likely to get e.g. 100 of the top 200? Now I think I understand the trade off they are going for (e.g. Getting 100 of the top 200 is more efficient and they are "good enough")

Eh I don't know that they're getting 100 out of the top 200 either. At some point Google's reputation for an insane hiring process causes the best computer scientists to not even bother applying because it's a waste of their time. Those people have many, many options that would pay them handsomely for their talents.

Look at it this way. If you're a cream of the crop programmer and you're looking for a job, Google has the most drawn out and arduous hiring process. Even if you apply there and start the interview process it often takes a lot longer than the industry average to get to an offer. In the meantime a multitude of other companies have probably already determined that you are an excellent programmer and tried their best to snap you up.

Google seems to be happy with the tradeoff they're making but I'm pretty sure their process is not optimized for getting the best people in the field.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#528

Post by fishnchips » Thu, Jun 11, 2015, 7:54 AM UTC

danielvinson wrote: post #248

sshumaker wrote: post #199

Earlier quoted context omitted.

I think you may have left with the wrong impression. If you ask Googlers or Xooglers alike, most agree that the people here are actually the best thing about Google. Like anywhere else, there are some bad apples, but compared to most other places the people here are on average more talented, nicer human beings and more helpful. Certainly compared to your typical startup or other BigCo. In my nearly 3 years here, that…

In my experience pretty much everyone is excellent, apart from the lower level non-engineering managers. These tend to be grads from top schools who have zero previous work experience. I encountered at least three or four in my time at Google who were just out to prove themselves and get promotions and regularly threw their teams under the bus.

I've seen some teams that fully deserved the bus treatment.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#529

Post by sytelus » Thu, Jun 11, 2015, 7:54 AM UTC

nostrademons wrote: post #194

eonw wrote: post #127

Earlier quoted context omitted.

other then search and maps, how many of their products use algos heavily though? many projects i have worked on over the years required very little knowledge of algos.

All of infrastructure. You end up using LSM trees, Paxos, variations on binary search trees, checksums, Reed-Solomon, bloom filters, external sorts, and all sorts of other academic algorithms when you deal with distributed systems. Docs/Drive does a lot with operational transforms and CRDTs, ever since Wave was merged into it (c. 2011). Remember that all Google Docs are collaborative. All logs analysis & experimentat…

This is one thing people don't understand. In my current work I need to regularly design a new algorithm or modify existing ones. I've to keep books like CLRS and TACP always accessible, not for show but actually looking through pseudocode and analysis. I regularly sweep through dozens of research papers to find the state of art. These are not one-off events it's my and my teams day to day life. Lot of people often gets surprised when I tell this to them because most developers think they never need to use any CS stuff they had learned. If they ever need answer on any algo there is always framework or wikipedia. They just don't understand that most real world problems (or at least the ones we work on) require significant amount of customizations and mixing. These same people then insist that just because they have "shipped" some code or because they have showed "coding" capability via github profile, they should be eligible to be hired anywhere. Coding and development is "given" and that's considered as easiest part in our line of work. Shipping things is certainly art but that's hardly sufficient condition. The choice, analysis and design of algorithm makes ALL the difference in type of problems that we work on. If a guy showed up who wrote some package manager on Mac but couldn't work with binary trees, I would probably would pass too because in the kind of work we do his chances of success is fairly low. Frameworks and programming languages can be learned pretty fast but learning CS and building problem solving abilities using CS primitives takes years and years of intensive study.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#530

Post by scotty79 » Thu, Jun 11, 2015, 7:55 AM UTC

scorpion032 wrote: post #457

bskinny129 wrote: post #355

Earlier quoted context omitted.

Those are simple numbers, but they don't get at the real issue. People say that because 1 bad hire can have negative effects on the whole team, causing others to get less done and leave. Missing a good hire doesn't poison your team.

The good and bad the op is talking about is different. If the attitude is not the best, you don't hire anyway. If the candidate cannot invert a binary tree and gets mostly there, and has demonstrable real world software, it's a different thing.

> invert a binary tree

What does that even mean? Swap left-right child nodes? Write it linearly (n-th children at 2n and 2n+1) and reverse it as if it was a string? OP later described it as "to min-max the tree, ascending to descending." confusing me further.