If I could ask only one job interview question(asserttrue.blogspot.com)
asserttrue.blogspot.com
If I could ask only one job interview question
http://asserttrue.blogspot.com/2009/05/if-i-could-ask-only-one-job-interview.html
12 comments
I absolutely agree with the article on this matter.
While what you're saying is 100% correct, I'm now seeing first-hand (we're dealing with a bunch of new hires at our company, and I'm the most senior developer on the floor) the reasons behind this.
The biggest reason is this: 9 out of 10 hires haven't yet cultivated the art of researching for themselves (we're speaking entry level programming jobs). If you give them an easy way out, yes, they do benefit more in the programming aspect in that they now have an answer and have gained a jewel of information; but they're missing out on researching for themselves. The art of looking for an answer. Cultivation of the persistence that is required of good programmers, both in searching for and implementing any given solution.
These talents are worth more than the coding knowledge itself. The coding is propositional knowledge, but getting the solutions and doing it right is propositional knowledge and worth the wasted weeks.
While what you're saying is 100% correct, I'm now seeing first-hand (we're dealing with a bunch of new hires at our company, and I'm the most senior developer on the floor) the reasons behind this.
The biggest reason is this: 9 out of 10 hires haven't yet cultivated the art of researching for themselves (we're speaking entry level programming jobs). If you give them an easy way out, yes, they do benefit more in the programming aspect in that they now have an answer and have gained a jewel of information; but they're missing out on researching for themselves. The art of looking for an answer. Cultivation of the persistence that is required of good programmers, both in searching for and implementing any given solution.
These talents are worth more than the coding knowledge itself. The coding is propositional knowledge, but getting the solutions and doing it right is propositional knowledge and worth the wasted weeks.
Research of the sort we are talking here is easy, in that it isn't mentally challenging. Doing a google search and then sifting through all the articles does not require any skills other than patience, just as searching through a 1,000 page book to find the page you want doesn't require anything more than patience.
You don't learn anything by these actions. You learn by understanding the solution, and the sooner you can find an explanation for the solution the better, and in my opinion there is no quicker way of getting to the solution than by asking an expert.
You don't learn anything by these actions. You learn by understanding the solution, and the sooner you can find an explanation for the solution the better, and in my opinion there is no quicker way of getting to the solution than by asking an expert.
Although to a large extent I agree with you when you say "[Resaerching] talents are worth more than the coding knowledge itself.", I'm not sure you're accurately representing the author's position.
Particularly his last acceptable answer is "If you have a friend who is knowledgeable on the subject... I don't care if you bother someone outside the organization with endless questions."
What the author is interested in is not having new employees disturb old employees with questions, although having new employees understand researching is a solution, it isn't his goal.
Particularly his last acceptable answer is "If you have a friend who is knowledgeable on the subject... I don't care if you bother someone outside the organization with endless questions."
What the author is interested in is not having new employees disturb old employees with questions, although having new employees understand researching is a solution, it isn't his goal.
I believe it depends on the situation. Most cases, a little bit of research beforehand almost always helps.
When you go to the expert, you can talk about what you've found so far and how you think you should proceed. This tells the expert that he is not spoon feeding you.
It also makes the discussion more interesting since you are coming to the table with your ideas and trying to refine them using the expert's knowledge, which, I have found, is the best way of learning: finding out what an expert would do if he were in your shoes.
When you go to the expert, you can talk about what you've found so far and how you think you should proceed. This tells the expert that he is not spoon feeding you.
It also makes the discussion more interesting since you are coming to the table with your ideas and trying to refine them using the expert's knowledge, which, I have found, is the best way of learning: finding out what an expert would do if he were in your shoes.
I agree with alexkearns. Having been in both positions I would have to say that you are going to build a better team by letting them communicate with each other. IM, IRC and email are excellent tools for this, allowing you to easily decide when to answer their questions.
How is the new programmer supposed to integrate with the rest of the team if they don't ask questions? As well as the fact that Google generally sucks for programming questions these days. Your project will progress much more quickly if the newbie spends 5 minutes with a senior developer learning than 3 hours with Google sifting through answers they don't have the experience to analyze.
How is the new programmer supposed to integrate with the rest of the team if they don't ask questions? As well as the fact that Google generally sucks for programming questions these days. Your project will progress much more quickly if the newbie spends 5 minutes with a senior developer learning than 3 hours with Google sifting through answers they don't have the experience to analyze.
I only ever do ask one question in an inverview. I decsribe a simple application and then ask the candidate to design the database schema and business objects to support it. That usually takes up the time I'm given with the candidate, and tells me a ton about what techniques and technologies they've been exposed to and their maturity level working with same. I also watch for how willing they are to involve me in the process. The best team candidates have me working along side them (but then I get to toss in a few curve balls)
"Can you please teach me something?"
I only use it when I'm interested in the candidate, and the interview has progressed to the point where we're both comfortable.
I only use it when I'm interested in the candidate, and the interview has progressed to the point where we're both comfortable.
I'd ask what technical communities they are part of
OP's one question would not be my one question, which would be:
"What would be different here in one year because of your presence?"
Their approach, as well as their response, would teach me a lot about them.
"What would be different here in one year because of your presence?"
Their approach, as well as their response, would teach me a lot about them.
The key in asking someone else is to avoid the disturbance effect. Hence, email: a delayed questions & answers session.
I would ask "What are we looking for?"
A correct answer requires great insight and pretty much compels the candidate to continue and explain how they fit the description.
An expert may be able to solve an issue in seconds that a might stump a newbie for weeks. Moreover, a newbie will learn much quicker if given guidance from an expert than if left to their own devices.
I have been in both situations, learning from experts and sharing my expertise with newbies. I have always been happy to help out others and have certainly been shown the same helpfulness by people more expert than me.