Combustion Research Associates Software Engineer Interview Guide

The 60-second brief

Candidates describe Combustion Research Associates as an engineering firm whose work spans engineering, design and commissioning for industrial and defence projects. Reported topics for the role include 3D CAD, CAD modelling, commissioning engineering and installation engineering alongside general software engineering. The Software Engineer role, as candidates describe it, covers software for data-driven interfaces, automation tools and system integration. That work sits next to mechanical and design engineers, and it includes troubleshooting during the commissioning or installation phase of a project.

This guide is for candidates applying to Combustion Research Associates as a Software Engineer, including people whose evidence comes from academic or trainee projects rather than long industry tenure. It covers the four reported rounds, the ten reported questions (technical discussion, problem-solving and behavioural), how to structure each answer, and a seven-day schedule that ends in a full spoken run-through.

Candidates report four rounds over about 3-5 weeks: Initial Assessment, Problem-Solving Evaluation, Interaction with Stakeholders and Final Assessment. Reports give each round a one-line description rather than a list of questions per round.

Focus areas

• Software Engineering (General)
• 3D CAD
• CAD Modeling

Overview

The reported questions read less like algorithm puzzles and more like engineering conversations. Several ask how you keep software reliable and safe when it is wired into mechanical or industrial systems, how you debug a complex failure under deadline pressure, and how you would connect custom software to 3D CAD or commissioning workflows. Others ask about real-time data processing and monitoring, optimising live code, and the trade-off between performance and maintainability. Nothing in the reports mentions a coding-puzzle round or a take-home, so the preparation that pays is explaining real engineering decisions precisely.

The role, as candidates describe it, produces data-driven interfaces, automation tools and integration software that sit beside mechanical and design engineering, with troubleshooting during commissioning or installation. That has a practical consequence for your answers: show what happens when a sensor feed stops, when a tool is run on a site machine you cannot easily reach, or when a spec and a drawing disagree. Prepare each technical answer as a mechanism (what you checked, what you changed, how you confirmed it) rather than an adjective such as robust or careful.

Reported requirements list core programming languages, familiarity with the software development lifecycle and the ability to read technical specifications as must-haves. CAD-related software, industrial automation protocols and exposure to defence or large infrastructure projects appear as nice-to-haves. Candidates also mention system-level software as a useful strength. If your background lacks the nice-to-haves, plan to be explicit about the nearest thing you have built and how you would close the gap, and have one project ready that you can defend line by line.

Round three is described as an exchange with technical leads and project stakeholders, and several reported questions are about non-technical feedback and cross-functional bottlenecks. Prepare stories where you translated a vague request into a testable requirement, and practise saying a technical trade-off in plain terms. The loop is reported to run about 3-5 weeks, so you can spread preparation across it, but have the project stories and the reliability answer ready before the first conversation.

The Combustion Research Associates interview process

Candidates report four rounds spread over about 3-5 weeks. Only the round names and a one-line description of each are reported, so each stage below pairs that description with preparation tied to the reported questions.

Initial Assessment

Candidates describe the Initial Assessment as a first review of your technical background and how well it matches the role. Reports do not break it into set questions, so expect to be asked to walk through what you have built and the languages and tools you used. Your goal is to show the match with the listed requirements: core programming languages, the software development lifecycle and reading technical specifications. Choose two projects and prepare the architecture, your own contribution, one failure and one decision you would now make differently.

What to demonstrate

• Technical background and how it maps to the reported requirements (core languages, development lifecycle, reading specifications)
• Whether you can explain a past project's architecture and your own part in it
• Familiarity with general software engineering fundamentals

How to prepare

• Write a half-page summary of two projects: components, why each was chosen, your contribution, what broke
• Rehearse the reliability and safety answer for software that touches mechanical or industrial equipment: requirements, defensive checks, safe state on failure, testing, review
• Rehearse the debugging-under-deadline sequence as a numbered list you can say without notes
• List the nearest equivalent for any nice-to-have you lack (CAD software, automation protocols) and how you would learn it

