Interview guides · Bertrandt

Bertrandt Software Engineer Interview Guide

Bertrandt Software Engineer interview guide: the four reported rounds, embedded and safety-critical questions, behavioral prompts and a 7-day prep plan.

The 60-second brief

Bertrandt is described as an engineering consultancy that builds development work for clients in automotive, aerospace and medical technology. Candidates and the role description mention software for flight automation, aerospace defense systems, battery production and measurement technology, plus manufacturing processes and mobility. A Software Engineer there sits in project teams that also include hardware and other specialist engineers, and turns technical requirements into working, tested software that ends up inside physical machinery. Because the work is project-based and client-driven, the role mixes implementation, system tests against safety requirements, architecture reviews and regular communication with people outside the software team.

This guide is for Software Engineer candidates preparing for the Bertrandt loop, especially those with embedded, control or automation experience. It covers the four reported rounds, all eleven reported questions (safety-critical reliability, RTOS, hardware and software integration, a hard past challenge, performance debugging, flight automation architecture, stack selection, legacy code, and four collaboration questions), and a plan that turns your past projects into answers. It does not assume aerospace experience, since candidates describe that as a plus rather than a requirement.

Candidates report four rounds over roughly 3-5 weeks: Experience Screening, Technical Deep-Dives, Methodology Discussion and Project History Review. Each is described as a discussion of your experience, your methods or your past projects.

Focus areas

Systems Engineering
Software Architecture
Automation Engineering

Overview

The work behind the interviews is software that has to behave correctly on real hardware: automation modules, flight automation, battery production and measurement technology are the examples candidates mention. The requirements they describe list C/C++ or a comparable language, embedded systems or complex architecture experience, and a solid grasp of software safety standards. Nice-to-have items are aerospace or automotive exposure, simulation tools and time in regulated industries. Preparation therefore means being able to talk about constrained, verified, documented software, not only about features you shipped.

All four reported rounds revolve around what you have already done: your experience, your technical methodology, your approach on earlier projects and the relevance and impact of those projects. That makes your project history the main asset. Before anything else, build a short inventory of three or four projects, and for each one write the target hardware, the language and tools, the lifecycle (Agile or V-model are the two candidates name), the standards or safety constraints, the architectural choices you made and rejected, and the exact parts you personally owned. Candidates report that being specific about your own responsibility matters in team-based projects.

The reported evaluation areas map onto that inventory. Systems engineering and architecture covers system integration between software and physical hardware, standards compliance and documentation, and architectural trade-offs. Technical methodology covers development lifecycles, debugging and validation before release, and tooling, including simulation tools. The reported topic list adds automation engineering, flight automation software and requirements engineering. Rehearse each reported question against a real project: the technical ones need a method (traceability, layered testing, a bisecting debug sequence, a layered architecture), and the behavioral ones need a story with a decision and a measurable result.

Two smaller items are worth a slot in your plan. Candidates report a motivation question, "Why Bertrandt?", and the tip is to know the company's recent work in areas such as aerospace or battery systems and to say why one of them interests you. Candidates also report that roles in aerospace or defense can include extra technical vetting, so have your domain-specific examples ready in more depth than a general software summary. Coding is not described as the centre of the loop, but C/C++ is a must-have, so keep language fundamentals such as memory, volatile and interrupt-safe code fresh enough to discuss them while describing projects.

The Bertrandt interview process

Candidates describe four stages in this order, spanning roughly 3-5 weeks. The descriptions are about your experience and past projects, so prepare stories and methods rather than puzzle patterns.

Experience Screening

Candidates describe Experience Screening as the first look at your background to judge whether it fits the role. Expect to summarise which domains, languages and kinds of system you have worked on. The requirements list C/C++, embedded or complex-architecture experience and software safety standards, so your summary should name them explicitly where you have them. Treat it as a pitch with evidence: each claim points to a project, a constraint you worked under and a result.

What to demonstrate

Fit between your background and the stated requirements: C/C++ or similar, embedded or architectural experience, safety awareness
How clearly you can summarise your own projects and your personal contribution
Whether your domain exposure (aerospace, automotive, medical, automation) is relevant

How to prepare

