What separates a technician who can troubleshoot from one who can only follow procedures
The standard interview process — behavioral questions, resume review, reference checks — was designed to evaluate character, work history, and cultural fit. It was not designed to evaluate whether someone can diagnose a PLC fault at 2 AM under production pressure. The failure mode is predictable, and it is expensive.
"Tell me about a time you solved a difficult problem." This is the most common behavioral question in maintenance and technical hiring, and it produces the least useful information. The answer is almost always some version of: "We had this machine that kept failing. I figured out it was [part]. I replaced it and it worked." What that answer tells you about the candidate's actual diagnostic capability is essentially nothing — because the answer describes an outcome, not a reasoning process.
Behavioral interviewing works well for evaluating interpersonal skills, conflict resolution, and work patterns because those situations have no objectively correct answers — the interesting thing to evaluate is how the person navigated ambiguity. Technical troubleshooting is different. There are right answers and wrong answers. There are systematic approaches and random ones. Behavioral questions cannot surface the difference between a technician who diagnoses through principled isolation of variables and one who guesses and replaces parts until something works. Both will give you a behavioral answer that sounds identical.
Ten years of maintenance experience on a specific equipment type is a strong indicator that a candidate has been present when that equipment had problems. It tells you nothing reliable about what they did when those problems occurred. Were they the person doing the diagnostic work, or were they the person handing tools and watching? Did they develop deep equipment knowledge, or did they follow the same five PM procedures for ten years without accumulating diagnostic capability?
The most competent troubleshooters in maintenance are not always the ones with the most years on the most equipment. They are the ones who treated every failure as a problem to understand, who sought out explanations for why things happened rather than just what needed to be replaced to restore operation. That orientation — toward diagnosis rather than restoration — is what produces troubleshooting skill. It does not correlate strongly with tenure or with equipment hours logged on a resume.
This does not mean experience is irrelevant. A candidate with two years of experience on your exact equipment type has a useful head start. But that head start is in equipment familiarity, not necessarily in troubleshooting capability. Do not confuse the two in the hiring process.
A reference from a prior employer will tell you whether the candidate was reliable, got along with people, and did not steal anything. It will almost never tell you that the candidate struggled to diagnose intermittent electrical faults, or that they consistently over-ordered parts because they could not isolate failures, or that they were the person senior technicians quietly worked around on complex problems. Former managers are reluctant to share specific skill critiques in reference calls — the legal exposure is real, and the social norm favors positive comments or neutral silence.
The practical consequence: technical skill assessment cannot be outsourced to reference checks. It has to happen in the interview itself, through questions and scenarios that require the candidate to demonstrate technical reasoning in real time. If you are relying on references to confirm technical competence, you are not assessing it — you are hoping someone else already did and will tell you about it.
The standard interview process filters for people who are good at interviews. Technical troubleshooting and interview performance are not correlated. Some of the best technicians are terrible at articulating their process verbally. Some of the worst are fluent, confident, and reassuring. An interview process that cannot distinguish between them will produce inconsistent hires that are systematically unpredictable in the field.
Troubleshooting ability is not a single thing. It is the product of three types of knowledge working together. Assessing only one or two of them produces a distorted picture — and the most common failure is assessing the most testable type while ignoring the most predictive one.
Declarative knowledge is conceptual understanding: what components do, how systems work, what failure modes exist. Can the candidate explain what a VFD does? Can they describe the difference between angular and parallel misalignment? Can they explain why over-greasing a bearing causes failure?
This is the easiest type of knowledge to test and the most commonly assessed in technical interviews. It is also the least predictive of field performance. Declarative knowledge is easy to study, easy to acquire from textbooks and YouTube, and does not require any hands-on experience to develop. A candidate can have excellent declarative knowledge and be unable to effectively diagnose a real fault.
Procedural knowledge is step-by-step skill: how to perform a specific task correctly. Can the candidate describe the LOTO procedure for a specific energy type? Can they walk through a shaft alignment sequence? Can they describe how they would pull a vibration signature from a motor?
Procedural knowledge is harder to fake than declarative knowledge because it requires specificity. Someone who has actually done shaft alignment with a laser tool will describe the process differently than someone who has read about it — they will mention soft foot, they will describe the specific steps in the correction sequence, they will know what happens when you tighten the hold-down bolts after alignment. Someone who has not done it will describe the concept but will be vague about the mechanics.
Adaptive knowledge is the ability to apply existing understanding to novel situations — to reason through a problem that does not match any procedure the candidate has memorized. This is what troubleshooting actually is: confronting a system in an unknown state and reasoning toward a diagnosis without a script.
Adaptive knowledge is the hardest to develop, hardest to assess, and most predictive of field performance. A technician with strong adaptive knowledge can diagnose equipment they have never seen before by reasoning from first principles. A technician with only declarative and procedural knowledge needs the right procedure to already exist and will struggle when it does not.
Most maintenance interviews assess primarily declarative knowledge, some procedural knowledge, and almost no adaptive knowledge. The consequence: candidates who tested well in the interview demonstrate mediocre field performance, while candidates who seemed inarticulate in the interview sometimes turn out to be exceptional diagnosticians.
The fix is deliberate: design the interview so that at least one-third of the time is spent on scenarios that require adaptive reasoning. Not "have you ever seen this type of problem" — but "this is happening right now, what do you do next." The candidate's reasoning process, not just their answer, is what you are evaluating.
Diagnostic scenarios are the most powerful tool available in a technical interview. They are also the most misused — because the difference between a scenario question and a knowledge question is specific, and getting it wrong produces the same kind of coached, rehearsable answer you were trying to avoid.
A knowledge question has a correct answer that the candidate either knows or does not: "What are the common failure modes of a centrifugal pump?" A scenario question puts the candidate in a situation and asks them to reason through it: "A centrifugal pump that was running fine yesterday is now making a new noise and the flow rate has dropped by 30 percent. What do you do first?"
The difference is consequential. The knowledge question can be prepared for by anyone who has studied pump failure modes. The scenario question requires the candidate to apply that knowledge under the constraints of the situation — which tests whether they can actually use what they know, not just recite it.
The best scenarios have these characteristics: they are specific enough that the candidate cannot answer abstractly, they have genuine diagnostic ambiguity (more than one plausible cause), and they require the candidate to choose an action before they have all the information — which is the actual condition of every real troubleshooting situation.
A strong response to a diagnostic scenario does three things: it narrows the possibility space systematically, it identifies what information is needed before committing to a repair, and it shows awareness of what the candidate does not know. A technician who says "I would check the bearing temperatures and the inlet pressure first, to rule out cavitation before I assume it is a bearing issue — I need to know which direction to go before I start disassembling anything" is demonstrating exactly the kind of disciplined reasoning that predicts effective field performance.
The hallmark of a strong response is the question: what would the candidate ask before acting? Experienced troubleshooters gather information before they commit. They ask what changed recently. They want to know whether anyone else has been working on the machine. They check whether the problem is repeatable before they assume it was a one-time event. These information-gathering habits — the reflex to investigate before replacing — are what you are trying to surface.
A coached or rehearsed response to a scenario sounds comprehensive but lacks specificity. It covers all the right categories without committing to a specific sequence. "I would start by checking electrical, then mechanical, then the process connections" is a framework, not a diagnostic approach. It does not tell you what specifically they would check in each category, in what order, with what tools, using what criteria to decide whether each check passes or fails.
The tell: a coached response sounds like a checklist. A genuine diagnostic response sounds like reasoning. The candidate who has actually troubleshot equipment explains their logic — "I would check the bearing temperature first because if this is a lubrication issue I want to catch it before it causes damage, and temperature gives me that information in 30 seconds with an IR gun." That level of specificity is difficult to rehearse and reveals genuine experience.
Regardless of how the candidate answers the initial scenario, follow-up questions are where the depth of their knowledge becomes visible. For any step they describe, ask: "Why that first?" For any conclusion they reach, ask: "What would you expect to find if that were the cause, and what would tell you it is not?" For any tool they mention, ask: "What would you actually be measuring, and what is the threshold that tells you action is needed?"
These questions do not require the candidate to know the answer — they require them to reason. A candidate who says "I'm not sure of the exact threshold on that motor, but I would pull the OEM spec before I made any decisions" is demonstrating appropriate epistemic humility and a sensible approach. A candidate who confidently states a specific threshold that is clearly wrong is demonstrating a dangerous overconfidence. The follow-up question surfaces which one you have.
Start the scenario with the symptom and the constraint: "This machine just stopped. Production needs it running. You are the only technician available." Let them start their approach. When they take their first action, add a result: "You check that — and it looks normal." Then ask what they do next. This forces real-time reasoning rather than a prepared speech, and it reveals what the candidate does when their first hypothesis is wrong — which is exactly what the job requires.
Safety knowledge is the easiest technical knowledge to fake in an interview. Almost every candidate knows that they are supposed to say the right things about lockout/tagout, arc flash, and electrical safety. The question is whether what they say reflects actual practice or a memorized answer designed to pass the interview screen.
Safety requirements are documented, well-publicized, and widely discussed. OSHA 1910.147 is freely available online. Lockout/tagout procedures are covered in every maintenance training program, every safety orientation, and every pre-employment drug screen briefing packet. A candidate who has heard about LOTO but has never followed it correctly knows the vocabulary: de-energize, isolate, verify zero energy state, apply personal lock.
What they do not know — and what they cannot fake if you ask the right questions — is the specificity that comes from actually doing it on real equipment. Which stored energy sources did they have to address on the last complex lockout they performed? What did they do after applying the lock before they touched the machine? Have they ever had a situation where a lockout revealed residual energy they were not expecting, and what happened? Those answers require experience, not vocabulary.
The most effective safety questions are specific and situational. "Tell me about the most complex lockout you have ever performed — what were all the energy sources you had to address?" is more revealing than "Walk me through the LOTO procedure," because it requires the candidate to describe a real experience with real details.
Listen for specificity about multiple energy types. Electrical isolation is the one everyone names. The candidates who have actually performed complex lockouts also mention pneumatic pressure, stored hydraulic pressure, gravity (raised components that need to be blocked), capacitive discharge, and spring tension. A candidate who describes locking out a machine that also had pneumatic cylinders and omits the step of bleeding the pneumatic system has a gap — either in their knowledge or in their actual practice.
After the candidate walks you through a LOTO procedure, ask this: "You apply your lock. You go to start the machine to verify it is de-energized. It starts. What do you do?"
There is one correct answer: stop work immediately, get off the equipment, and investigate why the lockout failed before touching anything. The candidate who says "I would check the disconnect again" is describing a response to a failed lockout that involves touching potentially energized equipment. The candidate who says "I would call my supervisor" before stopping work has their priorities wrong. The candidate who gets uncomfortable and uncertain about the scenario is worth examining further — the discomfort may be appropriate, or it may indicate they have never thought about what a lockout failure actually means.
This question works because it is genuinely difficult. It requires the candidate to think through a scenario they should never have experienced but must know how to respond to correctly. The right answer is a reflex — stop, get clear, investigate the failure — not a procedural recitation.
A candidate who describes working on energized equipment as a routine practice — "we just work carefully" or "I know when it's safe" — should not receive an offer regardless of their technical ability. This is not a training issue. A technician who has normalized bypassing energy isolation procedures will do so on your equipment, with your team, creating liability and risk that no level of technical skill offsets. The interview is the right place to identify this; the incident report is not.
A good interview process produces consistent decisions. If two different interviewers using the same questions would reach different conclusions about the same candidate, the process has a reliability problem — and that problem will manifest as inconsistent hires, poor panel agreement, and eventually a loss of confidence in the interview process itself.
Gut feel in technical hiring has a specific failure mode: it is disproportionately influenced by fluency and confidence. Candidates who speak confidently and use the right vocabulary register as more competent than candidates who reason carefully but articulate slowly. This is a calibration error. The field does not reward confident wrong answers — it rewards careful right diagnoses, regardless of how they were communicated.
A second failure mode of gut feel is recency and primacy bias in candidate comparison. The last candidate interviewed is remembered most vividly. The first candidate is often the implicit comparison baseline. Neither is the right frame. When comparing five candidates across two weeks of interviews, gut feel will produce rankings that reflect memory and likeability as much as actual technical ability.
A third failure mode: gut feel cannot be explained to a hiring committee, to HR, or to the candidate who does not receive an offer. In an environment where hiring decisions are being reviewed — which is any organization of meaningful size — a scoring framework is not just operationally useful, it is legally protective.
A scoring framework does three things for a panel: it aligns interviewers on what they are evaluating before the candidate walks in, it provides a common scale for comparing observations after the candidate leaves, and it forces disagreements into specific questions rather than general impressions.
A panel where both interviewers score each section independently and then compare produces better decisions than a panel that debrief without structure. Independent scoring prevents anchoring — the phenomenon where the first interviewer's stated opinion disproportionately influences the second's. When both interviewers reveal their scores simultaneously, disagreements become visible in a way that can be resolved with evidence: "I scored the scenario a 4 because he asked clarifying questions before acting. You scored it a 2 — what did you see that I missed?" That conversation produces a better-calibrated final assessment than either interviewer could have reached alone.
Total interview score predicts performance reasonably well. One specific section predicts it significantly better: the diagnostic scenario score. The candidate's ability to reason through an unfamiliar situation in real time — under mild pressure, with incomplete information, on a problem they have not seen before — is the single most predictive measure available in a technical interview.
Why? Because the diagnostic scenario directly simulates the core job demand. A technician's declarative knowledge can be refreshed by training. Procedural gaps can be addressed by pairing with an experienced technician during onboarding. But adaptive reasoning — the habit of thinking through problems rather than searching for the right procedure — is much harder to install in someone who does not already have it. It is better assessed than trained.
When two candidates have similar total scores and you are deciding between them, look at the scenario score first. The candidate with the stronger scenario score is more likely to be the one your team calls when the unfamiliar failure happens at midnight and there is no procedure to follow.
| Interview Section | Knowledge Type Assessed | Predicts Field Performance? | Recommended Weight |
|---|---|---|---|
| Technical knowledge questions | Declarative | Weakly | Lower — necessary but not sufficient |
| Procedural walk-throughs | Procedural | Moderately | Medium — specificity reveals experience |
| Diagnostic scenarios | Adaptive | Strongly | Highest — most direct simulation of job demand |
| Safety questions | Procedural + behavioral | Strongly (as a disqualifier) | High — failure here should disqualify regardless of total |
| Communication / soft skills | Behavioral | Moderately | Medium — important but not primary |
If you are hiring multiple technicians or conducting panel interviews with different interviewers across candidates, run one calibration session before the interviews begin. Use a hypothetical candidate profile and score them together, discussing what a 5 answer looks like versus a 3 versus a 1 on each question. That 30-minute calibration session is worth more than any interviewer training — it aligns the scoring scale to a shared standard rather than each interviewer's individual one.
This article explains the principles behind effective technical interviewing. The Technician Interview & Evaluation System gives you everything built and ready to run:
You can run a structured, defensible technical evaluation the day you receive it — no customization or test-writing required.
Get the Interview System — $79 →