Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

twitter.com

Post reply on HN
Print view View original

611–620 of 683 posts

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

#611

Post by krschultz »

enraged_camel wrote: post #455
krschultz wrote: post #414

Earlier quoted context omitted.

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 y…

I have been a manager, and I have had to fire people.

I have also quit a job because they fired the wrong person.

In my opinion, if you fire someone and the reaction from the whole team isn't "thank god, that guy needed to go", then you made a mistake firing them and should have tried to make it work. In the past when I fired someone, the general reaction was much more along the lines of "what took you so long". In both cases I was the one at the table defending the person while everyone else said they needed to go.

Interestingly, in both cases the reason for firing them was that the person in question was not treating other people with respect. So what is worse, letting one person shit on your whole team and make everyone else feel bad, or getting that person off your team?

Managing isn't easy.

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

#612

Post by ascendantlogic »

72deluxe wrote: post #603
nextw33k wrote: post #583

Earlier quoted context omitted.

brew is a package manager, I can install a set of applications and libraries that will be kept up to date with a simple command line. If your coding doesn't take you outside of what Apple provide then you are probably not missing anything. Personally I have the Android SDK and NDK, QtCreator, Qt5, cppcheck, cloc, mongodb, node, wine and others. If you are not using a variety of 3rd party tools to produce/automate you…

I use xcode and use wxWidgets, but I grab these manually and compile them myself. I also use the Android SDK and NDK, cppcheck cloc etc like you I didn't realise that they could be kept up to date with homebrew?? Is that the case? Last time I looked at MacPorts (and perhaps homebrew) I saw it as a porting of BDS/GNU tools to OSX and therefore making the OS more Linuxy to my mind. I wanted a clean break from Linuxland…

Homebrew is really the default package manager. You don't need it, per se, but for the vast majority of people it'd be like trying to set up a Linux system without using apt-get or yum: an exercise in pain.

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

#613

Post by FireBeyond »

vezzy-fnord wrote: post #8
bla2 wrote: post #3

Interviewing is stressful and all, but if the guy's reaction to not getting hired is to flame on twitter, not hiring might've been the right call.

I also somewhat laughed at the poster who stated "Apparently my GitHub wasn't enough."

To be fair, though I know the situation in question: Company A wants to acquire Company B, because their product integrates well and also adds value to a particular niche of their customers. Person is one of the lead developers of Company B's product, and together they have also open sourced one of the single biggest components of their product.

i.e. "You want to buy us because of this, and a decent part of this is on GitHub, running every day, but you'd rather not look at -that- code but -this- arbitrary homework assignment".

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

#614

Post by asdfkljsaga »

varelse wrote: post #555
kodablah wrote: post #491

Earlier quoted context omitted.

"it is your god damn job to find a way to make it work" That attitude is how bloat happens. There is a middle ground here. Not firing bad employees also hurts many people emotionally as does an underperforming, overbloated company. Employees are as replaceable as employers. To use a sports analogy, it's the big leagues and you may not make the team and often times it is hard to know whether someone can make the team…

If Google didn't apply the equivalent of the Hogwarts Hat to placing its employees, I'd agree with you. But in doing so, they remove the ability of the potential Googler to meet their potential teammates and decide whether it's a good fit. Ergo they own the problem, not so much the Noogler. Also generalists == mediocre code in my experience because there's no passion for such work in a lot of people who are fantastic…

Hmm. When I joined Google, I interviewed the managers of both teams I was offered a position on, and a team member on the one I ultimately decided to join.

I'm not sure if this is the norm--I believe it differs for industry hires versus those fresh out of school--but it's certainly not true that, as a rule, you can never meet potential teammates.

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

#615

Post by Anderkent »

austinjp wrote: post #586
philipwalton wrote: post #322

Earlier quoted context omitted.

My main complaint with the tweet is that it's almost certainly speculation. 1) Most companies (for legal reasons) don't tell candidates why they weren't offered a job. Maybe it was because of the binary tree question, but maybe it was for some other reason. 2) Homebrew is a Mac-only product, so the likelihood that 90% of Googlers use homebrew is very low. Moreover, Google does not track the software its employees dow…

Really? In the UK companies are legally obliged to reveal why a candidate did not get a job, if asked... in my understanding.

I'm sceptical; I've heard this before but never managed to track down a source; I also don't know if you need some specific wording for this or if it's so vague as to be useful. Case in point: when I've failed my google interviews in London, I asked for the feedback, and got a reply saying something like "Sorry, we don't do detailed feedback. We weren't happy with your performance on the interviews". Which, duh, I got that from the being rejected part :P

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

