CDH Professionals Software Engineer Interview Guide

The 60-second brief

Candidate reports place this Software Engineer role in embedded systems. The work centres on developing and producing embedded hardware platforms, and the engineer is involved from concept through production release. The day-to-day tasks reported are building and maintaining models in MATLAB/Simulink, generating embedded code from those models, and confirming that the software integrates correctly with the hardware. Candidates also describe helping with bring-up and validation of new hardware, which means working directly with sensors, actuators and microcontrollers, and collaborating with hardware, systems and manufacturing teams. The reports do not name specific products or customers, so prepare around the engineering work itself.

This guide is for engineers applying to CDH Professionals as a Software Engineer in embedded systems. It covers the five reported rounds, the question types candidates describe (Simulink and model-based design, embedded C/C++ coding, debugging and hardware integration, real-time control, and behavioral questions), an answer approach for each reported question, and a seven-day plan. It assumes you already write C or C++ and helps you sharpen and present that experience rather than teach the language.

Candidates report five rounds over roughly 4-6 weeks: Initial Screening, Technical Assessments, Behavioral Interviews, Collaborative Discussions and Final Evaluations. Reports describe each stage in a line but do not publish a detailed process or say which questions belong to which stage.

Focus areas

• Model-Based Design (MBD)
• Simulink
• MATLAB

Overview

The reported work sits where models, firmware and hardware meet. Candidates describe building models in MATLAB/Simulink, producing embedded code from them in C/C++, and checking that the result behaves correctly on real hardware with sensors, actuators and microcontrollers. Preparation should follow that chain end to end: requirement, model, code, integration, validation on the board. If you can narrate one project through every link, most of the reported questions become variations on it.

The reported topic mix is Model-Based Design, Simulink, MATLAB, embedded C and embedded C++. Reported questions include the features of Simulink that support model-based development, debugging and testing embedded software, integrating software with hardware, optimizing control algorithms for real-time systems, troubleshooting a sensor-integration scenario, the role of interrupts, and C tasks such as reversing an array in place and implementing a state machine. Many are phrased as 'describe your experience' or 'how would you approach', so each needs a real project behind it, not a definition.

Three of the five stages (Behavioral Interviews, Collaborative Discussions and Final Evaluations) are about teamwork and overall fit. Candidates report that the role works with hardware, systems and manufacturing teams, and that the people questions cover cross-functional work, leading an initiative, disagreements, feedback and explaining technical issues to non-technical colleagues. Prepare stories where hardware or production constraints shaped a software decision. Candidates also report a hybrid arrangement with four days onsite, which is worth confirming with the recruiter early.

The CDH Professionals interview process

Candidates report these five stages, in this order, over roughly 4-6 weeks. Each stage has only a one-line description in the reports, so prepare by question type rather than by guessing which question lands where.

Initial Screening

Candidates describe the first stage as a review of your application and qualifications. The must-have skills they list for the role are MATLAB/Simulink for model-based development, embedded C/C++, experience supporting hardware development or production, and an understanding of real-time software. Treat this stage as the place where your CV has to line up with those four things in plain, checkable terms. Be ready to name the projects, targets and tools behind each line.

What to demonstrate

• How your experience maps to the listed must-haves: MATLAB/Simulink, embedded C/C++, hardware or production support, real-time software
• Whether your CV claims are specific enough to survive follow-up, for example which microcontroller, which model, which release
• Basic fit with the role as candidates describe it: embedded hardware platforms from concept to production release

How to prepare

• Build a table with one row per must-have skill and, for each, the project, your own contribution and the target hardware or toolchain
• Prepare a short spoken summary of your embedded career that ends on why embedded hardware work and model-based design in particular
• Confirm the remaining stages, the onsite expectation and the format of the technical stage with the recruiter, and note the answers

Technical Assessments

Candidates describe this stage as technical assessments of coding skills and problem-solving. The reported questions that fit it by type are the embedded and coding ones: C tasks such as reversing an array in place and implementing a state machine, synchronous versus asynchronous programming in embedded systems, debugging and testing embedded software, integrating software with hardware, Simulink features for model-based development, and optimizing control algorithms for real-time systems. A technical stage is where working code and a clear method get tested, so practise writing C without an IDE and explaining each choice as you go.

