Build an IT Support Skills Assessment Around the Job

Give the Candidate the Same Starting Point

I'd send a short description of the exercises, the available tools, and the interview format beforehand. Say whether reference material is allowed and whether the candidate should talk through their reasoning. Provide the same guidance to everyone, including how to ask for clarification or an adjustment to the setup.

On a podcast, James Bier recommends scenario-based technical questions or walking through a ticket to observe how candidates approach a solution. He values reasoning and recognizing when to seek help, rather than expecting perfect answers without tools or references. That's a practitioner's recommendation, and a sensible starting point for this design.

Use a prepared test environment and invented client records. The hiring lead owns the packet, the technical interviewer owns the fault and recovery steps, and a colleague owns the client role. Keep real client systems and private information out of the exercise.

Rehearse the assessment before inviting applicants. Check that the materials work, the intended fault is reproducible, and the exercises fit the interview slot you have booked. Cut unnecessary tasks rather than rushing candidates through a test the interviewers haven't tried.

Exercise: Triage a Ticket Packet

Give the candidate a small prepared set of requests with different stated impacts and missing information. For example, use a hypothetical person unable to sign in, a request for new equipment, and a report of a shared application being unavailable. Include your priority definitions and service commitments in the packet.

Ask the candidate to explain what they would clarify, which request they would handle first, and what they would record. Don't hide your priority rules and then penalize them for failing to guess them. A service desk assessment should reveal judgment within the job's actual boundaries.

The interviewer records whether the candidate checks impact and urgency, spots missing information, and identifies the next owner. A different order can be reasonable if the reasoning fits the supplied facts. Ask for that reasoning before scoring the choice.

Then introduce a clarification from the prepared script. Observe whether the candidate updates their plan and explains why. Keep the clarification the same across interviews, so one applicant doesn't receive a different problem because the conversation felt promising.

Exercise: Investigate a Prepared Fault

Use a contained fault representative of work the role will handle, on equipment or a lab account set aside for the interview. Give the candidate the user report, the permitted actions, and the route for requesting help. The technical interviewer must know how to restore the starting state afterward.

Ask the candidate to describe the next check and what each possible result would tell them. Observe whether they collect evidence before changing things, check the effect of their actions, and leave a usable note. Don't require the particular shortcut the interviewer prefers if another permitted method answers the same question.

Record requests for help as part of the evidence. For a role expected to escalate unfamiliar work, a clear explanation of what was tested and what help is needed can demonstrate the required handoff. Continuing beyond the permitted scope shouldn't earn extra credit for confidence.

The model's 30 labor minutes per ticket resolved at Tier 1 is a workload-planning assumption. It isn't an interview time limit or a required completion time for every fault. Set the exercise's boundaries through rehearsal and judge it against the role, rather than borrowing that average as a pass mark.

Exercise: Explain the Situation to a Client

Have a colleague play the client from a written script. Use the same fault or ticket packet so the candidate can carry their findings into the conversation. The client's questions should test whether the candidate explains the impact, the current position, and the next action in ordinary language.

Ask for an update when the answer is still uncertain. Look for a distinction between what has been established and what still needs checking. The candidate should be able to explain who will follow up without inventing a restoration promise the exercise doesn't support.

Include a request outside the candidate's authority, such as asking them to approve an unagreed change. The colleague records whether the candidate explains the approval route and keeps the work moving appropriately. A cheerful promise to do everything is not a handoff plan.

Finish by asking for the ticket note that should remain after the call. Compare the written record with the spoken update. Both need to give the next technician a clear starting point.

Score What You Could Actually Observe

Before interviewing, define the expected behaviors for each exercise and the evidence that would demonstrate them. Use descriptive results such as Demonstrated, Needs support, and Not observed. Add the concrete action or words behind each result.

• The hiring lead maps the exercises to the advertised role and states which requirements must be established before making an offer.
• The technical interviewer records evidence for triage, investigation, permitted actions, and the quality of the handoff.
• The colleague playing the client records the clarity of the update, the handling of uncertainty, and the approval route.
• Each interviewer records their assessment before the group compares impressions, then identifies any material disagreement.
• The hiring lead decides what follow-up is needed when a requirement wasn't observed, instead of converting missing evidence into an automatic pass or fail.

Keep the scoring sheet as short as the job allows. The interview doesn't become more objective because it has more boxes. It becomes easier to discuss when each box refers to something the candidate did.

Use the Result as Part of the Hiring Decision

A prepared exercise shows performance on that exercise under those conditions. It doesn't establish how the person will perform across an entire working week. Combine the observed work with the rest of your hiring process and be explicit about the training and supervision the role can provide.

If interviewers disagree, return to the recorded evidence and the role requirement. If the exercise itself failed, fix it and arrange an appropriate follow-up. Don't make the candidate carry a broken lab as a personal weakness.

Before your next interview, give the packet to a technician who understands the role. Have them work through it while the interviewers use the scoring sheet. Remove the guessing games and keep the parts that let you see the job being done.