Role: System Administrator, small IT teamFull interview loop

For a team of two to six people looking after a few dozen servers, a few hundred people's laptops and the directory they sign in to, where the person hired does the work rather than supervising a provider who does it. The rounds assume a mixed estate: Windows and Linux servers, mostly virtual; an on-premises domain synchronised to a cloud identity service; backups to local disk with a copy offsite. A team that runs only Windows can replace the Linux scenario in the first round with one from its own ticket queue, and the rest carries over unchanged.

Each round takes one part of the job and hands the candidate what that part produces. The first is a morning's escalations, each with the evidence already gathered. The second is a patch plan, then the morning after it ran, then the afternoon someone asks for it to be undone. The third is a backup report on which every row is green. The fourth is an offboarding script, its log, and the weekend it caused. Every round contains something deliberately correct and something that looks alarming and is not, because a good part of this job is knowing which alarm to leave alone.

Troubleshooting is read three times, each from a different direction: a fault nobody caused, in the first round; a fault a change caused, in the second, where the reflex is to undo the change; and a script's account of its own work, in the fourth, where the log is the thing that is wrong. Patching and change control, backup and recovery, and identity and access are read twice each, and the second read comes at the competency from the other side — patching as an emergency and as a routine, backups as a snapshot someone wants to revert to and as a report to be doubted, access as a caller at the service desk and as a leaver's weekend.

Scripting and documentation are nice-to-haves read once each, and that is a choice with a cost. This loop prefers an administrator who writes short, careful scripts and restores a backup before trusting it over a fluent automator who has never tested one. A team whose servers are mostly Linux, or numerous enough that nothing is done by hand, should make scripting a must and give it a second read — the service checks after patch night in round two can be asked for as code. Documentation is read in the backup round because a restore is the procedure most likely to be carried out by someone other than its author; a one-person IT function, whose written pages are the only handover it will ever have, should make it a must and read it again in the patch plan's rollback.

There is no behavioural round. How a candidate carries a patch night that went wrong, or a leaver's weekend, says more about ownership here than a prepared story would. Networking, cloud design and first-line support are not read at all.