Apollo Engineering Consultants Software Engineer Interview Guide

The 60-second brief

Candidates describe Apollo Engineering Consultants as an engineering consultancy that works on infrastructure projects for marine and energy clients. Those projects involve Electrical, Control and Instrumentation (EC&I) systems, and the Software Engineer writes the software that has to work with them. The reported day-to-day: turn client requirements into functional specifications and then into code, work alongside EC&I and Process engineers, document how the software was built, take part in peer code review, and in some cases support commissioning or testing on site. Because the software sits next to physical equipment, timing, failure handling and documentation carry as much weight as the code itself.

This guide is for software engineers preparing for the Apollo Engineering Consultants Software Engineer loop. It covers the five reported rounds, the nine reported questions (experience and process questions on reliability, hardware-or-software debugging, industrial protocols and real-time data, documentation and latency, plus behavioral questions on conflicting requirements, influencing a colleague, changing approach and juggling deadlines) and a seven-day plan. It suits candidates with or without marine or energy experience: the requirements candidates describe list that background as a plus, not a must.

Candidates report five rounds over roughly four to six weeks: Technical Screening, Deep-Dive Interviews, Cultural Fit Assessment, Meet Engineering Leadership and Final Selection. The same reports say the number of rounds can vary with the seniority of the role and the urgency of the project.

Focus areas

• Electrical & Instrumentation (E&I)
• Process Engineering
• Instrumentation Systems

Overview

The work sits between software and physical systems. Candidates describe a role that builds control software for EC&I projects, collaborates with EC&I and Process engineers, writes functional specifications from client requirements, keeps development records, joins peer code reviews and occasionally helps with onsite commissioning or testing. The topic labels attached to this loop are Electrical & Instrumentation (E&I), Process Engineering, Instrumentation Systems, Marine Engineering and Electrical Systems, and the technical evaluation area reported for it covers real-time constraints, fail-safes and error handling, and linking modern software to legacy hardware.

That shapes the preparation. None of the nine reported questions is an algorithm puzzle, and the advice candidates pass along is to explain engineering trade-offs instead of leaning on coding puzzles alone. Five questions ask about your experience and method: keeping software reliable inside control systems, debugging when the fault could be hardware or software, industrial communication protocols and real-time data, documentation in a regulated setting, and optimising for strict latency. Four more are stories: changing approach under new constraints, conflicting requirements between mechanical and electrical teams, persuading a colleague to adopt a better standard, and balancing deadlines across projects.

Two example scenarios are reported for the technical side: designing a control loop for a marine propulsion system, and troubleshooting a data acquisition error in a remote sensor network. Practise both aloud. For each, state the timing assumptions, what the software does when an input goes missing or stale, which part of the chain you would check first, and how you would show the fix works. C++ is the language associated with this role, so keep one project in it ready to discuss in detail.

Build every answer on the same spine: requirement, physical or timing constraint, decision, how you verified it, and what happens when something fails. Candidates also report the advice to bridge abstract software requirements and the constraints of engineering hardware, and to mention safety implications of a design. Make that concrete (the safe state, the fault you detect, the test that proves it) rather than a closing sentence.

The Apollo Engineering Consultants interview process

Candidates describe five stages, from a technical screening to a final selection. The reports do not say which questions belong to which stage, so prepare each question type for any of them.

Technical Screening

Candidates describe the first stage as a technical screening that checks your baseline for the role. No format is reported, so be ready for conversation and for code. Reported advice is to explain the engineering trade-offs behind your choices instead of relying on coding puzzles alone. Go in with a specific account of your most relevant project, from the requirement through to how you verified it.

What to demonstrate

• Baseline technical skills for a software role that touches control systems, as the stage is described
• How clearly you explain a design decision and its trade-offs
• Command of the core language you will work in

How to prepare

• Write a short walk-through of one project: requirement, constraint, design, test evidence and one failure you handled
• Practise the technical-expertise question types aloud: reliability inside control systems and debugging a fault that could be hardware or software
• Refresh the language fundamentals you will code in, such as memory ownership, timing and error handling

