Typical interviews that I've had in the past frequently say either "tell me about yourself" or "show my some code" but rarely seem to bring out the good technical qualities that I would look for myself.

What approach can I take that is more suitable for technical candidates for programming positions?

Having them write code in front of you has frequently not been as useful as expected due to nerves, new environment, different computers, etc.

  • Should this be on programmers? – MrFox Feb 13 '13 at 19:59

First of all, never interview alone. In fact, if you're the primary decision-maker, don't be the primary interviewer. You can learn more by letting one or two of their potential teammates interview them while you observe, and you get to see how good a team-fit they are if you can do that with different people over two interviews. (ie. meeting up to four of their potential colleagues.)

I do have themes for the two interviews though. The first is generally very soft-skills-based. Let's talk about your current job, how the process works, what works well for you, what works badly. The second is very technical. Send me some code ahead of time that you're happy with, proud enough to say "Yes, this is how I code." Then be ready to talk through it for an hour with technical people I already have.

I know all the arguments about their possibly sending code that isn't really theirs, but I maintain that if they can take a rigourous review from developers I know to be quality, they may as well have written it. But, honestly, if anyone is that much of a cheat and liar, I'm likely to catch it in the first interview. It's something I deliberately try to find out.

This technique hasn't failed me yet. When it does (as whiteboarding did -- I hired someone who was very good at a whiteboard, but a useless developer), I'll rethink. I don't believe there's a perfectly flawless system.

  • 1
    I disagree about interviewing alone. You should never be the only interviewer, but all interviewers should interview separately. When multiple people interview together they can be susceptible to group-think easily and not get true individual opinions about the candidate. The only time I would recommend multiple interviewers is when you're training someone to do interviews. – Samuel Neff Aug 16 '12 at 4:17
  • That's true Samuel, unless there is a predecided list of general questions ahead of time that the candidate is scored on based on specific criteria. You tally up the score and you have your man. Of course, part of the scoring includes a "does this person fit our culture" and that type of things. – Randy E Jan 13 '13 at 16:04
  • Many people work at companies that would take a very dim view of sending source code outside, making this pretty much impossible. – sdg Feb 13 '13 at 20:57

I go for low tech - often I'm hiring outside of my own comfort zone, so going into the weeds with someone on a particular technology isn't going to tell me much because I expect that if they are worth hiring, they know more than me.

My general strategy is to get them talking about a recent hard problem or big learning experience. If they say "I haven't had one" it's almost always a 'do not hire' because I can't imagine a technical worker working up to their potential who didn't have a hard problem or learning experience. I get them talking about why it was hard, and inevitably all the passionate frustration comes pouring out. In the midst of that, I sneak in the technical questions. Eventually we round out with "what eventually fixed the problem?" and "what would you do differently this time?"

It's not usual for this to be interpersonal rather than technical... but I usually drive us along until we get to a technical problem if I don't get there the first time.

I generally watch for problem solving skills, passion, and how they mix knowledge and learning with asking for help and working as a team. A technical team is special, and I always want to know that the guy will be able to communicate technically with his peers.

As a backup, in case I got a problem, but just couldn't get to the technical meat - I'll get them talking about a recent technology, the tradeoffs with competitive technologys, patterns or methodologies, and how they've maximized the potential of these things. Not my favorite, as it is easy to talk bit and know little in this way, but I can usually detect hype vs. content. If all I get is hype, it's a no-go for me.

  • 1
    So you don't recommend hiring a technical worker that hasn't been working up to their full potential, even if they have done a good job? – psr Aug 9 '12 at 18:20
  • 2
    I expect that people on my teams will be passionate enough to propose and try things that aren't easy. I understand that most recent project in someone's portfolio might be a "no brainer", but if at no time in recent memory you can remember being challenged enough to have something to talk about... I am doubtful as to whether you've been as engaged in your work as I will expect you to be. Hiring isn't about finding a reason to say "yes", it's about making sure there's no reason to say "no". – bethlakshmi Aug 9 '12 at 19:05
  • 1
    Well, that's responding to something else. – psr Aug 9 '12 at 19:12

When I am interviewing technical candidates, there are a few specific things that I'm looking for:


-- How will they fit in with the team? Is their personality compatible?
I first do my best to get the candidate to relax. I talk about my background, I talk about the company, I make jokes, I get them laughing, etc. I want to know how the person will be once they're settled in after 6 months and assume that, initially, they've got nerves or are on their best behavior. Once they relax a bit, I ask them to walk me through their ideal work day and probe that concept with follow-on questions for a bit. Above all, I make it as conversational as possible versus just a Q&A session.