What to demonstrate

• Working embedded C, including edge cases and behaviour on constrained targets
• A structured method for debugging, testing and hardware integration
• Understanding of model-based development in MATLAB/Simulink and of real-time constraints

How to prepare

• Write the in-place array reversal in C by hand, including NULL, length 0, length 1 and odd length, and say its time and space cost
• Implement a small table-driven state machine in C and explain how events reach it from an interrupt without blocking
• Prepare a numbered debugging sequence for a sensor that reports wrong values, and a short account of the integration steps from board power-up to a validated release
• Rehearse a verbal tour of the Simulink features you have used: solvers, subsystems, signal logging, code generation and test harnesses

Behavioral Interviews

Candidates describe the Behavioral Interviews as a focus on interpersonal skills and cultural fit within the team. The reported people questions are cross-functional collaboration, leading a project or initiative and its outcome, and handling conflicting ideas or disagreements in a team. Reported example questions also include explaining a complex technical issue to a non-technical audience and handling feedback from team members or stakeholders. Candidates report the STAR method as the advised way to structure answers, so build each story around a decision you personally made.

What to demonstrate

• Interpersonal skills and teamwork, as the stage is described
• Fit within the team, shown through how you describe colleagues, disagreements and feedback
• Your own role in past projects, visible in the decisions you narrate

How to prepare

• Write four STAR stories: a cross-functional project with hardware or manufacturing colleagues, a project or initiative you led, a technical disagreement, and a time you explained a technical issue to a non-technical audience
• For each story, write the single decision you made and the evidence you used, and cut any 'we' that hides your contribution
• Practise saying the outcome plainly, including what did not go to plan and what you changed afterwards

Collaborative Discussions

Candidates describe Collaborative Discussions as conversations that reflect teamwork and collaborative problem-solving. Two reported scenario questions fit this format by type: optimizing control algorithms for real-time systems, and troubleshooting a scenario involving sensor integration. Treat them as problems you work on together out loud: state your assumptions, ask what you need to know, and think in steps others can follow and redirect.

What to demonstrate

• Teamwork and collaborative problem-solving, as candidates describe the stage
• Clear, stepwise reasoning about control timing, sensors and integration
• Willingness to take input and change course on an approach

How to prepare

• Pick a real control loop you have worked on and write down its period, its worst-case execution time and what you moved or simplified to fit the budget
• Prepare a sensor troubleshooting walk-through that starts from power and wiring, moves to raw signals, then scaling, calibration and timing
• Practise stating assumptions and asking one clarifying question before proposing a solution, using a scenario you have not seen before

Final Evaluations

Candidates describe Final Evaluations as the closing stage that decides overall fit for the role. Reports do not break it down further, so plan for both sides of the loop to be open again: technical depth in Simulink, embedded C/C++ and hardware integration, and the people questions about cross-functional work, leadership and disagreement. Go in with your strongest project fully rehearsed and a few questions of your own about the work.

What to demonstrate

• Overall fit for the role, covering technical and interpersonal sides
• Consistency between what you said in earlier stages and what you say now
• How you connect model-based design, embedded code and hardware validation into one account of your work

How to prepare

• Rehearse one flagship project for each of three lenses: technical depth, cross-functional collaboration and leadership
• Review every answer you have given so far and make sure project details, tools and your role stay consistent
• Prepare questions about how software, hardware, systems and manufacturing teams work together on a release, and about the onsite pattern

Where candidates lose points

Describing Simulink as a diagramming tool and never getting from the model to code running on a target

Narrate the whole chain for one project: requirement, model, simulation, code generation, integration with handwritten drivers, and validation on hardware. Name the solver, the sample time and how you checked the generated code against the model.

Writing the C answer for a desktop: reversing an array without handling NULL, zero or one element, or building a state machine with blocking delays

State the signature and the edge cases first. Keep state machines event-driven and non-blocking, with the state held in a variable or table, and say how events arrive from interrupts.

Jumping to a cause in the sensor-troubleshooting scenario and blaming the sensor or the software before isolating anything

Walk a fixed sequence: power and wiring, the raw signal on a scope or logic analyzer, the register or ADC values, then scaling and calibration, then timing and sampling. Say what each step would rule out.

