Main menu:

Site search



A Short Guide to Interviewing

I’ve been meaning for a while to write a post on how to interview software engineering candidates: here it is. In my opinion, there’s really no science to interviewing: it’s an intuitive, practice-based activity. So, as Barry Schwartz suggests in his book Practical Wisdom, I’m going to try to express what I know in just a few simple guidelines on each topic. First, a couple of general remarks:

  • Interviewing is important. Interviewing a candidate well is one of the most productive things you can do for your team in two hours as an engineer. So give interviewing the same attention and care as you do coding and debugging.
  • Interviewing takes practice. If interviewing feels awkward, or you get nervous, or you think you have no idea what you’re doing, that’s totally normal, and fine: you will get better with practice, and also more relaxed. It may take 3, 5, 10, or more interviews to hit your stride, but you will.

Basic Interview Template. Here is a basic 5-step interview plan, which you can use directly at first, and later adapt according to the specific interview and your own style:

  1. Greet the candidate and introduce yourself. The purpose is to make the candidate comfortable and mark the start of the interview. Example: “Nice to meet you. I’m Dave Mandelin. I work on JavaScript. Before we start, do you need a break or anything to drink?”
  2. Ask about experience listed on the resume. The key here is to follow your curiosity–look for things on the resume that intrigue you and try to have an interesting conversation. Examples: “What was the project? What was your role? What did you learn? What was hard about it? How would you handle this variation of the problem?”
  3. Ask about interests. This is to learn about fit and motivation. Examples: “Why do you want to work here? What roles are you interested in? What projects would you like to join?”
  4. Ask your technical questions. Ideally, ask questions that are similar to what comes up on the job, or even have the candidate write some code on a laptop. Problem-solving ability and communication skills are as important as getting the right answer. Experiment with different questions, but eventually you will want to have a standard set so you can calibrate the responses.
  5. Invite the candidate to ask you about anything. Like the greeting, this part is really for the candidate. They deserve a chance to interview you too, to see if they really want the job.

Before the interview, prep by scanning the resume for interesting things to ask about. Also, pick out what technical questions will be appropriate for this candidate. In general, don’t find out what others thought of the candidate–go in fresh and see for yourself.

After the interview, think about how it went. Did you learn everything you wanted to about the candidate? Were your technical questions too easy, too hard, or just right? Did you spend the amount of time you wanted to on each topic?

Writeups. After the interview, write up your findings promptly, while your memory is fresh. Doing a good writeup is a lot of work: it may take over an hour at first.

I use a template based on the interview template, with four sections: summary, experience, interests, and technical. The latter three are the detailed sections, and I write them first. The summary is for busy readers and for you at debrief.

For the detailed sections, I write down what I asked about, and what I found out. I usually include a few evaluative remarks: e.g., “simple project, but creative”, “communicated the answer very concisely”.

The summary section starts with a summary of the summary: a one-sentence take on the candidate. Then it gives highlights from the details, and strengths and weaknesses. Last come general discussion and evaluation.

Evaluation. The last step is to decide whether you want to hire the candidate. This goes in the writeup summary and of course you will say it in the debrief. Choose one of these four:

  • Champion, or strong recommend hire. This means you will strongly advocate and argue for the candidate at debrief. Say this if you think the candidate will become a leader or outstanding individual contributor, i.e., the candidate would be a peer to your senior team members.
  • Yes, or recommend hire. This means you want to hire the candidate. Say this if you think the candidate will become an above average member of your team, i.e., the candidate would fit in as a peer on your team.
  • Veto, or strong recommend no hire. This means you seriously don’t want to work with this person. Say this if the candidate is clearly unqualified or you see serious behavioral issues.
  • No, or recommend no hire. This is the default answer. If you are concerned about issues that are not serious enough for a veto, say no. If you think “maybe”, or “don’t know”, say no. It’s OK to say no: you are not making the final decision right now, and you might be persuaded to say yes at the debrief. Saying no is hard, and deciding not to hire a candidate is sad. There’s no getting around that. But remember that you have a responsibility to your co-workers to hire the right people, and to the candidate not to hire them to a job where they won’t thrive.

Final thought: try to have fun. Interviewing can be fun: you get to meet people, talk about their work, and reflect on the experience. If you enjoy interviewing, it won’t seem like a chore, and you’ll find it easier to give it the mindful effort needed to do a good job. Also, if you go into the interview expecting to have fun, the candidate can pick up on that, connect with you better, and show you more of what they’re all about.


