What employers actually test in PLC interviews

You have an interview booked at a mid-size SA EPCM, a panel-shop, or a brownfield petrochem operator next week. The recruiter has told you "it will be technical" with no detail beyond that. The job spec mentions Siemens, ladder logic, fault-finding, and "ability to work under pressure". Everything else is vague. This page tells you what the SA technical interview actually looks like once you walk into the room — what the live-debug exercise really measures, the brand-fluency questions hiring managers use to separate the genuine from the rehearsed, the unfamiliar-code rung-walk that filters most candidates, and why a portfolio repo on your laptop changes the conversation in a way no CV bullet ever does.

Try the simulator →

The honest version

SA control-systems hiring managers do not run their technical interviews the way the published interview guides describe. The published guides assume a US or UK process: HR phone screen, recruiter-pitched candidate, technical panel with whiteboard problems, behavioural round, offer. The SA process is rougher and more direct. The hiring manager — who is usually an engineering team lead with no formal interview training — sits you down at a laptop running TIA Portal or Studio 5000, opens a project file, points at a deliberately broken program, and says "find the bug, you have twenty minutes". That moment is the first 80 percent of the hiring decision. Everything before it (CV review, recruiter chat, agency intro) is filtering. Everything after it (cultural fit, salary negotiation, references) is paperwork.

The reason the live-debug works as a filter is that it cannot be faked. A candidate who has memorised STEP 7 syntax from a YouTube series cannot debug an unfamiliar 50-rung sequencer in real time. A candidate with three years of plant time can. The hiring manager is not measuring your knowledge of ladder logic primitives — they are measuring your debugging instinct, your ability to read someone else's code, and the speed at which you converge on the actual fault rather than chasing the obvious-looking symptom. Those are the skills you actually use on day one of the job, and they are not testable via CV bullets.

The other piece of honest framing: the candidates who do well in SA technical interviews almost always bring their own portfolio to the meeting. Not a printed CV. A laptop with three or four working projects, commented code, README files, and the ability to walk through "here is what I built and why I made these design choices". The hiring manager moves from "applicant" to "colleague" the moment the laptop opens. The candidates without a portfolio stay at the applicant frame and are evaluated against the live-debug only — which is a higher bar than the same hiring manager applies to a portfolio-bearing candidate.

What it actually takes

The live debug, what it actually measures

The live debug is the single highest-weighted exercise in an SA control-systems interview. The standard setup is a 5 to 15-rung program in TIA Portal, RSLogix or Studio 5000 — something the team has actually built, with a deliberately injected bug. The bugs the hiring manager picks are rarely syntax errors. They are logic-of-the-system errors: a missed seal-in on a start-stop, a timer preset of T#2s where the panel labelling says 2 minutes, a comparator using LessThan where the spec says LessThanOrEqual, an unlatch on the wrong rung that bypasses an interlock under a corner-case condition. The bug is something an engineer who has run the system would catch in seconds. A candidate who has only read about ladder logic will spend twenty minutes chasing the wrong rung.

What the hiring manager is reading from the exercise: do you start by reading the comments, or do you dive straight into the rungs? Do you cross-reference tags before changing logic? Do you ask clarifying questions about the system's actual behaviour, or do you assume? Do you talk through what you are doing, or do you go silent? The candidates who narrate their reasoning ("I'm checking the seal-in on rung 3 first because that's the most common cause of this symptom") almost always score higher than the candidates who just stare and edit. Narration is the signal that the debugging is structured rather than guesswork.

The exercise is also a brand-fluency test. A candidate who claims TIA Portal experience but takes 90 seconds to find the cross-reference view has not used the tool in production. Hiring managers watch for that lag and weight it heavily — claiming a tool you have not actually used is the fastest way to lose the interview. If you have only used Studio 5000, say so up-front and ask for that platform. Most SA hiring managers will respect the honesty more than they would respect a fudged TIA claim.

Brand-fluency questions, the depth-not-breadth filter

The brand-fluency questions are the second filter. They look casual but they are deliberate: "What is the difference between an FB and an FC in TIA Portal?" "When would you use an AOI versus a subroutine in Studio 5000?" "What does an AOI revision rollback do, and why might you avoid it?" "Why would you choose a UDT over a STRUCT in Siemens?" "How does a CompactLogix differ from a ControlLogix in terms of safety task scheduling?" The candidate who has built one project understands the answer. The candidate who has read about the platform but not built on it gives a vague answer that almost works.

The candidates who do best on this round give specific answers tied to a real project: "On the cooling-tower job we used AOIs because we had three identical pump skids and we needed the parameter customisation per skid; we avoided the revision-rollback because the customer's HMI was bound to the AOI tags and a rollback would break the binding." That answer cannot be faked. A candidate who has only studied AOIs gives a textbook definition. The hiring manager hears the difference inside ten seconds and weights the rest of the interview accordingly.