Write a one-page experience summary that maps each project to its hardware, language, lifecycle and safety or standards constraints
Rehearse a spoken answer to the reliability question for safety-critical aerospace or medical software, with one real example behind it
Prepare a plain answer to "Why Bertrandt?" that names one area, such as aerospace or battery systems, and what draws you to it

Technical Deep-Dives

Candidates describe Technical Deep-Dives as in-depth technical discussions that centre on your methodology and your past projects. The reported technical questions cover hardware and software integration, a complex challenge you resolved and RTOS experience. Choose one or two projects you can go deep on and be ready to move between layers: requirements, architecture, code, test and hardware bring-up. Say what you decided, what you rejected and why.

What to demonstrate

Depth of understanding in the systems you built, from software down to the hardware interface
Disciplined approach to integration, testing and validation as you describe it
Ability to explain a technical problem and its resolution step by step

How to prepare

For the hardware and software integration question, outline a bring-up sequence: interface definition, simulation or stubs, first contact on the bench, fault injection, then system test
Write your RTOS story with tasks, priorities, interrupt handling and one measured timing result
Pick your hardest technical challenge and structure it as symptom, hypotheses, evidence, fix and verification

Methodology Discussion

Candidates describe Methodology Discussion as a conversation about the approach and strategies you used on earlier projects. This is where lifecycle experience (Agile or V-model), debugging and validation habits, tooling and architectural trade-offs fit naturally. The reported performance-debugging question, the flight automation architecture question and the stack-selection question all call for a stated method. Walk through constraints, options, trade-offs and a justified choice rather than jumping to a favourite technology.

What to demonstrate

Structured thinking about ambiguity: constraints, trade-offs and a reasoned decision
Familiarity with development lifecycles and verification practices
Awareness of tooling, including simulation tools

How to prepare

Practise the performance-debugging question as an ordered method: measure first, locate the bottleneck, change one thing, re-measure
Outline an architecture for a flight automation module on one page: sensors in, processing, decision logic, actuator out, fault handling, and how each part is tested
List the factors you would weigh when choosing a stack for a multi-year project, then apply them to one real choice you made

Project History Review

Candidates describe Project History Review as a walk through your past projects to judge their relevance and impact. Expect to be asked what you personally owned, which constraints and standards applied, and what changed because of your work. The reported legacy-code question and the collaboration questions fit here as stories. Prepare each project with a short context, your role, a decision you would defend, a result and a lesson.

What to demonstrate

Relevance of your project history to the work Bertrandt describes
Clarity about your own responsibility inside team-based projects
Impact of the work and what you learned from it

How to prepare

Build a project card for each of three or four projects: context, constraints, your parts of the system, result, lesson
Prepare the legacy-code story: what you inherited, how you protected existing behavior, and how new features went in
Prepare two collaboration stories, one about explaining a technical concept to a non-technical person and one about a change in scope

Where candidates lose points

Describing a project as "we built" without saying which parts you owned

Candidates report that you are expected to say exactly which parts of the system you were responsible for. For every project card, write what you designed, implemented, tested and debugged yourself, and what teammates did, and use those words aloud.

Answering the safety-critical reliability question with "I test a lot"

Build the answer as a chain: requirements with traceability, design reviews, static analysis, layered tests (unit, integration, hardware-in-the-loop or simulation), fault handling, and the documentation that proves each step. Tie it to one real project and the standard or lifecycle (Agile or V-model) it ran under.

Giving an RTOS answer made of definitions with no project behind it

Tell the story: tasks, priorities, interrupt handling, shared-resource protection and one measured timing result. If your RTOS exposure is limited, say so and describe the closest bare-metal work and the concepts you do understand.

Jumping straight to boxes and technology names in the flight automation architecture or stack-selection answers

Start with constraints: safety requirements, real-time needs, hardware interfaces, certification or documentation load, project lifespan and team skills. Then compare two options and give the trade-off that decided it.

Treating a change in client scope as something you either absorbed silently or refused

Show the impact analysis, the options you put to the client, the written agreement and the updated requirements and tests. Also have a sincere "Why Bertrandt?" ready, naming one area such as aerospace or battery systems, because candidates report that question.

Questions & practice

