Collins Aerospace Software Engineer Interview Guide

The 60-second brief

Collins Aerospace is a business unit of RTX. Candidates describe its software engineers as building avionics and defense software: flight management, tactical communications, flight control and cockpit display systems that run on military and commercial aircraft. The role sits between application-level code and hardware interfaces, including real-time operating systems, and the work is shared with systems engineers, hardware designers and verification specialists. Reported work ranges from embedded C/C++ for flight control, to C#/.NET tooling, to cloud-connected avionics applications, so the day-to-day language depends on the team.

This guide is for candidates applying for a Software Engineer position at Collins Aerospace, from entry level to senior. It covers the three reported rounds, the five behavioral questions and fourteen technical and domain questions candidates report, and a seven-day plan. Technical depth differs by team (embedded and avionics, enterprise toolchain, or cloud applications), so the guide separates the shared core from the parts to deepen after reading your own job posting.

Candidates report three stages over roughly 3-5 weeks: a Screening Call, Technical Interviews and Behavioral Interviews. Reports also mention a recruiter screen or asynchronous video assessment at the start, and a panel or on-site visit near the end for larger sites.

Focus areas

• Object-Oriented Programming (OOP)
• SQL Querying
• Java (language fundamentals)

Overview

The reported questions share one theme: can you write software whose behavior you can explain and verify. The technical questions ask about pointers and memory ownership, race conditions between threads, the cost of a linked list or hash table, what a key or an index does in a relational schema, and how unit testing differs from hardware-in-the-loop testing. None of them is a puzzle. Each rewards a precise definition, a small example you can sketch, and a trade-off you can name.

Depth depends on the team. Candidates report that embedded and avionics groups go into C/C++, data structures, operating-system concepts and memory management, while general software roles lean on behavioral fit, a walk through your resume projects and your problem-solving approach. The reported topic mix is OOP, SQL querying, Java fundamentals, DBMS and embedded systems. Prepare the shared core first (OOP, threads, memory, keys and indexes), then spend your extra time on the area your posting emphasizes.

Behavioral questions carry real weight. Five behavioral prompts are reported here: a teammate who was not pulling their weight, a challenging project, a failure, prioritizing under tight program deadlines, and why you want to work for Collins Aerospace. Reports also list a disagreement with a senior engineer, a deadline at risk, and quality on vague requirements. Five or six stories, each told in the first person with a measured result, cover almost all of them.

Because the domain is safety-critical, the standards and testing questions (DO-178, MISRA C, HITL, system of systems, build pipelines, risk in a migration) reward honest, concrete answers. If you have not used DO-178, say what you have used instead, such as static analysis, code review and requirement-to-test traceability, and show you understand why those practices exist. Candidates also report that every project on your resume is fair game, so finish the project inventory before anything else.

The Collins Aerospace interview process

Candidates describe three stages spread over roughly 3-5 weeks. Exact stages vary by site and team level, and some groups add a short presentation or a paper-coding exercise.

Screening Call

Candidates describe this stage as an initial call about your resume and your interest in the position. Reports also mention that the opening can be a recruiter screen or an asynchronous video assessment (HireVue is named) with introductory and situational questions. Approach it as a short, structured pitch: who you are, which languages and tools you have used, and a specific reason for this position.

What to demonstrate

• How your resume lines up with the position you applied for
• Your stated interest in the role and in the aerospace and defense domain
• Clarity and structure when you speak about your own background

How to prepare

• Write a spoken resume walk-through that links each project to its language, tools and your role, and rehearse it aloud.
• Prepare the answer to why you want to work for Collins Aerospace around named product areas (flight management, communications, flight control, cockpit displays) and your own related coursework or projects.
• If an asynchronous video assessment is possible, record yourself answering one situational question to check pacing and framing.

Technical Interviews

Reported as one or more interviews on technical skills, with the hiring manager or a small engineering panel. Candidates say the content depends on the team: embedded and avionics groups go into C/C++, data structures, OS concepts and memory, while general software groups lean on resume project walk-throughs. The reported technical questions fall into core programming and object-oriented design, technical and resume deep-dives, and domain and system fundamentals. Practise explaining aloud while sketching on paper, because some loops include a paper-coding exercise.

What to demonstrate

• Fundamentals in your main language: OOP, pointers and memory, threads and race conditions
• Whether you can explain the architecture and trade-offs of work you have already done
• Basic data-structure implementation and complexity analysis, plus relational database concepts
• Testing, standards and risk-management knowledge for safety-critical software

