Comaen. Find Your Spark. Software Engineer Interview Guide

The 60-second brief

Comaen. Find Your Spark. is described by candidates as a company that delivers automation projects for industrial sectors such as offshore, food and water treatment, with recycling also named as a sector. The Software Engineer works through the life of a project: analysing what the client needs, turning that into functional and technical specifications, programming PLC and SCADA software, testing in-house, and then commissioning on site. Projects can be local in the Netherlands or involve international travel, and the role also produces the documentation that lets systems be audited and maintained after handover.

This guide is for candidates applying for the Software Engineer role in industrial automation. Reported requirements are an HBO degree in Electrical Engineering, Mechatronics or Technical Informatics, 0-5 years of experience with LAD, SCL and FBD, working proficiency on at least one of Siemens, Beckhoff, Allen-Bradley or Bachmann, professional Dutch and English, and willingness to travel. SCADA/HMI visualisation design, See Electrical or similar design software, and offshore or food-processing experience are reported as pluses. The guide covers the reported questions, a seven-day plan, behavioural stories and FAQs.

No sequence of rounds is reported for this company. Candidates describe a process of roughly two to four weeks from first screen to final offer, mixing technical discussion of PLC and SCADA work with behavioural conversation.

Focus areas

• PLC (Programmable Logic Controllers)
• SCADA (Supervisory Control and Data Acquisition)
• Programmeren van PLC- en SCADA-software

Overview

The five reported questions are about hands-on automation practice: moving from a client's functional specification to a PLC design, explaining a hard bug in a PLC or SCADA system, choosing between LAD, SCL and FBD for different tasks, keeping code maintainable and documented, and describing your experience with Siemens, Beckhoff or Allen-Bradley. None of them is an algorithm puzzle, so preparation means turning your own projects into clear, structured answers rather than drilling data-structure problems.

Candidates also report evaluation areas and example scenarios. The areas are logic implementation (how you structure code so it can be read and troubleshot), hardware interfacing (connecting PLC systems to HMI and SCADA software), and advanced topics such as safety-rated PLC programming and fieldbus communication protocols. The example scenarios are structuring a project for a new machine assembly and handling hardware-in-the-loop testing before going to a site. Have a worked answer for each: modules and function blocks, operating modes, I/O mapping, alarm handling, a simulated or bench test before site, and the fieldbus and safety work you have actually done.

The role mixes independent programming with collaboration: candidates describe working with senior engineers, project managers and onsite client teams, writing technical manuals and project plans, and acting as a main contact during commissioning. Professional Dutch and English are reported as a requirement, so be ready to explain a project clearly in both. Choose two or three projects from your own history and know each one well enough to cover the client requirement, your design, the bug that cost you the most time, what you documented and what happened on site.

Where to focus your preparation

No fixed sequence of rounds has been reported, so this guide treats preparation as one block built from the reported questions and evaluation areas. Ask your recruiter which stages you will face and whether any task involves writing code.

Preparation focus

Candidates do not report a round-by-round sequence. They report a total span of about two to four weeks from the first screen to the final offer, with technical deep-dives and behavioural discussion, and a pace that varies by department and project urgency. Treat this as one preparation block. Build a project walkthrough you can deliver in either direction (requirements to commissioning, or a single bug back to its cause), prepare answers for the five reported questions, and have a worked answer for the two example scenarios: structuring a project for a new machine assembly and hardware-in-the-loop testing before site. Confirm the stage list with your recruiter before you start.

What to demonstrate

• Knowledge of PLC and SCADA architectures and of the LAD, SCL and FBD languages on a platform you have used
• A structured way of breaking down a problem: identify the issue, test hypotheses, implement a fix that holds up
• Communication and ownership, which matter because the role involves clients, senior engineers and commissioning trips
• Quality of documentation and maintainable logic, reported as part of the day-to-day work

How to prepare

