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

Debunking the Google Interview Myth

technologywoman.com

Post reply on HN
Print view View original

61–70 of 94 posts

Re: Debunking the Google Interview Myth

#61

Post by Evgeny »

wallflower wrote: post #40
moultano wrote: post #17

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'd like to believe this story

In the russian versions of the story the expert usually hits the object (server, or the machine that stopped working) with a huge hammer in the carefully identified spot. The result is the same though - the system resumes working as intended.

But, well, that's just the cultural differences in the ways the things are usually being fixed.

Re: Debunking the Google Interview Myth

#62

Post by highwind81 »

Two questions pop to my mind when I was interviewed by Google:

1. Given n number of computers with x number of numbers stored. Find the median of all the numbers distributed among those computers. Catch is that no single machine can store all the numbers. (Hope this is clear.)

2. Given a text file of logs, write a threaded program that scans the logs and produce some statistics. (My answer was to create n threads that reads every nth line.)

None of those brain teasers were asked of me.

Re: Debunking the Google Interview Myth

#63

Post by ianl »

sabj wrote: post #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-Micr…

The best exercises are to look for ACM Programming Contest Questions.

Here are some programming contest questions from 2005 from an Atlantic Canada programming contest http://projects.cs.dal.ca/apics/contest05/

Re: Debunking the Google Interview Myth

#64

Post by InclinedPlane »

strlen wrote: post #56
InclinedPlane wrote: post #54

Earlier quoted context omitted.

Keep in mind, I'm responding specifically to the idea that "[explaining] the significance of ‘dead beef'" is a valid interview question. Have you done a survey of memory debugging experts to determine how common knowledge of "dead beef" is? It's not a knowledge question, it's a trivia question. A shibboleth. It is neither a necessary nor sufficient pre-condition for knowledge of memory debugging techniques and it pro…

> It is neither a necessary nor sufficient pre-condition for knowledge of memory debugging techniques and it probably has about as much correlation with them as asking whether they have read The Lord of the Rings. It's a hexadecimal number, that should be quite obvious. It's a noteable and easy to notice one. Others may have used a different one (I used 0x12341234 for the task as others have used 0xdeadbeef) but it s…

When shorn of hexadecimal connotation as in the original question what value is there to it? If I ask someone verbally "what is the significance of dead beef" should I put any value in their either having already learned about 0xDEADBEEF or in their ability to appreciate that it could be a 32-bit word aligned hex value?

If someone were to change the question to "what is the significance of bad food?" would it be considered equally valuable?

Re: Debunking the Google Interview Myth

#65

Post by blacksmythe »

Periodic wrote: post #37
dkarl wrote: 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 was asked to write very little code for my current position. One of the questions was being presented with some code and figuring out what it did. I didn't realize how apropos that question was at the time. I just got done doing a series of 10 1-hour interviews for contractors for an enterprise Java web application contract lasting about 6 months. Only 2-3 of them could write correct Java on a white board for simpl…

Did you have a chance to rate the performance of the candidates that were hired that had trouble writing code at a whiteboard in the interview? Were any of them productive in a different setting?

I am more inclined to give people a chance to work at a terminal (with internet access) instead of a whiteboard.

Re: Debunking the Google Interview Myth

#66

Post by Nate75Sanders »

wallflower wrote: post #40
moultano wrote: post #17

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…

Trivially untrue. FedEx never would have protested a $10K bill for that act.

Re: Debunking the Google Interview Myth

#67

Post by wooster »

InclinedPlane wrote: post #44
strlen wrote: post #29

Earlier quoted context omitted.

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…

+1 for a well-put argument.

However, I admit to asking a lot of trivia questions when interviewing candidates at Apple, partly as a culture fit, and partly because I could use them to segue into a chain of questions that dealt with the consequences of seemingly innocuous design decisions made by engineers long ago. This was something my group had to learn to foresee and deal with when we thought bad things would happen.

One of these questions had to do with 0xCAFEBABE.

That said, getting the trivia part right was a +1, and not knowing the info was a +0, so no harm if the job candidate didn't know it.

I'd also use them as a shortcut to validating their experience in an area. Again, a +0 if they didn't know the trivia, but if they do, I can move on to a different line of questions.

Re: Debunking the Google Interview Myth

#68

Post by roxstar »

Evgeny wrote: post #61
wallflower wrote: post #40

Earlier quoted context omitted.

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'd like to believe this story In the russian versions of the story the expert usually hits the object (server, or the machine that stopped working) with a huge hammer in the carefully identified spot. The result is the same though - the system resumes working as intended. But, well, that's just the cultural differences in the ways the things are usually being fixed.

Actually you get the hammer one in automotive maintenance examples, and also if you are talking to an older generation where hitting stuff worked much better.

Re: Debunking the Google Interview Myth

#69

Post by [deleted] »

highwind81 wrote: post #62

Two questions pop to my mind when I was interviewed by Google: 1. Given n number of computers with x number of numbers stored. Find the median of all the numbers distributed among those computers. Catch is that no single machine can store all the numbers. (Hope this is clear.) 2. Given a text file of logs, write a threaded program that scans the logs and produce some statistics. (My answer was to create n threads tha…

[deleted]

Re: Debunking the Google Interview Myth

#70

Post by cdavid »

gcb wrote: post #60
code_duck wrote: post #45

Earlier quoted context omitted.

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.

most of my github account is filled with trash that i start for one day, barely learn something completely new to me, sometime a new language, then forget and move on. if I find said thing promising, i'd usually came back some weekends later and do something more complex, but again, basically junk. oh, and did i mention nothing looks finished? Now, take anything i code behind the closed doors at my employer or i cont…

I think you are not looking at it the right way: sure, a lot of stuff on github is crap, but if you have something good on it where you are a significant contributor, then it surely is a good sign.
Post reply on HN