Telling every behavioral story as 'we', or casting the hardware or manufacturing team as the obstacle

For each story, write the one decision that was yours and the evidence behind it. Describe other teams by what they needed and what you agreed, since cross-functional work is central to the role.

Listing MATLAB/Simulink, C and C++ as skills with no project behind them, then struggling when asked for specifics

Pick two projects and know them to the detail: target, tools, your part, what failed, what you measured. Say plainly where your experience stops and how you would close the gap.

Questions & practice

How would you approach optimizing control algorithms for real-time systems?

Medium · Problem-Solving / Case Studies

Approach

1. Measure first. Compare the worst-case execution time with the control period and set targets for deadline and jitter. Measure with a cycle counter (DWT CYCCNT on Cortex-M) or a GPIO toggled and watched on a scope, and profile before changing any code.
2. Look for algorithmic savings. Run slow outer loops at a lower rate than the fast inner loop. Replace trigonometric or nonlinear functions with lookup tables plus interpolation, multiply by a precomputed reciprocal instead of dividing, and precompute constants that come from the discretisation.
3. Choose the arithmetic. On a part without an FPU, use fixed point (Q15/Q31 scaling with saturation). With a single-precision FPU, keep everything in float (use 1.0f literals so nothing is promoted to double). Handle overflow and integrator windup explicitly, for example by clamping the integrator.
4. Make the timing deterministic. Assign priorities rate-monotonically (shorter period gets higher priority), keep ISRs short, use DMA for ADC sampling, and avoid dynamic allocation and unbounded loops on the control path.
5. Verify that the optimisation changed nothing it should not. Compare the optimised code back to back with the reference model or the floating-point version, and check that quantisation and the added delay leave enough stability margin.

Follow-up

• How do you choose the sample rate of a control loop?
• How does fixed-point quantisation affect a PID controller or a digital filter?
• The controller misses its deadline now and then. What do you look at?

Write a function in C that reverses an array in place.

Medium · Coding / Algorithms

Approach

1. Signature: void reverse(int *a, size_t n). Use two indices, i from 0 and j from n-1, and swap a[i] and a[j] with a temporary while i < j. This makes n/2 swaps, runs in O(n) time and uses O(1) extra space.
2. Guard the edge cases. Return early when a is NULL or n < 2: with size_t, n - 1 wraps to SIZE_MAX when n is 0. An odd length leaves the middle element where it is.
3. Use a temporary variable rather than the XOR swap. XOR swap zeroes the value when both operands are the same location, and it is harder to read. Compilers handle a plain temporary well.
4. For a generic version, write void reverse(void *base, size_t n, size_t size) and swap element bytes through unsigned char pointers, which avoids malloc or a VLA on a small embedded target.
5. Test n = 0, 1, 2, an odd length and an even length, and say these cases aloud before writing the loop.

Follow-up

• How would you reverse a singly linked list in place?
• How do you rotate an array by k positions in place? (Three reversals: the whole array, then the first k elements, then the rest.)
• How would you make the function work for any element type?

How would you implement a state machine for an embedded system?

Medium · Coding / Algorithms

Approach

1. Derive the states and events from the requirement and draw the transition table first. Represent states and events as enums, and include a safe initial state entered on reset.
2. Choose an implementation. A switch on the current state is readable for a few states. A const 2D table indexed by [state][event] of {next state, action function pointer} gives O(1) dispatch, sits in flash and is easy to review. For larger designs, use hierarchical machines (Stateflow or a framework).
3. Separate event capture from processing. ISRs post events to a single-producer, single-consumer ring buffer, and the main loop or a task dispatches them, so ISRs stay short and each transition runs to completion.
4. Handle entry and exit actions, guards, and timeouts driven by a tick counter. Decide what an unexpected event does (ignore, log, or move to a fault state) rather than leaving it undefined.
5. Test on the host by feeding event sequences and checking the resulting state and actions, aiming to exercise every reachable cell of the table.

Follow-up

• How would you add a timeout transition, for example leaving a state if no acknowledgement arrives?
• How do you make posting events from an ISR safe?
• When would you move from a flat state machine to a hierarchical one?

Explain the differences between synchronous and asynchronous programming in embedded systems.

Medium · Coding / Algorithms

Approach