The brand-fluency round also tests honesty. A candidate claiming dual-brand fluency on Siemens and Allen-Bradley will get one Siemens-specific question and one AB-specific question, back-to-back. The candidate who fudges either answer is filtered out — not because dual-brand fluency is required, but because the fudge signals they will fudge other things on the job. Single-brand fluency, honestly stated, lands more offers in SA than dual-brand fluency that cannot stand up to one direct question.

The fault-finding rung-walk on unfamiliar code

The third filter is the rung-walk. The hiring manager opens a 50 to 200-rung program from a project the candidate has never seen — usually a sequencer, a batch process or a startup permissive logic chain — points at rung 17 or rung 84 and says "explain what this rung is doing and why". The candidate has to read unfamiliar code in real time, reason about its place in the system, and articulate the design intent. This is the skill the job actually requires day to day, and it is the skill the live-debug only partially tests.

What the hiring manager listens for: the candidate who reads the rung in isolation versus the candidate who immediately checks what tags it shares with neighbouring rungs. The candidate who can identify whether the rung is a permissive, an interlock, a sequencing step or a fault-detection branch within twenty seconds. The candidate who recognises common patterns — a one-shot rising-edge, a debounce, a state-machine step transition, a fault-latch with an external acknowledge — and names them rather than describing them awkwardly. Pattern recognition on unfamiliar code is the deepest signal of plant experience, and there is no way to fake it from textbook study.

The numbers that matter

The structure and weighting of a typical SA technical interview for a control-systems technician or engineer role:

Exercise	Time allocated	Weight on hiring decision	What it actually measures
CV walkthrough	5-10 min	5%	Confirms the dates and roles match the application
Live debug on prepared program	20-30 min	35%	Debugging instinct, brand fluency in real use, ability to read others' code
Brand-fluency Q&A	10-15 min	15%	Depth of platform knowledge, honesty calibration
Rung-walk on unfamiliar code	15-20 min	20%	Pattern recognition, plant-experience proxy
Portfolio walkthrough (if candidate brings one)	10-15 min	15% (replaces 15% from other exercises)	Real project quality, design-decision articulation
Behavioural / fit	10-15 min	5%	Team-fit signal; rarely changes the decision
Salary discussion	5-10 min	5%	Negotiation reality check

The weighting tells you the prep priority. Practising live-debug on the simulator and being honest about brand fluency converts more SA offers than any other interview prep activity. CV polishing converts almost nothing past the recruiter screen. Behavioural-question practice is a thin marginal gain. The portfolio is the single highest-impact prep activity because it changes the structure of the conversation rather than just improving your performance within the standard structure.

The pass rates we observe across the SA controls hiring funnel: roughly 30-40 percent of CV-only candidates who reach the technical round get an offer; roughly 65-75 percent of candidates who bring a credible portfolio to the technical round get an offer. The portfolio doubles the conversion rate in the round that matters.

Stories — the patterns we see

The most common pattern: a 32-year-old EC&I technician with five years on F&B, applies for a control-systems engineer role at a Highveld mining EPCM, brings no portfolio, performs solidly on the live debug (catches the bug in 14 minutes), gives textbook answers on the brand-fluency round, gets the offer at the bottom of the band. He could have negotiated R5-8k a month higher with a portfolio in hand. The portfolio gap cost him roughly R1m in lifetime earnings on the curve.

The second pattern: a 28-year-old with three years on petrochem in Sasolburg, brings a laptop with three projects — a batch-reactor sequencer he wrote on the simulator, a fault-tolerant pump-station rotation logic, and an HMI-to-PLC tag-binding example with version control. The hiring manager spends 25 minutes walking through his projects rather than running the standard live-debug. The candidate ends up explaining design choices rather than defending against questions. He gets the offer at the top of the band, plus a project-specific add-on for the brand fluency he demonstrated. The portfolio shifted both the conversation structure and the wage outcome.

The third pattern, the cautionary one: a candidate with strong CV bullet-points but thin actual experience claims dual-brand fluency on Siemens and Rockwell. The hiring manager opens a TIA Portal project, asks for a cross-reference on a specific tag, and watches the candidate flounder for 90 seconds with the toolbar. The interview is effectively over by minute three. The same candidate, claiming only Rockwell fluency honestly, would have been measured against a different bar and would likely have landed an offer. The fudge cost him the role.

The fourth pattern: a senior candidate, 12 years experience, no portfolio, walks into the rung-walk and pattern-recognises the unfamiliar 200-rung program in under two minutes. Names the design pattern (a state-machine sequencer with two parallel branches). The hiring manager closes the laptop, asks two more questions, and offers at the top of the senior band. Plant experience that deep does not need a portfolio to demonstrate — it shows up in the rung-walk inside 60 seconds and the rest of the interview is paperwork.

