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

#451

Post by mark-r » Thu, Jun 11, 2015, 3:33 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…

"Google's perspective" shouldn't be a monolithic thing. Sure if you're sorting through candidates that were dropped on you then this process makes sense. But if you've discovered someone that by reputation and demonstrated code base has already excelled, and you're actively chasing them, then the interview process for that individual has to change. It's more about seeing if they'll thrive in your environment, and convincing them that you're an inevitable part of their career.

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

#452

Post by stuxnet79 » Thu, Jun 11, 2015, 3:35 AM UTC

rbanffy wrote: post #394

I don't think loudly (and impolitely) complaining about being rejected at a job application can, ever, be the smart thing to do.

It is not. IMO it's a pretty ballsy and idiotic thing to do. That's partly why I am not too active on Twitter. I have a lot of controversial, unpopular opinions that I wouldn't want a potential employer to get a whiff of.

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

#453

Post by Aloisius » Thu, Jun 11, 2015, 3:36 AM UTC

sangnoir wrote: post #445

Aloisius wrote: post #406

Earlier quoted context omitted.

It can't be just mirroring, because there's the obvious zero-op solution because "left" and "right" don't actually mean anything except when you're visualizing it for humans: struct NormalNode { int value; struct NormalNode *left; struct NormalNode *right; }; struct ReversedNode { int value; struct ReversedNode *right; struct ReversedNode *left; }; struct ReversedNode *reverseTree(struct NormalNode *root) { return (s…

This is genius. My C is rusty, but isn't this more than visualising for humans, if I cast a NormalNode as ReversedNode, traversal should be reversed, right? (I.e.reversed->right is normal->left

Yes, everything would be reversed. That version isn't actually how you'd do it if you actually for some reason wanted to use it in real software, it just was for illustration purposes to show "left" and "right" are just names and you don't need to change anything in memory to flip them.

A similar effect could be done in an OO language by having a base class NormalNode with two accessors, getLeft() and getRight() work normally and then a derived ReverseNode where getLeft() called super.getRight() and getRight() called super.getLeft(). With a proper compiler, the whole thing would simply be optimized away.

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

#454

Post by mvalmostnoogler » Thu, Jun 11, 2015, 3:36 AM UTC

chrismsnz wrote: post #209

falcolas wrote: post #140

Earlier quoted context omitted.

If only whiteboarding interview processes actually weeded out false positives. In practice, they select for people with good memorization skills. If you can remember the details on a ten dozen different algorithms and data structures, you can pass one of these without having a single lick of creativity or skill. I say this as an employee who has worked alongside many unskilled drones who made it past the algorithmic…

That's not what the interview process is like at all. They're more interested in how you approach real world issues (the questions I got asked were conceivably real-life issues a company like Google would face with its products). If you can solve that issue by applying efficient and well understood data structures and algorithms, then that indicates you understand the problem space and solutions that may apply. It's…

I'll be starting at Google in a week and a half. I can't go into specifics, but I can say this:

I had two phone interviews - the first had quite a few questions about my prior experience (over a decade) and how to approach real-world problems from a high-level, including some that I had worked on at my current position. The second was primarily purely technical, but did have some more theoretical/project-management-y type of questions. In neither one was I required to write any code.

On-site: one interview was entirely whiteboard-coding (in a collaborative style), on a set of related generic problems. Next was one with a set of problems related to my experience. Third was almost entirely telling war stories. Last two were some generic graph-theory-type problems and some simple problems involving data structures relevant to the my area of experience.

As I hadn't interviewed for anything in 11 years, I did spend some time brushing up on my basic algorithmic theory, and essentially followed Steve Yegge's suggestions. I honestly think I probably could have done the vast majority of it without any studying, but spending time practicing solving problems on paper (with a countdown-timer as an artificial pressure-inducing device) certainly did help me, I think, in the on-site. No amount of memorization could have helped with most of it, aside from basic knowledge that anyone who's taken Data Structures should know.

I didn't find the process to be insulting at all; it was an enjoyable challenge. Everyone I talked with on the engineering side of things I can only say the best about, and so far as I can tell the team I'll be with has some really great people. I am a more senior developer, so perhaps I got a different experience than some.

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

#455

Post by enraged_camel » Thu, Jun 11, 2015, 3:38 AM UTC

krschultz wrote: post #414

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.

But 1 bad hire is easily correctable - you fire the person. You won't know that you missed on the good hires. I personally have worked with several awesome people that have interviewed with Google, and none of them got hired. They all said the interview process was flat out insulting. Interestingly enough, most of them ended up at Facebook.

>>But 1 bad hire is easily correctable - you fire the person.

Not sure if you have ever been a manager, because firing someone is NEVER easy. It hurts everyone emotionally. The person getting fired feels awful. The person doing the firing feels awful (unless they are a real sociopath). And team morale tends to take a big hit.

Here is my stance: if you hire someone who isn't a good fit, unless they actively deceived you, it is your god damn job to find a way to make it work. As a principle you should treat people with respect and dignity, and not as easily disposable and replaceable cogs.

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

#456

Post by tlogan » Thu, Jun 11, 2015, 3:38 AM UTC

Google is about monoculture (certain type personality) - and from their business perspective it seems that approach works. Why to change it?

If they try to invent something new or in different market they might need different type of people but as of now ads business is cash cow and they would be crazy to try change it.

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

#457

Post by scorpion032 » Thu, Jun 11, 2015, 3:43 AM UTC

bskinny129 wrote: post #355

fsk wrote: post #344

Earlier quoted context omitted.

This has got to be the biggest hiring fallacy I've ever heard. "It's better to reject a good candidate than hire a bad candidate." That's completely false, and anyone who says that is completely ignorant of Bayesian logic. Here are some simple numbers. Suppose that a "good" candidate is a 1-in-100 find. Suppose that a "bad" candidate has a 1% chance of tricking you into hiring them anyway. Every time you pass on a "g…

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.

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

#458

Post by QuercusMax » Thu, Jun 11, 2015, 3:45 AM UTC

ZanyProgrammer wrote: post #316

decisiveness wrote: post #284

Earlier quoted context omitted.

I think what Google tries to find are the engineers with creativity, skill and ability to work intelligently at a problem which they haven't seen before. It's important to know how a person approaches a hard new problem and how easily or not they give up. I'd guess that a person who didn't solve a hard problem, but got close enough by displaying creativity, curiousness and a solid thought process might have an edge o…

I think you want to think that way, that whiteboard interviews have a shred of competency about them. I bet you dollars to doughnuts though 9/10 times a company will hire someone who can regurgitate algorithms rather than an eccentric who can't get them right but thinks really cleverly.

On two occasions I have "re-interviewed" current or past developers who wanted to move up from working on extremely simple low-complexity code / sysadmin work, and start working on our flagship project. In both cases the team leads and I didn't think these people were qualified to do so, but the candidates were really convinced they were. These were employees who had come into the company through non-standard channels, so hadn't experienced our normal interviews.

I had them attempt to solve the problems on a whiteboard that I would give to our intern candidates. Both totally bombed hard, and our other "re-interviewers" had the same result when they asked some design-related and algorithmic related questions.

This wasn't "regurgitating algorithms". It was basic problem-solving and software design. From their track record of development we didn't believe them to be qualified (despite their own opinion of themselves), and they only confirmed it by totally bombing the "re-interview" process (which was identical to our normal interview process).

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

#459

Post by [deleted] » Thu, Jun 11, 2015, 3:49 AM UTC

SamReidHughes wrote: post #371

callum85 wrote: post #338

Earlier quoted context omitted.

> If you can't do it, you probably don't understand recursion No, I can't do it (don't even understand the question) but I certainly understand what recursion is, and can solve problems and make things work far more reliably than many of the more academic programmers I have worked with.

I believe "invert" here means to flip the left-right direction. A better word for it would be "mirror."

[deleted]

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

#460

Post by tjradcliffe » Thu, Jun 11, 2015, 3:52 AM UTC

fsk wrote: post #436

meteorfox wrote: post #421

Earlier quoted context omitted.

I understand your point, and I'm not trying to be a troll. Humans are more complex than that. I don't think you can assume that candidates will perform the same all the time. Sometimes an excellent candidate can perform badly for multiple reasons (e.g. nervousness, poor preparation, bad interviewer, personal problems, etc). It seems to me, that rejecting a good candidate, and have him/her interview again after some t…

Why would anyone who has a job waste a vacation day to interview at a place that previously rejected him? If your flawed process rejected a good candidate the first time around, what makes you think the same flawed process won't reject them a second time?

And why don't they count the cost of good candidates who simply drop out of their hiring pool entirely, because they can't be arsed to bone up on the easily gamed idiotic hiring process?

I'd never even apply to Google based on the stories I've heard, and I'm sure there are plenty of others in the same position who are even better at what they do than I am. There are just so many stories out there of how crappy the hiring process is that everyone who's any good must have heard about it. Some significant fraction will have said, "Yep, not for me."