"I'd google it" is a terrible answer to some questions, e.g. stuff people ought to know like what recursion is. It's a great answer to other questions, e.g. stuff not worth remembering (like API details you use infrequently).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 believe a job interview should mainly focus on evaluating the candidate's Knowledge and Understanding, not on Data or Information.
One can argue that by using Google long enough, it is possible to reach the upper levels, but that comes at a price (you would need a lot of time).
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.
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.
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.
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.
[+] [-] xenophanes|17 years ago|reply
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.
[+] [-] jerryji|17 years ago|reply
[+] [-] mdasen|17 years ago|reply
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.
[+] [-] cduan|17 years ago|reply
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.
[+] [-] ShabbyDoo|17 years ago|reply
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.
[+] [-] ABrandt|17 years ago|reply
Interview questions aren't always about what the answer is, but how you answer it.
[+] [-] jacoblyles|17 years ago|reply
[+] [-] DenisM|17 years ago|reply
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
[+] [-] JohnFuex|17 years ago|reply
"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.
[+] [-] jcl|17 years ago|reply
[+] [-] dflock|17 years ago|reply
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.
[+] [-] philwelch|17 years ago|reply
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.
[+] [-] troystribling|17 years ago|reply
[+] [-] timwiseman|17 years ago|reply
[+] [-] derefr|17 years ago|reply
[+] [-] Kirby|17 years ago|reply
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.
[+] [-] Gibbon|17 years ago|reply
[+] [-] gurtwo|17 years ago|reply
It summarizes a model of possible levels of "knowledge", making a distinction of Data, Information, Knowledge, Understanding and Wisdom.
So in this context:
I believe a job interview should mainly focus on evaluating the candidate's Knowledge and Understanding, not on Data or Information. One can argue that by using Google long enough, it is possible to reach the upper levels, but that comes at a price (you would need a lot of time).[+] [-] maweaver|17 years ago|reply
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.
[+] [-] lhorie|17 years ago|reply
Personally, I wouldn't worry too much, since chances are that no one else actually gets these questions right anyways.
[+] [-] zupatol|17 years ago|reply
[+] [-] JohnFuex|17 years ago|reply
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.
[+] [-] TweedHeads|17 years ago|reply
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.
[+] [-] JohnFuex|17 years ago|reply
[+] [-] viggity|17 years ago|reply
"I'll just Bing it!"
[+] [-] foppr|17 years ago|reply
[+] [-] viggity|17 years ago|reply