Problem-Solving Evaluation

Candidates describe the Problem-Solving Evaluation as deeper technical discussion of how you approach problems. The reported question types in this area cover debugging a complex failure, integrating custom software with CAD or commissioning workflows, performance versus maintainability, and learning a tool quickly. Treat it as a spoken design review: state the constraints, name two options, pick one and say how you would verify it.

What to demonstrate

• How you break a multi-part engineering problem into smaller pieces
• How you identify constraints, compare options and validate a fix or design
• Technical depth in general software engineering

How to prepare

• Prepare an integration outline for custom software meeting an existing CAD or commissioning workflow: data formats, who owns each side, versioning, what happens when a file or message is malformed
• Prepare a performance-versus-maintainability answer with one real case where you chose each side and what it cost
• Practise a real-time monitoring answer: bounded buffers, timestamps, stale-data detection, alert thresholds

Interaction with Stakeholders

Candidates describe Interaction with Stakeholders as a conversation with technical leads and project stakeholders, aimed at understanding how the company's work operates. The reported behavioural questions, about non-technical feedback during design and cross-functional bottlenecks, fit this format. Prepare to explain technical choices without jargon, and prepare questions of your own about how software, mechanical and commissioning work hand off to each other.

What to demonstrate

• Communication of technical ideas to people outside software
• Collaboration across disciplines such as mechanical and commissioning engineering
• How you turn project requirements into executable technical tasks

How to prepare

• Write two stories in situation, task, action, result form: one on non-technical feedback during design, one on a cross-functional bottleneck
• Practise explaining one trade-off (for example speed of delivery against test coverage) in plain language with no acronyms
• Prepare three questions about how software work is specified, handed over and supported during commissioning or installation
• Prepare the optimisation story with before and after numbers, since technical leads may ask how you reasoned

Final Assessment

Candidates describe the Final Assessment as a thorough review of how deep your knowledge goes and what you could contribute. Reports give no detail beyond that, so treat it as a chance to consolidate: be ready to go back into any earlier answer, defend the tools you named against alternatives, and explain why high-stakes engineering work appeals to you.

What to demonstrate

• Depth of knowledge behind the claims made in earlier rounds
• Potential contribution to the kind of engineering work the role involves
• Consistency between your stories, your technical answers and your stated motivation

How to prepare

• Re-read your earlier answers and note every tool or technique you named; write one reason you chose each over an alternative
• Prepare the rapid-learning story: the deadline, how you triaged what to learn, what you built first, and what you got wrong
• Write a short motivation answer tied to a concrete past habit shaped by high consequences
• Prepare a closing summary of what you would work on in the first months and what you would ask to learn

Where candidates lose points

Answering the reliability and safety question with "I test thoroughly" and no mechanism

Structure the answer in layers: clear requirements, input validation, a defined safe state on failure, tests that cover fault cases, review, and documentation. Attach one real example to each layer you claim.

Telling a debugging story that jumps straight to the fix

Narrate the sequence: reproduce, find what changed, narrow with a test that rules out half the candidates, confirm the cause rather than the trigger, fix, then add a check that would have caught it. Say what you did first under the deadline and what you deferred.

Describing an optimisation with no measurement before or after

Give the symptom as a number, the profiler or timing evidence for the bottleneck, the change, and the new number. Mention what you compared to prove the output was unchanged and how you could roll back.

Explaining stakeholder or cross-functional stories in jargon, or as a story where you were simply right

Say the trade-off in the other person's terms, show how their feedback changed the design or why you held a constraint, and name the artefact (spec, mock-up, interface file) that made agreement stick.

Claiming CAD, real-time or industrial-protocol experience you cannot back up under follow-up

State the closest thing you have actually built, describe it in detail, and say how you would learn the rest. A detailed adjacent project holds up better than a broad claim.