• Ask the recruiter how many stages there are, who you will speak to, and whether you will write code or answer verbally
• Write a one-page walkthrough of 2-3 of your own projects covering platform, languages, fieldbus, HMI/SCADA link, your role and the outcome
• Rehearse the five reported questions aloud, starting with the specification-to-design question and the bug story
• Prepare answers to the two example scenarios: structuring a project for a new machine assembly and hardware-in-the-loop testing before site

Where candidates lose points

Answering the specification-to-design question with 'I read the spec and write the code'

Walk through the sequence you actually use: read the functional specification, list the I/O, raise ambiguities with the client, define operating modes and interlocks, plan alarms and safety functions, split the program into modules, and write a test plan before programming. Tie each step to a project.

Telling the bug story as 'it was a timing issue and I fixed it'

Tell it in order: the symptom, how you reproduced it, what you checked first (online monitoring, forcing values, comms diagnostics, trace or logs), the hypotheses you ruled out, the root cause, the fix and the check that stops it returning. Choose a bug where the cause was not obvious.

Naming a single favourite language instead of matching language to task

Say why LAD suits discrete interlocks that electricians must read, why FBD suits continuous signal flows such as scaling and control loops, and why SCL suits calculations, loops, arrays and data handling. Mention who will maintain the code, not only what is quick to write.

Treating documentation and handover as an afterthought, or describing only solo work

State the concrete habits: naming conventions, commented blocks, version control, an I/O list, a functional description and a manual for the people who will maintain the system. Include one story where you worked with a senior engineer, project manager or client team.

Describing site commissioning as the first time the code runs

Explain how you test before travelling: simulated I/O or a bench rig, a PLC simulator or hardware-in-the-loop setup, scripted test cases and a checklist for site. Say what you would still expect to find on site and how you would communicate it to the client.

Questions & practice

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

• The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
• A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

• A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
• Where does the fingerprint get computed relative to request decompression and the body-size limit?

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

1. One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
2. Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
3. State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
4. Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

• A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
• Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

1. Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
2. Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
3. For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
4. State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

• A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
• How do you honour an erasure request while resource_revision.actor_user_id still references this table?

How do you approach the transition from a client’s functional specification to a technical PLC design?

Medium · Technical Proficiency and Domain Knowled

Approach

1. Break the functional specification into concrete design inputs: an I/O list, the equipment it controls, operating modes (auto, manual, maintenance), sequences, interlocks and permissives, and the alarm list. Give every requirement an identifier so you can trace it into the design and later into test cases.
2. Structure the software around the plant, not the spec's chapters: control modules for single devices (motor, valve, analog input), equipment modules that coordinate them, and units above those, in the ISA-88 style hierarchy. Model each sequence as an explicit state machine with defined start, stop, hold and fault states (PackML is one standard state model for machines).
3. Separate the safety functions early. Anything that comes out of the risk assessment (e-stops, guard doors, safe torque off) goes in the safety-rated program on a safety CPU, validated to ISO 13849 or IEC 62061, and is never mixed into the standard logic.
4. Write down the technical choices in a software design document: tag naming convention, UDTs for device interfaces, the function block library, the fieldbus (PROFINET, EtherCAT or EtherNet/IP) and the interface to HMI/SCADA. Review it with the client before writing code, because fixing a misread requirement there costs far less than fixing it at commissioning.
5. Cover the gaps out loud: list ambiguous or missing requirements as open questions for the client, agree change control for later changes, and build the FAT test plan from the same requirement list so every requirement has a test.

Follow-up

• The client changes a sequence after the FAT. How do you handle the change in the code, the documentation and the retest?
• How do you decide which requirements go in the safety program and which stay in standard logic?
• Show how one interlock in the specification becomes a cause-and-effect entry, a piece of code and a test case.

Can you explain a complex bug you encountered in a PLC or SCADA system and your step-by-step process for resol

Medium · Technical Proficiency and Domain Knowled

Can you explain a complex bug you encountered in a PLC or SCADA system and your step-by-step process for resolving it?

Approach

