Live data from Hacker News

Debunking the Google Interview Myth

technologywoman.com

41–50 of 94 posts

Re: Debunking the Google Interview Myth

#41
You can do useful mental exercises for Google interviews, or other interviews, by working through "puzzle questions" and similar problems. But if a world of limited time, this might not be the best use of your prep time.

A good source for the history of these questions and interview style, as well as a bevy of sample questions, can be found in "How Would You Move Mt. Fuji?" http://www.amazon.com/Would-Move-Mount-Microsofts-Puzzle/dp/...

Re: Debunking the Google Interview Myth

#42
post #15

Earlier quoted context omitted.

If you can comment, I would be interested on the standard of coding that successful candidates exhibit once employed. Personally, if I could only ask a candidate one question, it would be something that involved writing code. Too many times I've seen candidates with impressive resumes, technical knowledge, or conversation skills, fail miserably to implement trivial (e.g. stricmp) functions.

On the other hand, I don't understand how non-technical interviewers can tolerate not knowing how good a non-technical applicant is for the same reasons you mentioned. Do teams ever recruit athletes without watching them play?

http://www.kottke.org/08/05/gladwell-on-the-mismatch-problem

"One subject in Outliers is what Gladwell calls the "mismatch problem," which refers to his idea that the qualifications which people look for/companies require in candidates when hiring often do not necessarily have any correlation to successful job performance - and often leads to poor hiring decisions."

He's also written on the problems in scouting athletes & picking teachers in the New Yorker.

Re: Debunking the Google Interview Myth

#43

Earlier quoted context omitted.

probing you about stuff that even at Google's you won't be working on 5% of the time (if at all). In any highly skilled profession, 95% of the time someone with very little of your skill could do your job. The valuable part is that you can also be counted on for that 5% as well. Most of my time at Google hasn't involved any substantial theoretical work. One time though, I did have to come up with a algorithm for comp…

I'd like to believe this story (haven't found an authoritative source yet) that I heard once from a professional speaker of the FedEx main processing facility in Memphis. One day it completely stopped dead - usually it is controlled mayhem with the packages and machines running - the silence was deafening - thousands of dollars lost every minute. They brought in the best expert they could find. He investigated and we…

Unfortunately, this is likely just a modified version of a (almost certainly also fictional) anecdote about Picasso. I've heard this one from several different places:

A woman walks up to Picasso, later in life, as he sits at a cafe table. "Could you draw me a sketch?" she asks, thinking she'll make a quick buck. "I can pay you for it."

Picasso shrugs, says "sure", and quickly scratches out a little something on a napkin. "That'll be $10,000," he says.

"$10,000! But it only took you a few seconds!"

"Just the drawing of it took a few seconds," Picasso replies. "Learning how took my entire life."

Re: Debunking the Google Interview Myth

#44
post #29

Earlier quoted context omitted.

No, it's not. It's a trivia question. Nobody uses such techniques any more because looking at raw memory dumps is not the right way to debug these days.

Using a "magic marker" like this doesn't imply looking at a raw memory dump (which, however, is still needed in several places Google is involved e.g., kernel hacking, embedded devices). For example, I used it myself when debugging an issue where our processes morphed into un-killable zombies. I was dealing with crash dumps, where I was walking through the process list in the kernel (it's a doubly linked list) in cra…

If you want conformity that's fine. What would you think if your company instituted a very specific dress code? Requiring specific trivial knowledge is just as restrictive and constraining.

If you want to find engineers with talent then you need to do a lot more leg-work in plumbing their knowledge, experience, and skill than merely ticking off a checklist of shibboleths.

P.S. Personally I love hacker jargon and lore, I like knowing about scratch monkeys, core memory, the usenet cabal, and even 0xDEADBEEF, but I wouldn't take ignorance of those things to translate to ignorance of engineering fundamentals or of passion in software development.

Re: Debunking the Google Interview Myth

#45
post #2

Coding on the spot might seem surprising to those outside of the software industry, but it’s standard practice. Sounds like wishful thinking to me. At least I wish it were true. I've been involved in a lot of interviews at my company, and I'm the only one who ever asks anyone to write code.

I know this attitude won't win very many friends, but I wouldn't accept a position where I wasn't asked to write code during the interview. I'm going to be writing code for money and they don't want me to prove that I can before hand? That's like hiring a "farmer" from the inner-city.

I'd take a look at a candidates github account or other open source work. That might preclude the need to ask for code during the interview.

Re: Debunking the Google Interview Myth

#46

From anecdotal but first-hand experience (went through a couple of interview rounds), Google interviewers indeed don't ask the questions on that list. But the questions they do ask are hard and often academic - as in, you have likely never run into them in a real-world scenario before and you likely never will. At first I was like 'wow, Google must be populated with demi-gods'. Then I spoke to some Googlers off the r…

I'd call it more of a "people we are really, really, really sure are what we consider smart" filter rather than a "dud filter", considering they want to find the top M% rather than remove the bottom N%.

Re: Debunking the Google Interview Myth

#47

Earlier quoted context omitted.

probing you about stuff that even at Google's you won't be working on 5% of the time (if at all). In any highly skilled profession, 95% of the time someone with very little of your skill could do your job. The valuable part is that you can also be counted on for that 5% as well. Most of my time at Google hasn't involved any substantial theoretical work. One time though, I did have to come up with a algorithm for comp…

I'd like to believe this story (haven't found an authoritative source yet) that I heard once from a professional speaker of the FedEx main processing facility in Memphis. One day it completely stopped dead - usually it is controlled mayhem with the packages and machines running - the silence was deafening - thousands of dollars lost every minute. They brought in the best expert they could find. He investigated and we…

I've heard about 17 different versions of this story, which are probably all bullshit. Here's a few:

http://pinds.com/2007/05/27/knowing-which-screw-to-turn/

http://www.guidancechannel.com/default.aspx?M=a&index=65...

http://www.cs.uni.edu/~wallingf/teaching/agile/sessions/sess...

http://pocky.tumblr.com/post/49520543/knowing-which-screw-to...

Re: Debunking the Google Interview Myth

#48
post #2

Coding on the spot might seem surprising to those outside of the software industry, but it’s standard practice. Sounds like wishful thinking to me. At least I wish it were true. I've been involved in a lot of interviews at my company, and I'm the only one who ever asks anyone to write code.

I've been involved in a lot of interviews at my company, and I'm the only one who ever asks anyone to write code.

Would you consider the primary output and product of your company software? Perhaps you are just working in a position creating software in a non-software company.

Re: Debunking the Google Interview Myth

#50
post #33

Earlier quoted context omitted.

No, it's not. It's a trivia question. Nobody uses such techniques any more because looking at raw memory dumps is not the right way to debug these days.

The "right way" depends on the task at hand and the tools you have at your disposal. For any type of low-level work, being able to view, understand, and observe regions of memory is pretty much essential.

[deleted]
Post reply on HN