Questions & practice

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?

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?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

• Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
• Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

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?

How do you ensure the reliability and safety of software integrated into mechanical or industrial systems?

Medium · Technical Competency and Domain Knowledg

Approach

1. Start from a hazard analysis rather than from the code. List each failure mode (sensor fault, lost comms, hang, bad command), rate its severity and say which ones can hurt people or equipment. If the domain has a functional-safety standard such as IEC 61508, say how its integrity levels set the rigour of each part.
2. Define an explicit safe state for every actuator and make each fault path drive towards it. A hardware watchdog resets or trips the system if the control loop stops responding, and a hardware interlock is the final layer so that safety never rests on software alone.
3. Treat every input as untrusted. Check range and rate of change, timestamp readings so stale data is detected, and use redundant sensors with voting (2-out-of-3) where one bad reading must not drive a decision.
4. Verify at several layers: unit tests, static analysis and a restricted coding standard (MISRA C++ for C++ code), simulation or hardware-in-the-loop runs, and fault injection for paths that real hardware rarely triggers. Keep traceability from each safety requirement to its test.
5. Control change after release: version the configuration and firmware together, commission in stages, keep a tested rollback, and log every command and fault so incidents can be reconstructed.

Follow-up

• What should the controller do if it loses contact with a sensor mid-operation, and how would you test that path?
• Why should a safety interlock not depend only on software?
• How would you show an auditor that every safety requirement has a passing test?

How do you approach the integration of custom software with existing 3D CAD or commissioning workflows?

Medium · Technical Competency and Domain Knowledg

Approach

1. Map the existing workflow first: who uses it, which CAD or commissioning tools are involved, what goes in and comes out at each step, and which data is the master copy. The software should fit that flow rather than add a parallel one.
2. Choose the integration style and state its trade-off. A plug-in built on the CAD tool's own API has full access but is tied to that vendor's version. A separate tool that reads neutral exports is loosely coupled but loses data: STEP carries exact geometry but usually not the parametric feature history, and STL is a triangle mesh with no units.
3. Define one internal data model and map every source into it explicitly. Pin down units, coordinate frames and stable identifiers (part numbers, equipment tags) so that a design revision does not break the link to its commissioning records.
4. Protect the master data. Read from the model by default, route any write-back through review, and keep an audit trail of who changed which commissioning record and against which design revision.
5. Validate with round-trip tests and golden reference files, check units at every boundary, and pilot with one team before a wider rollout, pinning the supported tool versions.

Follow-up

• The CAD vendor releases a new version that changes its API. How does your integration survive it?
• The design changes partway through commissioning. How do you keep test records tied to the right revision?
• How would you catch a unit or coordinate-frame mismatch before it reaches the field?

How do you balance the trade-offs between system performance and maintainability?

Medium · Problem-Solving and Methodology

Approach

1. Make the requirement measurable before trading anything: a latency budget, a throughput target or a hard real-time deadline. Without a number, choose the readable version by default.
2. Profile before optimising (perf, gprof or a similar profiler for C++). Use Amdahl's law to set expectations: if a fraction p of runtime is sped up by a factor s, the overall speedup is 1 / ((1 - p) + p / s), so tuning code outside the hot path gains little.
3. Prefer algorithmic and data-layout wins, such as replacing an O(n^2) scan with a hash lookup or an O(n log n) sort, or storing data contiguously for cache locality. These often improve speed and clarity together. Leave micro-optimisations for last.
4. Keep the optimised code contained. Put it behind a clean interface, keep a simple reference implementation and test the two against each other, and write in a comment why it exists and which benchmark justified it.
5. Guard the decision over time with benchmarks in CI so a regression is caught, and revisit the optimisation if the requirement that justified it changes.

Follow-up

• Tell me about a time you chose the slower but clearer version. What made that the right call?
• How do you stop an optimisation from silently regressing later?
• When is early optimisation justified, for example under a hard deadline or tight memory limit?