Common mistakes

• Claiming brand fluency you do not have. The live-debug exposes it inside three minutes. Single-brand honesty beats dual-brand fudge every time.
• Going silent during the live-debug. Narrate your reasoning. The hiring manager is reading your debugging structure as much as the result.
• Bringing only a CV. The portfolio is the single highest-impact prep activity. Three working projects on a laptop changes the conversation structure.
• Practising textbook answers on brand-fluency questions. Answer with project context. "On the X job we used Y because Z" is the only answer format that lands.
• Treating the rung-walk as a test of memory. It is a test of pattern recognition. Name the pattern; do not describe the rung in isolation.
• Over-preparing behavioural questions and under-preparing the live-debug. The behavioural round is 5 percent of the decision. The live-debug is 35 percent. Allocate prep time accordingly.

15 PLC interview questions and straight answers

The sections above describe the structure. This is the ammunition: the fifteen plc programming interview questions that come up most often in SA brand-fluency rounds, with the answers a hiring manager actually wants to hear. Memorising these word-for-word defeats the point — the live-debug will expose it — but if any answer below surprises you, that's a gap to close before the interview, not during it.

1. Walk me through the PLC scan cycle

Read the physical inputs into the input image, execute the logic top to bottom against that frozen image, write the output image to the physical outputs, then do housekeeping and comms. Inputs don't change mid-scan, which is why a rung can rely on the same input value as the rung above it. Mention that immediate I/O instructions exist as the deliberate exception and you've separated yourself from the textbook candidates.

2. Why does a normally-closed e-stop button use a normally-open instruction in the program?

Because the instruction examines the bit, not the button. An NC e-stop wired healthy puts 24 V on the input, so the bit is 1, so an examine-if-closed (XIC) passes power while everything is fine. Pressing the button — or a broken wire, which is the whole point of NC wiring — drops the bit to 0 and the rung goes false. Candidates who say "NC button means NC contact" fail this one instantly.

3. When would you use a seal-in instead of SET/RESET, and why?

A seal-in is re-evaluated every scan, so the output drops the moment the stop branch opens or power is lost, and the machine stays off until someone presses start again. A latched bit (SET/RESET) stays set until explicitly unlatched, and if it lives in retentive memory it survives a power cycle — meaning a motor can restart on power-up with nobody near the start button. Default to seal-in for anything that moves; the pattern is worked through in the start-stop seal-in exercise.

4. TON vs TOF vs TP — what's the difference?

A TON delays the turn-on: output goes true after the input has been true for the preset, and drops immediately when the input drops. A TOF delays the turn-off: output follows the input true immediately, then holds for the preset after the input drops — fan run-on after a heater stops. A TP fires a fixed-width pulse on the rising edge regardless of how long the input stays on. The instruction-level detail, including what each accumulator does when the rung goes false, is in the timers reference.

5. What happens when a counter counts past its preset — and past its data type's maximum?

Past the preset, the done bit stays set and the accumulator keeps counting; nothing resets itself. Past the data type maximum (32 767 for a 16-bit INT) the behaviour is platform-specific — some controllers fault, some wrap negative — and either one ruins a totaliser. Design the reset deliberately and use a 32-bit counter for anything that accumulates over a shift; the failure modes are covered in the counters reference.

6. Why is putting the same output coil on two rungs a problem?

Because the output image is written once at the end of the scan, the last rung to write the coil wins, every scan. The first rung's result is silently overwritten, so online monitoring shows that rung "energised" while the physical output does whatever the later rung says — which is exactly the kind of lie that burns hours during a callout. The fix is intermediate bits OR'd into a single coil.

7. What are your rules for forcing I/O?

Forces are for commissioning and proving wiring, nothing else. Announce it, log it, put a person at the machine if anything can move, never force a safety signal, and strip every force before leaving site — a forgotten force is invisible until it costs a hand or a batch. The discipline side of this is written up in watchdog and force discipline, and a candidate who answers this question casually does not get the job.

8. What happens to retentive memory after a power cycle?

Retentive areas hold their last values through power loss; non-retentive areas reinitialise to defaults on power-up. So a retentive counter or an RTO accumulator carries on where it left off, which is what you want for a production totaliser and precisely what you don't want for a motor run command. Know which memory areas are retentive by default on your platform, because the defaults differ between Siemens and Rockwell.

9. Scale a 4-20 mA input from raw counts to engineering units