How to prepare

• Implement a singly linked list and a chained hash table by hand, then state time and space complexity for each operation.
• Write a thread-safe queue for incoming sensor readings and explain which state each lock protects.
• Draw the architecture of your strongest project, label the data flow between components, and list two design trade-offs you made.
• Write out how unit tests, static analysis and HITL integration tests each catch different defects.

Behavioral Interviews

Interviews on behavioral competencies and fit. Candidates report that behavioral performance weighs heavily, with questions on teamwork, resolving conflict and personal accountability. The reported prompts include a teammate not pulling their weight, a challenging project, a failure, prioritizing under tight deadlines, disagreeing with a senior engineer, and a deadline at risk. Approach it with a bank of five or six STAR stories, each mapped to several prompts.

What to demonstrate

• Teamwork and how you handle conflict with peers or senior engineers
• Accountability for deliverables from requirements through testing
• How you work through ambiguity, setbacks and deadline pressure

How to prepare

• Build a story-by-prompt grid so each of five or six stories covers at least two reported prompts.
• Rewrite each story so the Action section is entirely about what you did, and add a result you can measure.
• Prepare three or four questions about the team's technology stack, development process and site facilities.

Where candidates lose points

Describing a resume project as a feature list, then stalling when asked how data moves between its components or why you chose one design over another.

For each project on your resume, prepare a paper sketch with components and data flow, your exact role, two trade-offs you made and one defect you fixed. Practise explaining it while drawing, because candidates report face-to-face and panel loops.

Reciting the four OOP principles as definitions, mixing up encapsulation with abstraction, and having no example for how polymorphism differs from encapsulation.

Hold one small class hierarchy in your head, for example a sensor base class with concrete sensors. Show encapsulation as state hidden behind an interface and polymorphism as one call resolved to different behavior at run time through virtual dispatch, then connect it to the C++ vtable.

Answering the race-condition question with 'use a mutex' and nothing about what the mutex protects, lock ordering, deadlock or alternatives.

Name the shared state, the window where the invariant is broken, and the fix: a lock around the full read-modify-write, a condition variable for a bounded queue, atomics for a single counter, or message passing. State the four conditions for deadlock and one way to break them.

Treating DO-178 or MISRA C as buzzwords, or implying experience with them that you cannot back up.

State honestly what you have used: a coding standard, static analysis, code review, requirement-to-test traceability. Explain in your own words what each is for, so the answer shows you understand the practice even without certified-project experience.

Telling behavioral stories in team pronouns with no result, so the listener cannot tell what you personally did or whether it worked.

Keep five or six STAR stories with the Action written in the first person and a measurable result at the end. Check each story against the reported prompts: conflict, failure, deadline pressure, a disagreement with a senior engineer and vague requirements.

Questions & practice

What is the difference between processes and threads, and how do you handle race conditions in multi-threaded

Medium · Core Programming & Object-Oriented Desig

What is the difference between processes and threads, and how do you handle race conditions in multi-threaded applications?

Approach

1. Define the split: a process has its own virtual address space, file descriptor table and resources; threads in one process share the heap, globals and open files but each has its own stack and registers. Threads are cheaper to create and switch between; processes give fault isolation and need IPC (pipes, sockets, shared memory, message queues) to communicate.
2. Define a race condition with a concrete case: two threads running counter++ on a shared int, where the load, increment and store interleave and one update is lost. The fix is to make the read-modify-write atomic or mutually exclusive.
3. Match the tool to the case: a mutex (std::mutex with std::lock_guard so it unlocks on every exit path) for compound invariants, std::atomic for single counters or flags, condition variables for waiting on a state change, and thread confinement or message passing so nothing is shared. volatile in C/C++ is not a synchronization primitive.
4. Cover what locking introduces: deadlock (prevent it with one global lock order, or std::scoped_lock to take several mutexes together) and, on an RTOS, priority inversion, which priority-inheritance mutexes address. Keep critical sections short and never block on I/O while holding a lock.
5. Say how you find races: ThreadSanitizer or Helgrind over the test suite, stress tests that vary thread counts and timing, and a review of every piece of shared mutable state.

Follow-up

• How would you design a thread-safe bounded queue for incoming sensor data with one producer and one consumer?
• What is the difference between a mutex and a counting semaphore, and when would you use each?
• What is priority inversion, and how does an RTOS deal with it?