What factors do you prioritize when selecting a software stack for a long-term, high-complexity engineering pr

Medium · System Design and Architecture

What factors do you prioritize when selecting a software stack for a long-term, high-complexity engineering project?

Approach

Rank by project lifetime first: a language standard and toolchain that will still be supported and reproducible in ten to twenty years, vendor long-term support, and the ability to pin and rebuild the exact compiler and dependencies later.
Let the target and the regulation remove options: hard real-time or memory-constrained parts rule out runtimes with unbounded garbage-collection pauses, and safety work needs a compiler and analysis tools with qualification evidence for the relevant standard.
Count the dependency burden: each third-party library is code you must track, patch and, in regulated work, justify; licensing (copyleft obligations versus proprietary distribution) also belongs here.
Weigh the people and the existing code: what the team and future hires can maintain, interoperability through a stable C ABI with legacy components, and whether a coding standard and static analysers exist for the language (MISRA covers C and C++).
Make the decision explicit: a weighted comparison of two or three candidates, a small prototype on the real target for the riskiest criterion, and a written record of the reasons so later engineers know which assumptions to revisit.

Follow-up

When would you choose Rust over C++ for a new safety-relevant component, and what would stop you?
A core library you depend on stops being maintained halfway through the project: what do you do?
How do you guarantee you can rebuild a bit-identical release of the software many years from now?

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

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?

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

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.
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.
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.
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 the reliability of software in safety-critical environments like aerospace or medical device

Medium · Technical Competency and Domain Knowledg

How do you ensure the reliability of software in safety-critical environments like aerospace or medical devices?

Approach

Start from hazard analysis, not from code: I classify the software by its failure consequence under the governing standard (DO-178C design assurance levels A-E for airborne software, IEC 62304 classes A/B/C for medical device software, ISO 26262 ASIL A-D in automotive) because that level decides how much verification evidence is needed.
Keep bidirectional traceability: every high-level requirement maps to low-level requirements, code and tests, and every line of code traces back to a requirement, so untested or unrequired code shows up as a gap rather than a surprise.
Name the coverage targets correctly: DO-178C asks for statement coverage at level C, plus decision coverage at level B, plus MC/DC at level A, where MC/DC shows that each condition independently changes the decision outcome.
Constrain the code to make it analysable: a coding standard such as MISRA C/C++, static analysis in CI, no dynamic allocation after initialisation, bounded loops and recursion, and worst-case execution time analysis for anything with a deadline.
Design for detected failure: watchdogs, range and plausibility checks on inputs, redundancy or command/monitor channels where the hazard requires it, and a defined safe state the system falls back to when a check fails.

Follow-up

What is the difference between decision coverage and MC/DC, and how many test cases does MC/DC need for a decision with n independent conditions?
How do you qualify a tool, such as a code generator or static analyser, whose output you rely on without reviewing it?
How do you handle a third-party library with no development records inside a certified product?

How do you approach the integration of hardware and software components in complex systems?

Medium · Technical Competency and Domain Knowledg

Approach

Fix the interface before writing code: an interface control document covering register maps, bus protocol (CAN, SPI, I2C, UART), timing, byte order, units and scaling, and error signalling, agreed with the hardware engineers and under version control.
Put a hardware abstraction layer between application logic and drivers, so the logic is unit tested on the host and only the thin driver layer depends on the board.
Integrate in stages: software-in-the-loop against a plant model, then processor-in-the-loop on the target CPU, then hardware-in-the-loop with real I/O and simulated environment, so each stage adds one source of failure.
Bring up a new board incrementally: power and clocks, a debug UART or GPIO toggle, then one peripheral at a time, confirming each on a logic analyser or oscilloscope rather than trusting the driver's return code.
Check the embedded traps explicitly: volatile on memory-mapped registers, interrupt priorities and shared-data protection, DMA and cache coherency, and endianness across the bus.

Follow-up

A sensor returns plausible but wrong readings: how do you decide whether the fault is in hardware or software?
How do you keep developing and testing when the target hardware is late or scarce?
A board revision changes a pin mapping: what in your design limits how much code has to change?

Can you explain a complex technical challenge you faced in a previous role and how you resolved it?

Medium · Technical Competency and Domain Knowledg