1. Synchronous (blocking): the caller waits until the operation finishes, for example by polling a status flag or busy-waiting a delay. Sequencing is simple and deterministic, but the CPU is wasted, and in a superloop everything else is delayed.
2. Asynchronous: start the operation and get notified on completion through an interrupt, a DMA-complete callback or an RTOS event or semaphore. The CPU can do other work or sleep to save power. The cost is concurrency: callbacks run in interrupt context, and shared state needs protecting.
3. Map this onto architectures: a polled superloop, interrupt-driven with flags, RTOS tasks that block (synchronous inside the task, asynchronous across the system), or event-driven active objects.
4. Choose by duration and timing. Polling suits operations shorter than the interrupt overhead, or cases needing tight deterministic timing. Asynchronous suits long operations such as slow UART transfers, flash erase or ADC sampling with DMA, and low-power designs.
5. Name the pitfalls. volatile stops the compiler caching a value but does not make a read-modify-write atomic, so use critical sections or atomic operations. Functions called from ISRs must be reentrant. RTOS mutexes can cause priority inversion, which priority inheritance mitigates.

Follow-up

• How do you share a multi-byte variable between an ISR and the main loop safely?
• What is priority inversion, and how does an RTOS mitigate it?
• How do you bound the response latency in an interrupt-driven design?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

What are the key features of MATLAB/Simulink that support model-based development?

Medium · Technical / Domain Questions

Approach

1. Start from the modelling core. Simulink block diagrams hold the controller and the plant in one model, Stateflow handles mode and supervisory logic, and model-in-the-loop simulation exercises the controller against the plant before any hardware exists.
2. Cover code generation. Embedded Coder generates C or C++ from the model, which needs a fixed-step discrete solver. Fixed-Point Designer sets data types and scaling, and a Simulink data dictionary holds the signal and parameter definitions shared with the code.
3. Cover verification. Simulink Test provides harnesses and a test manager, Simulink Coverage measures decision, condition and MC/DC coverage, and Simulink Design Verifier proves properties or generates tests. SIL and PIL runs compare the generated code against the model back to back.
4. Cover modularity and standards. Model referencing and libraries split a large model and allow incremental builds, and variant subsystems handle product variants. Model Advisor checks modelling guidelines and code-generation settings, and Requirements Toolbox links blocks to requirements for traceability.
5. Close with the trade-off. Model-based design catches logic errors early and keeps model and code consistent, but plant-model fidelity limits what simulation proves, and drivers and low-level I/O are usually still written by hand.

Follow-up

• What is the difference between MIL, SIL, PIL and HIL testing, and what does each one catch that the previous one cannot?
• How would you resolve a fixed-point overflow that shows up only in the generated code?
• How do you manage merges and reviews of Simulink models in version control?

Can you explain the process of integrating software with hardware components?

Medium · Technical / Domain Questions

Approach

1. Start from the datasheet and the schematic: pin mux, voltage levels, bus type (I2C, SPI, UART, CAN), timing limits and power-up sequencing. Agree on an interface definition with the hardware team before writing drivers.
2. Bring the board up in order. Confirm power and the clock configuration first, then a GPIO toggle or a UART print to prove the toolchain and clocks, then bring up each peripheral alone while you check its waveform on a scope or logic analyzer.
3. Put the hardware behind a driver or HAL layer so the application logic (hand-written or generated from a model) can be tested on the host. Generated model code calls the drivers through I/O blocks or a thin wrapper that runs at the model's sample rate.
4. Verify against the requirement, not only that it works. Test signal ranges and limits, bus errors, timeouts and recovery (for example, clocking SCL to release a stuck I2C slave), on a bench or HIL rig, and record the results for the hardware team.
5. Plan for hardware revisions. Detect the board revision at boot, keep errata workarounds in the driver layer, and keep one code base with configuration per revision instead of forking it.

Follow-up

• A driver works on the dev kit but not on the custom board. What do you check first?
• When it is unclear whether a fault is in hardware or software, how do you split the investigation with the hardware team?
• A new board revision moves a peripheral to different pins. How do you support both revisions?

Discuss a project where you utilized model-based design.

Medium · Technical / Domain Questions

Approach

