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

#461

Post by Retric » Thu, Jun 11, 2015, 3:59 AM UTC

QuercusMax wrote: post #458

ZanyProgrammer wrote: post #316

Earlier quoted context omitted.

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

Nothing you said actually means they could not have done the job. You basically said, we gave them a test and they failed so clearly the test was a good idea.

The only way to validate your highering process is to randomly accept people you would otherwise fail. Anything else is meaningless.

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

#462

Post by BinaryIdiot » Thu, Jun 11, 2015, 4:04 AM UTC

philipwalton wrote: post #403

BinaryIdiot wrote: post #357

Earlier quoted context omitted.

> 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. So when I was declined at Google I knew people who worked for Google. One looked up my profile in whatever system they used and the other simply asked the interviewer why. OP may have done the same but as you say it's unclear either way…

The tweet starts out: "Google: 90% of our engineers...", which implies that this is information Google told him.

OP was obviously being sarcastic to express his frustration.

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

#463

Post by tjradcliffe » Thu, Jun 11, 2015, 4:05 AM UTC

silverlake wrote: post #96

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…

It's also stressful. To be fair the tree problem he got was easy, but brain freeze can kill you. I flubbed a trivial problem at a FB interview that still haunts me today.

In my academic days I used to refer to say "physics-standing-up" is a different subject from "physics-sitting-down" and needs to be studied separately. Some years after I left academia I had the good fortune to get in contact with the person who introduced me to acting at a very young age and thank her for her contribution to my academic career. About 30% of my success was due to my comfort working in front of an audience--even a panel of examiners is "an audience"--and I had a huge advantage over my peers because of it.

One thing that I'd recommend to anyone seeking any kind of job is taking some improv courses--they are pretty common in major centers and even some smaller towns, and can really improve your ability to deal with this kind of nonsensical interview situation, which tests a bunch of skills that have nothing to do with your ability to actually do the job.

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

#464

Post by Retric » Thu, Jun 11, 2015, 4:11 AM UTC

philipwalton wrote: post #403

BinaryIdiot wrote: post #357

Earlier quoted context omitted.

> 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. So when I was declined at Google I knew people who worked for Google. One looked up my profile in whatever system they used and the other simply asked the interviewer why. OP may have done the same but as you say it's unclear either way…

The tweet starts out: "Google: 90% of our engineers...", which implies that this is information Google told him.

http://en.m.wikipedia.org/wiki/Hyperbole

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

#465

Post by kevingadd » Thu, Jun 11, 2015, 4:17 AM UTC

owen_griffiths wrote: post #317

emsy wrote: post #155

Earlier quoted context omitted.

If you follow the twitter discussion, it says he applied for iOS tools. I don't know what tools they write but I'd be surprised if someone who manages to write a (pretty good, actually) package manager can't solve the problems in this position.

Google doesn't hire for specific projects like this - they want people who can work all over the company.

Not accurate anymore.

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

#466

Post by rsc » Thu, Jun 11, 2015, 4:18 AM UTC

logn wrote: post #331

eli_gottlieb wrote: post #318

Earlier quoted context omitted.

Ok, on the one hand, you should be able to answer the question with, "Get a standard-issue POSIX-conformant regex library. Next question!" On the other hand, knowing that DFAs are equivalent to regexes are equivalent to NFAs is already a step of theoretical knowledge that any "Just let me write code" so-called "dev" is likely to complain about being asked for.

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.

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

#467

Post by ufmace » Thu, Jun 11, 2015, 4:18 AM UTC

unoti wrote: post #395

lavamantis wrote: post #328

Earlier quoted context omitted.

"filter out a bad hire" Good teams have a balanced skill sets I've found. You need some uber-algorithm guys who can pass questions like this, but you also need engineers who can fill in all the rest of the tasks that make up a production worthy system. I have not found that the uber-algorithm guys always pay attention to detail, put in good comments, think of all the edge cases, communicate well with outside teams, e…

> you also need engineers who can fill in all the rest of the tasks that make up a production worthy system. I have not found that the uber-algorithm guys always pay attention to detail, put in good comments, think of all the edge cases, communicate well with outside teams, etc. What's to keep a good engineer like you describe from buying a couple of books and spending a couple of months working on becoming the type…

I'd rather flip it around - what's the reason for me to do that? I don't see them offering obscene piles of money anymore, so they don't get to make up ridiculous hoops and demand everybody jump through them. This stuff is rarely useful in the real world, and when it is, you can grab something off the shelf, or look it up then. I'd rather spend time learning the other stuff on that list, that's useful to companies that have their priorities straight.

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

#468

Post by dagamer34 » Thu, Jun 11, 2015, 4:18 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 recently went through an MS phone interview and didn't do as well as I would have hoped. I did learn quite a bit though. Here's my advice:

1) Actual programming and a technical interview are not and never will be the same thing. Assume you know nothing. And I do literally mean nothing. 2) Start with a basic intro to programming book in a language you aren't familiar with and try to do simple tasks in a language you already know. This simulates a bit how it feels to program under pressure. Things you know you know seem not to come out quite as quickly. This helps to emphasize point #3. 3) Practice. Practice. Practice. Practice. Practice. A decent chunk of your typical interview questions exist out there. I'm not saying to memorize them, but be familiar with their solutions. Eventually you'll get to the point that an approach for solving a new problem will come from pieces of old ones. 4) Since coding is done on whiteboards, do not use a compiler. Pencil and paper. 5) Find someone to give you an honest-to-goodness mock interview.

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

#469

Post by bphogan » Thu, Jun 11, 2015, 4:18 AM UTC

rbanffy wrote: post #431

iopq wrote: post #409

Earlier quoted context omitted.

So what's stopping them from running git blame?

Interviewer time is expensive and candidate time is cheap.

Running git blame is faster than waiting 30 minutes for the results of a whiteboard test.

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

#470

Post by Aloisius » Thu, Jun 11, 2015, 4:24 AM UTC

fishnchips wrote: post #230

[Ex-Googler here] Truth be told this is a trivial question to be asked during an algo interview and as an interviewer I'd consider this a warm-up. Otherwise it's a rather poor question since either you know how to do it (ie, you have an idea about recursion) or you don't - there aren't too many shades of grey or possible follow-up questions that I can ask to probe the depth of your knowledge. That being said if I ask…

> [Ex-Googler here] Truth be told this is a trivial question to be asked during an algo interview and as an interviewer I'd consider this a warm-up. Otherwise it's a rather poor question since either you know how to do it (ie, you have an idea about recursion) or you don't - there aren't too many shades of grey or possible follow-up questions that I can ask to probe the depth of your knowledge.

It is a terrible question.

First, you can't invert a binary tree (as in flip upside down). If you did, you'd end up with multiple roots and since all binary trees are rooted, you'd no longer have a binary tree. It'd be a tree, just not a binary tree.

If the questioner meant mirror a binary tree (swap left & right at each node), then it is a no-op. You do not need to modify memory to do it. Left & right are just labels for two pointers. You can just swap the order your variables in whatever struct defines your node and cast it against your existing memory (or change what your accessors return in a derived class or create a reverse iterator or however you want to implement it) and there you go, a "reversed" tree with zero overhead.

Either way, it is a terrible question unless you wanted to see if someone understood the difference between how a data structure is drawn on a whiteboard for humans vs. how it actually works. Maybe they were actually asking that question, but that seems highly unlikely.

And if they actually meant for you to recurse down and swap left and right on everything, it would dramatically lower my opinion of them because it would make me wonder if they knew the difference between how a binary tree is drawn on a whiteboard vs. how it is laid out in memory.