Describe a situation where you had to learn a new tool or technology rapidly to meet a project requirement.

Medium · Problem-Solving and Methodology

Approach

1. Structure the answer as Situation, Task, Action, Result, and state the constraint up front: which tool, why the project needed it, and the deadline. Spend most of the answer on how you learned it.
2. Show a method rather than saying you read the docs. Scope down to the subset the project needed, build a minimal working example first, then a throwaway prototype of the hardest part, and ask an experienced user to review your early work.
3. Show how you confirmed it was correct, not just that it ran: tests against known outputs, comparison with an existing tool or hand calculation, and checking the tool's documented limits and failure modes.
4. Give a concrete result (delivered on time, defects found, what the tool enabled) and what you passed on, such as notes or a short guide for the next person.
5. The answer falls apart when the story is vague or when the tool was learned by someone else. Pick a case where you made the choices yourself and can name a specific mistake you made and fixed.

Follow-up

• How did you verify that your use of the tool was correct, not just working?
• Why that tool rather than one you already knew?
• What would you do differently if you had to learn it again?

Describe your process for debugging a complex system failure under tight deadlines.

Medium · Technical Competency and Domain Knowledg

Approach

1. Contain the damage before chasing the root cause. Roll back, fail over or put the system into its safe state, and save the evidence first: logs, core dumps, a configuration snapshot and the exact build and firmware versions.
2. Build a timeline. Work out what changed (code, config, firmware, hardware, environment) and when the symptom started, then line up logs and metrics by timestamp, checking for clock skew between machines before trusting the order of events.
3. Narrow the search space by halves. Use git bisect over commits (about log2(n) builds for n commits), or split the system at its interfaces and capture the messages crossing each boundary to see which side first goes wrong. Change one variable at a time.
4. Rank hypotheses by likelihood and by how cheap they are to test, and pick tests that rule out a large share of the candidates whichever way they come out. Check that the monitoring is correct before believing the symptom.
5. Separate the quick fix that unblocks the deadline from the fix for the root cause. Add a regression test that fails without the fix, and write a short incident review so the trigger and the cause are both recorded.

Follow-up

• The failure is intermittent and will not reproduce on your bench. What do you do next?
• When do you stop debugging and roll back instead of fixing forward?
• How do you keep stakeholders informed while the cause is still unknown?

Suggested practice checklist

Seven days built from the four reported rounds and ten reported questions: one day on reliability, one on debugging and optimisation, one on integration and monitoring, one on trade-offs and fast learning, one on stakeholders, then a full spoken run-through.

Day 1 — Map the loop and inventory your projects

• Write the four reported rounds (Initial Assessment, Problem-Solving Evaluation, Interaction with Stakeholders, Final Assessment) and mark which you are least ready for.
• Pick two projects you can defend in depth and write for each: components, your contribution, one failure, one decision you would change.
• List the listed requirements (core languages, development lifecycle, reading specifications) and the nice-to-haves, and write your nearest evidence for each.

Deliverable: A one-page loop map, two project summaries, and a requirements-versus-evidence table with gaps marked.

Day 2 — Reliability and safety for software tied to industrial systems

• Write and say aloud an answer to the reliability and safety question using layers: requirements, input validation, safe state on failure, fault-case tests, review, documentation.
• Add a real example for each layer from your own work, or the closest equivalent project.
• Prepare a one-minute answer on how you read a technical specification and turn it into checks you can test.

Deliverable: A layered reliability answer with one example per layer, plus a spec-to-test example.

Day 3 — Debugging under deadline and live optimisation

• Write the debugging sequence as a numbered list for a complex system failure, including what you check first and why, and how you separate trigger from cause.
• Write the live optimisation story with the symptom number, profiling evidence, the change, the rollback plan and the after number.

Deliverable: A debugging sequence, a measured optimisation story, and a worked explanation of the index practice question.