Deep-Dive Interviews

Candidates report discussions that dig into how you solve problems and what you did on past projects. Expect to be taken from headline to detail on your own work, so choose projects you can defend at the level of interfaces, timing and test evidence. The experience-and-process questions (protocols and real-time data, documentation in a regulated setting, latency optimisation) fit this kind of conversation.

What to demonstrate

• How you break a large, ambiguous problem into testable parts
• Depth of the past projects you cite, including your own contribution
• Hands-on exposure to industrial communication or real-time data processing

How to prepare

• Pick two projects and write the requirement, your decisions, the numbers and what you would change
• Write down every protocol or data link you have used, with framing, timeout and retry behaviour; if none, name the closest analogue
• Prepare a latency story with a baseline, a budget, the profiling step, the change and the measured result

Cultural Fit Assessment

Candidates describe a Cultural Fit Assessment aimed at how you fit a collaborative way of working. For this role, collaboration means working with EC&I and Process engineers and joining multidisciplinary project meetings, so the stories that fit are cross-discipline ones. Use first-person stories with a decision, a cost and a result, and keep the situation short.

What to demonstrate

• Alignment with a collaborative way of working, as the stage is described
• How you handle disagreement across engineering disciplines
• How you explain technical ideas to people outside software

How to prepare

• Write STAR stories on a conflict between disciplines and on persuading a colleague to change a practice
• Add numbers to each result: defects, review rounds, rework, schedule effect
• Rehearse explaining one technical trade-off to someone who does not write code

Meet Engineering Leadership

Candidates report this stage as a chance to meet several members of the engineering leadership team. The reports frame it as a way to learn about team dynamics as much as to be assessed, so arrive with informed questions about how software work is split with EC&I and Process engineers and how reviews and documentation run. Have your strongest project summary ready, since you may repeat it to different people.

What to demonstrate

• How you present your work and decisions to senior engineers
• How you handle changed constraints and shifting priorities
• Whether your working style suits a project-based team

How to prepare

• Rehearse a concise project summary that senior engineers can interrupt at any point
• Prepare a story where you changed technical approach because a constraint moved, and what it cost
• Write five questions about how software, EC&I and process engineers share work, review and commissioning support

Final Selection

Candidates describe the final step as the concluding evaluation before a decision. The reports add that the number of rounds may vary with seniority and project urgency, so treat any later conversation as part of this stage. Keep your stories and numbers consistent with what you said earlier, and be ready for both technical follow-ups and questions about handling several projects at once.

What to demonstrate

• Consistency of your account across the earlier conversations
• Readiness to handle several project deadlines at once
• Overall fit for the role, as the closing stage is described

How to prepare

• Reread your project summaries and story notes so details match across conversations
• Prepare a clear example of balancing multiple deadlines, including what you deferred and how you told people
• Keep a short list of open questions about the team and the project mix you would join

Where candidates lose points

Answering the reliability question with 'I write unit tests' and nothing about the physical system

Describe layers: requirements traced to tests, simulated inputs, fault injection for lost or stale sensor data, a watchdog and a defined safe state, and peer review. State what the software does when each input fails.

Debugging story that jumps straight to blaming hardware or software

Narrate the isolation sequence: what changed, how you reproduced it, how you checked the instrumentation, and which known-good substitute or simulated input split the two cases. End with the cause and the evidence that confirmed it.

Latency story with no baseline, budget or measurement

Give the target, the measured starting point, the profiling step that found the cost, the change, and the before-and-after numbers. Say what you checked to make sure correctness and timing under load held.

Mentioning safety as a closing sentence instead of a design property

Name the safe state, the fault you detect, the error handling and the test that proves it for each design you describe. Do this for both the propulsion control loop and the remote data acquisition scenarios.

Preparing only coding puzzles, or telling cross-discipline stories as 'we' with no personal decision

Reported advice favours explaining engineering trade-offs, so rehearse design reasoning aloud. For stories, say 'I' for what you decided, name the other discipline's constraint, and give the outcome.

