Live data from Hacker News

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

twitter.com

641–650 of 683 posts

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

#641
post #204

Earlier quoted context omitted.

It depends how your interviewer is ranking/scoring you. One interviewer might be impressed with your ability to talk through and solve the problem from first principles, where another might ding you for not instantly knowing the answer. The former type of interviewer would be happy to give you hints and prompts, the second is a stone wall. I try to be the first -- it helps assess how a candidate responds to coaching…

> where another might ding you for not instantly knowing the answer While there certainly are incompetent interviewers, I think ones that extreme are rare.

I've definitely seen interviewers (both by reading other people's feedback, and in one rare case, being an interviewee) who expected a "correct" answer and wouldn't work with the candidate to get there if they didn't already know it.

See also: overused brainteasers. I remember being asked the 5 litre / 3 litre / get 4 litres problem for my Microsoft intern interview, and honestly told them that I already knew the answer, so I wouldn't be "solving" it, but here it is anyway...

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

#642

Earlier quoted context omitted.

Oddly enough, Google shows me interview questions where "inverting a binary tree" means something quite different — for example, flipping it upside down, and making the left leaf the root, the right leaf the left leaf and the root the right leaf. If this was really about "reversing" the tree, as you mention, the question seems more likely to address how the candidate approaches the situation. Like, he should start by…

I was gonna say, who calls reversing a tree's ordering inverting? > Oddly enough, Google shows me interview questions where "inverting a binary tree" means something quite different — for example, flipping it upside down, and making the left leaf the root, the right leaf the left leaf and the root the right leaf. Whaaaaa? I can't find this, but it seems like such a weird operation. Got a link?

> Whaaaaa? I can't find this, but it seems like such a weird operation. Got a link?

https://wwwx.cs.unc.edu/~duozhao/entry/2014/12/binary-tree-u...

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

#644
post #619

Earlier quoted context omitted.

> That said, memorization, in my limited experience, won't be that helpful, because the questions will likely come with a twist that requires that you understand the algorithms and are good at adapting and applying them Yeah...that is memorization. I've had questions like that before and the problem isn't adapting. Its the fact I don't have everything memorized. I have no problems taking an algorithm off a book/Googl…

Yes, that is true. Memorization doesn't necessarily mean rote memorization - for me at least, the algorithms are too complex to memorize by rote, I have to understand them to "memorize them". But yeah, if you are able to implement certain data structures and algorithms "in your sleep", then this does imply, as you said, a kind of memorization. I didn't get past the technical interview at google or amazon, so you migh…

> This might just be me, but I was kind of struck with just how much progress and accuracy you are expected to achieve at the whiteboard. And like I said, I am kind of blown away that people are able to do this. While I can pose those questions and develop a mental model for how to approach it, I just couldn't solve them at a whiteboard in 45 minutes to anything approaching what I believe is the standard.

That is why I stress its memorization because without memorizing things you've long since abstracted to libraries, you really can't perform in the stressful interview situation to the level the interviewer expects.

If, however, you take something the interviewee implemented in the past 6 months as the "standard problem" they could probably do it without much trouble.

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

#645
post #435

Earlier quoted context omitted.

Doesn't understand bayesian logic! Doesn't understand risk management!

Idiot: We don't want to make any bad hires! Therefore, we reject a lot of good candidates! FSK: If you pass on many good candidates, and you have a small chance of hiring any given bad candidate, then each good candidate you reject actually INCREASES your odds of making a bad hire. Idiot: We made a bad hire once! Never again! Now we reject lots of good candidates to avoid that repeat disaster! FSK: But, if you want t…

On a side note, this kind of passive-aggressive comment is not very welcome here on HN. Let's please keep discussion civil.

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

#646
post #435

Earlier quoted context omitted.

Doesn't understand bayesian logic! Doesn't understand risk management!

Idiot: We don't want to make any bad hires! Therefore, we reject a lot of good candidates! FSK: If you pass on many good candidates, and you have a small chance of hiring any given bad candidate, then each good candidate you reject actually INCREASES your odds of making a bad hire. Idiot: We made a bad hire once! Never again! Now we reject lots of good candidates to avoid that repeat disaster! FSK: But, if you want t…

You're missing something vital here. They're not rejecting good candidates because they're good candidates, they're rejecting them because they're not sure enough that they're good candidates.

They fear they might be bad candidates. They'd rather reject too many than too few, so they make sure they reject everybody who they're not 100% is a good candidate. That means they may reject some good candidates that aren't easily identified as such, but it doesn't increase their chance of hiring a bad candidate; it decreases it.

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

#647

Without commenting on whether this is a good interviewing strategy, surely the point is to sacrifice some potential good hires in favor of definite good hires. In other words, you might be able to write pretty good code even if you can't solve problems on a whiteboard, but, given a choice, why wouldn't we just choose the people who can do that, too ? I think the stated philosophy of interviews like this one is that a…

> why wouldn't we just choose the people who can do that, too?

I agree with your overall point (why not both?) but how does the interviewer know they can do both if they are only tested on their ability to solve problems on a whiteboard? I don't have a solution (that scales) to this problem but I tend to agree the types of whiteboard problems typically seen in interviews are a bad way to identify good developers.

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

#649
post #605

Earlier quoted context omitted.

Because it's hard to fire someone. Lets discount the emotional cost completely and simply look at this in terms of financial risk to the company. Employee X is hired. After a month it becomes clear to the whole team that X is a bad hire. But how do you turn a subjectively obvious feeling into an objectively obvious reason to fire. Because if that person decides to sue the company after getting fired that's what you w…

In the US you do not have to prove that person was not qualified. It is "at will employment". There is no need to prove that employee is causing losses. It's the employee who has to constantly "prove" to employer that this employee's salary is justified.

In theory this is true. In reality you will probably need said proof to prevent questions of discrimination of some sort.

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

#650
post #75
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.

People have previously mentioned hallway discussions at Google routinely devolve into bragging about SAT scores and GPAs. Nothing says Google must accept sub-par technical people, but Google fails to realize you don't have to be the top 0.0001% in absolute algorithms intelligence to do great work. Google's basic theme seems to be "you must be low latency ultra smart in our narrow interest areas" to pass an interview…

My friend worked at Google a few years ago (in a non-engineering role). After his in-person interviews, the recruiter called him back to ask him how many hours he worked during college (to pay his way), so as to excuse is less than 4.0 GPA to the hiring review board. He had completed his undergrad degree was 20 years in a subject not directly related to the Google position. He since had an relevant MS degree and real-world work experience, but that undergrad GPA was apparently still really important.
Post reply on HN