PLC Interview Questions: 15 Answers and a Debugging Exercise

PLC interview questions are useful preparation when you use them to explain requirements, trace behaviour and test a conclusion. The fifteen questions below cover core programming and troubleshooting topics. They are practice prompts, not a surveyed list of what every South African employer asks.

An employer may use a technical discussion, a written exercise, a project walkthrough, practical assessment or a combination. Ask about the actual format and relevant platform before the interview. There is no verified basis here for assigning a universal percentage of the hiring decision to a live-debug exercise or promising that a portfolio doubles offer rates.

This guide includes careful sample answers and a fictional boundary-testing task. Use them to identify gaps, then practise explaining an example from your own learning or work. Describe simulator experience as simulator experience and distinguish it from production responsibilities.

Prepare for the role and assessment you actually have

Read the vacancy and separate required qualifications, experience, technical responsibilities and working arrangements. A junior learning opportunity and a commissioning role can require different evidence. Your preparation should reflect those requirements rather than an assumed standard interview for the entire automation industry.

For opportunities in Johannesburg, Pretoria, Cape Town, Durban or elsewhere in South Africa, check the employer's actual location, travel and shift expectations. Do not assume that a province determines the interview format or the acceptable PLC platform. Answer those practical questions accurately alongside the technical ones.

Ask which software or controller family will be used, whether you should bring a device, and what reference material is allowed. If the exercise is remote, clarify access arrangements and how results should be submitted. These are preparation questions, not requests to be given the answers.

Prepare one relevant example you can explain in detail. The portfolio versus CV guide for PLC jobs shows how to document your contribution, environment and test evidence. A portfolio can support a discussion while the employer's other requirements still apply.

02

Fifteen PLC interview questions with useful sample answers

Each answer gives a starting point and identifies an assumption worth checking. Avoid memorising wording that you cannot connect to a program or trace. Where behaviour depends on a controller, module or instruction version, state that dependency and explain which documentation you would consult.

1. How would you explain the PLC scan cycle?

A basic cyclic model reads or uses input data, executes scheduled logic and updates outputs, but the exact timing and ordering depend on the platform. Check task scheduling, process-image behaviour, communication updates and any direct I/O access. Do not claim every physical input remains unchanged throughout every routine.

Rockwell's ControlLogix I/O update documentation explicitly describes asynchronous updates relative to logic execution. If a calculation requires a consistent set of values, investigate an appropriate snapshot or transfer method for that data. The PLC scan-cycle guide explains why a simple classroom diagram needs these qualifications.

2. Is a normally closed physical contact the same as a normally closed program instruction?

No. A physical contact describes a device's electrical behaviour under defined conditions. A Boolean instruction tests the value presented to the program. You need the wiring, input configuration and tag mapping to connect those two descriptions.

For a fictional Boolean example, an instruction that tests for true passes when its bit is true, regardless of why that bit has that value. Do not infer a complete emergency-stop function from that observation. Electrical faults, diagnostics and safety requirements need the appropriate system design; an ordinary logic instruction is not proof of that design.

3. When would you choose a seal-in or a set/reset arrangement?

Choose a structure that implements the required state and restart behaviour clearly. A seal-in uses feedback in a condition evaluated by the program. A set/reset arrangement changes stored state according to its set and reset conditions. Check priority when both requests occur and identify all writers to the state.

Neither pattern alone guarantees the required behaviour after power loss, a task interruption or a held Start signal. Specify those cases and test them in the actual environment. Explain the purpose of the pattern rather than saying that one drawing is automatically suitable for every moving machine.

4. What are TON, TOF and TP used for?

They describe common timing functions: an on-delay, an off-delay and a pulse function. A useful answer sketches the expected input and output timing, then checks the exact instruction's reset, retrigger and call behaviour. Similar names across platforms do not establish identical details.

For an on-delay exercise, test an input that stays true beyond the preset and another that becomes false before it. State the units and how often the instruction executes. The TON, TOF and TP reference gives a more detailed framework for comparing those cases without assuming every timer family uses the same state model.

5. Does a counter stop when it reaches its preset?

That depends on the instruction or program. A preset can be a comparison threshold rather than a maximum. Check the data type, reset priority, edge handling and overflow behaviour instead of assuming that the count clamps or resets automatically.

A good test includes a held input, a new edge, reset occurring with an edge, the preset boundary and the supported numeric limit. A wider type can increase range but does not remove the need to calculate whether that range is sufficient. State the exact counter implementation before predicting its result.

03

6. Why can multiple writes to the same tag be difficult to debug?

Within a particular execution sequence, a later write can replace an earlier value. The visible rung order may not tell the whole story when other routines, tasks, aliases, communication paths or force mechanisms are involved. Cross-reference the tag and establish when each possible writer executes.

