Mark Pearl

Do not give too much detail about why the candidate is not qualified for the job you have open as that can lead to a verbal shooting match in which the candidate feels compelled to argue each point.

CV Screening

When screening CV’s look at it in 3 areas 1) technical experience, including functional skills, product-domain expertise, and tool skills; 2) industry experience; 3) patterns of behavior.

Read the cover letter or e-mail the candidate sends you. A good cover letter or introductory e-mail will not just mention your position, it also will relate the candidate’s interests and experiences to your job.

I note how the candidate’s work context is similar to or different from my open job’s context. I start my comparison by noting similarities or differences in projects and companies.

The key question for you, the hiring manager, is whether the company can manage the start-up costs, including training, for a candidate whose technical skills are not a direct match

Look at the kinds of applications the candidate has worked on before. How similar is the application’s context to your context?

Typos in résumés submitted by a writer or a tester: Many writers have trained themselves to look for typos in their work, but don’t always remember that a résumé is one form of writing. Typos in a writer’s résumé do give me reason to pause, although I do forgive typos in e-mail because e-mail is an informal, rapid-fire way to communicate.

If a résumé is riddled with typos, I probably won’t phone-screen the person, because I want to find people who have both the ability and the will to review their work.



For example, for a developer, I’ll say, “Tell me what you’re developing now.” For a tester, I’ll say, “Tell me about your test choices and activities now.”

What issues did you run into during implementation? Tell me about a time when you had trouble. Tell me about a time when you had fun.

Tell me about a great defect you found. How do you advocate for defects you think need to be fixed?

The most effective interview consists of a series of closed questions to establish the basic facts, used in combination with behavior-description questions, followed by auditions.

Behavior-description questions

Behavior-description questions, a form of open-ended question, help you discover how a candidate has worked in the past. If you know about behavior-description interviewing, you have probably read that “the best predictor of future behavior/performance is past behavior/performance in similar circumstances.” JAN86 Two corollaries are helpful in evaluating behavior consistency:

The more recent the past behavior, the greater its predictive power. The more long-standing the behavior, the greater its predictive power. JAN86

Technical Lead: To learn how the candidate provides technical leadership

When things are proceeding well on the project, what do you do? How do you recognize when the work is proceeding well? How do you know when things aren’t proceeding smoothly, and what do you do? Do you coach or mentor? If so, how? Tell me about a time when you had trouble. Tell me about a time when you had fun.

Tell me about a time you didn’t have enough information to complete an assignment. What did you do?

Tell me about a time you come across any problems waiting to happen What did you do?

Tell me about a time you come across any problems waiting to happen What did you do?

“When was the last time you decided you wanted a promotion, and what did you do to obtain it?”

Technical Interview


Tell me about a design problem that you solved that you are proud of. How long did it take you to solve the problem? How did you know the problem was fixed?

Test Staff Member

Tell me what you have done in the past to test the product. How have you learned about the product?



Debugging: I show the candidate a software product in development, including a piece of the code, and ask him or her to solve a problem that I tell the candidate already exists in the code. (In this audition, I intend to see how the person looks for problems, isolates problems, considers solutions, looks for alternative solutions, chooses a solution, and implements a solution. If you will have candidates look at production code, be sure to carefully select the code sample in advance of the interview. Rather than having the candidate work on a computer or at a workstation, print out the selected segment of code so the candidate doesn’t possibly see something proprietary that you don’t want seen.)

Product design: I explain a desired addition or modification to one area in a particular product’s design. I ask the candidate first to re-design to satisfy my request, and then to explain why he or she chose the particular approach. (In this audition, I’m looking at how candidates examine designs, what issues they are sensitive to, and how they know either that the design is complete or what they would have to know in order to determine that the design is done. Be sure to select the product area in advance, so you know what to discuss with the candidate.)


One good technique for auditioning testers requires a product demonstration. I provide a brief written description of a part of the product and then give the candidate tester some time with the product to explore it. I then have one of two choices: Either I ask the candidate tester to walk through his or her thought process on how to test the product or I ask the candidate to perform actual testing and problem reporting. In cases in which it is possible to show the candidate the running product rather than just a description, I sit the person down in front of the computer, and say, “Go test. Here’s some paper so you can take notes. I want you to walk me through your testing in twenty minutes.” You can look for not just the person’s specific approach, but also how he or she went about exploring the product.


A type of project management audition I like to use when I’m looking for a manager for a high-visibility or large project requires candidates to thoroughly describe a project they have managed. I ask the candidate to describe how he or she organized the particular project and what the deliverables were, and then I ask the candidate to describe what variation on that organization he or she would use according to several lifecycles, such as staged delivery, SCRUM, spiral, or waterfall lifecycles. Depending on how familiar the candidate is with various lifecycles, I may then ask which lifecycle he or she would choose if doing the project again—and why—and what impact such a lifecycle might have on the interim and final project deliverables.

For managers, I sometimes set up an audition to take place during a lunchtime meeting, and I invite attendees from the group with which the candidate would be working if hired. The audition segment could consist of a brief presentation by the candidate, to be followed by a Q & A session. I note to whom the candidate talks most frequently, and whom the candidate avoids.


How not to mess up hiring in tech

blog comments powered by Disqus

Want to get my personal insights on what I learn as I learn it? Subscribe now!