Day 4 — Integration with CAD or commissioning workflows and real-time monitoring

• Outline an integration between custom software and an existing CAD or commissioning workflow: data exchange format, which side owns what, versioning, handling of malformed input.
• Write your real-time and monitoring answer: buffering, timestamps, stale-data detection, alert thresholds, and what the system does on lost input.

Deliverable: An integration outline, a monitoring answer with an incident example, and working code for the rolling failure rate exercise.

Day 5 — Trade-offs and learning quickly

• Write a performance-versus-maintainability answer with one real case on each side and what the choice cost.
• Write the rapid-learning story: the requirement and deadline, how you decided what to learn first, what you built first, what you got wrong.
• Say both answers aloud and cut anything that is an adjective rather than a decision.

Deliverable: Two spoken answers with decisions and costs named, each cut to its core.

Day 6 — Stakeholders, cross-functional work and motivation

• Write the non-technical feedback story: the request, the underlying need, the requirement you wrote, how you communicated a trade-off and what changed.
• Write the cross-functional bottleneck story: where work waited, what you did, who decided, what lasted.
• Write the high-stakes motivation answer with one concrete habit and one learning aim, and three questions for technical leads about hand-offs during commissioning.

Deliverable: Three behavioural answers in situation, task, action, result form and a list of three questions to ask.

Day 7 — Full spoken run-through

• Run the four rounds in order out loud: project walk-through, reliability and debugging answers, stakeholder stories, then motivation and rapid learning.
• For every tool or technique you name, say aloud why you chose it over an alternative.
• Re-record the two weakest answers and fix the weakest sentence in each.

Deliverable: One recorded run-through, a list of tools with the reason for each choice, and two improved answers.

Stories to prepare for the experience and stakeholder questions

The reported behavioural and experience questions ask about real-time monitoring experience, live optimisation, rapid learning, feedback from non-technical stakeholders, cross-functional bottlenecks and working on high-stakes projects. For this role, the strongest stories show a decision you made, what you measured, and how you explained it to people outside software. Prepare them in situation, task, action, result form, and keep the result concrete.

1. Describe a situation where you had to learn a new tool or technology rapidly to meet a project requirement.

What is your experience with real-time data processing and system monitoring?

Medium · Technical Competency and Domain Knowledg

Approach

1. Open honestly with scope: what the data was, roughly how often it arrived, where it came from (sensors, logs, messages) and which part you owned. If your experience is near-real-time or batch, say so and describe the closest system you built instead of stretching the label.
2. Describe the processing path mechanically: how data entered, how buffering was bounded (fixed-size queue, and whether overflow dropped data or pushed back on the producer), how timestamps handled late or out-of-order readings, and what deadline the processing had to meet.
3. Describe monitoring concretely: the signals you watched (end-to-end latency percentiles, queue depth, age of the newest reading, error counts, a heartbeat per source), how thresholds were chosen, and how you cut alert noise, for example by requiring several consecutive breaches before alerting.
4. Include one incident: a silent feed, a gap or an overload. Say how monitoring surfaced it, what you changed, and what you made visible rather than silent. For an industrial setting, state what the system does on lost input: hold the last value, flag it as stale, or move to a defined safe state.
5. Close with the result and one limit of your design, such as what would break at ten times the rate.

Follow-up

• How did you detect that a data source had silently stopped sending?
• What did the system do when processing fell behind the incoming rate?
• How did you choose alert thresholds, and how many alerts turned out to be false alarms?

Walk me through a time you had to optimize a piece of code that was underperforming in a live environment.

Medium · Problem-Solving and Methodology

Approach

