Why "I'd Google it" is not an acceptable Interview Answer(softwareplusplus.wordpress.com)
softwareplusplus.wordpress.com
Why "I'd Google it" is not an acceptable Interview Answer
http://softwareplusplus.wordpress.com/2009/05/15/why-id-just-google-it-is-not-an-acceptable-interview-answer/
36 comments
Maybe one that can be answered by 5 minutes of Googling is not an acceptable interview question.
It really depends on the question.
From the article: "what is a class?" can easily be answered as a definition from a Google search, but that definition doesn't help you write a class, use a class, etc. Similarly, you can search for a definition of a join, but if you can't come up with an answer off the top of your head, you don't have the skill to use a join.
This is different from, say, being asked what the "succ" method of the Ruby Integer class does. Or, the preg_replace in PHP takes 5 parameters, which position do you place the subject string in?
Those are two different types of questions. The first paragraph has questions about key computer science/database topics that, if you don't know, it will take learning and mastery to use them in a practical application. The second paragraph has questions of an arbitrary nature - knowing argument order in one language doesn't prove you understand regular expressions nor does knowing what a somewhat ambiguously named method does - especially a method that is also called "next" and can be accomplished as "var += 1" both of which seem clearer.
But there definitely are some things that can be answered by searching that don't necessarily mean that the person has a mastery of the topic that would be required to actually use the definition. Now, the second set of questions might be a clue that this isn't a good place to work since they emphasize random knowledge that doesn't actually prove any competency, but that's another story.
From the article: "what is a class?" can easily be answered as a definition from a Google search, but that definition doesn't help you write a class, use a class, etc. Similarly, you can search for a definition of a join, but if you can't come up with an answer off the top of your head, you don't have the skill to use a join.
This is different from, say, being asked what the "succ" method of the Ruby Integer class does. Or, the preg_replace in PHP takes 5 parameters, which position do you place the subject string in?
Those are two different types of questions. The first paragraph has questions about key computer science/database topics that, if you don't know, it will take learning and mastery to use them in a practical application. The second paragraph has questions of an arbitrary nature - knowing argument order in one language doesn't prove you understand regular expressions nor does knowing what a somewhat ambiguously named method does - especially a method that is also called "next" and can be accomplished as "var += 1" both of which seem clearer.
But there definitely are some things that can be answered by searching that don't necessarily mean that the person has a mastery of the topic that would be required to actually use the definition. Now, the second set of questions might be a clue that this isn't a good place to work since they emphasize random knowledge that doesn't actually prove any competency, but that's another story.
Yeah, if you don't know what a class is and is applying for a OO programming job you don't qualify, and it's not OK to look it up on the job. That's basically what the article is saying.
But at least googling for answers to inane questions is better than going directly to asking your fellow coworkers. RTFM!!!
But at least googling for answers to inane questions is better than going directly to asking your fellow coworkers. RTFM!!!
I would say that there are at least two reasons, in addition to those in the article, why a Googlable question is still a good question.
1. Internal memory is a pretty good predictor of sincere interest in a subject. Ever notice how baseball fans know every stat of every player? They don't spend hours rote-memorizing tables; their passion for the sport induces remembering facts about it.
2. Interview answers reveal how you problem-solve as well as what you know. Saying "I'd Google it" indicates to me at least that you go for the fastest method of solving the problem. Better would be "I don't know, but I'd look it up in a textbook on X" or something, which reveals a willingness to take the time to learn something in depth rather than just copy-paste someone else's code.
1. Internal memory is a pretty good predictor of sincere interest in a subject. Ever notice how baseball fans know every stat of every player? They don't spend hours rote-memorizing tables; their passion for the sport induces remembering facts about it.
2. Interview answers reveal how you problem-solve as well as what you know. Saying "I'd Google it" indicates to me at least that you go for the fastest method of solving the problem. Better would be "I don't know, but I'd look it up in a textbook on X" or something, which reveals a willingness to take the time to learn something in depth rather than just copy-paste someone else's code.
There's a half-way point: where I remember broadly how to do something, but I need to use my outboard brain to find the details. That's frustrating to introduce in an interview, though: "oh yes, I remember that... I'm sure I could find it again in a second...".
What's that joke about my brain being a L2 cache of Wikipedia? :)
What's that joke about my brain being a L2 cache of Wikipedia? :)
I generally ask interview questions which attempt to expose how a candidate thinks through a problem. And, I often tell them that they aren't being given enough information, so they should ask me relevant questions. Am I The Google?
In contrast, if I see a resume with a few years of experience writing Java code (working full-time on 90%+ Java systems), then I think it's reasonable to discuss the specifics of the language/platform. If you've supposedly been writing Java code for a few years and you can't tell me how exceptions work, then you're a moron or a liar.
In contrast, if I see a resume with a few years of experience writing Java code (working full-time on 90%+ Java systems), then I think it's reasonable to discuss the specifics of the language/platform. If you've supposedly been writing Java code for a few years and you can't tell me how exceptions work, then you're a moron or a liar.
I absolutely agree - if I'm trying to gauge whether an applicant really knows as much as they think they know, I would ask questions where the interviewee might think "google it" is acceptable, but that would make me trash the application.
For example, if someone rates themselves as 7 out of 10 on java, they better be able to come up with a handful of functions on Object that are useful to override, or walk through the rough call sequence to query a database using jdbc. And that should all be from memory.
Maybe that's unfair on my part, but I feel like it does a lot to filter for people who can actually walk the walk.
For example, if someone rates themselves as 7 out of 10 on java, they better be able to come up with a handful of functions on Object that are useful to override, or walk through the rough call sequence to query a database using jdbc. And that should all be from memory.
Maybe that's unfair on my part, but I feel like it does a lot to filter for people who can actually walk the walk.
Coming up with an answer on Google is not the same as knowing the answer. Sure I can look up what a class is and give you a reasonable answer, but if I knew anything about code (I don't) I would be able to give you an instant and satisfactory response.
Interview questions aren't always about what the answer is, but how you answer it.
Interview questions aren't always about what the answer is, but how you answer it.
Such as questions about the Java API. Can YOU open and search a text document in Java without looking anything up?
Here's the summary of the article:
All else being equal it's better to know the answer than to have to look it up. Also, the author of the article is going to assume all kinds of things about you
All else being equal it's better to know the answer than to have to look it up. Also, the author of the article is going to assume all kinds of things about you
I don't really think that captures what I was saying in the article. This quote is a little more representative of the overall message:
"On the job, the goal is to solve problems and get things done using any tool at your disposal. At the interview, the goal is to demonstrate why they should hire you instead of one of the other candidates who also have access to Google... A job interview is a competition, not a pass-fail test"
As for the comment that I am going to assume all kinds of things. Of course I am and so will other managers. We are all human and make assumptions all the time, often subconsciously. My point was just that it is in the candidate's best interest to recognize what you may be communicating by deferring to Google.
Getting mad about it doesn't help you get the job, so there is no sense in that. The intent of the article was to HELP candidates put their best foot forward with the benefit of some inside information from the other side of the interview table.
"On the job, the goal is to solve problems and get things done using any tool at your disposal. At the interview, the goal is to demonstrate why they should hire you instead of one of the other candidates who also have access to Google... A job interview is a competition, not a pass-fail test"
As for the comment that I am going to assume all kinds of things. Of course I am and so will other managers. We are all human and make assumptions all the time, often subconsciously. My point was just that it is in the candidate's best interest to recognize what you may be communicating by deferring to Google.
Getting mad about it doesn't help you get the job, so there is no sense in that. The intent of the article was to HELP candidates put their best foot forward with the benefit of some inside information from the other side of the interview table.
>A job interview is a competition, not a pass-fail test"
Yes, that's what it really means - "all else being equal during competition, remembering things will get you ahead".
The problem I have with you article is that all else is not equal. This could only work if you have an excess of qualified engineers. I have tons of anecdotal data about severe draught of qualified engieneers and none on the surplus, across Microsoft, Google, Amazon and funded Seattle startups. I am yet to see any data on actual competition, so your position does not pass the "inituition" test for me.
Are things that much different in the valley? It can't be, some of my data comes from people getting offers to move to the Valley.
>As for the comment that I am going to assume all kinds of things. Of course I am and so will other managers.
I think you are projecting.
Yes, that's what it really means - "all else being equal during competition, remembering things will get you ahead".
The problem I have with you article is that all else is not equal. This could only work if you have an excess of qualified engineers. I have tons of anecdotal data about severe draught of qualified engieneers and none on the surplus, across Microsoft, Google, Amazon and funded Seattle startups. I am yet to see any data on actual competition, so your position does not pass the "inituition" test for me.
Are things that much different in the valley? It can't be, some of my data comes from people getting offers to move to the Valley.
>As for the comment that I am going to assume all kinds of things. Of course I am and so will other managers.
I think you are projecting.
More to the point: "I’d just Google it." = "I don’t know."
It used to be that this was a valid interview tactic - asking people hard/obscure stuff and seeing if you could get them to admit they didn't know, then get them to explain where they'd go to find out. It used to be that there were many different places to go to find disparate bits of technical know-how, each specific to the task in hand. It used to be that knowing how to find out was a valuable skill, required of any developer - every developer looks stuff up, no-one can know everything.
This has changed a lot over the last few years - now the answer to all of that is basically just 'Google it.'. The only value left in this interview tactic is to probe the depth/breadth of the candidates knowledge and to see how they respond when they get to the end of it, in an interview/pressured situation. It's a good sign when they calmly admit they don't know and suggest sensible strategies for finding out. It is, however, a terrible sign if their domain knowledge stops before you get to 'What's a class?' - you really need to know the important stuff, end of story.
I'm always shocked by the number of candidates that I've intervied who get weeded out by questions like that.
This has changed a lot over the last few years - now the answer to all of that is basically just 'Google it.'. The only value left in this interview tactic is to probe the depth/breadth of the candidates knowledge and to see how they respond when they get to the end of it, in an interview/pressured situation. It's a good sign when they calmly admit they don't know and suggest sensible strategies for finding out. It is, however, a terrible sign if their domain knowledge stops before you get to 'What's a class?' - you really need to know the important stuff, end of story.
I'm always shocked by the number of candidates that I've intervied who get weeded out by questions like that.
In my youth (which was like...1 or 2 years ago) I used the far more naive "I'm not sure" or "I don't know" instead of "I'd Google it", and responded to the follow-up "So how would you find out?" question with some vague account of my research method (which included Google).
It turns out that a lot of problems require far more specific researching skills, say, if you're writing code to automate some type of proprietary system that Google knows nothing about. How do I automate a functional test? I talk to the people who run the test manually. How do I learn how to do this and that with a given box? I talk to the engineers who designed it.
"I'd google it" is the wrong, right answer. It's the right answer because you should have some ability to research things you don't know. It's wrong because there's no way Google will teach you what you need to know. Sometimes you need to read a book or make an appointment with an engineer in the other building, or run controlled experiments.
It turns out that a lot of problems require far more specific researching skills, say, if you're writing code to automate some type of proprietary system that Google knows nothing about. How do I automate a functional test? I talk to the people who run the test manually. How do I learn how to do this and that with a given box? I talk to the engineers who designed it.
"I'd google it" is the wrong, right answer. It's the right answer because you should have some ability to research things you don't know. It's wrong because there's no way Google will teach you what you need to know. Sometimes you need to read a book or make an appointment with an engineer in the other building, or run controlled experiments.
When I have received the "I'd Google it" response to a question in an interview I would the ask for the search terms, enter the query and discussed the result.
Agreed. I think it's up to the interviewer to redirect the responses towards something more meaningful. For example, "what criteria would you use to evaluate what you find on Google?" Or "how would you determine if the information was up to date/accurate/etc.?" I've found that a person might jump to the "I'd Google it" answer but still have a good knowledge of the problem domain.
All true, but unless you already know enough about that topic to know where to look then you need to start with a general search on that topic. Google is often a very good place to start to find out where to go next, even if that next involves books, experts, or even original research.
(To your last paragraph) Or, more generally, "I'd do research on it."
It really does depend on the question. A lot of interview time, particularly on phone screens, is "Does this person's resume reflect reality?" That's where "What's a class?" and "How do you do a join in SQL?" come from, and if the candidate can't easily answer, their resume is bloated, game over. Google it is a bad answer.
Also realize that even though you consider something to be trivia, your interviewer doesn't or the question wouldn't be asked. Saying, "I'd just google it" is dismissive, and people don't like being dismissed.
What you can do is invoke Google techniques as part of a larger problem. Like, "I forget the order of arguments to this function, but that's on Google, can you tell me if I got it right?" When the point of the question isn't the trivia, but the approach.
Also realize that even though you consider something to be trivia, your interviewer doesn't or the question wouldn't be asked. Saying, "I'd just google it" is dismissive, and people don't like being dismissed.
What you can do is invoke Google techniques as part of a larger problem. Like, "I forget the order of arguments to this function, but that's on Google, can you tell me if I got it right?" When the point of the question isn't the trivia, but the approach.
"I don't need to know the answer," he growled "if I know where to find the answer." - Henry Ford
This article comes to my mind:
http://www.systems-thinking.org/dikw/dikw.htm
It summarizes a model of possible levels of "knowledge", making a distinction of Data, Information, Knowledge, Understanding and Wisdom.
So in this context:
It summarizes a model of possible levels of "knowledge", making a distinction of Data, Information, Knowledge, Understanding and Wisdom.
So in this context:
API -> Information
SQL join, class, OO paradigm -> Understanding
Work experience -> Wisdom
I didn't realize people thought it was an acceptable answer, I just thought it was something people said afterwards (as in, "Can you believe he asked me about the fourth argument to the foo function? In real life I'd have just Googled it"). It's almost an insult to the interviewer (Of course I don't know the answer, you shouldn't have expected me to).
As an aside, I hope people don't mean this literally. If I wanted to know what the fourth parameter to function foo is, I have quick access to my language's reference manual, and I look in there. I don't just pop it into Google and hope whatever comes up is right.
As an aside, I hope people don't mean this literally. If I wanted to know what the fourth parameter to function foo is, I have quick access to my language's reference manual, and I look in there. I don't just pop it into Google and hope whatever comes up is right.
You can always make it sound like a plan of action: "I don't remember/know off the top of my head, but I will after 5 minutes with Google". (Provided that it's one of those ultra-specific questions that have nothing to do with the actual job).
Personally, I wouldn't worry too much, since chances are that no one else actually gets these questions right anyways.
Personally, I wouldn't worry too much, since chances are that no one else actually gets these questions right anyways.
He argues that a job interview is a different situation than being at work with access to google because it's 'a competition'. If he likes to select people on things unrelated to the job, why not ask them to sing and dance too?
Go ahead and pretend a job interview is not a competition. I hope that works out for you.
Also, you seem to imply that I favor asking questions unrelated to the job when my article says exactly the opposite, that I despise those questions and only resort to them when I have two candidates who are running neck and neck and I need a tiebreaker.
Also, you seem to imply that I favor asking questions unrelated to the job when my article says exactly the opposite, that I despise those questions and only resort to them when I have two candidates who are running neck and neck and I need a tiebreaker.
Google is a tool every job should allow you to use.
Google for me is like an extension to my brain which doesn't have much more available free space.
So, yes, "I'll google it" IS a valid answer.
Google for me is like an extension to my brain which doesn't have much more available free space.
So, yes, "I'll google it" IS a valid answer.
I think you might want to re-read the article because you seem to be mischaracterizing the point. That point is: Yes Google is a critical tool to do your job, but it doesn't differentiate you from other candidates when interviewing so it is a worthless answer in that context.
Of course not, the appropriate answer is:
"I'll just Bing it!"
"I'll just Bing it!"
Yeah Bing that shit dude!
I know that we want to keep HN focused, but is all humor going to be down voted from now on?
Some things are simple enough you can (re)learn in 5 minutes with google. Others aren't. Knowing which is which is a good skill. Trashing Google in all cases equally is wrong.