Interviewing a maintenance engineer: questions that show real skill

The CV looks great. Fifteen years in food manufacturing. Multi-skilled. PLC experience. 18th Edition. The candidate is friendly, on time, and talks well about "root cause" and "continuous improvement".

You offer the job. Three weeks in, the case packer stops on a night shift. Your new engineer spends four hours on it, swaps two sensors that weren't faulty, and hands it over to days still broken. Days find a loose wire in the junction box in twenty minutes.

You'd asked about their experience. You never asked them to show you how they think.

A bad hire costs you twice: once in the recruitment, and again every time the line stops and they can't fix it. The interview is your one chance to find out before they're on your shift.

What you're really testing

HSE describes competence as the combination of training, skills, experience and knowledge, and the ability to apply them "to perform a task safely" (HSE, what is competence). The last part is the bit a CV can't show you.

A ticket shows someone passed a course. HSE's guidance on electrical work says a completed electrical apprenticeship, with some experience after it, is a good way of showing competence for general electrical work. It also says more specialised work, such as control system modification, is likely to need extra training and experience (HSE, electrical safety FAQs).

So check the tickets, but don't stop there. Your questions need to show how the person works on a real fault, under real pressure.

Ask them to walk you through a fault

The best single question we know is this: "Tell me about the last fault you found that someone else couldn't."

Then keep digging. What was the machine? What did the HMI say? What did you check first, and why? What did you rule out? How long did it take? What did you change afterwards so it didn't happen again?

A real engineer will give you detail without being asked. Make, model, the fault code, the wire number. They'll tell you what they got wrong on the way. Someone padding their CV will stay vague and go back to phrases like "I diagnosed the issue".

Listen for method. Good fault-finders split the problem in half and test in the middle, rather than swapping parts until it works. If you want to know what good looks like, our guide to half-split fault-finding sets it out.

Give them a scenario from your site

Pick a real breakdown from your own logs and describe it as it looked at the start.

"It's 2am. The palletiser has stopped with a fault on the turntable. The motor isn't turning, the drive shows no fault, and the operator says it made a bang. What do you do?"

Then stay quiet and let them talk. You want to hear, in roughly this order:

1. Make it safe. Isolate, lock off, prove dead, and think about stored energy.
2. Gather facts. Photograph the HMI, read the alarm history, talk to the operator.
3. Work from the evidence. Supply, drive output, motor, mechanical drive, in a logical order.
4. Know when to call for help, and who to tell.

If they jump straight to "I'd swap the motor", that tells you a lot. If they never mention isolation, that tells you more. The basics of safe isolation should come out without a prompt.

Ask about the time they said no

"Tell me about a time production wanted the machine back and you said no."

Every engineer who's done shift work has a story like this. A guard that couldn't go back on. A live fault-find they refused to do alone. A restart they wouldn't sign off.

You're testing whether they'll hold the line on safety when a shift manager is stood behind them asking how long. You want someone who can explain the risk calmly, offer a safe option, and stick to it. Someone who has never said no either hasn't worked many breakdowns, or has been taking risks.

Check the controls claims properly

"PLC experience" on a CV can mean anything from writing code to reading a lamp on an input card.

So be exact. Which platforms? Siemens, Allen-Bradley, Mitsubishi, Omron? Can they go online and monitor? Have they forced an input, and when is that safe? Have they changed code, and how did they back it up first?

If you can, put a laptop in front of them with a copy of a real program. Ask them to find why an output isn't coming on. Ten minutes of that is worth an hour of questions. We cover practical tests in more depth in trade test or a chat.

Questions to leave out

Be careful with health questions. Under the Equality Act 2010, you must not ask about an applicant's health before offering them work, with some exceptions (section 60). One exception covers whether they can carry out a function that is "intrinsic to the work concerned". If the job means climbing into machines or working at height, you can ask about that. Keep the question to the task. Leave general health questions until after the offer.

Then, before they start, you must check they're allowed to work for you in the UK. You could face a civil penalty if you employ an illegal worker without a correct check (GOV.UK, right to work checks).

What we'd do

Here's our view. Interview an engineer the way you'd test them on the job. Less about the CV, more about the fault.

Get your best engineer in the room. They'll spot a vague answer faster than any manager. Use a real scenario from your own breakdown log, and if you can, a short practical on your own kit. Then plan the first month properly, because even a strong hire needs time to learn your machines. Our post on the first 30 days covers that.

What to do on Monday

1. Pick two real breakdowns from your log and write them up as interview scenarios.
2. Ask your senior engineer to sit in on the next interview and test the fault-finding answers.
3. Set up a short practical: a laptop with a program copy, or a fault on a test rig.
4. Check your application form and interview notes for any general health questions, and take them out.