Comment from Jim B
Time: June 30, 2011, 6:59 pm

You forgot to mention asking the candidate why manhole covers are round. No interview is complete without it.

More practically, I think it is important to stress that the interview is about the candidate, not the interviewer. It should be obvious, but for some people it isn’t.

I’ve worked with people who, either because of ego or in order to kill time because they don’t know what to ask, talk about themselves.

I’ve worked with people who appeared to have a goal of proving that they were smarter than the candidate. “So, I see here you have experience programming on IBM mainframes. In the IBM/360 decimal edit instruction, what is the final state of the Z flag when formatting a number too large to fit in the specified field? Hmm, I thought you said you knew this stuff.”

Pingback from David Mandelin: A Short Guide to Interviewing | Firefox Latest News
Time: June 30, 2011, 9:55 pm

[…] Planet Mozilla No Comments July 1, 2011 By Giovanni Panasiti in Planet Mozilla Tags: David, Guide, Interviewing, Mandelin, Short « Breaking the egg: Mmmm, Test Pilot for Thunderbird. So, what studies should we run… […]

Comment from Axel Hecht
Time: July 1, 2011, 1:53 am

Reading “above average” makes me wonder, would you really not want to hire a good share of your team again?

Comment from Claire
Time: July 1, 2011, 1:59 am

I myself have just gotten the task of hireing new candidate teachers at my community school where I teach. I really find it difficult, both because I’ve never interviewed before but also because of the fact that the people I talk with might end up being my co-workers. I just think it’s awkward to talk “officially” with someone you might end up working with.
Any advice as to how to overcome this “awkwardness”?
Anyways it was a great article. I learned a few gold nuggets from reading it that I hopefully can use for my interview on monday

Pingback from David Mandelin's blog » A Short Guide to Interviewing | Internet blog
Time: July 1, 2011, 3:29 am

[…] more: David Mandelin's blog » A Short Guide to Interviewing Bookmark to: This entry was posted in Uncategorized and tagged mandelin. Bookmark the permalink. […]

Comment from alade funke
Time: July 1, 2011, 11:14 am

I love this. it’s educative

Pingback from David Mandelin's blog » A Short Guide to Interviewing | Cell Mobile Guide
Time: July 1, 2011, 11:31 am

[…] See more here: David Mandelin's blog » A Short Guide to Interviewing […]

Comment from Nicolas Chevallier
Time: July 1, 2011, 2:16 pm

I think more and more cadidates lie about their skills, so we have to be careful and ask many technical questions.

Comment from dmandelin
Time: July 1, 2011, 4:51 pm

That heuristic is taken straight from a Peter Norvig blog post that Rob Sayre showed me a while back. I believe the idea is that if you are willing to hire people below the current average skill level, the average level will drop, leading to even less skilled hires. But if you try to hire only candidates that would be above average, of course some will end up being below average, but the overall level will stay high.

Comment from dmandelin
Time: July 1, 2011, 4:59 pm

Yes, that is not good interviewing. Some of that may come from interviewers being intimidated by candidates. I know that when I started interviewing, I often was, because oddly enough, people tend to write resumes that make them look really brilliant. And it can be worrying to think about hiring someone who will turn out to outshine you.

I personally have had some interviews where, on later reflection, I thought I talked too much, or was showing off to a candidate. I feel embarrassed when I think about that. We are only human, and interviewing is a highly imperfect process. The best we can do is reflect on interview experiences and try to do better in the future.

Comment from hírek
Time: July 2, 2011, 2:21 am

We have a five years old computer related company, so I can add some of our experience here.

First, I think that not always the knowledge is the most important factor. We hired a super genius a year ago, but he is not that much interested in real user problems and is not so effective than some of our above-average collegues.

Another thing is that I prefer some written exams above the interview, because there are a lot of youngsters who blocks when intervied but can write excellent codes anyway.

Comment from Olivier Berger
Time: July 2, 2011, 4:42 am

I’m thinking about asking them to play Carcassonne, to evaluate their cooperation skills. That’s the kind of ability I’m looking for for collaborators, in particular in FLOSS context

Comment from Jim B
Time: July 2, 2011, 7:14 am

Claire, it can be intimidating when interviewing someone older or more experienced, but it is your job to put your personal fears aside and do as good of a job as you can.

I have only a BSEE and I’ve interviewed people with PhD’s. At first I felt silly trotting out my toy programming problems to have them solve, but guess what? Not all of them can do it. I’ve had people get very indignant that they need to prove their abilities. Either they are bluffing, or they have a major attitude problem and aren’t someone you want on your team.

