It's pointless to downvote the OP as his attitude is pretty common in my experience. There are many programmers who react with disgust if you ask them anything that might be construed as beneath them... embrace that attitude, because it can help to end the interview early and prevent wasting everyone's time.
This is the truth. I've had candidates walk out of interviews when they learn that they'd be asked to write pseudo code showing some basic algorithmic competence.
Actually, I make a point of asking to see a sample of production code anywhere I interview, and have done for a while. Nowhere has ever refused, although most places have asked to wait until the following interview if not warned in advance (which is best if possible).
This has been a very enlightening practice. To date, almost 100% of the places that showed me code put me off enough that I wouldn't have accepted any offer from them. The way they wrote their code told me more about the deep-rooted problems they had than anything anyone could ever say or not say in an interview.
It was fairly obvious to all concerned that those places and I weren't a good fit, though, and most didn't make me an offer in the end anyway. But if feedback was at all honest, asking to see their code has nothing to do with that, and in fact it was more often taken as a positive sign that I was genuinely interested, which at that stage I was.
My other favourite thing to do is turn questions around. If the people interviewing me at a smaller company are supposedly the senior technical people and they're assessing my abilities during a discussion about a code snippet (mine or theirs) in the interview, then I'm going to assess theirs as well: I will use a certain level of terminology, or mention related concepts, or allude to alternative design possibilities, and watch for their reactions and where the discussion goes. In other words, I would be assessing technical interviewers just the same way that I assess a candidate from the other side of the table, and for much the same reasons.
By the way, you should never feel insulted just because someone asks you to write code at interview, no matter what your level. I used to get some mild irritation from that, but having interviewed supposedly very experienced candidates, I have found that even those with great-looking CVs can be clueless no-hires in practice. The point of the basic coding test isn't to make the really good people stand out, it's to make the really bad people stand out. Of course, if you rapidly produce a decent answer to the simple coding problem, continuing with more simple coding problems starts to say more about the interviewer/company policy than anything else, and you might reasonably question whether they are wasting your time at that point.
Why do you feel insulted if someone asks you to show for an hour that you can do what you intend to do for the next couple years? I mean - it's not like you can't do that, right?
Depends. When I interview a candidate I can say if he is a good programmer or not after talking with him for 30 minutes.
May be because I am a programmer.
And I think I am bad interviewer if I cannot do that.
Do we really TEST Lawyers, Surgeons, Cooks in an interview?
Lawyers have to learn for many years and pass exams. Then they have a record of what they actually did, along with results in public records. Same exams situation for surgeons. Cooks usually are hired based on previous jobs (the really good ones are "tested" by entering competitions / getting additional training). Simple / begginer cooks are sometimes tested on the interview.
Those occupations are nothing like being a programmer.
It's surprising how many previously-good-looking candidates cannot write, say, a simple function to walk a tree. Now, part of the problem is certainly the fact that it's harder to write code with a pen and paper or a blackboard, and you have to account for that. It can still give valuable insight.
We always ask our candidates to write code in our interviews, but is there a reason why many companies seem to do this with pen & paper, or a blackboard?
We sit them in front of a computer with various editors/IDEs and ask them to code a function/class or two there on the machine.
Isn't this better for the candidate (ie less stressful, interviews are stressful enough already) and more realistic, as they can use editor/IDE features and the compiler?
Exactly, I wouldn't mind a future employee to ask me for some code samples so as to gauge the quality of our work... After all, I've seen some code from some companies before where I'd just run away if it was my first day at work there...
The very premise of an interview is this: I see you're allegedly qualified from your résumé, but I'm skeptical. Prove you are who you say you are. This can be phrased much more tactfully, and it's great if the interviewer does so, but at some deep level every interviewee has to decide if they're comfortable with this dynamic or not. I think a technical question can raise the exact same hackles as requesting code.
If someone isn't comfortable with a complete stranger trying to validate whether they are the person described in the résumé, I suggest that they work hard on their networking so that they are always in a situation where the prospective employer is convinced in advance that they are a good hire.
Of course, this should also go the other way. As an interviewee, your task is both to prove yourself and to make the interviewers prove that their company is somewhere you want to work. So, ask probing questions about their culture, their code, their processes, their structure, the foundations of their business. And if they don't give good answers, or get upset about the questions, run away.
Absolutely. And I would say the same thing to interviewers: Part of the dynamic is of a candidate being skeptical that the company and the job are as good as they sound, and asking you to prove it. If that rankles an interviewer, seeking candidates through networking where the candidate arrives with a certain realistic view of the prospects is also a good thing.
That might work if the guy interviewing you have seen it, but I just really want to reply to can "can you write a function to traverse a tree" with "yes, on page 3 of the source code to the compiler I implemented in clojure".
I had much the same experience. I was interviewing with Steve Rosenberg at KL Group, and he asked me a question about Java coding. "Here," I said, pulling out a sheaf of papers, "is the source code for a small Scheme interpreter I wrote in Java..."
He waved me off, that was good enough for him. The rest of the interview was then about cultural fit and ability to ship software on time without drama.
(And no, what I wrote is not in the same league as Clojure, much less the same ballpark. But it was good enough to demonstrate some basic understanding of Java and familiarity with undergraduate-level Computer Science.)
