In 2008, we created two new positions within the department. Employee in these positions would be expected to answer incident questions (tickets) which the front line help desk had neither the knowledge nor access to resolve. They’ll be level two support partners in the ITIL model. Prior to the creation of these positions, everyone in our unit answered tickets. Now, ticket resolution would fall solely on the backs of these two staff members.

Prior to this job search, everyone I hired had a role of trainer and consultant. An integral component of their final interview was to give a presentation to the department. That seemed a natural way for them to demonstrate their ability to perform the duties of the job, but not so for these new Support Specialists. They wouldn’t be presenting to anyone, only answering tickets. So how do we test them in the final stages of the interview process?

Since they’re to be answering tickets, why not present them with sample tickets and see how they do? These ticket scenarios would have to be general enough that any incoming candidate would have the skills to tackle them. So we couldn’t just select them from our records, say a convoluted Blackboard problem. Besides, we’re more interesting in getting them to demonstrate how to tackle a problem, not just deriving or knowing an answer.

So here’s what we came up with, as given to the perspective candidates ahead of time:

• You will be in an office with a computer.
• Anything you can access from that computer is fair game in the exercise. The computer is a standard Purdue lab build and has no restrictions put in place to constrict your use of it.
• Two committee members will be in the room with you as observers
• The other two committee members will be in a different room, simulating customer interactions
• They will be sending you questions/problems via email and phone
• The most important things we’re looking for are:
  • Your problem solving techniques; *how* you go about tackling the issues/questions given to you;
  • Your interaction with the customer in terms of style, process, and etiquette
  • Your avoidance of giving incorrect information
• While the speed with which you complete the simulations will be taken into account, it is far less important than any of the aforementioned attributes
• In fact, we won’t tell you before, during, or after the exercise what percentage of the simulations you were given. For we really want you to focus on giving all your attention to each problem as it is presented to you without regard to knowing there are 1, 2, or 5 left to go
• For example, let’s say we have 10 different possible simulations. You will receive a far higher mark from us if you deliver a perfect solution, and only get to four of them than if you give incomplete (especially if any contain erroneous information) solutions to all 10.
• We’re looking for technique and quality, not quantity
• There will be no trick questions, for we aren’t doing this to be tricky. They are pulled from our experiences handling real incident tickets. They are our attempt at giving you a chance to not only prove to us that you could handle the job under consideration, but the opportunity to see if this is the kind of position that would be to your liking as well.

When we first interviewed for these positions, we found these simulations to be an extremely effective way to identify which candidates are best suited for the job. Since then, we have used simulations in searches for other types of positions with great success as well. While we might ask a Support Specialist to answer a question which requires (re)searching the web, an Educational Technologist might face a role-playing curmudgeon being forced to put their class online for the first time. Many of our current staff all went through simulated exercises in acquiring their jobs with us and enjoyed the experience. The ideal candidate will relish it. The other type of candidate will be revealed by it.