1. Choose a project where you owned a model all the way to target code. State the controller, the plant it ran against, the sample rates and the requirements it had to meet.
2. Walk the workflow in order: requirements, then the model, then MIL simulation against test vectors, then code generation, then SIL or PIL back-to-back comparison, then integration with the drivers on the target, then bench or HIL testing.
3. Name the concrete decisions you made: fixed-point or floating-point and how you chose the scaling, how you handled multiple rates (rate transition blocks, task mapping), and how you split the model into referenced models or libraries.
4. Quantify the result: requirements or coverage reached, defects caught in simulation rather than on hardware, execution time and memory on the target.
5. Say where simulation fell short (for example, an integration issue the plant model did not capture) and what you changed afterwards.

Follow-up

• How did you check that the plant model was accurate enough to trust the simulation?
• How did you confirm the generated code behaved the same as the model?
• Which parts would you still write by hand instead of generating them, and why?

Describe a complex technical challenge you faced and how you resolved it.

Medium · Problem-Solving / Case Studies

Approach

1. Pick a challenge with a technical root cause that you found yourself, such as an intermittent fault, a timing overrun, memory corruption or an integration failure, and state the impact in one sentence.
2. Structure it as an investigation: the symptom, the hypotheses you ranked, the experiment that ruled each one in or out, the root cause, the fix, how you verified it, and what you added so it cannot recur (a test, a check, a review rule).
3. Show the evidence you worked from (scope traces, logs, measurements, coverage results), not only the conclusion.
4. Explain why you chose that fix over the alternatives, with its cost, for example moving work out of an ISR rather than raising its priority.
5. Keep your own role clear. A story where the team solved it and your part is vague, or one that ends without verifying the fix, does not answer the question.

Follow-up

• Which hypothesis did you rule out first, and how?
• How did you confirm the fix held on real hardware or in the field?
• What would have caught this problem earlier?

How do you approach debugging and testing embedded software?

Medium · Technical / Domain Questions

Approach

1. Testing in layers. Unit-test the logic on the host (Unity, CppUTest or GoogleTest) behind a hardware abstraction layer that can be mocked. Add static analysis (strict compiler warnings, a MISRA checker), then integration tests on the target, then hardware-in-the-loop for closed-loop behaviour.
2. Reproduce before theorising. Decide whether the fault is deterministic or depends on timing, record the build, the board revision and the inputs that trigger it, and read the reset-cause register when the symptom is a reset.
3. Tools matched to the symptom. Use a JTAG or SWD debugger with breakpoints and data watchpoints for memory corruption. A logic analyzer or oscilloscope, plus a GPIO toggled around an ISR, shows timing. SWO/ITM trace or a RAM ring-buffer log replaces printf, which changes the timing it is supposed to observe.
4. Check the usual embedded causes. Stack overflow (paint the stack and check the high-water mark, or use an MPU guard region), data shared between an ISR and the main loop without volatile or a critical section, uninitialised variables, watchdog timeouts and peripheral misconfiguration.
5. Close the loop. Every bug fixed gets a regression test. CI builds the target image and runs the host tests on each change.

Follow-up

• A device in the field resets about once a day. How do you find out why?
• How do you unit-test code that writes directly to memory-mapped registers?
• Why does volatile not make a read-modify-write on a shared variable safe?

Given a scenario involving sensor integration, outline your approach to troubleshooting.

Medium · Problem-Solving / Case Studies

Approach

1. Pin down the symptom: no data, wrong values, noise, or intermittent dropouts. Then find what changed: a board revision, a firmware change, the environment, or which units are affected.
2. Work up from the physical layer. Check supply and ground, I2C pull-ups and signal edges on a scope, then decode the bus with a logic analyzer. Does the device ACK at the expected address (7-bit versus 8-bit address confusion)? Do the SPI CPOL and CPHA settings match the datasheet?
3. Check the driver. Read the ID (WHO_AM_I) register first, compare the init sequence and power-up delay with the datasheet, and check the range and output-rate settings, byte order, two's-complement conversion and unit scaling.
4. Check the data path. Compare against a reference instrument, read only after data-ready, and check that the sample rate is high enough to avoid aliasing and that the filtering is appropriate.
5. Isolate by substitution. Swap in a known-good sensor or board or a dev kit, or bisect the firmware versions. Each swap should rule out one layer whichever way it turns out.