Approach

Pick one problem you diagnosed yourself and tell it in first person singular, with the system, the constraint that made it hard (timing deadline, memory limit, safety standard, hardware you could not change) and the symptom as it was observed.
Walk through the hypotheses in order and the evidence that ruled each one out: the measurement, trace or experiment, not just the conclusion.
State the fix and its cost: what you traded (memory for latency, a simpler design for less flexibility, schedule for a proper root-cause fix) and why that trade fit the project.
Close with verification: how you proved the fix worked, the regression test or monitor you added so it cannot return silently, and a measurable result.
Avoid the story that sinks this answer: a team narrative where your own contribution is unclear, or a challenge that was only hard because of a missed deadline rather than a technical constraint.

Follow-up

Which alternative fix did you reject, and why?
How would you know if the same root cause appeared in another part of the system?
What would you do differently if you met the same problem at the start of a project?

How would you design a software architecture for a new flight automation module?

Medium · System Design and Architecture

Approach

Scope it before drawing boxes: which function the module performs (for example altitude or heading hold, mode management, monitoring), its inputs (air data, inertial, GNSS) and outputs (actuator or guidance commands), its update rate, and the assurance level, because that level drives every later choice.
Lay out a pipeline with clear ownership: sensor acquisition and validation (range, rate and cross-channel voting), state estimation such as a Kalman filter, control laws, mode logic as an explicit state machine with defined transitions, and an output stage that enforces command limits, plus an independent health monitor.
Make timing deterministic: a fixed-rate cyclic executive or rate-monotonic priorities with schedulability checked against worst-case execution times, no dynamic allocation after start-up, and time and space partitioning (as in ARINC 653) if it shares a processor with other functions.
Plan for failure: redundant channels or a command/monitor pair, defined degraded modes, and what the module does on loss of an input, ranging from hand-back to the pilot to a fail-operational fallback, depending on the hazard.
Say how it is verified: requirements traced to tests, model-based development and simulation for the control laws, software- and hardware-in-the-loop testing, and structural coverage at the level the assurance level requires.

Follow-up

Two of three air-data sources agree and one drifts slowly: how does your voting logic detect it, and what happens if the drift stays inside the tolerance?
How do you show that the mode-transition logic has no unreachable or missing transitions?
How do you guarantee the control loop meets its deadline when a new function is added to the same processor?

What is your process for debugging performance bottlenecks in a distributed or embedded system?

Medium · Technical Competency and Domain Knowledg

Approach

Define the metric and the budget first (end-to-end latency percentile, deadline misses per hour, CPU load, throughput) and reproduce the problem with a fixed, repeatable workload before changing anything.
Measure rather than guess. On a microcontroller I use cycle counters (the DWT cycle counter on Cortex-M3 and above), GPIO toggles timed on an oscilloscope, and RTOS trace tools that show task switches and interrupt load. In a distributed system I use distributed tracing spans per hop, queue depths, and sampling profiles rendered as flame graphs.
Classify the bottleneck: CPU-bound, memory or bus bandwidth, I/O wait, lock contention or priority inversion, interrupt latency, or a downstream dependency. Then apply Amdahl's law: speeding up a part that takes 10% of the time can save at most 10%.
Watch for measurement artefacts: instrumentation overhead, debug builds without optimisation, logging over a slow UART, and averages that hide tail latency.
Change one thing at a time, re-measure against the same workload, and keep a benchmark or timing assertion in CI so the regression is caught next time.

Follow-up

A high-priority task occasionally misses its deadline while a low-priority task holds a shared mutex: what is happening and how do you fix it?
Client-side latency is high but every service reports fast handling times: where do you look next?
The slowdown appears only on the production hardware and never on the bench: how do you investigate?

Suggested practice checklist

The plan starts from your own projects, because all four reported rounds revolve around them, then rehearses the reported technical questions by subject, then the collaboration stories, and ends with a full mock loop.

Day 1 — Build your project inventory

List three or four past projects and write for each the hardware, language, tools, lifecycle (Agile or V-model), standards or safety constraints and the parts you personally owned.
Mark which projects touch embedded, automation, aerospace, automotive, medical or battery topics, and which are your two strongest for a deep dive.
Write a one-page summary of your background for the Experience Screening round.

