Last updated: September 3, 2026
By Jennifer Burdick, Recruiting Manager, KORE1
Automation engineer interviews in 2026 should test startup behavior, safety judgment, and OT network sense. PLC trivia is free. Anybody can memorize scan cycle mechanics in a weekend, and the plants that screen on it keep hiring people who cannot run a commissioning.
I run delivery at KORE1 and have been recruiting for fourteen years, almost thirteen of them here, across tech, engineering, finance, HR, and operations. Automation reqs have a problem no other engineering search has. The title means two completely different jobs, and half your applicants are answering the other one.
Here is what that looks like in a funnel. We opened a controls-heavy automation engineer req for a packaging line last year. Sixty-one applications in eight days. Twenty-two were Selenium, Cypress, and Playwright people, strong ones in a few cases, applying in good faith to a job that involves standing in front of an open control cabinet at 3 a.m. Nobody was confused about their own skills. They were confused about ours, because the posting said automation and so did their resume.
Then the loop itself goes wrong, in a separate way, for separate reasons.
My bias, stated plainly so you can price it in. KORE1 has staffed engineering desks since 2005 and I run delivery for automation engineer staffing, which sits inside our broader engineering staffing group. A signed offer pays us. Nothing on this page is gated and most plants I talk to could run this loop without calling anyone.
The Screen Almost Everyone Runs Is the Screen That Tells You the Least
Sit in enough of these and you hear the same eight questions. What is a PLC scan cycle. Explain the difference between a PLC and a DCS. What are the five languages in IEC 61131-3. Describe PID tuning. What is the difference between HMI and SCADA.
Every one has a correct answer a candidate can rehearse from a blog post the night before. There are dozens of those posts. Good ones, some of them. They are written for the person being interviewed, which is fine, that is a legitimate thing to write. It just means the questions have been answered in public so many times that asking them tells you almost nothing about whether this person can be trusted with your line.
The information is in what they do when something is wrong and nobody has told them what.
Do not take that too far. Fundamentals still matter. Somebody who cannot explain analog scaling, or does not know why you would reach for a retentive timer, is not a senior automation engineer no matter how good the stories are. Ask the fundamentals. Four minutes, not forty. Treat them as a floor rather than a score.
Sort the Seat First or the Loop Will Not Mean Anything
Three plants post the same title. They want three unrelated people. One needs somebody to babysit and improve twelve existing lines. One needs a person to take a greenfield installation from a functional spec through factory acceptance test and site acceptance test. One needs a systems integrator profile who will live in airports for eight months.
Decide which one you have before you build questions, because the artifact you hand the candidate changes completely. Our automation engineer job description template works through that sorting in more detail, and if the req itself is still loose, start there instead of here. The whole search, req through offer, is laid out in our 2026 guide to hiring an automation engineer.
| Shape of the seat | Hand them this | What you are listening for |
|---|---|---|
| Sustaining an existing plant floor | A downtime report with three weeks of fault codes | Whether they look for the repeat offender before they look for the biggest number |
| Greenfield installation and commissioning | A sequence of operations with a gap in it | Whether they find the undefined state before you point at it |
| Integrator or capital project work | A customer punch list two days before a site acceptance test | How they decide what ships and what gets written down as a deviation |
| Regulated process, pharma or medical device | A change request that touches validated logic | Whether the words impact assessment come out unprompted |
Most reqs land on two of those rows. A posting that claims all four is not a req. It is a wish, and you will spend five months learning that.
Start With the Downtime Report, Not a Question
Open the technical screen by handing over a document.
Take a real downtime or fault log off one of your lines, three weeks of it, strip anything proprietary, and print it. Paper. Twenty or thirty rows is plenty. Leave the ugly parts in. The duplicate entries, the operator comments that say nothing, the fault that shows up eleven times on second shift and never on first.
Then ask one thing. What would you go look at first, and why that?
Weak candidates sort by duration and start talking about the longest outage. It is the obvious move and it is usually wrong, because the eleven short faults on second shift often cost more in aggregate and they are telling you something about a person, a setpoint, or a sensor that only fails when the room warms up. Strong candidates find that pattern in under two minutes. Some of them have found it before, in a real plant, and you will hear it in how fast they get there.
The best answer I have watched a candidate give to that prompt was a question. He asked whether the timestamps were from the PLC or the historian, because if they came from two clocks that were not synced then the sequence in front of him was not necessarily the sequence that happened. Nobody on the panel had thought about it. He got the offer.
Ask About the Startup That Went Badly
Every automation engineer worth hiring has one. A startup that ran long. A line that would not hand off cleanly. A night that turned into a morning.
Ask for it directly. Tell me about the worst startup or commissioning you have been part of. Then let them talk, and do not rescue them when they pause.
What you are listening for is not the failure. It is the rollback. Somebody who has genuinely done this work stages the change so the old program can come back, and they can tell you how long that takes because they have timed it. Under twenty minutes is a real answer. “We would have restored from backup” is not, and the follow-up question that exposes it is short: had you tested that restore, on that hardware, before that night?
Ask what they changed afterward. A mid-level engineer fixes the logic and moves on. A senior one adds something that makes the next failure louder or smaller, an alarm on a condition that had no alarm, a staged commissioning plan, a written handoff that the night shift actually reads. Then ask whether it ever got used. Some of the honest ones will admit it did not, and that is a better conversation than a clean story.
One more, and it separates people faster than anything else in the loop. Ask about a time they told a plant manager the line was not ready.
Almost every automation engineer has been leaned on to release something that was not finished. The ones who have never once pushed back either have not been in the room where that pressure happens, or they folded and do not want to say so. Neither is disqualifying. Both change what you need from the person above them.
Safety Is Where Seniority Actually Shows
Most panels skip this section. It is the one I would keep if I could only keep one.
Safety questions are boring to ask and they correlate with real experience better than anything technical. Somebody who has commissioned inside a functioning safety system has opinions. Somebody who has read about it has definitions.
Four that work:
- Walk me through how you validate a safety function after you have modified it. If ISO 13849 performance levels or a SIL rating come up without prompting, that is real.
- Under what circumstances have you bypassed a safety device, and what was the paperwork? The right answer is almost never a flat no. Bypasses happen during commissioning. The signal is whether it was controlled.
- Where does the emergency stop circuit sit relative to your control logic, and why does that distinction matter? Hardwired versus safety PLC versus a GuardLogix-style integrated safety task are different worlds and a candidate should be able to say which they have worked in.
- Who signed off the last risk assessment you worked from, and did you read it?
The last one is not a technical question at all. I put it in because the answer is usually revealing. Engineers who have been near an incident read the risk assessment. Engineers who have not, mostly have not.
The OT Network Question Nobody Is Asking Yet
Plant floors got connected. The interviews have not caught up.
Historian data goes to a cloud dashboard, an OEM has remote support access into their own equipment on your network, somebody’s laptop moves between the corporate VLAN and the control network, and a vendor tech shows up with a USB stick full of firmware. That is an ordinary week in a modern plant and it is a security surface that did not exist when most of the senior candidates you are interviewing learned the job.
The relevant standard is ISA/IEC 62443, maintained jointly by the International Society of Automation and the International Electrotechnical Commission, with the organizational requirements in part 2-1 refreshed in January 2025. You do not need a candidate who can recite the security levels. You need one who has heard of the zone and conduit model and does not think an air gap is a thing their plant still has.
Ask it concretely. How does an OEM get remote access to their machine on your floor, and who turns that access off when the project ends? Then the harder one. Your integrator wants a cellular modem on a panel so they can support it from Ohio, and they need an answer today.
Candidates who have lived through a plant IT and OT negotiation answer these with a specific person’s job title in the story. That is the tell. Where the environment is regulated or the data has to leave the floor at all, the seat starts overlapping with manufacturing IT staffing, and in pharma it becomes its own discipline covered by our pharma IT and cGMP staffing desk.
What the Money Is Actually Telling You
The comp data is a mess. The mess itself is informative.
Payscale puts the average base for a control and automation engineer at $91,465, off 123 profiles. Glassdoor, measuring total pay for a PLC automation engineer, starts its middle range at $109,078 and runs to $167,135. Those two are not arguing about the market. They are counting different things, and one of them begins above where the other one finishes.
A hundred-thousand-dollar span on a single title happens because the title covers a plant sustaining engineer, an integrator who lives in airports, and a validated-environment specialist, and no aggregator separates them. Our automation engineer salary guide takes the published averages apart source by source if you want the fuller picture.
What moves an offer inside that band, in the order I see it move: travel load, whether the plant runs nights and weekends for changeovers, whether the environment is validated, and how many platforms the person actually has in production. A candidate who is genuinely productive in both Studio 5000 and TIA Portal knows exactly what that is worth and will not discount it. Our salary benchmark tool is free if you want a live read before you approve a number.
The interview consequence is the part people skip. Ask about the number in the first call, not the fourth. A candidate whose current pay already sits inside your band is a completely different negotiation from one who needs a twenty percent move to justify changing plants, and finding that out in week four is how a search restarts from zero.
A Loop That Fits Inside Two Weeks
Speed matters more in this field than most hiring managers believe, because good automation engineers are rarely on the market by accident and the ones who are get three conversations going at once.
- Recruiter or hiring manager screen, 30 minutes. Confirm the seat shape matches their history. Get the travel number and the shift reality on the table in this call, not the third one. This is also where you find out whether you are talking to a test automation developer.
- Technical screen with the downtime report, 45 minutes. Fundamentals for four minutes, then the artifact, then the bad startup story. Do not save the safety questions for later. Put them here.
- Plant visit or working session, 90 minutes. Walk the actual line if you have one. Watching a candidate look at real equipment tells you things a call cannot, and it lets them decide whether they want the job, which matters more than panels admit.
- Final conversation, 30 minutes, no new technical content. Scope, on-call, who owns the line after this hire, what month three looks like. Decide that week.
Three rounds is often enough. Four is the ceiling. Our average time-to-hire across IT roles runs 17 days, and the only way anyone hits a number like that is by moving from final conversation to written offer inside a week. Add a fifth round and you are not learning anything new. You are buying the opportunity to lose a finalist to a plant that moved faster.
Whether you run the seat as contract or direct hire depends on one honest question: does the work end? A capital project with a real finish line is a contract engagement. A plant floor that will still be running in 2032 is not, and hiring a contractor to commission it means watching the only mental model of how it works walk out the door at project close.
The Answers That Have Cost Us the Most
None of these is an automatic no. Each one earns a follow-up.
- A platform list with no failure attached to it. Six brands named, nothing ever misbehaved. Equipment misbehaves. If none of it ever did, they watched somebody else commission it.
- Every story ends with the vendor or the integrator fixing it. Vendors do cause plenty of incidents, so this one is tricky, and the thing to listen for is whether a single story ends with something the candidate changed on their own side.
- Fluent on architecture, vague on the floor. Ask what the actual I/O count was. The number arrives immediately or it never arrives.
- “I follow best practices for alarm management.” Ask how many alarms were active on their last line during a normal shift, and how many of those operators had learned to ignore.
- Only greenfield. Genuinely different skill from inheriting a 2001 panel and drawings that stopped matching reality three contractors ago. If your environment is the second kind, and most are, ask what the oldest system they ever inherited was and what they did with it.
- A candidate who has never worked a shutdown. Not a red flag by itself. It is a scheduling conversation you need to have before an offer, not after.
What Hiring Managers Ask Us Halfway Through
Half our applicants are software test people. What is wrong with the posting?
Probably nothing except the word automation. It carries two meanings and search engines do not distinguish them, so the funnel arrives mixed no matter how the body of the posting reads.
Put the platform in the job title and the problem mostly solves itself. “Automation Engineer, Allen-Bradley” or “Controls and Automation Engineer, PLC and SCADA” filters before anybody opens the description. The applicants you are turning away are not wasting your time on purpose, and a fair number of them are strong at what they do, which is why we route that traffic to test automation engineer staffing and keep the two searches on separate desks. If the seat really is Selenium and Cypress work, our QA engineer interview questions are the right page.
Does the ISA CAP certification tell us anything?
It confirms experience more than knowledge. The Certified Automation Professional credential requires five years in automation with a four-year technical degree, or ten years without one, documented in hours.
That makes it unusual among certifications, because the hour requirement is doing most of the work rather than the exam. It is a reasonable tiebreaker and a reasonable first-pass filter on a large applicant pool. It is not a substitute for asking what they have commissioned. I have interviewed certified candidates who had never run a startup alone, and uncertified ones carrying twenty lines. The certification renews every three years on professional development points, so a current one at least tells you the person is still engaged with the field.
Our maintenance team says they can cover this. When is that true?
When the changes are small, the platform is one they already know, and nobody is asking them to modify validated or safety logic. It stops being true at the first capital project.
Good maintenance technicians do more automation work than most plants acknowledge, and pretending otherwise is a fast way to lose them. The line I watch for is authorship. Maintaining logic somebody else wrote is a different job from designing a sequence, and the moment a line changes shape, or an OEM integration lands, or a customer audit asks who validated a change, the absorption has already failed. It usually shows up first as a maintenance backlog nobody can explain.
Is a controls engineer the same as an automation engineer?
In most US plants, close enough that the titles trade places. Controls tends to sit nearer the panel and the instrumentation. Automation tends to reach further up into SCADA, historian, and line-level sequencing.
Do not spend energy on the taxonomy. Spend it on the scope sentence. Whichever word you put in the title, the posting still has to say what they own, which platform, and how far up the stack the job goes before it becomes somebody else’s. We run both through the same controls engineering desk because the candidate pools overlap almost completely. Where the seat is really the SCADA and historian layer rather than the panel, our guide to hiring a SCADA engineer is the closer fit.
How many finalists should we expect on one of these searches?
Two, sometimes three. If a panel is looking at six finalists for an automation seat, the req is too broad and the loop is not filtering.
The pool is small and regional in a way software roles are not, because the work is physically on a floor and most of these people will not relocate for a lateral move. That is the constraint that surprises companies coming from software hiring. Widening the geography rarely helps. Widening the platform requirement does. So does deciding up front that you will train the second platform.
Should we give an automation take-home?
Skip it. A ninety-minute working session on a real artifact reads a candidate just as well and does not cost you the people who have three other conversations running.
There is a narrow exception. Where the seat is genuinely a programming seat, a small structured text or ladder exercise with the environment provided and a strict time box is defensible. Pay for it if it runs over an hour. What you should not do is send a four-hour unpaid assignment into a candidate pool this tight, because it filters out the strong people faster than the weak ones. The strong ones have options and they know it.
Watch What They Reach For First
The best automation engineers I have placed share one thing. It is not a platform.
They have all been standing in front of a line that was down, with people waiting, holding incomplete information, and they had a next move. Not the right answer. A next move, and a reason for it, and the discipline to check the cheap thing before the expensive one.
You cannot find that with a scan cycle question. You find it by putting a broken thing in front of somebody and watching where their hands go.
We hold 92% twelve-month retention on placements across more than 30 US metros, and our recruiters average 15 years on their desks. There is no assessment behind that number. It is a lot of hours listening for the incident instead of the presentation. Run the loop above yourself, honestly, because most plants can.
Where you would rather hand it off, talk to a KORE1 recruiter. Bring three things: the control platform, the travel percentage, and the name of whoever gets called when the line stops. That is enough to set a band and a sourcing plan in one call.
Hiring adjacent to this seat? Robotics engineering staffing covers cell integration and the FANUC, ABB, and KUKA side of the floor, and our guide to hiring robotics engineers in 2026 goes deeper on that loop. Where the req is really about process and throughput rather than the control system, start with manufacturing engineering staffing or industrial engineering staffing instead.
