In the scenario you described, I might try something like this: "I think I see what you're trying to measure by asking that question, but it assumes a working style that is foreign to me. So that you can get a better reading of what I can really do, would you mind if we used my laptop, with you looking over my shoulder, as I solved a problem of similar difficulty?"
An interview is a negotiation. If you want to change it, just ask. Most interviewers will be happy to agree to any changes that will help them get a better read on your true abilities.
If I'm interviewing you, it means that we already think you are worth talking to. I don't want to waste either my time or yours. If what I'm asking you to do makes you uncomfortable, TELL ME! I can think of the last two people I interviewed who gave me a series of immediate "I don't know..." answers to a bunch of questions. They're happily (I hope!) working here now because we changed the interviews to go down productive paths to find out what they do know instead of beating our heads against a wall!
In a given interview, sure, he's hoping that he can hire that person, but how many people get interviewed before the position is filled? I'm certain the average is much higher than one.
No matter how much anxiety he might have, he's doesn't have to worry about stuff like paying rent, keeping his car in working order, or feeding his family, because he already has a job.
Not really - some interviewers may not get that an interview goes both ways, but it really is very much symmetrical. For me at least an interview is the perfect chance to evaluate a company and until now I've declined about 3 job offers simply because I didn't like the conversations I've had with the people doing the interviewing.
New (inexperienced) hires are also more likely to feel the bottom side of asymmetry, which can counteract the effect for the youngest.
So yes it is, and no it isn't, depending on the candidate and on the company.
But the interview process is such a time suck (not to mention that you have to nick out on your regular job which you can only do so many times for a half a day before they get wise) that by the time you are walking into an office for an interview, you've already made a non-trivial commitment. You can only repeat it a handful of times (assuming you have another job or are otherwise professionally engaged) before it becomes a real burden.
Now, if you are unemployed and you have a substantial financial cushion or can pick up enough 'anytime/anyplace' freelance work, sure, interview with 5 companies a week, take your time and be picky. But how many job seekers are in such an ideal position?
Business theater continues despite evidence it doesn't work. [1] Consider this a signal everything else is broken too. Notice their signals to show you are more than a technical automata to "fill a process void in the value chain".
The best interviews are as casual as possible, and not called interviews.
Good interview process looks like:
- 2 phone screens (recruiter||hr and then hiring manager && closest cowoker, if any)
- webcam screen
- a couple on-sites that may lead to:
- questions about what they've been working on, what's important to them, their career development goals and eventual desired package (that's basically it)
- take someone out to lunch
- play a sport with them [2]
- work on a current problem
- have an adventure
(very important for hiring manager and coworkers to have a say; placing staff under a manager is fail.)
Skip the:
- behavioral questions
Before hiring someone on a temporary project basis. Full time in a reasonable amount of time (average 6 months), or part time if that works better for them. This way, it's cool to feel each other out in the non-creepy professional way and there's no hurt feelings.
[1] http://www.techrepublic.com/blog/career/google-admits-bizarr...
[2] I hate all sports, except Scrumball and World Cup.
Obviously this is predicated on the dev job market being as good as it is, but still. I can just go elsewhere.
Now, it could be that the employer is desirable because they provide a lot of perks that you don't really care about, in which case it's perfectly legit to eschew those perks and interview elsewhere. But oftentimes it's because they provide a bunch of tangible benefits that you do care about. Interesting work. Lots of money. Professional reputation that you can then use to increase your desirability to other employers.
It's usually a good career move to take a job at a place where you have a weak negotiating standpoint, work like hell to learn all the skills you can there, and then use professional reputation gained there to increase your negotiating position with other employers. That requires taking a "one-down" position sometimes and hoping that you get lucky and they like you.
Or, as some folks here are fond of saying, "If you're the smartest person in the room, it's time to find a new room."
Given two options, one out of my comfort zone and one in my comfort zone, I chose to be comfortable.
I realized that the value I add is not being able to complete tasks. The true value I add comes in looking beyond the task and figuring out how to address larger problems.
I've noticed in the past that when I continually don't know what I'm doing, I miss out on opportunities to really add value. While I'm able to figure stuff out and get the assigned task done, at best I come across as competent.
It was a great choice. There are still ample opportunities to learn. At the same time, I feel like I have time and mental capacity (freed up by not continually playing catch up with the team) to find and explore new ideas and improvement.
So when people say "Don't be the smartest person in the room" I would say it is also important to not put yourself in a situation you can barely handle. Having some breathing room will make you better at your job and make you far less stressed out.
So, if you ever find yourself in an interview about to go the wrong way, ask.
Nevertheless the interviewer asked me to write it down on paper (using python). I've done so, but made a few mistakes. I still got the job offer, so the mistakes weren't a factor. I just wanted to point out that some interviewers are really set in their ways and don't change their minds.
[1] http://googleresearch.blogspot.com/2006/06/extra-extra-read-...
I think this is an important consideration. I do interviews quite often at my current company. And two steps of the interview process is a technical phone interview and a technical on-site interview.
I always ask coding questions, but before I start, I clearly tell the guys that they can use any language they want, and that I do not expect the program to "compile" or parse (in case of interpreted languages). What I always try to read is 1) that the person is not completely lost about programming, 2) What is his approach to solving the problem, and that he can explain it to me.
The problem I have with technical interviews (I also have always hated them when I've been in the interviewee sit), is when interviewers setup an "all or nothing" style. Usually it is because they were told to interview you, but they really don't know to do an interview, so they just read a bunch of problems to you and wait for you to solve them... without trying to read anything from the process.
I also like the idea of asking the person to give a presentation. Give them an amount of time, to include questions, and they choose the topic. I don't think that works with everybody, so I'd never mandate it, but a lot of people really thrive in that situation. You get to talk about something you know, demonstrate your passion, and so on. The down side is that it can entail a big time commitment from the person.
Probably good advice but most programmers I know including me are terrible negotiators which is why at least I work for the man instead of being a rich entrepreneur with that house at 3000 Ft overlooking the ocean with an unobstructed view.
That said, whiteboards are still usually better for conveying ideas. If you don't understand the problem you're trying to solve or the data structures you need, you might want to start on the board before sitting down to code.