Deliverable: A project card for each project plus a one-page experience summary with the two deep-dive projects marked.

Day 2 — Safety-critical reliability and standards

Outline an answer to the reliability question as a chain from requirements and traceability to reviews, static analysis, layered tests and documentation.
Attach one real project example to each link of the chain, and note the standard or process it followed.
Compare how Agile and V-model change when verification evidence is produced.

Deliverable: A one-page reliability argument with a real example per step, plus a short Agile versus V-model note.

Day 3 — RTOS and hardware integration

Write your RTOS story: tasks, priorities, interrupt handling, mutexes and priority inheritance, stack sizing and one measured timing result.
Outline a hardware and software bring-up sequence from interface definition and simulation through bench testing to system test.
Revise C/C++ points that come up while describing embedded work: volatile, memory ownership and interrupt-safe code.

Deliverable: A written RTOS story and a bring-up checklist, each tied to a real project.

Day 4 — Architecture and stack choice

Sketch an architecture for a flight automation module: inputs, processing, decision logic, outputs, fault handling and test points.
Write the factors you would weigh when selecting a stack for a long-term, high-complexity project, then apply them to a real choice you made.
For both, write the trade-off between two options and the constraint that decided it.

Deliverable: A one-page architecture diagram with fault handling and a ranked list of stack-selection factors with one applied example.

Day 5 — Debugging and your hardest challenge

Write the performance-debugging method for a distributed or embedded system: measure, locate, change one variable, re-measure.
Structure your hardest technical challenge as symptom, hypotheses, evidence, fix and verification, and say it aloud.
Prepare a cause-versus-coincidence example from a bug you chased.

Deliverable: A debugging checklist and a spoken, written-down version of the challenge story.

Day 6 — Legacy code and shifting scope

Write the legacy-code story: what you inherited, tests you added first, how new features were integrated and how you limited risk.
Write the changing-requirements story with impact analysis, options given to the client and the agreed outcome.
Check both stories for your own role, a measurable result and one thing you would do differently.

Deliverable: Two story outlines, each with situation, decision, result and a lesson.

Day 7 — Communication, teamwork and a full mock

Write the story about explaining a technical concept to a non-technical stakeholder, starting with the decision they had to make.
Write the story about working with engineers from different backgrounds, naming the specific gap and your action.
Prepare an answer to "Why Bertrandt?" and run all four rounds' topics aloud in order with a friend or recording.

Deliverable: Two collaboration stories, a "Why Bertrandt?" answer and a recorded mock run with notes on weak spots.

Project stories and client-facing collaboration

Candidates report behavioral questions about explaining technical ideas to non-technical stakeholders, changing requirements in a client-driven environment and working in teams with different engineering backgrounds. The experience and project-history rounds also reward stories about your specific role, so each prompt below needs a real project, a decision you made and a result.

Why Bertrandt, and which area of its work interests you most?

Describe your experience with real-time operating systems (RTOS) and their application in your past projects.

Medium · Technical Competency and Domain Knowledg

Approach

Anchor the answer in one real project and name the RTOS you used, the target processor, and what had to happen on time. Separate hard deadlines (a missed one is a failure) from soft ones (a missed one degrades quality), because that decides how much margin you design in.
Describe the task structure: which tasks you created, how you assigned fixed priorities (for periodic work, shorter period gets higher priority is the usual rate-monotonic rule), and which work you kept out of tasks entirely by handling it in an interrupt.
Cover the mechanics you actually dealt with: short interrupt handlers that hand work to a task through a queue or semaphore, mutexes with priority inheritance to prevent priority inversion, stack sizing per task, and avoiding blocking calls in time-critical paths.
Give one measured result: worst-case latency or jitter, how you measured it (logic analyzer, trace tool, GPIO toggling, execution-time counters) and what you changed after seeing the numbers.
If your experience is thin, say so and describe the nearest equivalent, such as a bare-metal loop with timer interrupts, then explain what an RTOS would have changed. A confident gap beats invented detail.

Follow-up

What is priority inversion, and how did you prevent or find it in your project?
How did you determine worst-case execution time and size task stacks?
Why did you need an RTOS instead of a simple super-loop with interrupts?