It is OK to talk generalities to cover a broad sweep of their experiences, but it is important to drill down deep in at least one place and get to the nitty gritty. Some people are masters at talking a good game, but when you try to get specific, they are like a buoy that keeps bobbing back up to the superficial generalities of the problem. This is a sure sign they are not a hands-on person.

Comment from Tas Branded
Time: July 2, 2011, 11:44 pm

good point, but i always nervous when come to interview.

Comment from justin
Time: July 4, 2011, 9:22 am

Ha my interview is on next tuesday :). This article helped a lot

Comment from Sam
Time: July 4, 2011, 6:17 pm

2 hours per interview might work for second interview, but for me most of the time I hire people for a team that needs to scale up in short notice, and I have a rather large number of candidates to go through meaning it would take days out of my productive work if it took 2 hours each.
So I tend to have a quick screening of 15 minutes or so, if the candidate shows promise then the interview would continue to the next level.

Comment from Bangalore Flats
Time: July 4, 2011, 11:31 pm

Nice guide, Thanks

Comment from Web Designer Qatar
Time: July 5, 2011, 4:46 am

I could found out excellent and useful information from you guys. This guide will be useful for everyone. Thanks.

Comment from Georgette
Time: July 5, 2011, 9:57 pm

Thank you!
This post got all what I wanted…I have a problem about interviewing also and I still don’t know what to do about it until this time, I saw your blog and have many questions in my mind that have been answered. Thank you!
That’s all I can say for now and hoping so that I can apply all the stuff I learned from here in my future interview.

Comment from Tammy
Time: July 6, 2011, 12:06 am

I hope I’ve read this tips before interviewing. I did most of the things you said but I had missed the others.

Comment from kids playhouse
Time: July 6, 2011, 12:33 am

This was a disgrace to the subject matter and should have been thought through better before being written.

Comment from Asbestos Training
Time: July 6, 2011, 1:09 am

I am so thrilled for having found your site.

Comment from Webkatalog
Time: July 6, 2011, 4:14 am

Interesting contribution did, found your blog during a search. And saved him the same again.

Comment from long island foreclosure
Time: July 6, 2011, 12:46 pm

Sweet guide on interviewing. I am about head into one tomorrow….these will help out my anxiety. Thanks mate!

Comment from bağlama tılsımı
Time: July 6, 2011, 1:44 pm

good point, but i always nervous when come to interview

Comment from CrisB
Time: July 7, 2011, 3:37 am

Interviews were a night mare for me. But now I am in a position to
interview others. Nice blog. Thanks
Los angles web design

Comment from flex belt reviews
Time: July 7, 2011, 3:52 am

Taking notes and preparing bulletined topics works all the time. Nice roundup thanks!

Comment from Damir
Time: July 7, 2011, 3:57 am

Thank you, i prefer to hide from interviewers!

Comment from yoga
Time: July 7, 2011, 3:58 am

I´lll hide from interviews, and try to wear allways sunglasses

Comment from Wedding Favors
Time: July 7, 2011, 8:24 am

This post is quite informative. Interviewing is indeed an intuitive, practice-based activity. Whatever your decision after the interview is, depends on your own perspective.

Comment from Corian Worktops
Time: July 7, 2011, 11:17 am

I am such a big fan of yours, as you have this special ability of making people read your posts and always come back for more.

Comment from Sciatic Leg Pain Relief
Time: July 7, 2011, 1:45 pm

I’ve been the interviewer and the interviewee. In both cases I hated it. But I do agree how important it is. It is key to get past the formality to see if this person is really qualified or not. This is a great guide. Thanks for the great article!

Comment from Six Pack Abs
Time: July 7, 2011, 10:53 pm

It’s a good idea to practice interviewing so you can get used to introducing your technical experience.

Comment from Best Diet Pills
Time: July 7, 2011, 11:04 pm

I will utilized these guides. I’m among others who don’t like to participate in interviews regularly.

Comment from forex signals
Time: July 8, 2011, 12:03 am

The page is great and the guide very nice.

Comment from wall art
Time: July 8, 2011, 6:04 am

Great stuff, thanks.

Comment from Flooring Supplies
Time: July 8, 2011, 11:51 pm

Very useful tips. I always prepare a set of easy question, difficult ones and some mind buglers to make the interview pretty interesting to me and the viewers.

Comment from khareen
Time: July 11, 2011, 9:04 pm

Great sample and good choice of topic yet very informative.