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, resilient, ...
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.
OTOH, they are cheap to ask and help me judge the applicant's personality and cultural fit with my team.
Certainly, I've been shocked at how many highly experienced
developers cannot answer any of these questions!
Update: Based on feedback to this node, I no longer ask 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?
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 a 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.
Related to Behavioral Questions is STARR:
- Situation: what was the business goal?
- Task: what were they tasked to do?
- Action: what steps did they take to accomplish it?
- Result: what was the outcome?
- Reflection: what would they have done differently? what have you learnt?
See "References Added Later" section below for more information.
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'.
Update: To protect yourself from hiring developers who talk a good game -- yet are unable to deliver in the workplace --
candidates must be asked to write some code ... and then explain their thought processes behind it in a debrief session.
For some examples of different ways to do that, see Re^4: Rosetta Dispatch Table (Interview Question).
- 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.
Some general skills employers may be looking for:
- Problem solving
- Data analysis
- Technical skills
- Commercial awareness
Not sure how to test for these, apart from Behavioral Questions and STARR above.
Perl Monk References
References Added Later
Related to Organizational Culture and Teamwork:
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. Aug 2018: added new "STARR" and "References Added Later" sections (Structured Interviews, STARR etc). Sep 2018: added LanX Self Assessment Reference; added "General Skills" section. Jan 2021: Added extra modern perl books links