http://www.perlmonks.org?node_id=486805

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.

Joel Spolsky recommends asking yourself just two questions about each applicant:

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 in Perl. 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:

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?

General Questions

  • 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.

Trivia Questions

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

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.

STARR

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.

Auditions

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?

Meta Questions

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?

Developer Questions

  • 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).

QA/Testing Questions

  • 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.

General Skills

Some general skills employers may be looking for:

  • Problem solving
  • Teamwork
  • Communication
  • Adaptability
  • Data analysis
  • Resilience
  • Organisation
  • Technical skills
  • Creativity
  • Leadership
  • Language
  • Commercial awareness
Not sure how to test for these, apart from Behavioral Questions and STARR above.

Perl Monk References

Outside 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