Questions & practice

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

1. Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
2. Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
3. Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
4. Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

• The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
• The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

1. Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
2. For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
3. Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
4. Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

• 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
• A dashboard runs this for 40 owners in one page load. What changes about the design?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

1. Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
2. Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
3. Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
4. Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

• The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
• A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

How do you ensure software reliability when it is integrated into critical electrical or control systems?

Medium · Technical & Domain Expertise

Approach

1. Start with the hazard, not the code: say what the physical system does if the software is wrong, late or silent, and what the safe state is (for example outputs de-energised, valve to its fail position). Every design choice after that serves reaching that state.
2. Treat every input as untrusted: range checks, rate-of-change limits, timestamp or sequence checks to catch stale values, and a defined action for each fault (hold last good value for N cycles, then alarm, then go to the safe state).
3. Detect your own failure: a hardware watchdog the control loop must service every cycle, so a hang or overrun forces a reset or safe state. Keep safety trips in an independent layer (interlock or safety system) so the application software is not the only protection.
4. Constrain the code: in C++ that means no dynamic allocation or exceptions in the cyclic path, bounded loops, a coding standard such as MISRA C++, static analysis, and reviewed changes.
5. Prove it with tests that break things: unit tests on the fault handling, hardware-in-the-loop runs with a simulator, and fault injection (pulled cable, frozen sensor, out-of-range value, comms timeout) with the expected reaction written down before each test.

Follow-up

• The sensor freezes at a plausible value instead of dropping out. How does your software notice?
• How do you choose between holding the last good value and tripping straight to the safe state?
• What would you test on real hardware that a simulator cannot show you?

What experience do you have with industrial communication protocols or real-time data processing?

Medium · Technical & Domain Expertise

Approach

1. Be concrete about what you have actually used: the protocol, the transport (serial RS-485 or Ethernet), your side of the link (client or server, master or slave), the device count and the polling or update rate. If your experience is adjacent (MQTT, CAN, a custom TCP protocol), say so and map it honestly rather than claiming depth you lack.
2. Show you know the protocol's sharp edges. With Modbus: RTU frames carry a CRC-16 while Modbus TCP drops it and adds an MBAP header; registers are 16-bit, so a 32-bit float spans two registers and word order differs between vendors; it is polled, so data age depends on the scan cycle. With OPC UA: subscriptions, sampling versus publishing intervals, deadbands.
3. Describe the data path end to end: acquisition, timestamping at the source if possible, quality flags (good, stale, comms fault), then processing and storage or display. Explain how a timeout, retry and bad-quality value flow through it.
4. For real-time processing, name the bound you met and how: a fixed-size ring buffer between the acquisition thread and the consumer, no allocation in the hot path, and a deliberate overflow policy (drop oldest, drop newest, or block) chosen for what the data means.
5. Close with a measured result: update latency, missed-poll rate, or the number of devices handled, and one problem you hit and fixed.

Follow-up

• Two devices return the same 32-bit value with different word orders. How do you handle it in code and configuration?
• Your consumer falls behind the acquisition rate. What does your system do, and why that choice?
• How would you add a modern data feed alongside a legacy polled device without disturbing the control traffic?

How do you approach the documentation of code in a highly regulated engineering environment?

Medium · Technical & Domain Expertise

Approach

1. Start from traceability: every requirement has an id, and a matrix links it to the design element, the code that implements it and the test that verifies it. Then a reviewer can answer both which test covers this requirement and why this code exists.
2. Name the standard that governed the work if there was one (IEC 61508 for functional safety, with Part 3 covering software, or IEC 61511 for the process industry) and what it required of documentation, without claiming certification you did not hold.
3. Separate the layers: requirement and design documents say why and what; code comments say why a non-obvious choice was made (a unit, a timing assumption, a safety margin); generated API docs say how to call it. Avoid comments that restate the code.
4. Make documentation part of change control: commits reference the requirement or change-request id, code review records are kept, releases are tagged with a version and the test evidence, and a change to safety-related code triggers an impact analysis and re-test of the linked requirements.
5. Keep it current by automating what you can (traceability checks in CI, docs built from the repository) so the documents cannot drift silently from the code.