1. Tell it as an investigation: the symptom and its impact, the hypotheses you ranked, the evidence that ruled each one in or out, the fix, how you verified it, and what you changed so it would not come back. Pick a bug where you made the diagnosis yourself.
2. Show a disciplined sequence: reproduce or characterise it first (when does it happen, alarm and event history, timestamps), then separate the possible layers: field hardware and wiring, fieldbus communication, PLC logic, or the HMI/SCADA side.
3. Use the right instruments. SCADA trends sample at the polling rate, so a pulse lasting one PLC scan can be invisible there. Use a high-resolution PLC trace (TIA Portal Trace, TwinCAT Scope), watch tables, and cross-references to find every place a tag is written. Only force I/O on a live plant with the operators' agreement.
4. Name root causes that actually happen in PLC code and say which one yours was: the same output written in two places so the last write in the scan wins, an edge-detection bit shared between two triggers, a signal shorter than the scan or task cycle, inconsistent data between tasks or from asynchronous communication, retentive data reset by a download, or integer overflow in a counter.
5. Close with verification and prevention: test the fix in simulation or on a test rig before an online change, watch it through the conditions that triggered the fault, and add a diagnostic or alarm that would catch it next time. Record the root cause in the project documentation.

Follow-up

• How did you test the fix without stopping production?
• Looking back, what would have found the cause faster?
• What diagnostics or alarms did you add afterwards, and has anything triggered them since?

Which programming languages (LAD, SCL, FBD) do you prefer for specific types of automation tasks, and why?

Medium · Technical Proficiency and Domain Knowled

Approach

