Interview guides · ALSTOM

ALSTOM Software Engineer Interview Guide

ALSTOM Software Engineer interview guide: the 4 reported rounds, CBTC and interlocking prep, safety-critical C/C++ questions and a 7-day plan.

The 60-second brief

ALSTOM is a rail company. Candidates report that Software Engineer work touches Automatic Train Control (ATC) applications, validation systems, telecommunications and the integration of software interfaces into wider rail systems. Candidates also report owning a feature from specification through to system integration, and working with mechanical, electrical and systems engineers. The languages listed for the role are C, C++ and Java, with version control, object-oriented design and data structures as baseline requirements.

This guide is for software engineers interviewing for a Software Engineer role at ALSTOM, whether you come from embedded and real-time work or from general application development and are new to rail. It covers the four reported rounds, question-by-question guidance for the ten reported technical and behavioral questions, the domain topics candidates list (resume-based technical discussion, CBTC signaling, interlocking concepts, programming fundamentals and HVAC load calculations), and the requirements reported for the role: C, C++ or Java, version control, object-oriented design and data structures, with EN 50128, embedded systems and RTOS experience as pluses.

Candidates report four rounds over roughly 3-5 weeks: a Screening Call, a Technical Deep Dive, an Interaction with Leads and a Final Assessment. The reported questions are conversational, covering reliability, verification, interfaces and teamwork, rather than timed algorithm puzzles.

Focus areas

Resume-based Technical Interview
Electrical/Signaling Domain Knowledge (CBTC)
Interlocking Concepts

Overview

Every reported technical question for this role is about engineering practice rather than puzzles: keeping real-time code safe, debugging an interface between subsystems, running validation and verification cycles, fitting a new module into a legacy system, and optimizing under resource limits. Answers to these questions are built from your own projects, so the bulk of your preparation is turning your CV into a set of detailed, defensible stories with numbers, interfaces and test evidence attached.

The domain topics candidates list are specific to rail: Electrical/Signaling Domain Knowledge (CBTC) and Interlocking Concepts. You do not need to be a signaling engineer, but you should be able to explain moving-block train control, movement authority, the ATP/ATO/ATS split, what an interlocking prevents (conflicting routes, moving points under a train) and why rail systems fall back to a restrictive safe state on any detected fault. Candidates also list HVAC Load Calculations, which is unusual for a software role; ask your recruiter whether it applies to your team, and refresh the basic heat-gain formulas if it does.

The listed stack is C, C++ or Java, with EN 50128, embedded systems and real-time operating systems as pluses. That shapes how you should answer: talk about static memory allocation, bounded execution time, watchdogs, message integrity checks, structural coverage and requirement traceability, not just unit tests and code review. If your background is outside safety-critical work, map what you have done (regulated releases, strict QA, high-availability services) onto those ideas honestly rather than claiming rail experience you do not have.

The later rounds put you in front of technical leads and project stakeholders. The reported behavioral questions cover technical disagreement, competing priorities, catching a failure before it happened, why you want to work in mobility and rail, working across locations and disciplines, optimizing under constraints and validation experience. Prepare one specific story for each, with your own decisions and a measurable result.

The ALSTOM interview process

Candidates report these four stages, in this order, over about 3-5 weeks. The descriptions below summarize what candidates report about each stage and how to prepare for it.

Screening Call

Candidates describe the first stage as an initial call that checks your background and your motivation. Treat it as the place to anchor your story: a short walk through your CV that names the languages you use (the role lists C, C++ or Java), the kinds of systems you have built and tested, and a concrete reason for wanting rail work. This is also the right moment to ask practical questions: which area the team works in (train control, validation or telecommunications), what the remaining stages look like, and how much on-site presence the role needs if it involves hardware integration.

What to demonstrate

Your baseline experience against the languages and skills listed for the role
Your motivation for ALSTOM and for the mobility and rail sector

How to prepare

Rehearse a concise CV walk-through that names the languages, version control, test tooling and any embedded or RTOS work you have done, and ends with the project you most want to discuss later.
Write a motivation answer for the mobility and rail question that includes one accurate domain fact, such as what CBTC moving-block control changes compared with fixed blocks.
List questions for the recruiter: the team's product area, the remaining stages, and on-site expectations for hardware integration work.

Technical Deep Dive

Candidates describe this stage as an in-depth conversation about your technical projects and how you approach problems. Expect to be taken several levels below the summary on your CV: why a design was chosen, how a component talked to the rest of the system, what happened when it failed, and how you proved it worked. Prepare two projects in full depth rather than five at surface level. For each, be ready to draw the architecture, name the interfaces and their data formats, describe the hardest defect you hit and how you found it, and state what testing and coverage you achieved.