#616

Post by toomuchtodo »

72deluxe wrote: post #559
toomuchtodo wrote: post #119

Earlier quoted context omitted.

Happened to me at Twilio. The answer was transactions (database). You never forget that sort of mistake.

...unless you forget to commit that mistake to memory and rollback instead...?

Too soon :) (all joking aside, this was ~5 years ago, very happy for Twilio and things worked out for me very well; no complaints).

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

#617

Post by GFischer »

austinjp wrote: post #586
philipwalton wrote: post #322

Earlier quoted context omitted.

My main complaint with the tweet is that it's almost certainly speculation. 1) Most companies (for legal reasons) don't tell candidates why they weren't offered a job. Maybe it was because of the binary tree question, but maybe it was for some other reason. 2) Homebrew is a Mac-only product, so the likelihood that 90% of Googlers use homebrew is very low. Moreover, Google does not track the software its employees dow…

Really? In the UK companies are legally obliged to reveal why a candidate did not get a job, if asked... in my understanding.

They can offer non-answers :) ... in Germany they got very good writing "recommendation" letters that have some hidden hints:

http://www.goldbeck.com/hrblog/employee-references-germany-v...

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

#618

Post by varelse »

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…

I spent Xmas break reviewing the most recent TopCoder problems, C++ and STL, and read Sedgewick's algorithms book cover to cover. I drank two quad espressos right before the interview. The interview was a straightforward process and I didn't miss a single question. The offer came that evening.

I should have turned it down. I've written on this thread already what a career-churning waste of time my brief stint at Google turned out to be because I was blind allocated.

Fortunately, the skills that got me noticed by Google were in demand elsewhere then (and, ironically, in demand at Google now) so I just exited the building when it became clear HR had labelled me a troublemaker for trying to find a position that made use of my talents rather than opt for the career reboot they seemed to expect of me. Great perks, but the 2nd worst gig I've had my entire career.

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

#619

Post by geebee »

fweespeech wrote: post #387
geebee wrote: post #296

Earlier quoted context omitted.

I interviewed (unsuccessfully) at google. If you want to be prepped, yes, I would recommend going over the algorithm books, and make sure that you can do all the basics in your sleep. 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 - and you need to…

> 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 might want to take advice from someone else, but here's what I think I'd need to pass the algorithm section of the technical entrance exam at google.

You must be able to do the following in about 5 minutes or less at a whiteboard with no errors:

1) print all permutations of a set 2) build and print a binary tree (preorder, postorder). 3) create a hashing function 4) quicksort and mergesort

(I'm leaving out linked lists, arrays, stacks and so forth because you won't be able to do 2 or 3 without them anyway).

The reason you need to memorize these (yes, I'll go ahead and use your word now, I agree with you that this is memorization) is that you can't be dealing with how to implement these if you're going to do enough in 45 minutes to pass the exam. I think that these three things form the foundation for most variants on recursion, sorting, traversal, combinatorics, and so forth.

Next, you need to be able to identify when something is a variant of these algorithms and solve it very quickly at the whiteboard. "Cracking the coding interview" is good practice for this, but in this case, I don't think "memorizing" these questions and answers would be especially helpful, because you're unlikely to get that exact question.

Here are a few of questions I've invented on the spot (not from my interview, not from cracking the coding interview) that you'd probably want to get close to solving in 45 minutes or so. In other words, if a buddy wanted to apply to a top tech company and asked me to give him some practice, I'd give him 45 minutes at a whiteboard for each of the following questions.

"In a binary tree with positive and negative integers, find and print all paths with a positive sum. Now assume the tree is ordered, and make your code more efficient."

"In an nxm matrix, find all sub square matrices with a positive determinant."

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.

Again, whether this is a good way to filter people out isn't something I'm discussing here, this is just my advice if you are planning to apply and want to be prepped. Also, there will be more than just data structures and algorithms on the exam.

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

#620

Post by fsk »

zodiac wrote: post #575
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…

> Counterintuitively, if you pass on too many of the "good" candidates, in your overzealousness to reject bad candidates, you're actually INCREASING THE ODDS OF A BAD HIRE. Yes, but what hiring managers are doing isn't passing over candidates that they know are good, they're passing over candidates that they're not very sure about. > Because "good" candidates are rare, every time you pass on a good candidate that inc…

The slogan represents the opposite. You hire only 10% of the good candidates but the odds of hiring a bad candidate are cut to only 0.5%.
Post reply on HN