How do you handle legacy codebases while introducing new, modernized features?

Medium · System Design and Architecture

Approach

Open with the constraint: what the legacy code did, who depended on its behavior, and what the new feature required. Say plainly that the first goal was to avoid breaking what already worked.
Describe how you made change safe before changing anything: characterization tests that record current outputs (golden-master style), a build you could run reproducibly, and a map of the modules the feature would touch. In a regulated setting, add the impact analysis and which verification you had to repeat.
Explain the integration technique: introduce a seam or wrapper around the old module, route only the new behavior through new code, and keep the old path alive behind a switch until the new one is proven. Contrast this with a big-bang rewrite and say why you rejected it.
Give the result in numbers where you can: defects found by the characterization tests, regressions after release, delivery date kept. Name one trade-off you accepted, such as leaving ugly code untouched because it was stable and out of scope.
Avoid the story where you simply declare the old code bad. The mistake that sinks it is contempt for existing code with no plan for protecting existing behavior.

Follow-up

How do you decide between refactoring a module and replacing it?
How did you handle undocumented behavior that other components relied on?
How would you roll the new feature back if it failed in the field?

Tell us about a time you had to explain a highly technical concept to a non-technical stakeholder.

Medium · Behavioral and Collaborative Skills

Approach

Choose a story with a real decision at the end: a manager or client had to approve, accept a risk or change a schedule, and could only do it after understanding a technical point such as why a test phase could not be skipped or why a hardware limit affected the design.
Start from the audience, not the concept. State what they needed to decide, then give the conclusion first, the reason in their vocabulary (cost, schedule, safety, risk) and only then the technical detail they asked for.
Describe the device you used: an analogy that fits their world, a diagram of the system boundary, or a one-page summary. Say how you checked understanding, for example by asking them to restate the trade-off.
Close with the outcome and what you changed afterwards, such as a standing summary format for project reviews. The mistake that sinks the story is only showing you simplified words, with no decision or result.

Follow-up

What did you do when the stakeholder pushed back or misunderstood?
How would you explain priority inversion or a safety requirement to a client project manager?
How did you know they had understood, and what changed because of it?

How do you handle changing requirements or shifting project scopes in a client-driven environment?

Medium · Behavioral and Collaborative Skills

Approach

Pick a real change that arrived mid-project from a client or internal stakeholder, and state what it altered: scope, schedule, interfaces, tests or documentation.
Show the sequence: clarify what the client actually needs behind the request, run an impact analysis on design, verification and dates, and write the change into the requirements with traceability so tests and documents stay consistent.
Present options rather than a yes or no: absorb it with a trade (move another item, shift a date, add effort) or defer it to a later increment. Say how you got agreement in writing from the client side.
Show how you protected the team and the baseline: a change log, communication to everyone affected, and regression tests rerun on the touched parts. Name the outcome, including anything that slipped.
The mistake that sinks the story is silent absorption ("I just adapted"), which hides risk, or flat refusal, which ignores a client-driven setting.

Follow-up

What would you do if the change arrived after the design was frozen in a V-model project?
How do you say no to a request without damaging the client relationship?
How did you keep requirements, tests and documentation consistent after the change?

Describe your approach to working within a team that has diverse engineering backgrounds.

Medium · Behavioral and Collaborative Skills

Approach

Name the mix concretely: software, hardware, systems, test or mechanical engineers, or people from a different industry. A generic "diverse team" story is weaker than one about a specific gap in vocabulary or assumptions.
Describe a moment where background differences caused a real problem, such as two meanings of the same term, or hardware and software each assuming the other handled a fault, and how you spotted it.
Explain what you did: wrote a shared interface description or glossary, asked questions instead of assuming, paired with someone from the other discipline, and settled a technical disagreement with a measurement or a bench test rather than seniority.
State the effect on the project and what you learned from the other discipline. Keep your own contribution clear: the sinking mistake is a story where everyone worked well together and nothing you did shows.

Follow-up

Tell me about a disagreement with a hardware engineer over who should fix a problem, and how you settled it.
How would you onboard someone from a different engineering background onto your code?
What did you learn from a colleague in another discipline that changed how you work?