Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them.
-- David Brent in The Office
I'm interviewing. Again. Though I've done this many times before,
I'm still racked with uncertainty and doubt.
recommends asking yourself just two questions about each applicant:
- Are they smart?
- Do they get things done?
To be sure, these are important questions. We don't want a brilliant
PhD who seems unable to deliver because he keeps getting side-tracked
with "interesting" yet impractical theoretical problems. Even worse
is the numbskull programmer who gets a lot done but leaves behind
a trail of wreckage in the form of great wads of buggy (often
cut'n'pasted) code -- which can cost you an arm and a leg in
support calls and take years to put right.
Joel seems unconcerned about relevant experience, presumably because
computing changes rapidly and skills you have today may well be
obsolete tomorrow. I also remember Ovid mentioning that his team is happy
to recruit good developers with no Perl experience and train them
While that might work out well, it is risky. Here's why. Some years
ago I was hired as a Java programmer even though I had no Java experience.
I learnt Java easily enough, to be sure, but after learning it, I
discovered I disliked the language and hated its culture.
That is, I was a poor "cultural" fit for that company's Java-loving team.
I resigned four months later. That was an expensive hiring mistake.
So, in addition to being smart and getting things done, I add two more,
making my primary hiring criteria:
- Get things done
- Adequate relevant experience
- Personal: Good cultural fit, team player, enthusiastic, motivated, ...
Which of these do you think most important? What's your list?
The next step is to devise a set of interview questions that help
identify the right applicant. I've listed below some of my
favourite interview questions. What are yours?
- Why do you want to work at our company?
- What are you good at? Bad at? Enjoy? Dislike?
- How do you handle stress?
- What are your favourite books/magazines/web sites?
- What are your favourite tools? For example, if you start a new job, what tools *must* you install immediately?
- Tell me about the worst bug from hell (e.g. intermittent crashing program) you faced and how you solved it.
- Describe in detail a recent project you developed that you are proud of.
Some people feel these are a waste of time.
I still ask them because they are cheap to ask and help me judge
the applicant's personality and cultural fit with my team.
Certainly, I have been shocked at how many highly experienced
developers cannot answer any of these questions!
- What is a wiki?
- What is a Design Pattern?
- What is a Code Smell?
- What are agile methodologies? (for example, Extreme Programming)
- What is Test Driven Development (TDD)?
- What is xUnit? (e.g. SUnit, JUnit, cppunit, NUnit, ...)
- Have you heard of Subversion?
Update: Based on feedback to this node (see below), I no longer ask these questions.
Behavioral questions try to predict future performance based on
actual past behavior, not on responses to hypothetical questions.
The question format is sometimes referred to as PAR:
- The Problem you faced.
- The Action you took.
- The Results of your action.
Behavioral questions should be chosen to match the desired
attributes you're looking for -- based on job descriptions,
desired skills and personal qualities.
You might identify desired skills and personal qualities
based on an historical sampling of your employees -- both
highly successful and highly unsuccessful ones.
Some sample behavioral questions:
- Tell me of a time when you had to work with someone who was difficult to get along with. Why was that person difficult? How did you handle him/her?
- How do you tell if your work is high quality? Give some specific examples of ways you have improved the quality of your own work.
- Tell me of a time when you just couldn't complete everything on time. What did you do? What was the result?
- Give an example of something innovative you did that made a difference in your workplace.
- Give a specific example of when you sold your boss on an idea or concept.
- Describe the most difficult debugging/trouble-shooting problem you have faced and how you solved it.
Before asking such questions, you should explain to the candidate what you are doing and why. You'll further need to take notes to check with the candidate's referees to ensure the candidate is being truthful.
DeMarco and Lister, in their classic Peopleware book, recommend holding Interview Auditions. In the audition, the candidate gives a fifteen minute presentation on some aspect of their past work to an audience consisting of all the applicant's future co-workers. This helps ensure new hires are a good cultural fit with the team. Moreover, allowing all team members a say in whether to hire or not helps build team spirit and cohesion.
Role Playing Questions
I've never asked any of these but am toying with doing so.
The idea is to play out a scenario with the interviewee
to see how he reacts in inter-personal relationships in
various (e.g. stressful) scenarios. Has anybody tried doing this?
How did it go?
Towards the end of the interview, you can often gain useful information by asking the candidate questions about the interview itself. For example:
- What question didn't I ask that you feel I should have?
- What question did you fear I would ask but didn't?
- What question were you hoping I would ask but didn't?
- Give some tips for writing code that is: testable, supportable, portable, efficient, maintainable, thread-safe, reentrant, exception-safe, secure (choose one or more from the above list that are most relevant to your team).
- Perl: When do you use foreach versus grep versus map?
- Perl: What is the difference between my versus local versus our?
- Perl: What are your favourite CPAN modules?
- Perl: How do you do try/catch in Perl?
- Perl: What is a closure?
- C: Have you written your own hash table in C? Sketch out how you did it.
- C: Write a function reverse to reverse a string in-place.
- Unix: What is the difference between kill pid and kill -9 pid? Under what circumstances might kill -9 fail to kill a process?
- Unix: What is the difference between a wild-card and a regular expression? Write the wildcard ls *.c as a regular expression in ls | grep 'put your regular expression here'.
- Suppose you are to test a new release of Linux or Perl. They must run on many different hardware platforms and combinations. They should be "backward compatible", i.e. all programs that worked with the previous version should continue to work with the new version. Given there are a computationally infeasible number of platform combinations and programs out there to test, how do you go about testing such a release?
- By examining the bug database you can try to see which programmers produce fewer bugs and which testers find the most bugs. Is this a good idea? Why? Have you attempted this before? What happened?
- How do you know when your product is ready for release?
- You found a bug that you think important. The programmer is refusing to fix it. What do you do?
- You have an intermittent crash. How do you go about isolating the crash and making it repeatable? Who should do this? Support? Tester? Programmer?
- What is "Exploratory Testing"? When do you use it?
- Write down the test cases for our drink machine.
Perl Monk References
Updated April 2006: added new Auditions section. Feb 2008: added new Behavioral Questions section. July 2008: added new Meta Questions section. Jan 2011: added modern perl book perl questions link.