Follow-up

• Readings are clean at rest but noisy when a motor runs. What do you suspect and how do you confirm it?
• The I2C bus hangs occasionally. How do you detect it and recover?
• How would you detect a failed sensor at runtime?

Suggested practice checklist

The plan follows the reported topics in order: model-based design, embedded C/C++ coding, debugging and integration, real-time control, then the people questions, and ends with a mixed rehearsal. Each day produces something you can reuse in the interview.

Day 1 — Map the loop and your experience

• Write down the five reported rounds and what each is described as covering, and mark the one you are least ready for
• Build a table with one row for each reported must-have (MATLAB/Simulink, embedded C/C++, hardware or production support, real-time software) with the project, your role and the target hardware
• Choose the two projects you will use as your main examples through the whole loop

Deliverable: A one-page loop map plus a skills-to-projects table naming your two main projects.

Day 2 — Model-based design and Simulink

• Answer aloud: what are the key features of MATLAB/Simulink that support model-based development? Cover subsystems, solvers and sample times, signal logging, code generation and test harnesses
• Write a one-page walkthrough of a project where you used model-based design, from requirement to model to generated code to hardware
• Write down how you checked generated code against the model, for example by running the same test inputs through both

Deliverable: A spoken answer on Simulink features and a one-page model-to-hardware walkthrough of one project.

Day 3 — Embedded C and C++ coding

• Write the in-place array reversal in C on paper, then add tests for NULL, length 0, length 1, even and odd lengths, and state its complexity
• Implement a small event-driven state machine in C (a button debounce or a simple protocol parser) using a transition table
• Write a short comparison of synchronous and asynchronous programming in embedded systems, with a polling example and an interrupt-driven example
• Write five sentences on the role of interrupts, including keeping handlers short and sharing data with volatile or atomic access

Deliverable: A tested C file with the reversal function and the state machine, plus a written sync-versus-async comparison and an interrupt explanation.

Day 4 — Debugging and hardware integration

• Write a numbered debugging sequence for embedded software that fails intermittently: reproduce, observe, bisect, instrument, fix and add a regression test
• Write the integration steps for a new board: power and clock checks, peripheral bring-up, driver tests, then the application software and validation
• Outline a sensor troubleshooting plan, from wiring and power to raw signals, scaling, calibration and sampling, with what each step rules out

Deliverable: Three written checklists: debugging and testing, hardware integration, and sensor troubleshooting.

Day 5 — Real-time control and your hardest problem

• Write an outline for optimizing a control algorithm on a microcontroller: measure worst-case execution time against the loop period, profile, simplify the math, consider fixed-point and lookup tables, and move non-critical work out of the interrupt
• Write a STAR answer to 'Describe a complex technical challenge you faced and how you resolved it' using an embedded or control problem of your own
• Choose the project example where you can show a measurement before and after, and write those two numbers down

Deliverable: A control-optimization outline and a written STAR story for the hardest technical challenge, each with a measured result.

Day 6 — Behavioral stories

• Write STAR stories for the four reported people questions: embedded C/C++ experience, cross-functional collaboration, leading a project or initiative, and handling disagreements
• Add a short story about explaining a technical issue to a non-technical audience and one about acting on feedback from a colleague or stakeholder
• Rehearse each story aloud and cut it to the decision you made, the evidence and the outcome

Deliverable: Six rehearsed STAR stories, each with one named decision and one measurable or observable outcome.

Day 7 — Mixed rehearsal across the loop

• Run a mixed session: one Simulink question, one embedded debugging question, one C coding task and one cross-functional story, answered aloud one after another
• Write three questions to ask about how software, hardware, systems and manufacturing teams work together on a release
• Check logistics you have not confirmed: the format of the technical stage and the onsite expectation

Deliverable: A recorded or written mixed rehearsal, a list of three questions for the team and the logistics confirmed.

Stories for hardware, systems and manufacturing teams

The reported behavioral stages cover interpersonal skills, teamwork and fit. For this embedded role, candidates describe working with hardware, systems and manufacturing teams, so prepare stories where a hardware or production constraint shaped a software decision, where you agreed an interface with another team, and where you handled a disagreement with evidence. Use STAR, as candidates report, and keep your own decision at the center.