Follow-up

• A hotfix is needed on site tonight. How do you keep the documentation trail intact?
• How do you show an auditor that a given requirement is fully tested?
• Which documentation do you think is overhead, and how would you reduce it without losing traceability?

Walk us through a time you had to optimize a piece of software to meet strict latency requirements.

Medium · Problem-Solving & Methodology

Approach

1. State the requirement precisely: the latency budget, measured from which event to which event, and at which percentile (p99 or worst case, not the average). For control or acquisition code, say whether it was a hard deadline or a soft target.
2. Show how you measured before changing anything: timestamps at the boundaries, a profiler such as perf for CPU time, and a latency histogram under realistic load. Point out that a slow tail often comes from something the average hides.
3. Name the root cause you found and the fix, for example allocation in the hot path replaced by preallocated buffers, lock contention replaced by a single-producer single-consumer ring buffer, a blocking call moved off the time-critical thread, or a cache-unfriendly data layout made contiguous.
4. Address scheduling where relevant: thread priorities, CPU pinning, and priority inversion (a low-priority thread holding a lock that the high-priority loop needs), fixed with priority-inheritance mutexes or by removing the shared lock.
5. Close with before-and-after numbers taken under the same load and measurement method, the trade-off you accepted (memory, code complexity, flexibility), and how you guarded against regression, such as a latency test in CI.

Follow-up

• How did you know your measurement was not hiding the tail it was supposed to show?
• Your p99 is fine but you see one large spike every few minutes. Where do you look?
• What did the optimisation cost you in maintainability, and was it worth it?

Describe a situation where you had to pivot your technical approach due to unexpected project constraints.

Medium · Problem-Solving & Methodology

Approach

1. Pick a technical story with a real constraint that appeared mid-project: hardware that turned out slower or smaller than specified, a protocol the field device did not support, a certification or safety requirement found late, or a memory or latency budget the first design could not meet.
2. Explain the signal: what you measured or learned that showed the original approach would fail, and how early you raised it. Catching it from a prototype or benchmark beats discovering it at commissioning.
3. Lay out the options you weighed and the trade-off of each (cost, schedule, risk, rework), and why the one you chose fit the constraint. Say who else had to agree, such as the hardware engineers or the client.
4. Show how you limited the damage: which parts of the design survived because they sat behind a clean interface, what you rewrote, and how you re-verified the safety-relevant behaviour after the change.
5. Finish with the outcome in numbers (delivered on what date, latency or memory achieved) and the specific practice you now apply earlier, such as benchmarking on target hardware in the first week.

Follow-up

• Looking back, what earlier evidence could have shown you the constraint sooner?
• How did you communicate the change and its cost to people outside the software team?
• What would you have done if the new approach had also failed?

Describe your process for debugging a complex system where the failure could be either hardware or software-re

Medium · Technical & Domain Expertise

Describe your process for debugging a complex system where the failure could be either hardware or software-related.

Approach

1. Pin down the symptom first: exactly what is wrong, since when, intermittent or constant, on one unit or all units, and what changed recently (firmware, wiring, configuration, a software release).
2. Split the system at a boundary you can observe. Put a logic analyser or bus sniffer on the wire, or log the raw register value next to the engineering value. If the raw signal is already bad, the fault is upstream of the software; if the raw signal is good and the displayed value is bad, it is in the scaling, parsing or logic.
3. Swap one half at a time: run the software against a simulator or a known-good device, and the suspect hardware against a known-good build or test tool. A fault that follows the hardware is hardware, one that follows the build is software.
4. Use what the physics tells you. A 4-20 mA loop reading near 0 mA points to an open circuit or dead transmitter, not a low process value. A fault that tracks a motor starting or a cable route suggests noise or grounding. A fault on a fixed period suggests a timer, buffer wrap or polling conflict.
5. Close it properly: reproduce the fault on demand, fix it, show the reproduction no longer fails, and add a log, alarm or test so the same fault is diagnosed faster next time.