Communication Skills

--How are their communication skills? Can they convey a technical concept to a technical person, a technical concept to a non-technical person, etc?
I'm generally interviewing for positions on smaller teams. These teams generally need to wear multiple hats and have interactions with non-technical teams. Evaluation of this skill happens throughout the interview, especially when I'm asking them to explain projects that they've worked on. I will probe on the business and technical end of the project to get a feel for how much they understand both sides and how well they can communicate both sides.

General Attitude

--How likely are they to be a poisonous or negative influence? How do they handle criticism?
In my region, the IT market is pretty small. I will usually ask a 'bait' question (though I don't like it, it seems to work) here and say something along the lines of "Oh, I see you worked here, I've heard some pretty bad things about that place..." and see what their response is. I'm looking for people to handle it gracefully rather than taking the bait. In addition, as we're discussing the details of a particular project they've worked on, I will challenge them on the choices that were made to see if they can defend it and if they can take criticism of their ideas if warranted. Questions like "Why did you use Technique X instead of Technique Y?" And then probing on that front.

Problem solving skills

--Can you take a business problem and develop a technical solution to it?
This one is usually something I have to infer as I haven't been able to come up with a good set of questions. However, having a conversation about a project that they've worked on usually helps.


--Can you be passionate about something you're working on?
I usually ask people to describe to me their most favorite project that they've ever worked on. I want to see them get animated and excited about something that they've done. And then I'll probe about what made the project so awesome. Answers to those questions are insightful, e.g. "I learned new technology X", "Business Problem Y was a new vertical for me", "it was difficult and accomplishing it made me proud", etc... I will also ask about hobbies and other related things here.

Conceptual Knowledge

--Do you actually know stuff and can you admit it when you don't?
Depending on the position, here I will ask about high-level and low-level technical concepts. I want to see how much listed on the resume is actually accurate and, contrary to the first section, I want to make you a little bit uncomfortable to see how you handle it. Also, I'm looking for you to honestly, without embarrassment, say "I don't know."

After I get through all of these things (not necessarily in this order (except Personality, which is always first)), I feel like I can make an informed decision about the quality of the candidate.


Normally I do not just paste links but there have been some very good posts in relation to your exact question.

The 1st one is quite inclusive of what is required when interviewing an engineer and was written by Jeff Atwood:

How to Hire a Programmer

The next blog post was written by Scott Hansleman and has some specific question you can draw from (and I have as the list and additional ones in the comments) are very good on the OO front:

New Interview Questions for Senior Software Engineers


I would make them sit in front of a computer with a dev environnement .tell them they have a software (explain them what it does and how to run through the application) and a list of Jira issues. Now let them handle the whole thing. Usually good people are people who knows where to look for information and that can say, "I don't understand this, I'm stuck, please could you explain it to me?". Plus you can see how fast he can comprehend someone else's code and debug. The demonstration software and issues should be near what you would expect him to do if hired. Also debate over an ongoing conception and ask them their opinions. They should be able to say yes or no and even change their minds after a debate. Every one can get wrong but good assets can say "I was wrong" or "this is why you are wrong" early in development cycle. Last thing, if you expect them to be part a team and to evolve inside it, someday they will end leading a part of it. Try letting them delegate some issue solving to a junior or intern and see how it goes. If the junior is pissed off they are doing it wrong. If the intern ends alone or without something to do he lacks leadership.

I'm not someone that know everything, I'm more a google nerd type but I'm a really good developer no matter what. Paper pen tests are just useless in my case.

This is my opinion and experience I hope I'm near what you expected. It's just every day situations applied to recruitment which I think really lacks during interviews.

  • 1
    +1 There's something to be said for allowing the interviewee to show that he knows how to find/google an answer if he doesn't know it off the top of his head. In most cases, knowing how to quickly find a solution is just as good as knowing the solution. – Jefferson Aug 10 '12 at 17:11

Sit with them as they use the IDE or other tools of the job and give them something to do at a computer.

It's not just purely can they get the code right, but: 1. do they know their way around? 2. diplay basic keyboarding skills 3. can they tell you why they do what they do? 4. coding style - at least have one 5. Do they ask necessary questions? 6. Look at some existing code: ask if they can tell you the good, the bad and the ugly (At least find out if they've seen the movie.).

I've heard all the arguements about being nervous and making minor mistakes, but any question you can ask sitting at a table, you can ask at the keyboard. If it's more of a conceptual question, go to the white board.

Why is this a last resort or never considered at all?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.