What to demonstrate

Depth of understanding on the technical projects you list
How you break down a technical problem and explain your method

How to prepare

Write a one-page dossier for each of two projects: architecture sketch, interfaces and message formats, failure handling, the hardest bug, and test and coverage results.
Be ready to defend the object-oriented design and data structure choices in your own code, in C, C++ or Java.
Practise answering the reliability, interface-debugging, validation and legacy-integration questions out loud using examples from those two projects.

Interaction with Leads

Candidates describe this stage as meeting technical leads and project stakeholders, with discussion of how the team works and the challenges it faces. It runs both ways: you learn about the team, and they hear how you collaborate. Prepare behavioral stories that show cross-discipline work, handling disagreement and juggling project streams, and come with informed questions, such as how the team handles integration with hardware groups, where its technical debt sits, and how verification and validation are organized.

What to demonstrate

How you work with technical leads and project stakeholders
How you collaborate across disciplines on integration and delivery

How to prepare

Prepare STAR stories for technical disagreement, competing priorities and working across locations or disciplines, each with your own decision and a result.
Write three questions for leads about system integration challenges, technical debt and how the V&V process runs on their project.
Practise explaining one software trade-off (for example a timing budget or a message timeout) in terms an electrical or mechanical engineer would use.

Final Assessment

Candidates describe the final stage as an overall assessment of technical aptitude and cultural fit. Nothing more specific is reported about its format, so prepare to be consistent with what you said earlier and to close any gaps. Review where earlier answers felt thin, especially on domain topics such as CBTC and interlocking, and have one more failure-prevention story ready, such as a time you spotted a potential system failure before it happened.

What to demonstrate

Technical aptitude across the areas covered earlier in the loop
Cultural fit with the team and organization

How to prepare

Re-read your own notes from earlier rounds and write a better answer to the question you handled worst.
Review a one-page CBTC and interlocking primer so you can use the terms correctly without hesitating.
Have a failure-prevention story ready with the signal you noticed, how you confirmed it and what you changed so it could not recur.

Where candidates lose points

Answering the reliability and safety question with 'I write unit tests and do code review' and nothing about requirements, coding rules, fail-safe states or coverage.

Prepare a layered answer: hazard analysis and traceability, a restricted coding subset with static analysis, deterministic scheduling and watchdogs, a safe state on detected faults, and structural coverage with independent review. Tie each layer to something you have actually done.

Stumbling over CBTC or interlocking vocabulary when candidates list both as tested topics.

Write a one-page primer and say it out loud: moving block compared with fixed block, movement authority, ATP/ATO/ATS, route setting and locking, point detection, flank protection, approach locking, and the fail-safe principle. Use the terms correctly before you use them confidently.

Describing your projects in the Technical Deep Dive only at feature level, without being able to explain the interfaces, how failures were handled or how the work was tested.

Prepare two projects to full depth with an architecture sketch, message formats, the hardest defect, and test and coverage evidence. Rehearse being asked 'why' three times in a row on each design choice.

Answering the interface-debugging question with a guessed fix instead of a sequence of steps that narrows the problem down.

Walk through the steps in order: reproduce and timestamp both ends, check the interface contract (endianness, units, version), capture traffic on the wire to decide whether the sender or the receiver is at fault, isolate with a simulator, then fix and add a regression test.

Behavioral stories with no measurable result, or where the team's effort hides what you personally decided.

For each of the reported behavioral questions, write the situation in two lines, then your own actions in the first person singular, then a number or concrete outcome. Cut any story where you cannot name your own decision.

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

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.
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.
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.
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

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.
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.
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.
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?

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

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.
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.
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.
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?

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

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.
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.
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.
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?

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

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.
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.
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.
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?

How do you ensure code reliability and safety in a high-stakes, real-time environment?

Medium · Technical and Domain Expertise

Approach

Answer in layers, starting with requirements. Each safety requirement comes out of hazard analysis (a hazard log or FMEA) and is traced to code and to the tests that cover it. Mention that EN 50128 sets which techniques are required at each software integrity level (SIL).
Coding rules: use a restricted subset in the style of MISRA C/C++. That means no dynamic allocation after initialization, no recursion, bounded loops, checked return values and fixed-width integer types. Treat compiler warnings as errors and run static analysis on every commit.
Real-time determinism: fixed-priority scheduling with worst-case execution time (WCET) estimates, priority-inheritance mutexes to avoid priority inversion, fixed-size queues and a hardware watchdog. A missed deadline counts as a fault, not a slow path.
Fail-safe behavior: any detected fault drives the output to the restrictive state (brake command, stop aspect). For communication, name EN 50159, the rail standard for safety-related communication, which is where defences such as a sequence number, a timestamp or timeout and a safety code (CRC) come from. For the highest integrity levels, add redundancy such as 2-out-of-3 voting or two diverse channels.
Verification: unit tests with structural coverage (statement and branch, MC/DC where the integrity level calls for it), hardware-in-the-loop tests and independent review. Name the trade-off: these rules slow development and limit language features, and that is the price of being able to argue the system is safe.