1. Frame the answer with IEC 61131-3: Ladder (LAD), Function Block Diagram (FBD), Structured Text (SCL is Siemens' name for it) and Sequential Function Chart, with Instruction List deprecated in the 2013 edition. Then give a rule for choosing per block, not a single favourite.
2. LAD for discrete Boolean logic: interlocks, permissives, motor start/stop and safety-related status. The online power-flow view lets maintenance staff and electricians trace why an output is off without reading code.
3. FBD for signal-flow logic and continuous control: analog scaling, PID loops, alarm comparisons, where blocks wired together read like the process diagram. It is common in process plants such as water treatment.
4. SCL for anything with loops, arithmetic or data handling: iterating over arrays, recipe and parameter management, string and telegram parsing, calculations, and state machines written as a CASE statement. The trade-off is that it is harder to debug online for someone who only reads ladder.
5. Name the deciding factors: who will maintain the code after handover, the client's own programming standard (which can dictate the language), and the platform (Studio 5000 and TIA Portal both offer ladder, FBD and structured text). Mixing languages by block type is normal if the convention is documented.

Follow-up

• Write a small state machine for a fill-and-drain sequence in SCL using CASE. How do you handle a fault in any state?
• The client's maintenance team only reads ladder, but your logic is easier in SCL. What do you do?
• When would you use SFC or Siemens GRAPH for a sequence instead of a CASE statement?

How do you ensure your code remains maintainable and well-documented for future engineers?

Medium · Technical Proficiency and Domain Knowled

Approach

1. Structure: one reusable function block per device type (motor, valve, analog input) with its own instance data, UDTs for device interfaces, and equipment-level blocks that call them. Keep these in a versioned library (TIA Portal global library types, or a TwinCAT library) so a fix reaches every instance.
2. Coding rules: symbolic tags only, a consistent naming convention, named constants instead of magic numbers, each output written in exactly one place, and block headers that state purpose, inputs, outputs and revision history. Comment why a rung or line exists, not what it does.
3. Version control: TwinCAT projects are text files that work with Git directly; for Siemens, export through the TIA Portal Version Control Interface or Openness; for Rockwell, L5X exports. Commit with a message per change so the history explains the plant's behaviour.
4. Documentation that outlives the project: functional and software design documents, I/O list, cause-and-effect matrix for interlocks, alarm list and an operator or maintenance manual, updated to as-built after commissioning rather than left at the design stage.
5. Name the classic failure and how you prevent it: online changes made on site that never reach the master project. Back up the running program, merge site changes back into the repository at the end of each visit, and have another engineer review changes before release.

Follow-up

• After a commissioning trip, how do you reconcile the program running on site with the copy in your repository?
• What goes in a function block's header, and what do you leave out?
• You inherit a project with absolute addressing and no comments. What do you fix first?

One log partition stops advancing while the others drain

Easy · poison message · head-of-line blocking · consumer lag

Search results for a subset of tenants are hours stale; the rest are current. The projection consumer reports lag of zero on 15 of 16 partitions and 400,000 on one. Its error rate is flat and its CPU is idle. outbox_event has no pending rows older than a second, so the relay has published everything it holds. Identify the mechanism, give the ordered checks, and state what you do in the first ten minutes versus what you change permanently.

Approach

1. Read the lag distribution first. A slow consumer lags everywhere; zero on fifteen partitions and 400,000 on one is not throughput. Idle CPU on the stuck partition means the consumer is not advancing its offset at all, which points at one message it cannot get past rather than at a rate problem.
2. Exonerate the producer before touching the consumer. No pending outbox rows older than a second means the relay published, so the event exists in the log. This separates never sent from sent and never applied, which are different code paths and usually different owners.
3. Read the message at the stuck offset and the handler's log lines for its event_id. A flat error rate with no progress has two explanations and you must distinguish them: the handler is throwing and the retry loop is swallowing it, or the handler is blocking on something and never returning. Idle CPU with no error lines favours the second.
4. Mitigate before diagnosing further. Move the offending event to a dead-letter store and commit the offset past it. Adding consumers does nothing here, because a partition is consumed by exactly one member of the group, and the blast radius is every aggregate hashed to that partition, not only the aggregate that produced the bad event.

Follow-up

• The dead-lettered event carried aggregate_version 7 and the projection had applied 6. What must the replay do differently if 8 and 9 landed in the meantime?
• How do you show staleness to the user while the partition is behind, given the API already returns the projection's watermark?

Suggested practice checklist

The plan follows the reported questions and evaluation areas: specification to design, debugging, language choice, maintainability, platform experience, and the project stories that tie them together. Each day ends with something written or recorded.

Day 1 — Confirm the format and inventory your projects

• Ask your recruiter for the stage list, who you will speak to and whether you will write code or answer verbally.
• List 2-3 of your own projects with platform, languages used, fieldbus, HMI/SCADA link, safety work, your role and whether you commissioned on site.
• Compare that list with the reported requirements (platform, LAD/SCL/FBD, Dutch and English, travel) and note any gap you need an answer for.

Deliverable: A recruiter reply with the format, a one-page project inventory, and a short list of gaps with an answer for each.

Day 2 — From functional specification to PLC design

• Take one past specification and write the path to design: I/O list, operating modes, interlocks, alarms, safety functions, module split, test plan.
• Answer aloud the scenario of structuring a project for a new machine assembly, using that same path.
• Note the two questions you would put to a client when a specification is ambiguous.

Deliverable: A one-page design walkthrough from one real specification, plus a recorded spoken answer to the machine-assembly scenario.

Day 3 — Write the bug story

• Write your hardest PLC or SCADA bug in order: symptom, reproduction, checks, hypotheses ruled out, root cause, fix, safeguard.
• Prepare a second, shorter bug from the SCADA or comms side so you are not tied to one story.

Deliverable: Two written bug stories, each with a stated root cause and a safeguard, and one recording of the main story.

Day 4 — LAD, SCL and FBD by task

• Build a table of automation tasks (motor start/stop with interlocks, analog scaling, sequence step control, array or recipe handling) against the language you would pick and the reason.
• Write the same small function, such as a motor start/stop with an interlock, in LAD and in SCL on paper, and write an FBD layout for scaling an analog input.
• Prepare one example where you changed language or restructured code to make it easier for a colleague to maintain.

Deliverable: The task-to-language table, the paper implementations in LAD, SCL and FBD, and one maintainability example.

Day 5 — Maintainable, documented code and testing before site

• Write your maintainability checklist: naming conventions, block structure, comments, version control, I/O list, functional description, operating manual.
• Outline how you test before travelling: simulated I/O or a bench rig, scripted test cases, a site checklist.
• Answer aloud how you keep code maintainable for future engineers, using a real handover as the example.

Deliverable: A maintainability checklist, a pre-site test outline, and a recorded spoken answer to the maintainability question.

Day 6 — Platform depth, interfacing and collaboration

• Write a comparison paragraph for the platform you use most: two real advantages, one limitation and how you handled it.
• Prepare notes on one HMI/SCADA connection, one fieldbus you have used and any safety-rated programming you have done.

Deliverable: The platform comparison paragraph, a half-page of interfacing, fieldbus and safety notes, and one collaboration story.

Day 7 — Full spoken dry run

• Answer all five reported questions back to back, aloud and recorded, and cut anything you cannot support with a real project.
• Give a two-minute summary of one project in both Dutch and English, since both are reported requirements.
• Write the questions you want to ask about the team's current technical challenges and the mentoring available to newer engineers.

Deliverable: A recording of all five answers, a bilingual project summary, and a list of questions to ask.

Behavioural preparation

Candidates describe the role as a mix of independent programming and collaboration with senior engineers, project managers and onsite client teams, with documentation, commissioning duties and travel. Behavioural preparation therefore centres on stories that show ownership of your work, clear communication with clients and colleagues, and how you handled expectations when a project did not go to plan.

1. Tell me about a project you owned from requirements through to handover, including the documentation you left for the next engineer.
2. Describe a problem you met during commissioning on site and how you kept the client informed while you fixed it.
3. Tell me about a time you worked with a senior engineer or project manager to resolve a technical disagreement.
4. Give an example of managing a client's expectations when a requirement changed late in a project.

Describe your experience with specific platforms like Siemens, Beckhoff, or Allen-Bradley; what are the distin

Medium · Technical Proficiency and Domain Knowled

Describe your experience with specific platforms like Siemens, Beckhoff, or Allen-Bradley; what are the distinct advantages of the one you use most?

Approach

1. Pick the platform you have delivered the most on and open with one concrete project: the machine or process, the controller family, the engineering software, the languages you used, the fieldbus, how it connected to HMI or SCADA, and which part you owned. Two sentences of context, then spend your time on your own decisions.
2. Make the advantages specific and drawn from your own work, not brand slogans. Examples, to use only if they match your experience: Siemens TIA Portal keeps PLC, HMI and PROFINET configuration in one project; Beckhoff TwinCAT runs the PLC on an industrial PC and pairs naturally with EtherCAT; Allen-Bradley Studio 5000 uses tag-based addressing with user-defined types and add-on instructions. Say what that meant on a real job.
3. Give a balanced view: name one thing the platform makes harder (licensing or hardware cost, library reuse, tooling, diagnostics) and how you handled it. Describing a weakness in the platform you use most shows that your experience is real, and you should never run down the others.
4. Be exact about depth. Separate the platform you know well from ones you have only touched, and state your years honestly; the reported requirement is proficiency on at least one of Siemens, Beckhoff, Allen-Bradley or Bachmann, not all of them.
5. Close with transferability: how you would get productive on another platform on that list, by mapping concepts you already know (tasks and organisation blocks, data blocks versus tags, I/O addressing, fieldbus configuration, online diagnostics).

Follow-up

• If you had to port that project to another platform, what would you move first and what would you have to redesign?
• Which feature of that platform has caused you the most trouble during a commissioning, and how did you work around it?
• How would you become productive on a platform from the list that you have not used before?

Unblock an engineer without taking the keyboard

Easy · mentoring · leases · at-least-once

A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

Approach

1. Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
2. Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
3. Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
4. Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.

Follow-up

• How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
• Their handler calls an external endpoint before recording that it did. What do you tell them to change first?

Tell callers you do not own that their integration breaks

Medium · deprecation · compatibility · stakeholders

A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

Approach

1. Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
2. Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
3. Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
4. Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.

Follow-up

• How would you detect a consumer that reads the field only during a monthly export?
• One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?