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

471–480 of 683 posts

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

#471

Post by discardorama »

trustfundbaby wrote: post #382
michaelvkpdx wrote: post #48

As goes the recruitment, so goes the employment. If you wanted to work for an organization where everyone likes to show off their skills to one another in the interviews, you'd have gotten the job, and you'd be one of them. The best interviews I find are like a first day of work (but unpaid). Your experience and skills are established by resume and portfolio. The interview shows whether you can work with the team and…

> Much like FB, it's an org whose coding needs are really pretty trivial I was with you till riiiiiight there. Google isn't just a search company anymore they're working on lots of very interesting non-trivial things all around the company.

> Google isn't just a search company anymore they're working on lots of very interesting non-trivial things all around the company.

Right. And I really doubt that people like Andrew Ng or Geoff Hinton or Sebastian Thrun were asked to invert binary trees....

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

#472

Post by jbrukh »

nostrademons wrote: post #22

Sorta ironic, but remember that the point of an interview is to determine how well you'd do in the environment that's hiring you , not how good a developer you are . Because Google tends to reinvent the wheel for basically everything, algorithmic knowledge really does matter. Package management only matters within a few very specific subteams. If you're interviewing for a general SWE position, you could be Mark Zucke…

I might be wrong, but I'm pretty sure Mark Zuckerberg can reverse a binary tree.

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

#473

Post by eyeareque »

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?

I've heard that it's not uncommon to have to interview twice before getting in to Google.

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

#474

Post by jbrukh »

Frenchiie wrote: post #427

I dont want to be an ass but how do you not know how to invert a tree? Anyone who knows how to write a tree and traverse it should be able to do this. If you ran out of time coding it then that's different.

Not even. If you know what a tree is, and you've written a couple of recursive problems on trees in your life, then you know most of them are approximately 5-6 lines of code.

If you're spending 45 minutes writing 5 lines of code, it is not definitive, but certainly a red flag.

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

#475

Post by jwecker »

jpatokal wrote: post #400
jwecker wrote: post #252

Earlier quoted context omitted.

I interviewed @ google several years ago as part of some due-diligence they were doing to decide if they wanted to acquire the startup I was working at, [redacted]. It was several hours, with many interviewers one at a time, of academic exercises. Some I could see were relevant to some of Google's projects, but that wasn't the emphasis- it was very much a "how much do you remember from CS courses?" (with a few except…

Your previous work is what gets you in the door, but interviews at Google are explicitly structured so that you need to demonstrate competence right then and there. And ye olde "what's your greatest strength/weakness" question sounds like a terrible way to judge an engineer.

Makes sense for google. And it's not that I didn't appreciate doing all that (and I did do well), it just struck me how they knew nothing else about me afterward except that I could answer academic questions, and how different that was from the startup world- where, at the very least, you want to know what they're passionate about and that they are productive.

Asking an engineer what their strengths are and then to demonstrate or explain in concrete terms is how you find out their unique value proposition. I'm not talking about "I'm a hard worker" type garbage, I mean "my strongest experience is in systems programming on Linux." "How so?" "For example, I wrote a specialized TCP kernel module that works like this..."

Again, not saying that should be the whole interview- but there are some non-academic skills and experience (like managing and leading a critical system used by thousands of people) that are worth more than a few weaknesses in problems that were already solved years ago and that are easily looked up. It's how you should judge people looking to get into a graduate program, but falls short if you're trying to build teams of awesome fury that need more broad experience and even (gasp) unique experience that you don't have a ready-made question for ;-)

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

#476

Post by jwecker »

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 agree with you, but it's still easier to fire someone than to un-not-hire someone ;-)

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

#477

Post by nrivadeneira »

fsk wrote: post #435
liberatus wrote: post #361

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…

Basing all of your management decisions purely on statistics is a bad strategy. You're assuming that the weighting of good vs. bad candidate is the same, when they're not.

Hiring a good employee is not nearly as impactful as hiring a bad one. If you can have a strategy that filters out 100% of bad employees, but unfortunately also filters out 90% of good employees, this is preferable to filtering only 50% of good employees, but also only filtering 90% of bad employees. You may have more good employees with the latter strategy, but the bad employees can kill the team.

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

#478

Post by 10098 »

Am I missing something? Are we talking about getting a left-to-right mirrored version of the tree? If so, I'm amazed. This is a technical community, and people who presumably know how to program are moaning that this is some kind of "academic" question? Are you guys for real?

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

#479

Post by jwecker »

mvalmostnoogler wrote: post #454
chrismsnz wrote: post #209

Earlier quoted context omitted.

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…

This sounds like a huge improvement from when I talked with them a few years ago.

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

#480

Post by logn »

rsc wrote: post #466
logn wrote: post #331

Earlier quoted context omitted.

I was asked that question about 7 years after reading Mastering Regular Expressions and about 10 years after taking Automata in college. It so happens that I am an expert in regex, have a patent in the field, regularly answer stackoverflow regex questions for fun, etc. Unfortunately, the question involved me actually drawing a DFA, trying to remember the notation, etc. At this point I don't even remember the particul…

Perhaps that's the point. A self-proclaimed expert in the field should know how to draw or at least read a DFA.

The interviewer told me this was a favorite question of his. Also I don't think I presented myself as a regex expert to them. Anyhow, I'm an expert in regex like a DBA would be an expert in SQL or particular databases. The interview was for an ordinary software engineer role.

Regardless, I only meant to make the point that I disagree with the comment "They're more interested in how you approach real world issues" and that this statement is false: "It's not like they get you in a room and ask you to draw a linked list or a binary tree"

edit: by "expert" I just mean something I'm particularly skilled in, not something I'm an authority in from theory to practice.

Post reply on HN