Follow-up

How would your code detect a message that is well-formed but stale?
What happens to an in-progress braking command if the watchdog resets the processor?
How would you show a reviewer that one specific safety requirement is fully tested?

How do you approach the integration of new software modules into legacy systems?

Medium · Technical and Domain Expertise

Approach

Characterize the legacy system before changing it: its interfaces, timing, resource budget and undocumented behavior. Write characterization tests that record what it does today, so any change in behavior is visible.
Isolate the new module behind an adapter or anti-corruption layer so the legacy data model does not leak into new code. Write a versioned interface contract both sides agree on.
Integrate incrementally. Move one function at a time (the strangler pattern), and run the new module in shadow mode so its outputs are compared with the legacy outputs before it takes control. Keep a fallback path to the legacy behavior.
Check the target's budgets: CPU slot, memory, scheduling priority and bus bandwidth. Then run full-system regression, ideally on a hardware-in-the-loop rig, before field deployment.
State the trade-off: a wrapper adds latency and another layer to maintain, while a rewrite adds the risk of losing behavior nobody documented. Explain how configuration management and version control keep long-lived releases traceable.

Follow-up

The legacy code has no tests and its author has left. Where do you start?
In shadow mode the new module disagrees with the legacy one. How do you decide which is right?
How would you roll back a module that is already deployed in the field?

Can you explain your process for debugging a complex system interface?

Medium · Technical and Domain Expertise

Approach

Pin down the symptom first: which side reports the error, how often, under what load, and since which software or hardware change. Collect logs from both ends with synchronized timestamps.
Check the contract before the code. Read the interface control document for field order, endianness, scaling and units, signedness and protocol version. Many interface bugs come from two sides holding different assumptions, each correct in its own view.
Observe the wire. A capture (Wireshark, a CAN or serial analyzer, or a logic analyzer) tells you whether the sender transmitted the wrong bytes or the receiver parsed correct bytes wrongly, which removes half the search space in one step.
Isolate each side by replacing the other with a simulator or a replay of captured traffic. Vary timing and load to expose timeouts, buffer overruns, framing errors and retransmission races that only show up on the real system.
Close the loop: fix the root cause, add a regression test that replays the failing message, correct the interface document if it was ambiguous, and tell the team that owns the other side.

Follow-up

The fault shows up on the vehicle but never on the bench. What do you change about your setup?
The other side of the interface belongs to a different team or supplier. How do you get them to act?
How do you tell a timing problem from a data-content problem on this interface?

Suggested practice checklist

The plan follows the four reported rounds. It starts with your CV and motivation, then works through the reported technical questions, the CBTC and interlocking topics, programming fundamentals in the listed languages, and the behavioral set, and ends with a full mock.

Day 1 — CV walk-through and motivation for rail

Write a CV walk-through that names your languages (C, C++ or Java), version control, test tooling and any embedded or RTOS work, ending with the project you want to discuss in depth.
Write and rehearse an answer to the mobility and rail motivation question that includes one accurate domain fact.
List your recruiter questions: the team's area (train control, validation or telecommunications), the remaining stages and on-site expectations.

Deliverable: A written CV walk-through, a rehearsed motivation answer and a list of recruiter questions.

Day 2 — Safety, reliability and V&V

Outline a layered answer to the real-time reliability and safety question: traceability, coding rules, determinism, fail-safe behavior and coverage, each tied to your own work.
Sketch the V-model for one of your projects and map each specification level to the tests that covered it.
Read a summary of EN 50128 integrity levels, the independence rules at each SIL, EN 50159 and MC/DC coverage so you can mention them accurately.

Deliverable: A one-page reliability answer outline, a V-model sketch of one project, and notes on EN 50128, EN 50159 and MC/DC.

Day 3 — CBTC and interlocking primer

Write a one-page CBTC summary: train-to-wayside communication, moving block, movement authority, and the ATP, ATO and ATS roles.
Write a one-page interlocking summary: route setting and locking, point detection, signal aspects, flank and approach locking, and why the safe state is the restrictive one.
Check with your recruiter whether HVAC load calculations matter for your team, and if they do, review sensible and latent heat gain and conduction (Q = U x A x deltaT).