Follow-up

• The fault appears only on site and never on the bench. What do you do next?
• How do you tell a cause apart from something that merely changed at the same time?
• What would you log permanently so the next engineer can split hardware from software quickly?

Suggested practice checklist

The plan follows the reported loop: domain vocabulary first, then the experience questions on reliability, debugging, protocols and latency, a control-loop design talk, a behavioral story bank and a full mixed rehearsal.

Day 1 — Map the loop and the domain vocabulary

• Write the five reported rounds in order with one line each in your own words, and mark the stage you feel least ready for.
• Build a glossary for the reported topic areas (Electrical & Instrumentation, Process Engineering, Instrumentation Systems, Marine Engineering, Electrical Systems) and mark each term you can explain with an example from your own work.
• List your projects that involved hardware, timing, safety or regulated documentation, and note the gaps.

Deliverable: A one-page round map, a marked glossary and a project-to-topic table showing your gaps.

Day 2 — Reliability, safety and documentation answers

• Write your answer on keeping software reliable in control systems as layers: traced requirements, simulated I/O, fault injection, watchdog and safe state, peer review.
• Make a failure-mode table for a sensor-to-actuator loop covering lost sensor, stale reading, out-of-range value, comms timeout and power restart, with the safe behavior for each.
• Outline your documentation approach for a regulated setting: requirement link, design rationale, test evidence, review record and version history for each change.

Deliverable: Two written answers (reliability and documentation) plus the failure-mode table.

Day 3 — Debugging across the hardware and software boundary

• Write your debugging sequence: what changed, reproduce, check instrumentation and calibration, swap in a known-good part or simulated input, compare timestamps and logs.
• Talk through the remote sensor network data acquisition error aloud, listing at least six candidate causes across sensor, wiring, gateway, protocol, parser and clock, and the first check that separates them.
• Write one real debugging story with the step that isolated the fault and the evidence that confirmed the cause.

Deliverable: A decision sequence, spoken-walkthrough notes for the sensor-network scenario and one debugging story.

Day 4 — Protocols, real-time data and latency

• For each protocol or data link you have used, write framing, polling versus event-driven behavior, timeouts, retries, checksums and byte order; if you have none, describe your closest analogue and how you would learn the rest.
• Write your latency story: target, baseline, profile, change, measured result.

Deliverable: A protocol experience sheet, two solved practice questions and a latency story with before-and-after numbers.

Day 5 — Control-loop design talk and a changed-constraint story

• Sketch a control loop for a marine propulsion system: sensor read, validation, filtering, controller, actuator output, watchdog and fault handling, with sample period and worst-case execution time stated as assumptions.
• Add the interoperability layer: how the new software talks to legacy hardware, what you would test on site, and what the system does on loss of an input.
• Write the story of a time you changed technical approach after a constraint moved, covering the original plan, the trigger, the new plan and the cost.

Deliverable: One loop diagram, a spoken script of the design with its safe states, and a written pivot story.

Day 6 — Behavioral story bank

• Write four first-person stories: conflicting requirements between disciplines, persuading a colleague to adopt a better standard, changing approach, and balancing several deadlines.
• Put a number in every result and cut each situation to two sentences, then record yourself and trim.
• Write five questions for engineering leadership about how software, EC&I and Process engineers share work, reviews and commissioning support.

Deliverable: Four one-page STAR stories and a list of five questions to ask.

Day 7 — Full mixed rehearsal

• With a partner, answer a mixed set of technical and behavioral prompts aloud without notes and record it.
• Fix the two weakest answers, and check that each technical answer states its safe state and its trade-off.
• Prepare one example of deciding with incomplete requirements and finish with a one-page sheet of stories and numbers.

Deliverable: A recorded rehearsal, a list of fixes made and a one-page story-and-numbers sheet.

Cross-discipline and deadline stories