Straight-line interpolation: EU = (raw − rawMin) × (EUmax − EUmin) ÷ (rawMax − rawMin) + EUmin. Know your platform's nominal raw span — 0 to 27 648 on a Siemens analog channel for 4-20 mA, while many Rockwell cards can scale to engineering units onboard. Then sanity-check it: 12 mA must land exactly mid-range, and if it doesn't, your rawMin is wrong, usually because someone ignored the live-zero offset.

10. What's the difference between an interlock and a permissive?

A permissive must be true to allow a start and is typically ignored once the equipment is running — lube pressure proven before the start command is accepted. An interlock must stay true while running and trips the equipment the moment it's lost. Confusing the two gives you either a machine that refuses to start or one that won't trip when it should, and the hiring manager has met both.

11. What is the scan watchdog for?

It's a supervisory timer that checks each scan completes within a configured maximum. Its job is to catch runaway logic — a stuck loop, a blocked comms call, an oversized data copy — before the controller spends so long computing that it stops controlling. It exists because a PLC that isn't scanning isn't watching the plant.

12. What actually happens if scan time exceeds the watchdog?

The CPU faults. On Siemens, the time-error OB gets called if it exists; if it doesn't, the CPU goes to STOP and outputs fall to their configured safe state. On Logix it's a major fault that needs a fault routine or a human to clear. The classic cause is an unbounded loop in structured text added during commissioning, which is why the question follows the watchdog one.

13. FB vs FC in Siemens — when do you use each?

An FB has an instance data block, so its static variables persist between calls — timers, edge memory, and state machines live happily inside one. An FC has no instance memory, only temps, so its outputs must be fully computed from its inputs on every call, and an uninitialised temp produces intermittent garbage that's miserable to find. The full breakdown is in the FB vs FC reference, and this is the single most common Siemens fluency question in SA interviews.

14. Tags vs addresses — what's the practical difference?

On Rockwell platforms the tag is the memory object itself; there's no underlying absolute address to fall back on. Siemens classic works the other way: absolute addresses like %I0.0 and %MW20 with symbols layered on top, and TIA Portal's optimised blocks remove absolute access entirely. The practical consequence shows up in cross-referencing and HMI binding — on a non-optimised Siemens DB, an absolute pointer can quietly outlive a renamed symbol and point at the wrong data.

15. How do you prove a fault is the sensor and not the program?

Split the problem at the I/O boundary. Meter the field signal at the terminal, check the channel LED, then look at the input bit online. If the bit doesn't follow the wire, the fault is sensor, wiring or card; if the bit follows the wire but the output misbehaves, it's logic — cross-reference the tag and walk the rungs. The first-fault annunciator exercise builds exactly this boundary-first habit, and narrating this split out loud during the live-debug is worth more than getting the bug quickly.

How the simulator fits

The simulator's exercise sets are built specifically around the live-debug and rung-walk patterns SA hiring managers test on. The Free tier covers the start-stop, latched-output and basic timer/counter patterns the entry-band live-debug filters on. The Basic tier (USD 12 a month) opens the project-builder so you can write your own three-project portfolio. The Pro tier (USD 29) opens the deliberate-bug exercise sets — 40 prepared programs across TIA Portal, RSLogix and Studio 5000, each with a specific injected fault, mirroring the kinds of bugs SA hiring managers actually plant. Practising on those for 8-12 weeks before an interview round is the highest-impact prep activity available for SA controls roles.

What the simulator will not do: it will not put you in front of an interviewer. The interview pipeline still goes through the recruiter network, LinkedIn, ISA Sasolburg branch meetings, the SAIMC events and the panel-shop word-of-mouth network. The simulator builds the skills the interview tests for; you still have to source the interview through the SA controls network. A 12-week simulator-prep block plus a properly worked LinkedIn presence is the combined prep that produces interview offers.

Start the free tier →

Vendor reference

The cross-vendor industry credential SA hiring managers recognise is the ISA training and certification programme, specifically the CCST Level I, II and III ladder. For background on the technical-interview structure across engineering disciplines, Wikipedia: Technical interview describes the live-coding analogue that the live-debug ladder exercise inherits from. SA-specific events for the recruiter pipeline: ISA Sasolburg branch (monthly meetings, Highveld petrochem hiring managers attend), SAIMC Joburg branch (mining and EPCM hiring), the AfricaCom satellite events (panel-shop and OEM hiring).

What we don't claim

This site is not SAQA-registered, not MerSETA-accredited, and not an NQF-registered qualification provider. We are not a recruitment firm and we do not place candidates with SA hiring managers. The interview-structure observations on this page are reconciled across panel-shop, EPCM and end-user hiring patterns we have observed across the SA controls market in 2024-2026 — they are not formal hiring-process documentation from any specific employer. We are not an ISA cert delivery partner; our cert packs are CCST-aligned but the formal exam still goes through ISA directly.