Interviewing a PLC programmer can be difficult when you do not have an automation background.
The candidate may talk about ladder logic, structured text, PROFINET, servo drives, safety PLCs, scan cycles, and communication faults. Everything may sound impressive, but you may still have no idea whether the person can actually troubleshoot a machine, write reliable software, or complete a commissioning project without constant supervision.
You do not need to become a PLC expert before conducting the interview. Your job is not to prove that you know more than the candidate. Your job is to ask questions that reveal how they think, how clearly they communicate, and whether their claimed experience is genuine.
A strong PLC programmer should be able to explain technical work in a logical and understandable way. When someone hides behind jargon or cannot describe what they personally did, that is often a warning sign.
Understand What You Are Hiring For
Before the interview, define what the role actually involves.
A PLC programmer working for a machine builder may spend most of their time developing new software, testing machines, travelling, and commissioning equipment at customer sites.
A programmer in a factory may mainly troubleshoot breakdowns, modify existing programs, support maintenance technicians, and improve production reliability.
An automation integrator may need experience with PLCs, HMIs, industrial networks, drives, documentation, and customer communication.
These are different jobs.
Ask the technical manager or engineering team to identify the five most important requirements. For example:
- Siemens TIA Portal experience
- Machine troubleshooting
- HMI development
- Commissioning experience
- Ability to travel independently
This gives you a simple framework. You do not need to understand every technical detail, but you should know which abilities matter most.
Ask for a Real Project Example
One of the best interview questions is:
“Tell me about a PLC project you personally completed. What was the machine, what was your responsibility, and what problems did you solve?”
A genuine candidate should be able to describe the project clearly.
Listen for specific details. What type of machine was it? Which PLC was used? How many motors, sensors, or stations were involved? Did the candidate write the program from the beginning or only make minor changes? Did they design the HMI? Did they commission the machine on-site?
Weak answers often sound like this:
“We used Siemens and programmed the entire line. There were many problems, but we fixed everything.”
That answer says very little.
A stronger answer might explain that the candidate programmed a conveyor system with several motors, photoelectric sensors, safety gates, and a small HMI. They might describe how they created the operating sequence, tested the I/O, configured the VFDs, and solved an intermittent sensor fault during commissioning.
You do not need to judge the code itself. You are judging whether the explanation is detailed, believable, and organised.
Separate Team Experience From Personal Experience
Candidates often describe projects using the word “we.”
“We programmed the machine.”
“We commissioned the system.”
“We solved the communication problem.”
Follow up by asking:
“What parts did you personally handle?”
This question is extremely important.
A candidate may have worked on a large automation project without writing much of the software. Perhaps they assisted with cable checks, watched another programmer, or performed basic testing.
That experience may still be valuable, especially for a junior role, but you need to know the difference between participating in a project and leading it.
Ask the candidate to explain their own responsibilities, decisions, and mistakes.
Use Troubleshooting Scenarios
You can test problem-solving ability without knowing the correct technical answer.
Present a simple situation:
“A conveyor was working yesterday. Today, the motor will not start. How would you investigate the problem?”
Do not focus too much on the exact terminology. Listen to the process.
A strong candidate will usually approach the problem step by step. They may ask whether there are alarms, whether the emergency stop is active, whether the PLC is in run mode, whether the output is being commanded, whether the contactor or drive is ready, and whether the safety circuit is healthy.
They may also mention checking the electrical drawing, confirming power, reviewing the HMI, inspecting sensors, and avoiding random program changes before understanding the fault.
A weak candidate may jump directly to one conclusion:
“The PLC output is probably broken.”
Real troubleshooting involves testing possibilities rather than guessing.
Other useful scenarios include:
- A PLC input remains on after the sensor turns off
- An HMI cannot communicate with the PLC
- A machine stops intermittently without a clear alarm
- A motor runs manually but not in automatic mode
- A replacement sensor does not work
- A VFD is ready, but the motor does not start
You do not need to know the answer in advance. You are looking for a safe, structured, and evidence-based approach.
Ask How They Work Safely
PLC programmers often work around live machinery, electrical panels, moving equipment, pneumatics, hydraulics, and stored energy.
Ask:
“How do you make sure it is safe to test software on a real machine?”
A responsible candidate should mention some combination of risk awareness, communication with operators, lockout procedures, controlled testing, emergency stops, safety zones, reduced speed, manual mode, and checking outputs before enabling movement.
Be cautious if the candidate treats safety as someone else’s responsibility.
Programming errors can start motors, release cylinders, move robots, or create unexpected machine behaviour. A competent programmer understands that software testing is not separated from physical safety.
Test Communication Skills
A PLC programmer may need to speak with electricians, operators, maintenance technicians, project managers, customers, and equipment suppliers.
Ask the candidate to explain a technical fault as though they were speaking to an operator or production manager.
For example:
“Explain why a machine might stop even though the PLC itself is still running.”
The best candidates usually adjust their language to the audience. They explain the problem without unnecessary jargon and avoid making the listener feel foolish.
This skill matters because technical ability alone is not enough. A programmer who cannot explain delays, faults, risks, or required changes may create confusion during commissioning.
Good communication is especially important in customer-facing roles.
Ask About Mistakes
Try asking:
“Tell me about a programming or commissioning mistake you made. What happened, and what did you change afterward?”
Strong candidates usually have an answer.
Automation projects are complex, and nearly every experienced programmer has made mistakes. They may have used the wrong motor direction, missed an interlock, overwritten a parameter, tested the wrong software version, or underestimated how an operator would use the machine.
The key is whether they accept responsibility, explain what they learned, and describe how they now prevent the same problem.
Be cautious when someone claims they have never made a meaningful mistake. They may lack experience, self-awareness, or honesty.
Check Their Documentation Habits
Ask:
“What documentation do you normally produce or update after making PLC changes?”
A reliable programmer may mention software backups, revision notes, electrical drawings, I/O lists, alarm descriptions, drive parameters, network settings, and commissioning records.
Documentation is often ignored during recruitment, but poor documentation creates serious long-term costs.
If a programmer leaves and nobody knows which software version is correct, the company may lose hours or days during the next breakdown. Changes should not exist only on one employee’s laptop.
You can also ask how they name backup files and how they confirm that the uploaded program matches the current machine version.
Verify Platform Experience Carefully
A candidate may list Siemens, Allen-Bradley, Mitsubishi, Omron, Beckhoff, and Schneider on their CV.
Ask them to rate each platform by actual experience.
For example:
“Which platform could you independently program and commission tomorrow?”
Then ask:
“Which platforms have you only used occasionally?”
This makes it easier to separate deep experience from brief exposure.
You can also ask what specific PLC families, software packages, and HMI systems they have used. Someone with genuine experience should usually know the product names and explain what they did with them.
Do not reject a strong candidate simply because they used a different PLC brand. Programming principles often transfer, especially if the role includes training time.
Use a Practical Test
For technical roles, an interview alone is rarely enough.
Ask a senior engineer, external integrator, or experienced contractor to create a short practical test. It does not need to be complicated.
The test could involve reading a basic electrical drawing, identifying why a motor cannot start, explaining a small ladder-logic sequence, or describing how to test several PLC inputs and outputs.
For a junior position, evaluate logic and learning ability.
For a senior position, test architecture, fault handling, safety awareness, commissioning, and documentation.
Do not give candidates a large unpaid project that would normally be real client work. A practical test should be short, relevant, and respectful of their time.
Watch for Warning Signs
Common warning signs include:
- Cannot explain personal contribution
- Uses excessive jargon without clear answers
- Blames electricians, operators, or customers for every problem
- Makes program changes before checking the machine
- Shows little concern for safety
- Claims expert knowledge of every PLC platform
- Does not keep backups or revision records
- Cannot describe a completed project
- Becomes defensive when discussing mistakes
- Gives confident answers without asking for more information
Confidence is useful, but overconfidence can be dangerous in automation.
The strongest candidates are often comfortable saying, “I would need to check the drawings,” or, “I have not used that exact platform, but this is how I would approach it.”
Make the Final Decision With Technical Support
When possible, involve at least one technically experienced person in the hiring process.
This could be an internal engineer, senior maintenance technician, trusted integrator, or independent automation consultant. Even one hour of external technical evaluation can be cheaper than hiring the wrong person.
Your role is still important. You can assess communication, reliability, attitude, travel expectations, salary alignment, customer skills, and whether the candidate gives honest answers.
The technical reviewer can check whether the candidate’s knowledge matches the level required.
You do not need to understand PLC programming to conduct a useful interview. Ask for specific examples, focus on the candidate’s reasoning, test how they communicate, and verify their claims through a practical exercise.
A capable PLC programmer should not only know how to write code. They should also be able to explain problems, work safely, document changes, learn unfamiliar systems, and take responsibility when something goes wrong.