1. Set the scene in two sentences: what the code did, where it ran, and the symptom with a number attached (latency, CPU, memory, missed deadlines). Name your role in the fix.
2. Measure before editing: say how you reproduced the problem and what you profiled (profiler output, timing logs, a query plan). State the finding as a measured fraction, for example that most of the time went to one loop or one repeated call.
3. Describe the smallest change aimed at that hot spot and name its class: a better algorithm or data structure with the complexity before and after, removing repeated I/O, avoiding allocation in a loop, or caching with a clear invalidation rule.
4. Cover safety in a live system: how you showed the new output matched the old (replaying recorded inputs, side-by-side comparison), how it was rolled out in stages, the rollback plan, and what you watched afterwards.
5. Finish with before and after numbers and the maintainability cost: what became harder to read and what you documented or tested to compensate. The mistake that sinks this story is an optimisation described without a measurement.

Follow-up

• How did you know that was the bottleneck rather than guessing?
• What was the rollback plan if the change had made things worse?
• Looking back, was the optimisation worth the added complexity?

How do you handle feedback from non-technical stakeholders during the design phase?

Medium · Behavioral and Professional Alignment

Approach

1. Choose a case where the feedback was vague or conflicted with your design, such as a request to make a screen simpler or a change that touched a safety constraint. Show that you treated the feedback as information about their goals, not as noise or as an order.
2. Describe your method: restate the request in their words, ask what task they are trying to complete or what outcome they need, then convert the answer into a testable requirement and confirm it back in writing.
3. Make the trade-off visible without jargon: a mock-up, a before and after scenario, or cost, time and risk in their terms. When you could not do what was asked, say what alternative you offered.
4. Show the change handling: what you altered in the design, how you recorded the agreed decision so it was not reopened, and how you closed the loop with them afterwards.
5. The mistake that sinks this answer is a story where the stakeholder was simply wrong and you won, or one where you complied with everything and the design suffered.

Follow-up

• What did you do when their request conflicted with a technical constraint?
• How did you record the agreed change so it was not reopened later?
• Tell me about feedback you decided not to act on and how you explained that.

Describe a time you had to collaborate with a cross-functional team to resolve a critical project bottleneck.

Medium · Behavioral and Professional Alignment

Approach

1. Pick a bottleneck with a real cross-team cause, such as waiting on an interface specification, test hardware, or an agreed data format. Name the roles involved (for example mechanical, design or commissioning engineers) and what each needed.
2. Show diagnosis before action: how you found where work was actually waiting, for instance by mapping the handoffs and asking each side what they were blocked on, rather than assuming it was a software problem.
3. State what you personally did: agreed an interface contract or sample file, built a stub or simulator so others could keep working, set a short recurring sync, or wrote the missing specification. Say who made the final decision.
4. Address the friction honestly: different vocabulary, priorities or deadlines, and how you aligned everyone on a shared outcome.
5. Close with a measured result and a lasting change, such as a documented handoff or a shared test fixture, so the bottleneck did not return.

Follow-up

• Who disagreed with your approach and how did you resolve it?
• What would have happened if you had not stepped in?
• What did you change so the same bottleneck did not come back?

What motivates you to work in an environment centered on high-stakes engineering projects?

Medium · Behavioral and Professional Alignment

Approach

1. Answer with evidence rather than slogans. Describe a moment when higher consequences changed how you worked, such as adding review, tests, checklists or a written rollback plan, and what that taught you.
2. Connect it to the work candidates describe for this role: software that connects to mechanical systems, plus troubleshooting during commissioning or installation. Say which part of that draws you, without pretending to inside knowledge of the company's projects.
3. Be honest about the cost: slower change, more documentation, pressure when something fails on site. Name one concrete habit you use to cope with it.
4. Add a learning aim, for example reading industrial protocols or CAD data formats, so the answer looks forward as well as back.
5. Keep it to a few sentences. The mistake that sinks this answer is generic enthusiasm for challenge with no example attached.

Follow-up

• Tell me about a time a mistake in your work had real consequences.
• How do you work when requirements are strict and change is slow?
• What do you hope to learn here that you could not learn elsewhere?