How do pointers and dynamic memory management work in C/C++, and how do you prevent memory leaks?

Medium · Core Programming & Object-Oriented Desig

Approach

1. Start from the memory model: a pointer stores an address; locals live on the stack and disappear when the function returns; heap blocks from malloc/calloc/realloc (C) or new (C++) live until freed explicitly. Pair them exactly: free for malloc, delete for new, delete[] for new[]; a mismatch is undefined behaviour.
2. Define a leak precisely: the last pointer to a heap block is lost or overwritten before the block is freed. Typical causes are early returns and error paths that skip the free, an exception thrown between new and delete, and p = realloc(p, n), which leaks the original block when realloc returns NULL.
3. In C++, prevent leaks with RAII: std::unique_ptr (via std::make_unique) for single ownership, std::shared_ptr only when ownership is genuinely shared, and std::weak_ptr to break cycles, because two shared_ptrs that point at each other never reach a zero count.
4. In C, state ownership in each function's contract, use a single cleanup path (the goto cleanup idiom), check every allocation result, and set pointers to NULL after free so a repeated free is harmless (free(NULL) does nothing).
5. Name the tools and the embedded angle: Valgrind memcheck and AddressSanitizer/LeakSanitizer in tests, static analysis for leak paths; many safety-critical codebases allocate only at initialization or use fixed-size pools, and MISRA C:2012 forbids the stdlib allocation functions.

Follow-up

• Given a C function with several error returns, where does it leak and how would you restructure it?
• What is the difference between a dangling pointer, a double free and a leak, and which tool catches each?
• Why do many embedded systems avoid heap allocation after start-up?

Walk through a basic data structure implementation, such as a linked list or hash table, and analyze its time

Medium · Core Programming & Object-Oriented Desig

Walk through a basic data structure implementation, such as a linked list or hash table, and analyze its time and space complexity.

Approach

1. Pick one structure and outline it before coding: for a singly linked list, a Node {value, next} and a List holding head, a tail pointer if O(1) append is needed, and a size counter.
2. Give the costs: insert or delete at the head O(1); append O(1) with a tail pointer, O(n) without; search and access by index O(n); delete after a known node O(1). Space is O(n) with one pointer of overhead per node and worse cache locality than an array.
3. Handle the edge cases out loud: empty list, single node, deleting the head or the tail (and updating tail), and a value that is absent. In C/C++, free each removed node, and walking with a pointer-to-pointer removes the special case for the head.
4. For a hash table: an array of buckets, index = hash(key) mod capacity, collisions resolved by separate chaining (a list per bucket) or open addressing (linear probing, with tombstones for deletes). Average O(1) get, put and delete; worst case O(n) when many keys collide; space O(n + capacity).
5. Explain resizing: when the load factor passes a threshold (0.75 is a common choice for chaining), double the capacity and rehash every entry. One resize costs O(n), but doubling keeps the amortized insert cost at O(1).

Follow-up

• Reverse the linked list in place and state its time and space cost.
• How do you detect a cycle in a linked list without extra memory?
• What happens to the hash table's performance with a poor hash function, and how would you test for it?

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?

Stop tag and share joins from fanning out a page

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

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

Approach

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

Follow-up

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

Explain the four fundamental principles of Object-Oriented Programming (OOP) and how polymorphism differs from

Medium · Core Programming & Object-Oriented Desig

Explain the four fundamental principles of Object-Oriented Programming (OOP) and how polymorphism differs from encapsulation.

Approach