1. Describe a situation where you had to explain a complex technical issue to a non-technical audience.
2. How do you handle feedback from team members or stakeholders?

Describe your experience with embedded C/C++ programming.

Medium · Technical / Domain Questions

Approach

1. Organize the answer by target and responsibility rather than by years: which microcontroller or board, whether it ran bare-metal or under an RTOS, which modules you owned, and which language you used where. State your honest balance between C and C++.
2. Show embedded-specific judgment with one or two concrete practices you have used: volatile for variables shared with interrupt handlers, fixed-width integer types, no dynamic allocation after initialization, bounded loops, and a coding standard or static analysis tool if your team used one.
3. If you generated code from Simulink models, explain how that code met handwritten drivers and what the interface between them looked like. This ties your C/C++ experience to the model-based workflow candidates describe for this role.
4. Pick one piece of code and explain the constraint that shaped it, for example RAM, flash or a timing deadline, and what you measured to confirm it was met on the real target.
5. Say what you have not done. If most of your work is C, say how you would approach C++ on a small target, such as avoiding exceptions and heap use in time-critical paths.

Follow-up

• Which parts of that code ran in interrupt context, and how did you pass data to the main loop safely?
• How did you test on the target and not only in simulation or on a host build?
• Which C++ features would you avoid on that target, and why?

Can you share an experience where you had to collaborate with cross-functional teams?

Medium · Behavioral / Leadership

Approach

1. Choose a project where you worked with at least two of hardware, systems and manufacturing, and say in one sentence who needed what from you and what you needed from them.
2. Make the interface concrete: a signal list, pin assignment, message format, calibration value, test fixture or bring-up checklist. Name the artefact you wrote or negotiated and how you kept it current when the hardware design changed.
3. Describe one point of friction honestly, such as a timing assumption the hardware team did not know about, and how you resolved it with a measurement, a scope capture or a test result rather than with opinion.
4. State the result in checkable terms: bring-up completed, a defect found before production, or a release that went out. Say what you personally changed in how the teams worked together afterwards.
5. Avoid a story in which the other team is the problem. Keep your own decisions at the center and use 'I' for what you did.

Follow-up

• What did the other team need from you that you had not planned for?
• How did you keep the agreement current when the hardware design changed?
• What would you do differently if manufacturing found a problem after release?

Describe a time when you had to lead a project or initiative. What was the outcome?

Medium · Behavioral / Leadership

Approach

1. Define what you led, even without a title: a bring-up, a migration of a module to a model-based flow, a test-automation effort, a release. Give its goal and how many people it involved, accurately.
2. Show how you broke the work down: milestones, owners, what was risky first, and how you tracked progress. For embedded work, name the dependency that mattered most, such as hardware availability or a test rig.
3. Tell one decision you made under constraint, such as cutting scope, choosing between two designs or changing the order of work, and give the reason you chose it.
4. Report the outcome as it was, including any miss. Give evidence of the result, such as what shipped, what passed validation or what was measured, and say what you would structure differently now.
5. Common mistake: describing the project in the team's voice and never saying what you decided. Name the calls that were yours.

Follow-up

• How did you decide what to cut when the schedule slipped?
• Who disagreed with your plan, and how did you handle it?
• What would you change in how you set up that work if you did it again?

How do you handle conflicting ideas or disagreements within a team?

Medium · Behavioral / Leadership

Approach

1. Choose a real technical disagreement with substance, such as fixed-point versus floating-point math, polling versus interrupts, where logic should live (in the Simulink model or in handwritten code), or how much to test on hardware. Avoid a personality clash.
2. Show that you understood the other position first: restate it fairly and name the criterion that mattered, for example timing budget, memory, testability or schedule.
3. Resolve it with evidence where you can: a quick prototype, a measurement on the target, a simulation in the model, or a review with the person who owned the constraint. Say who made the final call.
4. Close the loop: once the decision was made, say how you committed to it even if it went against your preference, and how the working relationship stood afterwards.
5. Avoid a story where you were simply right and everyone came around. Include something you learned or a point where you changed your mind.

Follow-up

• What would you have done if the data had been inconclusive?
• What if the person making the decision had overruled you?
• Did the decision hold up, and how did you find out?