Deliverable: Two one-page domain primers, plus HVAC notes if your recruiter says the topic applies.

Day 4 — Interfaces: debugging and legacy integration

Write the step-by-step debugging answer for a complex system interface, built around a real interface bug you have fixed.
Outline a legacy integration plan: characterization tests, adapter layer, shadow mode, rollback and resource budgets.
Sketch a software interface for a train braking command and how it behaves when communication between two components fails: timeouts, sequence counters, CRC and the safe default.

Deliverable: A debugging walkthrough, a legacy integration outline and a braking-interface sketch with its failure handling.

Day 5 — Programming fundamentals and the optimization story

Review the C and C++ fundamentals that matter for embedded rail work: volatile and data shared with an interrupt handler, const correctness, stack versus heap and static allocation, fixed-width types and integer overflow, RAII, and the cost of virtual dispatch.
Solve the peak-concurrency interval problem in C++ or Java, stating the time and memory complexity of the sweep-line solution.
Solve the bounded-lateness stream merge with a min-heap, and explain how you would handle a message that arrives later than the bound allows.
Write your STAR answer to the optimization question with before and after numbers and how you proved behavior was unchanged.

Deliverable: A one-page C/C++ fundamentals sheet, two working solutions with complexity notes, and a written optimization story with measurements.

Day 6 — Behavioral set for the leads conversation

Write STAR stories for technical disagreement and for competing priorities, each with your own decision and a result.
Write a story about spotting a potential system failure before it happened, including how you confirmed it and what stopped it recurring.
Write a story about working across locations or disciplines that includes a misunderstanding and how you resolved it.

Deliverable: Four written STAR stories, each with a measurable or concrete outcome.

Day 7 — Full mock and questions for leads

Have a friend run a mock covering a project deep dive, the reliability question, the interface-debugging question and two behavioral prompts, and note where your answers thinned out.
Rewrite the weakest answer from the mock.
Finalize three questions for technical leads about integration challenges, technical debt and how their V&V process runs.

Deliverable: Mock notes, one rewritten answer and three questions for the leads.

Behavioural preparation

The reported behavioral questions for this role cover technical disagreement, competing project streams, anticipating failures, motivation for rail, working across locations and engineering disciplines, optimizing under constraints and validation experience. Each answer needs a specific situation, your own decision and a concrete result, and for this role at least one story should involve working with non-software engineers.

What is your experience with software validation and verification cycles?

Medium · Technical and Domain Expertise

Approach

Open with the distinction. Verification asks whether you built it right (reviews, static analysis, unit and integration tests against the specification). Validation asks whether you built the right thing (system tests against operational requirements). Place both on the V-model, where each specification level has a matching test level.
Walk through one real cycle you took part in: requirement, test specification, execution, defect, fix, regression. Name the traceability matrix or requirements tool, the test framework and the coverage tool you actually used.
Make your own role explicit: which test specifications you wrote, which reviews you ran, how you handled a failed test, and what root cause you found.
Mention independence, and be precise about it. Under EN 50128 the required independence depends on the SIL: at SIL 3 and 4 the verifier and the validator must be independent of the implementer, and the validator also independent of the project manager, while lower SILs allow roles to be combined more. Ask which SIL their product targets, and if your experience is in another regulated or QA-heavy domain, map it honestly.
Cover regression scope. After a change, explain how impact analysis decides which tests to rerun, rather than rerunning nothing or running everything without reason.

Follow-up

After a one-line fix, how do you decide which tests to rerun?
A test passed, but you later realized the requirement it covered was ambiguous. What do you do?
What coverage did you reach, and how did you justify the uncovered code?

Describe a time you had to optimize a piece of code for performance or resource constraints.

Medium · Technical and Domain Expertise

Approach

Situation: give a measurable constraint, such as a control cycle that overran its deadline, a RAM or flash limit, a CPU budget on an embedded target, or a latency requirement.
Measure before changing anything. Name the profiler or timing instrumentation, the hotspot it found, and the baseline numbers.
Action: describe the specific change and why you chose it over the alternatives. Examples include an algorithmic fix (quadratic to O(n log n), a lookup table instead of repeated computation), a data-layout change (contiguous arrays, no allocation inside the loop) or removing redundant copies.
Result: give the after numbers, show that behavior was unchanged (regression tests, output comparison), and say what it cost in readability or flexibility.
The answer that sinks you is an optimization with no measurement before or after, or one that changed behavior without anyone noticing.

Follow-up

What alternatives did you consider and reject, and why?
How did you prove the optimized code behaved exactly like the original?
Would you accept less readable code in a safety-relevant module to meet a timing budget?