Fascinating use of "Big Data" to cut through the bullshit. Wonder if it will change anything. I suspect the "tough" interview plays well into a company's PR.
>I suspect the "tough" interview plays well into a company's PR.
from: "The trick Max Levchin used to hire the best engineers at PayPal"
Levchin realized the best engineers wanted to be challenged both in their jobs and in the interview process. “We cultivated a very public culture of being incredibly hard to get in. Even though it was actually very hard to get good people to even interview, we made a point of broadcasting that it's incredibly hard to even so much as get into the door at PayPal. You have to be IQ of 190 to begin with, and then you have to be an amazing coder, and then five other requirements. The really, really smart people looked at it and said, "That's a challenge. I'm going to go interview there just to prove to these suckers that I'm better." Of course, by end of the conversation, I'm like, "Maybe you want to come get a job here because you're pretty amazing.”
I find the use of the term "Big Data" there bullshit. Even for the largest company like Walmart with 2 million employees - having some data about every one is hardly "big". Collect a whole deluge of data about each and you hardly fill a USB drive.
I realize that reporters like to throw buzzwords into anything to cater to the "simpler" readers. But come one, this is outright silly.
I asked these questions until a year ago. Brain teasers were never ok. They are defined as things that require a single insight and/or domain knowledge and could be communicated in a few seconds.
"Monopoly" is a perfect example of a brain teaser and anyone using that would be treated pretty harshly by the committee that reviews interview feedback. Estimate questions are not: there's no expectation of a "right answer" and the important fact is the working.
Some programming questions border on brain teasers to non programmers but that doesn't matter because you are asking programmers and again, it's the working that matters.
Finally different roles get different types of interviews. I worked in PM and there were analytical (these questions), product (design a better x) and technical (basic engineering interviews). The behavioral type was not one I encountered in PM or eng but maybe used elsewhere.
On the bright side, this article will boost the self-esteem of the 100s of thousands of devs like me who didn't get a job offer. "I'm not stupid, their process was stupid!"
I don't understand people's problem with estimating. It's a useful skill. Perhaps it would be better if the questions actually related to technology, rather than golf balls - but the principle is the same.
For instance - "how many hard drives does Gmail need?" requires a rough guess of how many users Gmail has (if you're interviewing at Google, you should know it's 1e8-1e9). How much space each one takes (probably nowhere near a gigabyte on average - let's say 1e8 bytes). And that the current capacity of hard drives is (1e12 bytes).
Then you can say that they probably need 1e5 hard drives, link it to redundancy, availability, deduplication, backups etc. You can comment that it's feasible to build a datacenter with that many hard drives.
No one cares that the actual number is 12,722 - but you've demonstrated a broad set of knowledge about the current state of technology. Saying "dunno - a billion?" is not going to get you anywhere, and with good reason.
I used to think estimation questions were useful. I still think that estimation ability is something a programmer needs for exactly the reasons you state.
However, I used to ask one estimation question (How many hours have you spent coding over the course of your life) on all my interviews. Over time, I lost interest in it because almost everyone got it "right" (took an acceptable route and arrived at a reasonable estimate). The only people that got it wrong were ones I decided to reject for other reasons (this being a semi-technical but mostly ask-about-experience phone interview).
So, although I agree it's a useful skill, I don't think it's worth askin estimation questions from my personal experience.
I had a professor who used to say: a great engineer should be able to answer any question in 30 minutes, at some level of precision. Her example was deriving the equations for the dynamics of the space shuttle. You should be able to do it in 30 minutes, even if it's an extreme approximation.
Even if this idea had some merit, I think once the candidates start preparing for interviews by reading some idiots guide to brain teasers then it loses it purpose and further hurts the candidate who is actually skilled, quick on his feet and has good instincts.
The other nice part about being able to estimate- you can often determine feasibility with a reasonable degree of confidence, for a minimal investment in effort.
The problem is, the interviewers often judge how accurate your estimation is, and not the fact that you know (the highly flawed) Drake Equation.
These estimates are completely useless in real life, because in real life nobody guesses how many drives you need for GMail, or how many gas stations there are in LA.
It's a crutch. Nobody knows how to interview. Interviewing properly is a lot of work. There are two people who can do interviews--people who have knowledge of the job and people who have time to interview--and they are so infrequently the same people. These sorts of things were appealing because they were easy, a way to not spend a lot of time on interviewing, or a way to not need a lot of knowledge about the job.
And these things are important, because job candidates are not people, they are OEM replacement parts being order from Pep Boys. Call up the recruiter and requisition a J6-252: Programmer, seasoned 5 years, with degree from MIT. Oh, those ones are too expensive. Guess I'll take the knock-off version, but I refuse to pay full price!
Hopefully, because it's Google saying it, everyone will cargo-cult on this bandwagon too.
From the original New York Times article that Quartz has linkspammed here: "On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart."
Long before this was reported in the New York Times, this was the finding of research in industrial and organizational psychology. A valid hiring procedure is a procedure that actually finds better workers than some different procedure, not a hiring procedure that some interviewer can make up a rationale for because it seems logical to the interviewer. We have been discussing home-brew trick interview questions here on Hacker News for more than a year now.
Brain-teaser or life-of-the-mind interview questions do nothing but stroke the ego of the interviewer, without doing anything to identify job applicants who will do a good job. The FAQ on company hiring procedures at the Hacker News discussion linked here provides many more details about this.
REPLY TO UPDATE SELF: Yes, the correct term was actually "blogspam," and I appreciate (and upvoted) the grandchild reply that pointed that out. I see that now the Hacker News curators have changed the link on the story submission from pointing to Quartz to pointing to the original New York Times article, which fits the Hacker News guidelines.
(I mention this because many comments in this thread will be very confusing to newcomers if it is not made clear that the thread used to point to Quartz but now points to the New York Times.)
From the original New York Times article that Quartz has linkspammed
No, this is Linkspan:
Link spam is defined as links between pages that are present for
reasons other than merit.[9] Link spam takes advantage of
link-based ranking algorithms, which gives websites higher
rankings the more other highly ranked websites link to it.
These techniques also aim at influencing other link-based
ranking techniques such as the HITS algorithm.
"On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart."
A similar equivalent in coding interviews would be "what does obscure function/feature do?"
There are questions that are actually fun and I can sort of see them starting a conversation with the right kind of interviewer that tells both parties a lot about who they're dealing with. From the article:
> How much should you charge to wash all the windows in Seattle?
Basic economics estimating - probably not that useful and a bit dull, but hey why not. At least the problem has several angles to it that might be fun to explore.
> Design an evacuation plan for San Francisco
That's a nice one. Kind of open-ended, a lot of things to consider, a lot of ideas to be had.
> How many times a day does a clock’s hands overlap?
Why? What happens to the interview after you counted them (possibly on a whiteboard)? It's a dead end and the question is dull.
> A man pushed his car to a hotel and lost his fortune. What happened?
Now this has the potential to be great or absolutely horrible, depending on the intent behind the question and the nature of the interviewer. If it's taken as a "fill in the blanks" kind of challenge it would be a fun way to explore the candidate's imagination. But I'm guessing it's not. It's probably one of those "clever" questions that have only one "right" answer that makes no real sense except creating a few moments of uncomfortable silence.
> You are shrunk to the height of a nickel and your mass is proportionally reduced so
> as to maintain your original density. You are then thrown into an empty glass blender.
> The blades will< start moving in 60 seconds. What do you do?
Again, this could be a fun physics and chemistry question and I see a couple of possible solutions that might or might not work out - might be fun exploring them. But again, it sounds more like a trick question with one standardized answer. Bad.
The problem with trick questions and standardized answers is that the nature of the question makes the candidate uneasy and even if they eventually figure it out, nobody will have learned anything during the process. It's more like a hazing, not a hiring interview.
I've never seen any citation that Google ever used these kinds of question. Especially the idiotic one about pushing a car to a hotel. I think it was just an urban legend and a good piece of linkbait.
There must be thousands of people on HN who interviewed at Google over the years. Did anyone ever get a question like this?
When I interviewed at Google 5 years ago they weren't using those brainteasers.
There are many posts online about the actual, CS-y questions that you can expect in a Google interview, I had just assumed that the mentions of brainteasers were merely urban legend.
I've interviewed at Google. Years, years ago. I didn't get the job. Similarly, no brainteasers, but something worse: they made me write syntactically correct code on a whiteboard. I have never written code without using a keyboard; turns out, I just didn't have the neural pathways for anything else. My brain kinda seized up. I specifically recall failing to recognise the fibonacci sequence (especially horrifying given that I read mathematics at Edinburgh). Things went downhill from there.
Ever since, whenever I've interviewed someone, I ask them to demonstrate their strengths to me first.
From what I hear, the brainteasers were retired quite a while ago for engineering and technology roles, but persisted in other fields (like account management, sales, etc) for some time longer.
I was contacted by a Google recruiter a few months ago, I had no intention of changing my day job at the time, but for shits and grins I went through a couple phone interviews. The position they were hiring for wasn't an area I have any experience in (the recruiter had made a mismatch), but I thought the questions were reasonable for somebody who works in that field and were kind of fun. They were quizzy, but could be practical. It was a management position so there weren't any coding questions, but things like basic cost estimating that sort of thing.
I had fun and wouldn't mind it again, it didn't feel like a bunch of stupid random brain teasers like I've experienced before (how many t-shirts would it take to make sea worthy sail? why are manholes round?) etc.
"It was a management position so there weren't any coding questions"
Interesting; when I interviewed for a management position (test manager) it was nothing but coding questions, including the infamous "reverse a string" question. ("Would like that optimized for space or speed? In-place, or do I get a buffer? Can you tell I've heard this a zillion times before?") I can understand wanting a test manager to be more than an empty suit, but yoiks.
This topic/discussion reminds me of a movie I saw recently It was called "That guy...who was in that thing". It is a documentary about working actors. Not Big time superstars like Tom Cruise, but the small time 'character' actors.
Anyways, there was one part in the movie where they start talking about auditions. All four or five of the actors they were interviewing for the movie unanimously spoke badly about the typical audition process. Some quotes taken from memory:
"I love acting, but I hate auditioning"
"You've seen my demo reel, you've seen me when I was on Star Trek, you know I can act, then why not just give me the part? Why make me go through this tedious audition process"
"90% of acting is reacting. You can't fully demonstrate your full acting abilities when you're standing in front of a panel of producers 'acting' out a scene that consists of 5 lines of dialog"
What the actors were saying about how they hate the audition process reminded me a lot of my frustrations surrounding hiring during tech interviews. Making an engineer do puzzles like FizzBuzz is a lot like making an actor act out a 20 second scene without any time to prepare or a proper "scene partner" to act alongside of.
I wish I could like to a youtube of the movie, but I can't find one. Its on netflix though.
Making an engineer do puzzles like FizzBuzz is a lot like making an actor act out a 20 second scene without any time to prepare or a proper "scene partner" to act alongside of.
FizzBuzz is self-contained tho, so maybe a better comparison would be to asking for a dramatic poetry reading?
They aren't using the brain teasers right. The Idea is not to create a barrier to entry, nor is it to stress the candidate. The objective of the brain teaser is having the candidates think slow enough that the interviewer can observe how he approaches a problem.
It's hard, when using problems that are common, to really understand how the candidates gets to the answer. Often, he's building on pre solved sub problems he encountered on his professional life, so the resolution process didn't even occur at the interview.
I personally don't use brain teasers, because they stress out valid candidates who do not work well under pressure. However, I think teasers, when properly used, are valid tools in an interviewers toolbox.
Totally agree with this. The essential skill of a software engineer regardless of position is to be able to approach any problem no matter how unfamiliar or intractable and formulate a means of attacking it and verifying the solution. The right type of brainteaser can be a great way to demonstrate this provided: A) The interviewee hasn't heard it before B) It's meaty and not relying on some flash of insight (the manhole cover question is absolute garbage) C) you are able to capture the thought process in sufficient detail, either through verbally talking it out or writing down or whatever.
This has the potential to reveal a certain high level problem solving ability which the lack thereof will not necessarily be revealed by more concrete "write pseudocode for X" type of interview questions. What I mean by that is that there is a continuum of skills ranging from rote copying of solutions all the way through synthesizing solutions to business problems and designing architectures to fulfill a malleable list of requirements. A mediocre engineer can inch their way up the continuum through raw pattern matching ability (which humans excel at) without ever attaining mastery of the high level abstraction that are driving the implementation detail. Such engineers can appear tremendously productive at the ground level, but they are dangerous for an technical organization to have many of them because they tend not to see where technical debt is piling up and can often paint themselves into corners because they're not considering the bigger picture. Knowing someone has strong reasoning skills from very high level human tasks down is a good hedge against this.
I took an i/o psychology course during school and a chunk of it dealt with interviewing and finding best candidates (from an employer stand point and equity standpoint), as lots of people who took the course tend to pursue education with the idea of obtaining an HR-related certificate.
The comment about brainteasers vs structured rubrics is sort of surprising to me, given Google's reputation for quantitative data. Speaking from a very high level, structure was really what was emphasized for interviews. It's interesting how culture can get in the way of proven 'fact,' and I love that Google is using their own (much larger data sets) to make these improvements and in/validate other research
1. Invent a bunch of silly riddles that a non-technical reader might accept as tech interview questions.
2. Pull a major tech company out of a hat (today it's Google), and claim with no evidence that their interviews are based around silly riddles. The article will be cited for years as proof that people working at $COMPANY are weird and obtuse.
3. Wait a couple years. Ignore all evidence that $COMPANY does not use silly riddles in interviews.
4. Once traffic on the original article dies down, write another article claiming $COMPANY has "admitted" silly riddles aren't useful for interviews.
I see you didn't read the article. The basis for the article is a NYT interview with a SVP at Google, claiming that the brainteasers are not useful (among other things). Surely that is good source? I haven't got a clue if Google actually used these kinds of questions but the interview sure seem to suggest it.
A problem I see with many of these sorts of questions is that they often require the candidate to have some supposedly common knowledge which is not required for the job itself. Cryptic word games surely are much more difficult for a non-native speaker of the language in use. Questions related to facts about cities probably require local geographic knowledge. Surely the evacuation plan for SF must consider the capacity of various bridges? Someone who has lived in northern CA for most of his life would have a much easier time thinking through the logistics of moving people off a peninsula. And, of course, there's the Monopoly question (which I had to Google).
I like estimation questions in general for many of the reasons other commenters have cited. However, I wish those using them would consider the knowledge implicitly required of a candidate.
> Years ago, we did a study to determine whether anyone at Google is particularly good at hiring. We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship.
Can we see the study?
Also note that performance on the job is a noisy measurement, because people who get to work on impactful projects (through luck or people skills) get rated higher than others. I wouldn't be surprised if interview scores were a better measurement of "true" skills.
> I wouldn't be surprised if interview scores were a better measurement of "true" skills.
Possibly, but in a sense "true" skills don't really matter. What matters to Google, ultimately, is Google's opinion of the worker. It's almost certainly skewed / flawed / distorted in some way from the individual's true skills, and that's unfortunate but mostly a fact of life.
Sounds great, although like with any retraction I doubt this will be enough to stop the spread of interview puzzles. Even I'm guilty of asking my share before I realized that the only thing that matters about the candidate is whether they can sit down and start writing code (and the quality of said code).
Google still ask puzzles: they just don't ask brainteasers.
For example, write a program to find every possible word in a given Boggle board is a puzzle, but one you're going to solve by coding...rather than "how many piano tuners are there in New York", which is a rather different matter. I've interviewed on-site with Google several times, and always found the CS puzzles to be challenging but fair.
I had a couple questions like this at a couple of interviews more than a few years back now. In both cases, I sat for a minute, and asked a few questions back, like "do you mean the city limits of Raleigh, or the metro area?", "how do you define gas station - do we include public-only, or private fueling places?", etc. Part of this was buying some time, because the question caught me off guard, but I think my questions back caught him off guard a bit too.
That interviewer told me I was the only person who asked clarifying questions before blurting out an answer or walk through. Another one was "take this marker and design a house on the whiteboard for me". So I took the marker and asked questions like "how many people will live here, do you want one or two story, do you need a garage/shed/basement, etc?" And again, was told I was the only person who'd asked questions before starting to draw.
I don't think the intention behind those brain teasers was necessarily to determine how you react to those sorts of problems, but it may have been a useful determining factor for some interviewers nonetheless.
Every time I click any link on HN that points to qz.com I get QZ without any reference to the article in question. Currently it points to "Why Tesla wants to get into the battery-swapping business that’s failing for everyone else"... in Chrome. Firefox seems to work. Terrible website.
Knowing how to quickly estimate something is useful.
I imagine that Larry Page does a few quick estimates every day. How many Loon balloons would it take to bring Internet to 90% of Africa?
But not everybody at Google has a job like Larry Page. It's gotten to be a big company full of accountants, HR people, and other jobs that don't require much thinking in unfamiliar territory.
In other words, guesstimation is a useful skill, but not for every Google employee, so it's not going to show up as useful on average.
Some of the more flippant sounding ones could be useless but I thought the idea of the simpler ones (how many golf balls etc.) is to get a feeling for how people's minds work and whether they can make sensible best guesses in the abscence of concrete facts and make judgements based on those guesses. Weed out the ones who have no appreciation for how the volume of a golf ball relates to the size of a bus.
Good logical thinking shown here could indicate an ability to rapidly prototype systems without getting hung up on too fine detail.
On the other hand, demonstrating evidence for being able to rapidly prototype systems without getting hung up on too fine detail also indicates an ability to rapidly prototype systems without getting hung up on too fine detail. And it does it much more directly (i.e. there is an obvious link rather than a tenuous at best one) and with much less stress, awkwardness and mind games.
[+] [-] edent|12 years ago|reply
Fascinating use of "Big Data" to cut through the bullshit. Wonder if it will change anything. I suspect the "tough" interview plays well into a company's PR.
[+] [-] hkmurakami|12 years ago|reply
from: "The trick Max Levchin used to hire the best engineers at PayPal"
Levchin realized the best engineers wanted to be challenged both in their jobs and in the interview process. “We cultivated a very public culture of being incredibly hard to get in. Even though it was actually very hard to get good people to even interview, we made a point of broadcasting that it's incredibly hard to even so much as get into the door at PayPal. You have to be IQ of 190 to begin with, and then you have to be an amazing coder, and then five other requirements. The really, really smart people looked at it and said, "That's a challenge. I'm going to go interview there just to prove to these suckers that I'm better." Of course, by end of the conversation, I'm like, "Maybe you want to come get a job here because you're pretty amazing.”
http://firstround.com/article/the-trick-max-levchin-used-to-...
[+] [-] rdouble|12 years ago|reply
Seems like it would fit into a normal database. Or maybe even an unwieldy Excel spreadsheet.
[+] [-] eliben|12 years ago|reply
I realize that reporters like to throw buzzwords into anything to cater to the "simpler" readers. But come one, this is outright silly.
[+] [-] killermonkeys|12 years ago|reply
"Monopoly" is a perfect example of a brain teaser and anyone using that would be treated pretty harshly by the committee that reviews interview feedback. Estimate questions are not: there's no expectation of a "right answer" and the important fact is the working.
Some programming questions border on brain teasers to non programmers but that doesn't matter because you are asking programmers and again, it's the working that matters.
Finally different roles get different types of interviews. I worked in PM and there were analytical (these questions), product (design a better x) and technical (basic engineering interviews). The behavioral type was not one I encountered in PM or eng but maybe used elsewhere.
[+] [-] goblin89|12 years ago|reply
[+] [-] silverlake|12 years ago|reply
[+] [-] Alex3917|12 years ago|reply
http://www.nytimes.com/2007/01/03/technology/03google.html?e...
Which there have already been a few HN discussions about:
https://www.google.com/search?client=safari&hl=en&ei=ZfzCUYa...
[+] [-] donohoe|12 years ago|reply
[+] [-] Jabbles|12 years ago|reply
For instance - "how many hard drives does Gmail need?" requires a rough guess of how many users Gmail has (if you're interviewing at Google, you should know it's 1e8-1e9). How much space each one takes (probably nowhere near a gigabyte on average - let's say 1e8 bytes). And that the current capacity of hard drives is (1e12 bytes).
Then you can say that they probably need 1e5 hard drives, link it to redundancy, availability, deduplication, backups etc. You can comment that it's feasible to build a datacenter with that many hard drives.
No one cares that the actual number is 12,722 - but you've demonstrated a broad set of knowledge about the current state of technology. Saying "dunno - a billion?" is not going to get you anywhere, and with good reason.
The Monopoly question is crap, though.
I'd like to know how useful http://google-tale.blogspot.com/2008/07/google-billboard-puz... was.
[+] [-] fishtoaster|12 years ago|reply
However, I used to ask one estimation question (How many hours have you spent coding over the course of your life) on all my interviews. Over time, I lost interest in it because almost everyone got it "right" (took an acceptable route and arrived at a reasonable estimate). The only people that got it wrong were ones I decided to reject for other reasons (this being a semi-technical but mostly ask-about-experience phone interview).
So, although I agree it's a useful skill, I don't think it's worth askin estimation questions from my personal experience.
[+] [-] rayiner|12 years ago|reply
[+] [-] nawitus|12 years ago|reply
Why? Is the interview a trivia exam like in college?
[+] [-] bcgraham|12 years ago|reply
Not sure if you were referencing this bit from comedian Pat Brice, but here's a relevant video: http://www.youtube.com/watch?v=J2nrKdECSGU
[+] [-] pavanred|12 years ago|reply
[+] [-] tomlu|12 years ago|reply
[+] [-] sliverstorm|12 years ago|reply
[+] [-] rorrr2|12 years ago|reply
These estimates are completely useless in real life, because in real life nobody guesses how many drives you need for GMail, or how many gas stations there are in LA.
[+] [-] moron4hire|12 years ago|reply
And these things are important, because job candidates are not people, they are OEM replacement parts being order from Pep Boys. Call up the recruiter and requisition a J6-252: Programmer, seasoned 5 years, with degree from MIT. Oh, those ones are too expensive. Guess I'll take the knock-off version, but I refuse to pay full price!
Hopefully, because it's Google saying it, everyone will cargo-cult on this bandwagon too.
[+] [-] tokenadult|12 years ago|reply
Long before this was reported in the New York Times, this was the finding of research in industrial and organizational psychology. A valid hiring procedure is a procedure that actually finds better workers than some different procedure, not a hiring procedure that some interviewer can make up a rationale for because it seems logical to the interviewer. We have been discussing home-brew trick interview questions here on Hacker News for more than a year now.
https://news.ycombinator.com/item?id=4879803
Brain-teaser or life-of-the-mind interview questions do nothing but stroke the ego of the interviewer, without doing anything to identify job applicants who will do a good job. The FAQ on company hiring procedures at the Hacker News discussion linked here provides many more details about this.
[+] [-] tokenadult|12 years ago|reply
http://ycombinator.com/newsguidelines.html
(I mention this because many comments in this thread will be very confusing to newcomers if it is not made clear that the thread used to point to Quartz but now points to the New York Times.)
[+] [-] donohoe|12 years ago|reply
Lets be clear, there is link-spam and then there is writing an original piece based on information from elsewhere.
The NYT article is about 8 questions and answers from a HR person at Google.
The "puzzle" aspect is 1 of those 8 questions.
From that Quartz references that, links directly to the piece and then expands upon it and links out to other relevant and related information.
[+] [-] renegadedev|12 years ago|reply
A similar equivalent in coding interviews would be "what does obscure function/feature do?"
[+] [-] Udo|12 years ago|reply
The problem with trick questions and standardized answers is that the nature of the question makes the candidate uneasy and even if they eventually figure it out, nobody will have learned anything during the process. It's more like a hazing, not a hiring interview.
[+] [-] raldi|12 years ago|reply
There must be thousands of people on HN who interviewed at Google over the years. Did anyone ever get a question like this?
[+] [-] litewulf|12 years ago|reply
There are many posts online about the actual, CS-y questions that you can expect in a Google interview, I had just assumed that the mentions of brainteasers were merely urban legend.
[+] [-] inopinatus|12 years ago|reply
Ever since, whenever I've interviewed someone, I ask them to demonstrate their strengths to me first.
[+] [-] objclxt|12 years ago|reply
[+] [-] bane|12 years ago|reply
I had fun and wouldn't mind it again, it didn't feel like a bunch of stupid random brain teasers like I've experienced before (how many t-shirts would it take to make sea worthy sail? why are manholes round?) etc.
[+] [-] mikestew|12 years ago|reply
Interesting; when I interviewed for a management position (test manager) it was nothing but coding questions, including the infamous "reverse a string" question. ("Would like that optimized for space or speed? In-place, or do I get a buffer? Can you tell I've heard this a zillion times before?") I can understand wanting a test manager to be more than an empty suit, but yoiks.
[+] [-] freework|12 years ago|reply
Anyways, there was one part in the movie where they start talking about auditions. All four or five of the actors they were interviewing for the movie unanimously spoke badly about the typical audition process. Some quotes taken from memory:
"I love acting, but I hate auditioning"
"You've seen my demo reel, you've seen me when I was on Star Trek, you know I can act, then why not just give me the part? Why make me go through this tedious audition process"
"90% of acting is reacting. You can't fully demonstrate your full acting abilities when you're standing in front of a panel of producers 'acting' out a scene that consists of 5 lines of dialog"
What the actors were saying about how they hate the audition process reminded me a lot of my frustrations surrounding hiring during tech interviews. Making an engineer do puzzles like FizzBuzz is a lot like making an actor act out a 20 second scene without any time to prepare or a proper "scene partner" to act alongside of.
I wish I could like to a youtube of the movie, but I can't find one. Its on netflix though.
[+] [-] tbrownaw|12 years ago|reply
FizzBuzz is self-contained tho, so maybe a better comparison would be to asking for a dramatic poetry reading?
[+] [-] sergiosgc|12 years ago|reply
It's hard, when using problems that are common, to really understand how the candidates gets to the answer. Often, he's building on pre solved sub problems he encountered on his professional life, so the resolution process didn't even occur at the interview.
I personally don't use brain teasers, because they stress out valid candidates who do not work well under pressure. However, I think teasers, when properly used, are valid tools in an interviewers toolbox.
[+] [-] dasil003|12 years ago|reply
This has the potential to reveal a certain high level problem solving ability which the lack thereof will not necessarily be revealed by more concrete "write pseudocode for X" type of interview questions. What I mean by that is that there is a continuum of skills ranging from rote copying of solutions all the way through synthesizing solutions to business problems and designing architectures to fulfill a malleable list of requirements. A mediocre engineer can inch their way up the continuum through raw pattern matching ability (which humans excel at) without ever attaining mastery of the high level abstraction that are driving the implementation detail. Such engineers can appear tremendously productive at the ground level, but they are dangerous for an technical organization to have many of them because they tend not to see where technical debt is piling up and can often paint themselves into corners because they're not considering the bigger picture. Knowing someone has strong reasoning skills from very high level human tasks down is a good hedge against this.
[+] [-] nchlswu|12 years ago|reply
The comment about brainteasers vs structured rubrics is sort of surprising to me, given Google's reputation for quantitative data. Speaking from a very high level, structure was really what was emphasized for interviews. It's interesting how culture can get in the way of proven 'fact,' and I love that Google is using their own (much larger data sets) to make these improvements and in/validate other research
[+] [-] jmillikin|12 years ago|reply
1. Invent a bunch of silly riddles that a non-technical reader might accept as tech interview questions.
2. Pull a major tech company out of a hat (today it's Google), and claim with no evidence that their interviews are based around silly riddles. The article will be cited for years as proof that people working at $COMPANY are weird and obtuse.
3. Wait a couple years. Ignore all evidence that $COMPANY does not use silly riddles in interviews.
4. Once traffic on the original article dies down, write another article claiming $COMPANY has "admitted" silly riddles aren't useful for interviews.
[+] [-] pathy|12 years ago|reply
http://www.nytimes.com/2013/06/20/business/in-head-hunting-b...
That said, the riddles listed are of course a bit clickbaity but they did not conjure the story out of thin air.
[+] [-] ShabbyDoo|12 years ago|reply
I like estimation questions in general for many of the reasons other commenters have cited. However, I wish those using them would consider the knowledge implicitly required of a candidate.
[+] [-] cousin_it|12 years ago|reply
Can we see the study?
Also note that performance on the job is a noisy measurement, because people who get to work on impactful projects (through luck or people skills) get rated higher than others. I wouldn't be surprised if interview scores were a better measurement of "true" skills.
[+] [-] jasonwocky|12 years ago|reply
Possibly, but in a sense "true" skills don't really matter. What matters to Google, ultimately, is Google's opinion of the worker. It's almost certainly skewed / flawed / distorted in some way from the individual's true skills, and that's unfortunate but mostly a fact of life.
[+] [-] lobotryas|12 years ago|reply
[+] [-] objclxt|12 years ago|reply
For example, write a program to find every possible word in a given Boggle board is a puzzle, but one you're going to solve by coding...rather than "how many piano tuners are there in New York", which is a rather different matter. I've interviewed on-site with Google several times, and always found the CS puzzles to be challenging but fair.
[+] [-] darrellsilver|12 years ago|reply
We used it to build our hiring process for http://www.thinkful.com/ and it consistently proves valuable.
We also use it to help our students prepare for job interviews.
[+] [-] dpritchett|12 years ago|reply
Have you gathered much data on the success of this book's approach in your firm? I'd love to hear a positive take on it.
[+] [-] mgkimsal|12 years ago|reply
I had a couple questions like this at a couple of interviews more than a few years back now. In both cases, I sat for a minute, and asked a few questions back, like "do you mean the city limits of Raleigh, or the metro area?", "how do you define gas station - do we include public-only, or private fueling places?", etc. Part of this was buying some time, because the question caught me off guard, but I think my questions back caught him off guard a bit too.
That interviewer told me I was the only person who asked clarifying questions before blurting out an answer or walk through. Another one was "take this marker and design a house on the whiteboard for me". So I took the marker and asked questions like "how many people will live here, do you want one or two story, do you need a garage/shed/basement, etc?" And again, was told I was the only person who'd asked questions before starting to draw.
I don't think the intention behind those brain teasers was necessarily to determine how you react to those sorts of problems, but it may have been a useful determining factor for some interviewers nonetheless.
[+] [-] jacques_chester|12 years ago|reply
I once got negative feedback from an interviewer: I'd asked too many questions about the questions.
[+] [-] troni|12 years ago|reply
[+] [-] troymc|12 years ago|reply
http://en.wikipedia.org/wiki/Fermi_problem
Knowing how to quickly estimate something is useful.
I imagine that Larry Page does a few quick estimates every day. How many Loon balloons would it take to bring Internet to 90% of Africa?
But not everybody at Google has a job like Larry Page. It's gotten to be a big company full of accountants, HR people, and other jobs that don't require much thinking in unfamiliar territory.
In other words, guesstimation is a useful skill, but not for every Google employee, so it's not going to show up as useful on average.
[+] [-] tonylemesmer|12 years ago|reply
Good logical thinking shown here could indicate an ability to rapidly prototype systems without getting hung up on too fine detail.
[+] [-] bengillies|12 years ago|reply