[ghotli]

Recently I interviewed roughly twenty candidates for a software development position. There were a handful of recurring things the candidates did that bothered me.

If given a programming problem, don't stand/sit quietly while you work out the solution. Give the interviewer some insight to your thought processes. It would be nice if you could answer the question correctly. What would be best is if you can express to me that you're going to try different approaches to solve a problem when you hit a roadblock.

If you need help and it is offered, take it. Quite a few candidates got very close to the solutions but were too stubborn to accept help when it was offered. That sealed the deal on me not hiring a handful of people.

If you really don't know the answer to a technical question just give it your best shot. Admit that's all you've got and ask the interviewer how he would solve the problem. What I'm looking for in that situation is that you can show me honesty and that you are genuinely interested in learning that which you don't currently understand.

If you wrote your own resume, have it edited and cut down to size by someone completely non technical. Less is more as far as resumes are concerned.

Be prepared to answer ad hoc questions based upon things you put in your resume that you profess to be an expert in. For example, if you put Javascript on your resume instead of just jQuery or some other framework I'm going to ask you about the prototype, variable scope, and closures in the language.

Quite a few candidates just stared blankly near the end of the interview when I asked them if they had any questions for us. Ask questions about the technologies we use and why. Ask us what hard problems we've had to overcome. Engage with us, your future coworkers.

Smile. Be sure to smile.

[davidw]

> If given a programming problem, don't stand/sit quietly while you work out the solution. Give the interviewer some insight to your thought processes.

I think most of us are much more naturally going to sit and quietly do our work, as we have done all our lives, unless you're asking us to talk you through what we're doing.

[Jim_Neath]

+1 for that.

I'm not in the habit of shouting out what's going through my mind as I'm working.

[gvb]

But this isn't work, and the answer isn't a program.

This is an interview, your "customer" is the interviewee, and the answer you are trying to impress on your "customer" is that you are smart, articulate, personable, etc. Even more important, can the candidate look at an obvious question (the quiz) and see the underlying real question (is this candidate outstanding?).

All the things that don't come through on a paper-and-ink resume.

P.S. I've worked with lots of engineers that answer the question that is asked, but never think about what is underlying the question - sometimes the question is wrong. That is the difference between "smart, and gets things done" http://www.joelonsoftware.com/articles/fog0000000073.html and "done, and gets things smart" http://steve-yegge.blogspot.com/2008/06/done-and-gets-things... (a GREAT rant).

[potatolicious]

More importantly I think, in "real work" you will often have to explain/justify your implementation and design decisions - which is also basically what you're doing in front of your interviewer.

[fauigerzigerk]

Good points. But I think nobody can be genuinely interested in understanding what they don't currently understand during a job interview.

[ghotli]

A valid point. Perhaps genuine interest is asking a bit much. Willingness to at least get a little enlightenment as to what the interview is talking about is what I'm looking for.