Candidates report a Cultural Fit Assessment and a meeting with engineering leadership, and the behavioral questions concern working across engineering disciplines, persuading colleagues, changing course and managing several projects. For this role, that means stories about working with mechanical, electrical, EC&I and process people, where you made the decision and measured the result.

1. Describe a situation where you had to pivot your technical approach due to unexpected project constraints.
2. Walk us through a time you had to optimize a piece of software to meet strict latency requirements.
3. Tell me about a decision you made with incomplete requirements: what you did to find the gaps and how you checked the decision afterwards.

How do you handle conflicting requirements from different engineering disciplines, such as mechanical versus e

Medium · Problem-Solving & Methodology

How do you handle conflicting requirements from different engineering disciplines, such as mechanical versus electrical teams?

Approach

1. Choose a real conflict where two sets of requirements could not both be met as written, for example an enclosure-space limit against an electrical need for heat dissipation or cable length. State each requirement in one sentence, with numbers where you have them.
2. Show that you looked under the positions: ask each discipline what its requirement protects (clearance for maintenance, signal integrity, temperature margin) so the stand-off becomes a constraint you can trade.
3. Put the options in one shared artifact, such as an interface table showing what each option costs each discipline, and decide from it. Name who owned the final call, and if it sat above you, say how you framed it for them.
4. Close with the result and the record: the requirement change was written down, affected tests and documents were updated, and you re-checked the other discipline's constraint afterwards. Say what the compromise cost.
5. The mistake that sinks this answer is a story where you simply sided with the group you sat closest to, or where phrases like 'I aligned stakeholders' hide what you actually did.

Follow-up

• What would you have done if neither team would move and the deadline was fixed?
• How did you keep the software requirement traceable after the change?
• How would your approach differ if one of the requirements was a safety constraint?

Tell us about a time you had to influence a team member to adopt a more efficient coding standard or process.

Medium · Leadership & Collaboration

Approach

1. Pick a standard with a payoff you can measure: an automated formatting or static-analysis rule, a naming convention for units, a review checklist, or a rule that tests run before merge. Define 'more efficient' with a number such as review rounds per change, defects found late or build time.
2. Start with why your colleague preferred the old way and say what was valid in it. Influence that begins with understanding reads as persuasion; one that skips it reads as pressure.
3. Lower the cost of switching: add the check to CI or a pre-commit hook, trial it on one module, and pair on the first change. Bring before-and-after numbers from that trial instead of opinions.
4. If they still disagreed, say what you did next, for example agreeing a trial period or asking the code-review owner to rule, and why you did not escalate first.
5. End with the result and the relationship: what changed, how you know the standard caused it, and what you would do differently. The mistake to avoid is a story where you told them and they complied, with no mechanism and no measurement.

Follow-up

• What if the person had been more senior than you?
• How did you know the standard, rather than other changes, caused the improvement?
• Tell me about a time the standard you pushed turned out to be wrong for the situation.

How do you manage your time when balancing multiple project deadlines in a fast-paced consulting environment?

Medium · Leadership & Collaboration

Approach

1. Open with a concrete stretch of time: name the deliverables, who each was for and which dates were fixed (a client handover, a site visit) versus internal. 'I use a to-do list' tells the listener nothing.
2. Show the method: list commitments, estimate each, separate hard external dates from soft ones, then order by deadline, dependency and cost of delay. Reserve time for review, testing and documentation steps, since they are the first things to get squeezed.
3. Show the trade-off you made: what you deferred, descoped or handed off, and that you told the affected people early, with options, instead of late with an apology.
4. Show re-planning when something slipped: which estimate was wrong, how you re-sequenced and what you checked at a regular cadence afterwards.
5. Finish with what shipped and when, and one change you made to your estimating. Working longer hours cannot be the whole answer, and claiming you never miss a deadline is not credible.

Follow-up

• Two senior colleagues each say their deadline comes first. What do you do?
• Tell me about a deadline you missed and what you changed afterwards.
• How do you estimate work on hardware you cannot access yet?