A useful design goal is clear ownership of the final command, with intermediate conditions combined deliberately. Do not solve every multiple-writer problem by blindly OR-ing conditions together: that can change priority or defeat an intended restriction. First establish the required behaviour and then choose the structure that represents it.

7. What would you check before considering an I/O force?

Confirm the authorised test procedure, the exact signal and its effects, the equipment state, the responsible people and the restoration checks. In an interview, explaining those requirements is more useful than immediately proposing to override a signal to see what happens.

Also distinguish a force entry from an enabled force and from an ordinary value write. Logix Designer's Force documentation describes controller-level enable status and the relationship between aliases and their underlying values. These details matter when checking what is active. A simulator override should not be assumed to reproduce every hardware controller's force mechanism.

8. What does retentive memory mean?

Ask which event the value is expected to survive. Retaining state between block calls is different from retaining it through power loss, a restart, a download or a memory reset. The platform, data configuration and operation determine the applicable behaviour.

For a learning project, document the starting values and test the specific restart operation you claim to support. Do not assume that every timer accumulator or counter automatically resumes in the desired way. A retained run request can have very different implications from a retained production total, so connect the data choice to its purpose.

9. How would you scale an analogue value?

For a defined linear range, subtract the raw starting value, divide by the raw span, multiply by the engineering span and add the engineering starting value. Check units, numeric conversion and whether the raw span is non-zero. Obtain the nominal raw endpoints from the configured module and range rather than a universal brand rule.

For a fictional input of 200–1000 representing 0–80 units, a raw value of 600 represents 40 units. Check both endpoints as well as the midpoint. Treat unknown or invalid data separately; a plausible scaled number does not prove signal health. See PLC scaling and resolution for further worked examples.

10. How do you distinguish a permissive from an interlock?

Terminology can vary, so translate the words into a behavioural requirement. Does the condition need to be true only when accepting a start, continuously while operating, or during a specific sequence step? What happens when it becomes false, and what is required before operation can resume?

Do not assume a condition is ignored after startup simply because someone calls it a permissive. Ask for the cause-and-effect or sequence requirement, then trace the implemented logic against it. Naming the condition is useful; specifying when it applies is what makes the answer testable.

04

11. What is a task watchdog, and what does its expiry mean?

A task watchdog monitors execution against a configured time limit in the documented controller model. It is different from an ordinary process timer or a communication heartbeat. Determine the fault response and output behaviour from the controller configuration and applicable manuals.

The Rockwell tasks, programs and routines manual explains that its task watchdog timing includes interruptions by other tasks and that expiry causes a major fault. Further behaviour depends on fault handling. Do not present increasing the watchdog limit as a diagnosis, or assume one universal safe output state follows every controller fault.

12. What is the difference between a Siemens FB and FC?

In the relevant Siemens programming model, an FB uses instance data for its static state, while an FC does not have that instance data block. That makes an FB useful when a block needs state associated with each instance. It does not automatically establish retention through every restart operation.

The Siemens S7-1200/1500 programming guideline, version 1.6 discusses FCs, FBs and global data blocks. Use the documentation applicable to your software version when checking the details.

An FC is not necessarily a mathematically pure function: it can access permitted external data, so review its interface and actual dependencies. Check how temporary values are initialised and outputs assigned. Explain a real or fictional use case without claiming that all state must come only from the FC's explicit input parameters.

13. What would you check when an HMI value disagrees with a PLC value?

Confirm that both displays refer to the intended tag, instance and revision. Then check data type, scaling, update timing, connection status and quality indications. A familiar label on two screens does not establish that both are reading the same underlying value.

Use timestamps or a controlled observation where appropriate to separate stale data from incorrect mapping. Avoid changing the PLC calculation until the data path is understood. If you cannot verify the HMI configuration in the exercise, state that limit instead of declaring the PLC or HMI faulty from one screenshot.

14. How would you investigate a missing feedback signal?

Start from the required behaviour and establish what evidence is available at each relevant point: the field condition, module diagnostics, mapped data, program condition, output command and feedback interpretation. Consider execution, validity and overrides as well as sensor, wiring and configuration causes.

A displayed bit matching one observation does not prove that all downstream logic is correct. Equally, an unexpected bit does not identify a sensor as the only possible cause. Describe an authorised diagnostic sequence and the evidence that would distinguish hypotheses; do not propose unsupervised electrical measurements as an interview shortcut.

15. How do you know a code change fixed the fault?

First reproduce the discrepancy against a clear requirement. Make a justified change, repeat the failing case and check related boundaries or interactions. Record the program revision and actual results. A successful compile establishes a different fact from correct runtime behaviour.