1. Name the four and give each a one-line definition tied to code: encapsulation (state kept private behind methods that protect an invariant), abstraction (callers depend on an interface, not the implementation), inheritance (a subclass reuses and extends a base type), polymorphism (one call site, behaviour chosen by the object's actual type).
2. Draw the contrast directly: encapsulation hides and protects data inside one class; polymorphism lets many types answer the same call differently. A class can be fully encapsulated with no polymorphism, and polymorphism works through public interfaces whatever each class hides internally.
3. Show both in one small example: a Sensor base class with a virtual read(), TemperatureSensor and PressureSensor overriding it, the raw register value kept private (encapsulation), and a loop over Sensor pointers calling read() (polymorphism).
4. Separate runtime polymorphism (C++ virtual functions dispatched through a vtable; Java instance methods, which are virtual unless final, private or static) from compile-time polymorphism (overloading, C++ templates). Mention that a C++ base class deleted through a base pointer needs a virtual destructor, or the behaviour is undefined.
5. Close with the trade-off: deep inheritance trees couple classes tightly, so prefer composition and small interfaces; in hard real-time or certified code, dynamic dispatch complicates worst-case timing analysis and coverage, so be ready to justify it.

Follow-up

• Walk through what happens when a virtual function is called through a base-class pointer: where the vptr and vtable live and what the call costs.
• When would you choose composition over inheritance? Give an example from your own code.
• Why does a polymorphic base class in C++ need a virtual destructor?

Explain the difference between primary keys, foreign keys, and indexes in relational database design.

Medium · Core Programming & Object-Oriented Desig

Approach

1. Primary key: the column or column set that uniquely identifies each row; it must be unique and NOT NULL, a table has at most one, and it can be composite. Engines back it with an index automatically (PostgreSQL creates a unique B-tree; MySQL InnoDB clusters the table on it).
2. Foreign key: a column whose values must match a primary key or unique column in the referenced table, so the database rejects orphan rows. Name the referential actions (ON DELETE CASCADE, SET NULL, RESTRICT / NO ACTION) and choose one on purpose, since CASCADE can delete far more than intended.
3. Index: a separate structure, usually a B-tree, that turns lookups and range scans from a full table scan into roughly O(log n), at the cost of storage and slower INSERT/UPDATE/DELETE. It is a performance tool, not a constraint, except a unique index, which also enforces uniqueness.
4. Tie them together: PostgreSQL does not index a foreign-key column automatically (MySQL InnoDB requires one and creates it), so index FK columns used in joins or parent deletes. In a composite index on (a, b), filters on a or on a and b can use it; a filter on b alone generally cannot.
5. Illustrate with a two-table schema, for example aircraft(id PK) and flight(id PK, aircraft_id FK referencing aircraft), an index on flight(aircraft_id), and the join that benefits from it.

Follow-up

• When would you choose a natural key over a surrogate key?
• A query filtering on an indexed column is still slow. How do you find out why?
• Can adding an index make the application slower overall? When?

Walk me through the software architecture of your final-year capstone project or a recent production system yo

Medium · Technical & Resume Deep-Dives

Walk me through the software architecture of your final-year capstone project or a recent production system you built.

Approach

1. Open with one sentence on what the system does, who used it, and the constraint that shaped it (latency, memory, safety, budget, team size), so every later decision has a reason behind it.
2. Sketch the components and the data flow on paper: inputs, processing stages, storage, outputs, and the interface or protocol on each edge. Then trace one real request or data sample end to end through the sketch.
3. Say which parts you built yourself and which you integrated or inherited, using I for your own work and naming teammates' parts plainly.
4. Defend two decisions as trade-offs: the option chosen, the one rejected, and the evidence (a measurement, a hardware or schedule constraint). Cover how errors are handled at each boundary.
5. Finish with how the system was tested and what you would change now; a candid critique of your own design is stronger than a flawless-sounding one.

Follow-up

• What happens if the middle component in your sketch fails or receives malformed data?
• Why that language, framework or database, and what would have gone wrong with the alternative?
• How would the design change if the input rate grew ten times?

What specific role did you play in your team’s recent engineering project, and how did you make key design tra

Medium · Technical & Resume Deep-Dives

What specific role did you play in your team’s recent engineering project, and how did you make key design trade-offs?

Approach

1. State your role precisely in the first sentence: what you owned, who else was on the team, and what you only contributed to. Use I for your decisions and credit the team where the work was shared.
2. Pick one or two real trade-offs and frame each the same way: the options, the criteria (performance, memory, schedule, testability, maintainability), what you chose and what you gave up.
3. Back each choice with evidence: a prototype, a benchmark, a requirement, or a constraint from hardware or another team, rather than preference.
4. Close with the measured outcome and say whether you would make the same call today, and why.

Follow-up

• Who disagreed with that decision, and how was it settled?
• What did the rejected option end up costing you, if anything?
• If the schedule had been half as long, what would you have cut?

Explain how software testing and hardware-in-the-loop (HITL) integration testing differ in embedded systems de

Medium · Technical & Resume Deep-Dives

Explain how software testing and hardware-in-the-loop (HITL) integration testing differ in embedded systems development.

Approach

1. Define the levels: software tests (unit and software-in-the-loop) run the code on a host or simulator with the hardware replaced by mocks or models; hardware-in-the-loop runs the production software on the real target controller, wired to a real-time simulator that emulates the sensors, actuators and environment around it.
2. Say what each finds: host tests are fast, cheap, run on every commit and reach high coverage of logic and edge cases; HIL catches what they cannot, such as timing and interrupt behaviour, real I/O and bus traffic, target compiler, word-size and endianness differences, and integration faults between boards.
3. Name the costs of HIL: bench time is scarce, rigs are expensive, runs are slower and harder to make deterministic. Use it for integration, timing and fault injection (sensor dropout, out-of-range values, bus errors) that would be unsafe or impossible to trigger on a real aircraft.
4. Give the strategy: push as much verification as possible into host tests behind a hardware abstraction layer, reserve HIL for what needs real hardware, and trace tests at both levels back to requirements so coverage gaps are visible. Mention the usual ladder: model-, software-, processor- and hardware-in-the-loop.

Follow-up

• Give an example of a defect that passes every unit test and only shows up on a HIL bench.
• How do you unit test a function that reads a memory-mapped hardware register?
• How do you keep HIL results repeatable when the simulator and the hardware have timing jitter?

How do you adapt when requirements change late in the software development lifecycle?

Medium · Technical & Resume Deep-Dives

Approach

1. Run an impact analysis before touching code: trace the changed requirement to the design elements, code and tests it affects, and estimate the effort and retest scope. Requirements-to-test traceability is what makes this fast.
2. Make the cost visible to whoever owns the requirement: schedule, risk and what else must slip, so the change goes through change control as an explicit decision rather than a quiet edit.
3. Implement in the smallest safe increment, update the requirement, design notes and tests together, and rerun the regression set the impact analysis identified.
4. Explain how you limit the cost of the next change: clean interfaces, configuration instead of hard-coded values, and an automated test suite that makes late changes safe to land.
5. Anchor it in one real example told in STAR form, including what you did differently on the following project.

Follow-up

• Tell me about a time you pushed back on a late change. How did it go?
• How do you decide which tests to rerun after the change?
• What do you do when the new requirement conflicts with an existing one?

What experience do you have with software development standards such as DO-178 or MISRA C guidelines?

Medium · Domain & System Fundamentals

Approach

1. Answer honestly first: state the direct experience you have; if it is none, say so and move to what you know and the related practice you have done (static analysis, coverage measurement, reviews against a coding standard).
2. DO-178C, which replaced DO-178B, covers software in airborne systems. Software gets a level from A (failure could be catastrophic) to E (no safety effect), and the level sets the objectives: requirements-based testing, traceability between requirements, code and tests, independence in verification, and structural coverage.
3. Know the coverage ladder: statement coverage for Level C, decision coverage added for Level B, and MC/DC added for Level A, where each condition must be shown to independently change the decision's outcome; a decision with N conditions needs at least N + 1 tests.
4. MISRA C is a set of guidelines defining a safer subset of C. MISRA C:2012 classes them as mandatory, required or advisory and checks them with static analysis; a required guideline can be broken only through a documented, approved deviation, a mandatory one not at all.
5. Connect it to code you write: why recursion and stdlib heap allocation are banned (bounded stack and memory use), why every switch needs a default label, and how a static analysis report feeds a code review.

Follow-up

• Write a minimal MC/DC test set for if (a && (b || c)).
• Your code needs to violate a required MISRA guideline. What do you do?
• What changed between DO-178B and DO-178C?

Describe your understanding of a "system of systems" approach in aerospace software deployment.

Medium · Domain & System Fundamentals

Approach

1. Define it: a system of systems is a set of systems that are each useful, operated and often developed independently, but interoperate to deliver a capability none of them provides alone. Commonly cited traits are operational and managerial independence, independent evolution, emergent behaviour and geographic distribution.
2. Make it concrete: an aircraft's flight management, navigation sensors, cockpit displays and radios, together with ground systems and air traffic control, each with its own developers and release cycle, exchanging data over defined interfaces.
3. Draw the software consequences: the interface is the contract (interface control documents, versioned message formats, standard data buses such as ARINC 429 or MIL-STD-1553), so a change in one system needs compatibility planning and coordinated integration testing.
4. Cover failure and emergent behaviour: each constituent validates inputs it does not control, degrades gracefully when a partner goes silent or sends stale data, and is exercised in integration labs mixing real and simulated systems, because some behaviour appears only when they run together.

Follow-up

• How does a system of systems differ from one large, complex system?
• Another team changes the message format your software consumes. How do you keep both sides working?
• How would you test behaviour that only emerges when several systems run together?

How do you implement unit testing and automated build pipelines for embedded or desktop applications?

Medium · Domain & System Fundamentals

Approach

1. Structure the code for testing first: separate logic from hardware behind a hardware abstraction layer (an interface in C++ or C#, a function-pointer table or link-time substitution in C), so the logic compiles and runs on a desktop host.
2. Pick a framework per language and say how you fake dependencies: GoogleTest/GoogleMock for C++, Unity with CMock or CppUTest for C, NUnit or xUnit with a mocking library for C#, JUnit for Java, pytest for Python. Each test checks one behaviour, including boundary and error cases.
3. Describe the per-commit pipeline: build with warnings as errors, cross-compile with the target toolchain, run static analysis (clang-tidy, cppcheck or a MISRA checker), run unit tests with a coverage report (gcov/lcov), and archive versioned build artifacts.
4. Add slower scheduled stages: on-target or emulator runs (QEMU, for example) and hardware-in-the-loop suites, since host tests miss word-size, endianness and timing differences. Pin the toolchain, for example in a container image, so any commit rebuilds identically.
5. Gate merges on the fast stages and keep them fast enough that nobody bypasses them; track coverage trends and untested requirements rather than chasing one percentage.

Follow-up

• How do you unit test code that writes to a memory-mapped register or waits on an interrupt?
• A test passes on the host and fails on the target. What could differ?
• What belongs in the merge gate, and what runs nightly?

How do you manage technical risks during a complex software migration or feature addition?

Medium · Domain & System Fundamentals

Approach

1. Start with a risk list: each risk with likelihood, impact, an owner and a mitigation, covering undocumented behaviour in the old code, data and interface compatibility, performance, schedule and downstream users.
2. Pin down current behaviour before changing it: characterization tests over the existing code and interfaces, plus baseline measurements of timing, memory and throughput, so a regression shows up as a number.
3. Change incrementally instead of in one cut-over: migrate one module or interface at a time (strangler-style), put new behaviour behind a configuration switch or feature flag, and where practical run old and new paths side by side and compare outputs.
4. Set rollback steps and exit criteria in advance: how to revert each step, which test results or metrics mean a step is done, and when to stop and escalate. On embedded targets where rollback in the field is hard, put more weight on bench and integration testing before release.
5. Use the risk list as the status report to stakeholders, and close with a real example of a risk that materialised and what the mitigation saved.

Follow-up

• How do you decide a side-by-side run has lasted long enough to retire the old path?
• Which risk did you miss on a past migration, and how did you discover it?
• How would you migrate a database schema without downtime?

How do you approach debugging a critical software defect when source code documentation is limited?

Medium · Technical & Resume Deep-Dives

Approach

1. Contain and reproduce first: capture the exact symptom, build version, inputs and environment, judge the impact, and apply a safe workaround if the defect is live. A reliable reproduction is worth more than any early theory.
2. Rebuild the missing documentation from other sources: version history (git log, git blame on the failing lines, linked tickets), existing tests, interface definitions, and the people who last changed the code.
3. Narrow the search by bisection: git bisect between a known-good and a known-bad build, or halve the inputs or configuration until the trigger is minimal, then read the code backwards from the failure point.
4. Instrument instead of guessing: breakpoints and watchpoints, targeted logging, core dumps, and on embedded targets a JTAG/SWD debugger or trace. A bug that vanishes when logging is added points to a timing, race or interrupt problem.
5. Prove the fix: a regression test that fails before the change and passes after, a search for the same pattern elsewhere, and a written note of what you learned so the next engineer has the documentation you lacked.

Follow-up

• The defect appears only on the target hardware, never in the simulator. What do you check next?
• How do you confirm you found the root cause rather than a change that hides the symptom?
• git bisect lands on a large merge commit. What now?

Suggested practice checklist

Seven days built around the three reported rounds and the reported question groups: fundamentals first, then databases, testing and standards, then your own projects, with behavioral stories on the final day. Each technical day points at the matching reported questions.

Day 1 — Map the loop and inventory your projects

• Write the three reported stages (Screening Call, Technical Interviews, Behavioral Interviews) and mark which reported question groups you could answer cold today.
• For each resume project, list the language, tools, your role and one design decision you would defend.
• Read your job posting and decide whether it leans embedded and avionics, toolchain or cloud applications, then rank the fundamentals accordingly.

Deliverable: A one-page loop map, a project inventory table, and a ranked list of weak areas.

Day 2 — OOP and concurrency out loud

• Explain the four OOP principles using a single class hierarchy, and say in two sentences how polymorphism differs from encapsulation.
• Explain how virtual functions resolve through a vtable in C++ and the equivalent dispatch in Java.
• Write a bounded thread-safe queue for sensor readings using a mutex and condition variable, naming the race it prevents.
• Answer the process versus thread question and list the four deadlock conditions.

Deliverable: A working thread-safe queue in your main language, plus spoken answers to the OOP and process/thread questions.

Day 3 — Pointers, ownership and core data structures

• Write notes on stack versus heap, pointers versus references, malloc/free versus new/delete, RAII and smart pointers.
• Take a short C snippet with leak paths (early return, missing free) and fix every path.
• Implement a singly linked list (insert, delete, reverse) and a chained hash table, then state time and space complexity including worst-case collisions and resizing.

Deliverable: A leak-fixed C snippet, two implementations, and a complexity table for their operations.

Day 4 — Relational basics and SQL

• Design a small schema and explain primary keys, foreign keys and indexes using it, including how an index speeds reads and costs writes.
• Use EXPLAIN on a slow query before and after adding an index, and write down what changed.
• Outline how you would find a bottleneck in a database-driven application: measure, read the plan, check indexes, look for repeated queries.

Deliverable: A schema with keys and indexes, a before/after EXPLAIN comparison, and two solved practice exercises.

Day 5 — Testing, HITL and avionics standards

• Write a comparison of software testing and hardware-in-the-loop integration testing: what each runs on, what each catches, what each cannot.
• Summarize DO-178 and MISRA C in your own words and write down honestly which related practices you have used.
• Sketch an automated pipeline for an embedded or desktop project: build, unit tests, static analysis, artifacts.
• Write a paragraph on the system-of-systems idea using an example where software, hardware, networks and sensors depend on each other.

Deliverable: A one-page testing and standards sheet and a pipeline diagram.

Day 6 — Resume deep-dive, debugging and changing requirements

• Draw the architecture of your best project on paper and explain the data flow between components aloud.
• Write a short statement of your role and two design trade-offs, including what you gave up in each.
• Outline a debugging sequence for a serious defect with thin documentation: reproduce, narrow the scope, use logs and a debugger, read callers and tests, change only after you can predict the failure.
• Write answers for late requirement changes and for managing risk in a migration or feature addition: impact analysis, regression tests, incremental rollout, rollback.

Deliverable: An annotated architecture sketch and written outlines for the debugging, late-change and migration-risk answers.

Day 7 — Behavioral stories and a full run-through

• Write five or six STAR stories and map them to the five reported behavioral prompts plus the senior-engineer disagreement and vague-requirements prompts.
• Write the answer to why you want to work for Collins Aerospace, naming a product area and a link to your own work.
• Prepare three or four questions about the team's stack, development process and site facilities.
• Record yourself answering one question from each group (behavioral, core programming, resume, domain) and review the recording.

Deliverable: A story-by-prompt grid, a written why-Collins answer, a question list, and a recorded run-through.

Behavioral stories for Collins Aerospace

Candidates report that the behavioral stage carries real weight and covers teamwork, conflict, accountability and working through ambiguity. For an engineer in a safety-oriented domain, the strongest stories involve engineering work: a defect, an interface, a review, a schedule. Prepare five or six stories and map each to several prompts. Also prepare your reason for wanting to work for Collins Aerospace.

1. Why do you want to work for Collins Aerospace, and what interests you about its engineering domain?
2. Tell me about a time you disagreed with a senior engineer’s design choice. How did you navigate the conversation?

Tell me about a time you worked with a difficult teammate who was not pulling their weight, and how you resolv

Medium · Behavioral & STAR Scenarios

Tell me about a time you worked with a difficult teammate who was not pulling their weight, and how you resolved the situation.

Approach

1. Choose a story where the shortfall affected a deliverable others depended on, such as a module, interface or test set, so the stakes are visible. Describe the situation in a few sentences and put your time on the Action.
2. Show you diagnosed before you judged: you asked privately whether they were blocked, unclear on ownership, overloaded or missing a skill, and listened to the answer.
3. Describe the concrete fix: smaller deliverables with dates, a pairing session, clearer task ownership, or a regular check-in. Escalate to a lead only after that, framed around the work and its impact rather than the person.
4. Close with the outcome (the module shipped, review turnaround improved, the relationship afterwards) and one thing you would do earlier next time.
5. The mistake that sinks it is blame or contempt for the teammate, or the opposite: silently doing their work and never addressing it.

Follow-up

• What did you do when the first conversation changed nothing?
• At what point did you involve your lead, and what did you tell them?
• How would you handle it if the teammate were more senior than you?

Describe a challenging engineering project from school or work. What obstacle did you encounter and how did yo

Medium · Behavioral & STAR Scenarios

Describe a challenging engineering project from school or work. What obstacle did you encounter and how did you overcome it?

Approach

1. Pick a project where the obstacle was specific and technical, such as an intermittent race, an interface that did not match the hardware's behavior, a performance limit or a requirement that kept moving. A capstone or coursework project is acceptable if the problem was real.
2. Define the obstacle precisely enough that a listener could picture it, then lay out the options you considered and why you chose one over the others.
3. Say which parts you personally built, tested or decided, and which belonged to teammates. Keep the first person in the Action.
4. Give the result with evidence: the failing test that now passes, the latency or memory number, the integration that finally worked. State what you would change in the design if you started again.

Follow-up

• What alternative did you reject, and what would have made you pick it?
• How did you confirm that the fix held rather than hid the symptom?
• Which part of this project would you redesign today?

Give an example of a project where you failed or made a mistake. How did you handle it and what did you learn?

Medium · Behavioral & STAR Scenarios

Approach

1. Choose a real mistake where you were responsible, with consequences you can name (a defect that reached a test bench, a missed edge case, a bad estimate). A story with no cost reads as evasion.
2. Walk through the sequence: how you found out, what you did to contain it (told the team promptly, rolled back, added a workaround), and how you found the root cause rather than the nearest cause.
3. Describe the systemic change you made afterwards, such as a regression test, a checklist item, a stricter review step or a static-analysis rule, so the lesson is a changed practice and not a slogan.
4. State the result of that change, for example the same class of defect has not recurred. Keep the tone accountable: no blaming a teammate, a vague spec or the schedule.
5. Because this loop is safety-oriented, emphasize that you reported the problem early and prevented a repeat.

Follow-up

• How and when did you tell your team or manager?
• What check exists now that would have caught this earlier?
• Looking back, what warning sign did you miss at the time?

How do you prioritize tasks and maintain code quality when working under tight program deadlines?

Medium · Behavioral & STAR Scenarios

Approach

1. Answer with a method and then a story. Method: list the work, rank it by requirement impact and risk, confirm the ranking with the person who owns the schedule, and cut or defer scope rather than quality.
2. Name the quality practices you keep fixed under pressure: tests on every changed path, code review, static analysis, and updating documentation or requirement traceability.
3. Tell a specific case: what was at risk, what you deferred, how you negotiated it (what you offered instead, such as a reduced feature set or a phased delivery), and what shipped.
4. Show you track the debt you deferred, with a ticket, a date and an owner, so the shortcut is visible instead of hidden.
5. The failure mode is claiming you simply worked longer hours, or that you skipped tests to hit the date.

Follow-up

• What exactly did you cut, and who agreed to it?
• What would you do if your manager asked you to skip a review to hit the date?
• How did you make sure the deferred work actually got done?

Why do you want to work for Collins Aerospace, and what interests you about our specific engineering domain?

Medium · Behavioral & STAR Scenarios

Approach

1. Build the answer from facts you can verify: Collins Aerospace is a business unit of RTX building software for flight management, communications, flight control and cockpit displays on military and commercial aircraft. Name the area closest to your interests.
2. Tie it to your own experience with evidence, such as an embedded or real-time course, a project with sensors or hardware interfaces, a testing-heavy codebase, or a reason you prefer verification-driven engineering.
3. Show you understand what working here involves: software that must be tested against requirements, standards such as DO-178 and MISRA C, and collaboration with systems and hardware engineers. Say what appeals to you about that, not just that it is important.
4. Name the specific team or posting you applied to and what you would like to learn there, then end with what you can contribute.
5. Avoid reasons that fit any large employer, such as brand size, and avoid praising the company in general terms.

Follow-up

• Why aerospace and defense software instead of other embedded or enterprise work?
• What do you know about the team you would join, and what would you want to learn first?
• How do you feel about working under formal processes and documentation requirements?