Explain what remains outside your evidence. A virtual exercise may validate selected logical cases without demonstrating physical I/O timing, installation safety or production performance. The PLC troubleshooting guide develops this distinction between a symptom, a hypothesis and a supported conclusion.

A fictional PLC live-debug exercise with a boundary fault

Use this paper model to practise a short explanation. It classifies an integer Reading from 0 through 100 as WithinBand when the value lies from 40 through 60 inclusive. Values outside 0–100, or an unknown reading, are invalid for this exercise. The model has no physical sensor or actuator.

Return two results: Valid and WithinBand. For an invalid input, Valid is false and WithinBand is false as a placeholder. That placeholder must not be interpreted as a valid reading below or above the band. For a valid input, WithinBand follows the inclusive comparison.

Revision A checks Reading greater than 40 and less than 60. Revision B checks Reading greater than or equal to 40 and less than or equal to 60. Both revisions use the same validity rule. The deliberate defect is therefore the excluded boundary values, not a different range or data-quality policy.

05

Predict the results before changing the comparisons

Reading	Valid	Expected WithinBand	Revision A WithinBand
Unknown	false	false placeholder	false placeholder
-1	false	false placeholder	false placeholder
0	true	false	false
39	true	false	false
40	true	true	false
41	true	true	true
50	true	true	true
59	true	true	true
60	true	true	false
61	true	false	false
100	true	false	false
101	false	false placeholder	false placeholder

The midpoint passes even in the faulty revision. Testing only 50 would therefore fail to expose the defect. The boundary values 40 and 60 distinguish the two implementations, while 39 and 61 help check that the correction has not widened the band beyond its requirement.

For the declared integer domain, you can check every value from 0 through 100. Revision A and B should differ only at 40 and 60. There are 21 integers in the inclusive band, compared with 19 in the strict interior. This count is a check on the example, not a claim about industrial measurement accuracy.

Explain the correction and its limits

A concise explanation would be: “The specification includes both endpoints, but the comparisons exclude them. I reproduced the mismatch at 40 and 60, changed the operators and checked the neighbouring values. I also retained the separate validity result for invalid inputs.”

Then identify what the model does not address: non-integer data, measurement uncertainty, signal quality beyond the supplied validity rule, changing limits, hysteresis or physical action. Those are possible additional requirements, not behaviours you should silently add during the exercise.

If an interviewer supplies different requirements, adapt the test to those requirements. Do not insist that inclusive comparison is always correct. A strict boundary can be intentional; the fault exists here because the supplied specification explicitly includes the endpoints.

Practise a technical conversation without inventing an employment story

Use a project you can accurately describe, whether it came from work, supervised training or personal study. State what was supplied, what you changed and what you tested. If you use a fictional process, say so. A made-up customer installation does not become credible because its explanation includes a city or a PLC brand.

For rehearsal, ask someone to choose one requirement, one unexpected input and one follow-up question. Explain your reasoning, then listen to the correction or new information. This is a suggested learning activity, not a validated employer scoring system or a prescription for how long every interview should last.

The PLC interview preparation resources provide a relevant starting point for further practice. Check the current access conditions and exercise environment. Do not describe a learning interface as vendor-native TIA Portal or Studio 5000 experience unless that is actually the tool you used.

Use PLC program testing resources to organise small cases and evidence. Neither resource establishes what a particular employer will ask or guarantees an employment or certification outcome.

06

Questions about PLC interview preparation in South Africa

How should a graduate prepare without plant experience?

Describe your qualification and learning honestly, then select a small project you can explain and test. Practise reading an unfamiliar requirement and identifying missing information. Do not claim commissioning experience from a virtual exercise; use it as evidence of defined learning.

What should an electrician moving into PLC work revise?

Connect your existing experience to signal interpretation, task execution, logic state and documented testing. Review the parts you have not used rather than assuming trade experience covers every programming concept. The vacancy determines which additional qualifications or experience the employer requires.

What if the interview uses a PLC brand I have not used?

State your background before the exercise and ask what environment is expected. You can explain transferable concepts while identifying where you need the exact manual or tool guidance. Do not invent production familiarity, but do not assume that one unfamiliar menu proves you cannot learn the platform.

Can I use notes, manuals or AI during a remote assessment?

Follow the assessment's explicit rules and ask if they are unclear. Do not use undisclosed assistance where independent work is required. For your own preparation, verify any suggested answer against the requirement and documentation so that you can explain it yourself.

What if I cannot solve the fault within the available time?

Summarise what you established, what you ruled out and which hypothesis remains. Identify the next observation or test that would resolve it. Do not label an untested change as a fix. A clear account of incomplete evidence is more useful than a confident but unsupported conclusion.