Aptiv Software Engineer Interview Guide

The 60-second brief

Aptiv builds vehicle software. Candidates describe Software Engineer work on autonomous driving, advanced safety systems and connected-vehicle architectures. The work depends on the team. On the embedded side it covers AUTOSAR stacks and real-time code in C/C++. Other teams work on GPU driver development or on cloud infrastructure that supports AI workloads, where the requirements candidates describe list Golang or Python. Matlab, Simulink and C++ are also named for feature development. The role is described as end to end: requirements analysis and design, implementation, testing and deployment. It also includes integration work with hardware engineers to get software running on target vehicle hardware, plus code reviews and architecture discussions. For preparation, this means one loop can draw on very different stacks, and you need to know which one your team uses before you start.

This guide is for Software Engineer candidates interviewing at Aptiv, on either the embedded track (C/C++, RTOS, AUTOSAR, vehicle networks, GPU drivers) or the cloud track (Python or Golang, data processing, AI infrastructure). It covers both reported stages and gives question-specific approaches and follow-ups for every reported question. It also covers the safety vocabulary (ISO 26262) that candidates call a differentiator, the mistakes that cost points on these question types, and a seven-day plan. Compensation and team-specific details are out of scope.

Candidates report two stages over about 2-4 weeks. A Technical Screening checks core competencies. It is followed by a series of Deep-Dive Interviews on hands-on experience, design philosophy and cultural alignment.

Focus areas

• AUTOSAR
• GPU Driver Development
• RTOS (Real-Time Operating Systems)

Overview

The reported questions fall into three groups. The first is automotive domain knowledge: communication inside an AUTOSAR architecture, memory and latency under an RTOS, GPU driver development for vehicles, and CAN versus Ethernet. The second is architecture: a fault-tolerant autonomous driving module, centralized versus distributed vehicle compute, AI workloads in a private cloud, and high-throughput Python or Golang processing. The third is behavioral: a legacy refactor, a technical disagreement, deadline pressure and learning a tool fast. The set covers both embedded and cloud work, so your first step is to find out which track the team is on and put most of your depth there.

On the embedded track, the reported topics are AUTOSAR, RTOS, GPU driver development and BCM. For embedded roles, candidate tips say the technical rounds go deep on C/C++, memory management and hardware-software integration. In practice, you should be able to trace one signal from a software component to the CAN controller and back, explain why heap allocation after startup is a risk in a real-time system, and describe priority inversion with its fix. You should also know the ISO 26262 terms (ASIL, safety goal, fault tolerant time interval, freedom from interference), because candidates report that familiarity with safety standards sets people apart.

On the cloud track, the reported areas are data pipelines for large vehicle datasets, containerization and orchestration in a private cloud, and performance tuning. Practise profiling before you optimize, Python's GIL and how to work around it, Go worker pools with backpressure, and GPU scheduling for training and inference jobs.

With only two stages reported, the screen carries the fundamentals and the deep-dives carry design and stories. Candidates advise that anything on your resume can be questioned down to how it works internally, and that you should explain why you chose one approach over another. So prepare each answer as a decision with its alternatives and a measured result, not as a list of features.

The Aptiv interview process

Candidates report the two stages below. Each one describes what candidates report and then how to prepare, for both the embedded and the cloud track.

Technical Screening

Candidates describe the Technical Screening as a first check of core competencies and technical rigor. Candidate tips say the technical rounds are specialized by domain. For embedded roles, that means depth on C/C++, memory management and the hardware-software interface. For cloud roles, the requirements candidates describe point to Golang or Python. Treat the screen as a fundamentals test in your own track. You should be able to explain memory ownership, concurrency primitives, interrupt handling and RTOS scheduling precisely without notes, or, on the cloud side, profiling and concurrency in Python and Go. Candidates also warn that any skill listed on a resume can be questioned down to its internals, so refresh or remove the ones you cannot explain.

What to demonstrate

• Core competencies in your stated domain, which candidates name as the purpose of the screen
• For embedded roles: C/C++, memory management and hardware-software integration, per candidate tips on the technical rounds
• Whether you can explain the mechanics behind skills you list, not only how to use them

How to prepare

• Write a fixed-size block pool allocator and a lock-free single-producer single-consumer ring buffer in C or C++. Explain volatile, memory barriers and why malloc is avoided after initialization.
• Rehearse the RTOS memory-and-latency question with a three-task priority-inversion example and the priority-inheritance fix.
• Cloud track: profile one Python script and one Go program, and practise a two-sentence explanation each of the GIL and goroutine scheduling.
• List every skill on your resume and write one internals question for each that you can answer cleanly.

Deep-Dive Interviews

Candidates describe the Deep-Dive Interviews as a series of conversations, run by engineers and leads, about hands-on experience, design philosophy and cultural alignment. The focus on design philosophy makes this stage the natural place to practise the architecture questions. The focus on experience and alignment covers the behavioral prompts. Prepare two projects you can defend at any depth: the constraints (timing, memory, safety level or data volume), the alternatives you rejected and the result you measured. In a design discussion, start from the hazard or requirement, then name the components, then explain how each failure is detected and handled. In a story, describe a decision you made yourself and the evidence that it worked.

What to demonstrate

• Hands-on experience: depth on systems you built yourself
• Design philosophy: how you reason through architecture choices and their trade-offs
• Cultural alignment, discussed through how you acted in past situations

How to prepare

• Write a one-page brief for each of two projects: the problem, the constraints, the rejected alternatives and the measured outcome.
• Whiteboard the fault-tolerant module and the centralized-versus-distributed questions. Start from hazards and the safe state, not from boxes.
• Learn the ISO 26262 vocabulary (ASIL, safety goal, FTTI, freedom from interference) so your design answers can use it accurately.
• Prepare STAR stories for the four reported behavioral prompts, each ending in a concrete result.

Where candidates lose points

Answering the AUTOSAR question by listing layer names (application, RTE, BSW, MCAL) without tracing a signal through them.

Practise one sender-receiver signal end to end, both directions: Rte_Write, Com_SendSignal, I-PDU packing, PduR, CanIf, CAN driver, and back up to a DataReceivedEvent and Rte_Read. Add one sentence on timeouts and one on E2E protection.

Giving desktop-style answers to the RTOS question: heap allocation at runtime, 'use a faster CPU', average latency instead of worst case.

Anchor the answer on static allocation and block pools, priority assignment with schedulability analysis, short ISRs that defer work to tasks, and priority inversion with priority inheritance. Say how you would measure the worst-case latency on the target hardware.

Designing the fault-tolerant module as 'add a second computer' with no detection mechanism, no safe state and no answer for common-cause failures.

Structure the answer as hazard and safe state, then detection (watchdogs, plausibility checks, sequence counters), then diverse redundancy, then a degradation ladder with a defined arbiter. Use the ISO 26262 terms correctly, including FTTI and freedom from interference.

Optimizing Python or Go throughput before profiling, or adding threads to CPU-bound pure-Python code.

Open with the profiler you would use and how you would classify the bottleneck. Then match the fix to the cause: vectorization or multiprocessing for CPU-bound Python, bounded worker pools and fewer allocations in Go, batching and columnar formats for I/O. Mention backpressure for slow sinks.

Behavioral stories with no measurable result, such as a refactor told as a rewrite with no before-and-after numbers or a disagreement where you were simply right.

For each of the four reported prompts, write the result line first: a number, a shipped milestone or a reversed decision. Then build the story backwards so the evidence and your own decision sit at its center.

Questions & practice

How do you manage memory and latency constraints in a real-time operating system (RTOS)?

Medium · Technical Domain Expertise

Approach

1. Memory: allocate everything at initialization. That means static task stacks, statically created queues and semaphores, and fixed-size block pools instead of a general heap after startup, because malloc has unbounded timing and fragments over long uptime. Size stacks from the worst-case call depth plus interrupt frames, then verify with high-water marks and a stack canary.
2. Scheduling: assign priorities by rate (rate-monotonic) or by deadline, and check schedulability with response-time analysis using measured worst-case execution times. The Liu-Layland bound n(2^(1/n) - 1), which approaches about 69 percent, is a sufficient test, not a necessary one.
3. Interrupts: keep ISRs short. Acknowledge the hardware, copy the data into a lock-free single-producer single-consumer ring buffer, and defer the processing to a task through a semaphore or task notification. Every critical section and every interrupt-disable window adds directly to worst-case latency, so keep them bounded and short.
4. Name priority inversion and its fixes: priority-inheritance mutexes or the priority-ceiling protocol. Do not use a binary semaphore as a mutex for a shared resource, and keep blocking calls out of high-priority tasks.
5. Measure the worst case, not the average. Use a GPIO toggle, a cycle counter or a trace tool to get interrupt-to-task latency and jitter, and place hot code and data in tightly coupled or cached memory where the hardware allows it.

Follow-up

• Walk through a priority-inversion scenario with three tasks and show exactly how priority inheritance resolves it.
• A task misses its deadline once every few hours. How do you find the cause?
• When would you accept dynamic allocation in an RTOS system, and how would you constrain it?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

• The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
• A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

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?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

1. Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
2. For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
3. Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
4. Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

• 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
• A dashboard runs this for 40 owners in one page load. What changes about the design?

Explain the communication flow within an AUTOSAR architecture.

Medium · Technical Domain Expertise

Approach

1. Start with the layers. Application software components (SW-Cs) communicate only through ports to the RTE. The RTE maps each port either to an intra-ECU buffer or into the Basic Software, where the services layer (COM, PDU Router) passes data down through interface and driver modules to the MCAL. Ports are defined against the Virtual Function Bus at design time, and the RTE is generated per ECU.
2. Trace one sender-receiver signal on transmit. The runnable calls Rte_Write. For a receiver on another ECU, the RTE calls Com_SendSignal. COM packs the signal into an I-PDU and applies its transmission mode (periodic, direct or mixed). PduR routes the PDU to CanIf, which passes it to the CAN driver and controller.
3. Then trace the receive path. The CAN driver (interrupt or polling) passes the frame to CanIf, which filters it and checks its length. PduR routes it to COM, which unpacks the signals, runs deadline monitoring and invalidation, and notifies the RTE. The RTE can raise a DataReceivedEvent that activates the consumer runnable, which reads with Rte_Read.
4. Cover the variations: client-server ports with synchronous or asynchronous server calls, last-is-best versus queued semantics, and signal groups for consistent multi-signal updates. Also cover E2E protection, which adds a CRC, a sequence counter and a data ID to detect corruption, repetition, loss and delay.
5. If the team works on newer platforms, add a sentence on Adaptive AUTOSAR. There, ara::com provides service-oriented communication, usually over SOME/IP, with service discovery in place of a statically configured signal layout.

Follow-up

• The sending ECU goes silent. What does the receiving component see, and how do timeout substitute values work?
• How does the RTE keep a multi-byte signal consistent when the runnable reading it is preempted by the task writing it?
• How would you route a CAN signal onto an Ethernet network through a gateway ECU?

Describe the challenges of developing drivers for GPU hardware in an automotive context.

Medium · Technical Domain Expertise

Approach

1. Split the driver into layers and say where each challenge sits. The kernel-mode driver handles memory management, command submission, interrupts, power and clocks. The user-mode driver translates a graphics or compute API (OpenGL ES, Vulkan, a compute API) into command buffers.
2. Memory: on an automotive SoC the GPU usually shares DRAM with the CPU. Cover IOMMU/SMMU mappings, DMA buffer sharing with the camera and display pipelines without copies, cache coherency (explicit flush and invalidate, or coherent mappings), and buffer lifetime when several engines touch one frame.
3. Mixed criticality: one GPU may serve a cluster display, infotainment and perception at the same time. Explain context priorities, the preemption granularity the hardware supports, and partitioning or GPU virtualization under a hypervisor, so that a low-criticality workload cannot starve or corrupt a safety-relevant one (freedom from interference in ISO 26262 terms).
4. Fault handling: detect a hang with a watchdog on command completion, reset per context so the safety-relevant output stays alive, report ECC and page faults, and keep logs that survive the reset.
5. Product constraints: fast boot to the first frame, thermal throttling in a sealed enclosure, long support lifetimes that pin kernel and driver versions, and validation on the target hardware rather than a desktop GPU.

Follow-up

• How would you recover from a GPU hang without blanking a safety-relevant display?
• How do you make sure a perception workload meets its frame deadline while infotainment rendering is queued on the same GPU?
• Corrupted pixels appear only under heavy load. How do you debug it?

What are the key differences between CAN and Ethernet protocols in vehicle communication?

Medium · Technical Domain Expertise

Approach

1. CAN is a multi-master serial bus with bitwise arbitration on the identifier. Dominant bits win, so the frame with the lowest ID takes the bus without the frame being destroyed, which means priority is encoded in the ID. Classic CAN carries up to 8 data bytes at up to 1 Mbit/s. CAN FD raises the payload to 64 bytes and switches to a faster bit rate in the data phase.
2. Robustness is built into CAN: CRC, an acknowledgement slot, bit stuffing, error frames, and fault confinement through transmit and receive error counters that move a node to error-passive and then bus-off. Latency is bounded for high-priority IDs, but low-priority frames can wait under load, so design for bus-load headroom.
3. Automotive Ethernet (100BASE-T1, 1000BASE-T1) runs point to point over a single twisted pair through switches. It is full duplex, has far more bandwidth, and allows payloads up to 1500 bytes. Determinism is not built in: it comes from VLAN priorities and TSN features such as gPTP time synchronization (802.1AS) and scheduled traffic (802.1Qbv).
4. Map each to its uses. CAN and CAN FD carry control signals in body, chassis and powertrain, where low cost and robustness matter. Ethernet carries camera and sensor streams, the backbone between domain or zone controllers, flashing and diagnostics over IP, and service-oriented middleware such as SOME/IP. Mention security too: CAN has no native authentication (SecOC adds message authentication codes), while Ethernet can use MACsec or IPsec.

Follow-up

• Two nodes start transmitting at the same instant. What happens, bit by bit?
• How would you guarantee bounded latency for a braking-related message on an Ethernet backbone?
• What does a gateway ECU have to do when it forwards CAN signals onto Ethernet?

How do you optimize Python or Golang code for high-throughput data processing in the cloud?

Medium · Technical Domain Expertise

Approach

1. Profile before changing code: cProfile or py-spy for Python, pprof and testing.B benchmarks for Go. Classify the bottleneck as CPU, I/O, allocation or serialization, and state the target as records per second plus tail latency.
2. Python: for CPU-bound pure-Python code the GIL prevents thread parallelism. Vectorize with NumPy, pandas or PyArrow, move hot loops into compiled code, or use multiprocessing with large chunks so the pickling cost is amortized. For I/O-bound work, use asyncio or a thread pool with bounded concurrency.
3. Go: a pool of goroutines fed by a bounded channel gives parallelism with backpressure. Cut allocations with preallocated slices, sync.Pool and no interface boxing in hot loops, check escape analysis output, and batch writes to the sink.
4. The data layout often matters more than the language. Stream instead of loading whole files, store vehicle logs in a columnar format such as Parquet, batch network calls, and compress when CPU is cheaper than bandwidth.
5. Cover the edge cases: a slow downstream sink, skewed partitions that leave one worker hot, duplicate or out-of-order records, and memory growth from unbounded queues.

Follow-up

• The pipeline is fast in tests but stalls in production when one sink slows down. What do you change?
• When would you rewrite a Python stage in Go, and what evidence would justify it?
• How do you process a file that is larger than available memory?

How would you design a fault-tolerant system for an autonomous driving module?

Medium · System Design and Architecture

Approach

1. Start from the hazard, not the boxes. Establish what the module controls, whether a safe state exists or the system must be fail-operational, the ASIL from hazard analysis, and the fault tolerant time interval within which a fault must be detected and handled.
2. Detection: heartbeat and watchdog supervision, timestamps and sequence counters on messages, cross-sensor plausibility checks (camera against radar or lidar), range and rate checks on outputs, and CPU and memory self-tests.
3. Redundancy with diversity: two compute channels in a doer/checker or 2-out-of-3 voting arrangement, diverse sensors and algorithms, and separate power and communication paths. The diversity is there so that one software bug or one shared power rail (a common-cause failure) cannot disable both channels.
4. Reaction: a graded degradation ladder (full function, then reduced speed or features, then a minimal risk maneuver such as a controlled stop) and a clearly defined arbiter that decides which channel drives the actuators.
5. Validation and trade-offs: FMEA and fault tree analysis on the design, fault injection testing, logging for post-incident analysis, and the cost, weight and power of each redundancy weighed against the availability it buys.

Follow-up

• The primary and backup channels disagree on the trajectory. Who wins, and why?
• How do you keep a bug in shared code from failing both channels at once?
• How would you test that the system reaches its safe state within the time budget?

Discuss the trade-offs between centralized and distributed computing architectures for vehicle functions.

Medium · System Design and Architecture

Approach

1. Define the two ends. A distributed architecture has many function-specific ECUs. A centralized one has a few high-performance computers, often with zone controllers that handle local I/O and power distribution.
2. Distributed strengths: physical isolation between functions, a small certification scope per ECU, short local control loops and independence between suppliers. Its costs: harness weight and complexity, duplicated hardware, many software versions to update over the air, and difficulty building features that span functions.
3. Centralized strengths: fewer ECUs, shared compute for sensor fusion, one place to update software, and easier feature evolution. Its costs: a single point of failure that needs redundancy, mixed-criticality software on one SoC (which needs hypervisor partitioning and freedom from interference), a higher thermal load, and a high-bandwidth backbone, usually Ethernet.
4. Give a placement rule and land on a hybrid. Hard real-time actuator loops such as braking and steering stay near the actuator or in redundant controllers, while perception, planning and infotainment move to central compute. Decide each function's placement by its latency budget, ASIL, bandwidth and how often it is updated.

Follow-up

• Where would you place the brake control loop in a zonal architecture, and why?
• What happens to the vehicle if the central computer reboots while driving?
• How does the choice change your over-the-air update and testing strategy?

How do you approach the integration of AI workloads into private cloud infrastructure?

Medium · System Design and Architecture

Approach

1. Characterize the workloads first: batch training (long-running, GPU-heavy, checkpointable), offline inference over logged vehicle data, and online serving with latency targets. Each needs different scheduling and storage.
2. Compute: package jobs in containers whose images pin the framework, CUDA and driver versions. Schedule GPUs through an orchestrator (for example Kubernetes with a GPU device plugin) using node pools, per-team quotas, priority classes and preemption, and checkpoint training so that preempted jobs resume instead of restarting.
3. Data: the bottleneck is often storage throughput rather than GPUs. Keep data close to compute, use sharded record or columnar formats, cache hot datasets on local NVMe, and track lineage so every model traces back to an exact data and code version.
4. Operations: monitor GPU utilization and memory, keep a model registry and reproducible pipelines, enforce access control and tenant isolation, plan capacity against demand, and have a rolling plan for driver upgrades that does not break running jobs.

Follow-up

• GPU utilization sits at 30 percent during training. Where do you look first?
• How do you share a small GPU pool fairly between research experiments and production retraining?
• How would you roll out a GPU driver upgrade across the cluster safely?

One customer endpoint stalls deliveries to every other destination

Medium · bulkhead · timeouts · saturation

The egress service delivers about 1.5k webhooks/second across 40,000 destinations, with a per-destination concurrency cap of 4 and a 10-second connect-plus-read timeout. Throughput falls to 300/second, queue depth climbs, and p99 delivery latency for unaffected destinations goes from 200 ms to minutes, while the error rate barely moves. One tenant holds 900 destination rows whose URLs share a hostname that now answers in 9.5 seconds. Explain the mechanism with the arithmetic, then give the containment in the order you would apply it.

Approach

1. Look at saturation before errors. A flat error rate with collapsing throughput says nothing is failing, things are waiting, so the first signal to pull is in-flight request count or pool wait time rather than the error counter. This is the distinction that decides the whole investigation.
2. Group in-flight work by resolved host, not by destination id. The cap is keyed per destination row, so 900 rows sharing one hostname buy 3,600 concurrent slots against a single host, each held for 9.5 seconds. The bulkhead was never a bulkhead for that host, and grouping by the wrong dimension is why the dashboard looked healthy.
3. Do the arithmetic in both directions. Required concurrency is arrival rate times latency, so 1.5k/second at 200 ms needs about 300 in flight, which is entirely consumed by 3,600 slow slots; conversely whatever concurrency is left sustains rate equals concurrency divided by 9.5 seconds, which is the 300/second you are seeing. Matching both numbers is what promotes this from a plausible story to the mechanism.
4. Explain why the circuit breaker never helped. It opens on consecutive failures, and a 9.5-second response inside a 10-second timeout is a success. Slow is not failing, so an error-rate breaker cannot see this; you need a slow-call ratio, a deadline propagated from the caller's remaining budget, or a concurrency limiter.

Follow-up

• The host recovers to 80 ms. How long does the queue take to drain, and what does the drain do to the recovered host?
• Where should the 10-second timeout number actually come from?

Suggested practice checklist

Each day covers one cluster of the reported questions, in an order that suits the two stages: fundamentals for the Technical Screening first, then design and stories for the Deep-Dive Interviews. Cloud-track candidates should swap days 1-3 to a lighter review and spend extra time on day 5.

Day 1 — C/C++ memory and RTOS fundamentals

• Write a fixed-size block pool allocator in C with O(1) allocate and free, and note why it replaces malloc after initialization.
• Write a lock-free single-producer single-consumer ring buffer for ISR-to-task handoff, and explain where volatile and memory barriers are needed.
• Answer the RTOS memory-and-latency question aloud, including a three-task priority-inversion walk-through and the priority-inheritance fix.

Deliverable: A working block pool, a ring buffer with a short note on memory ordering, and a recorded RTOS answer that covers allocation, scheduling, ISRs and priority inversion.

Day 2 — AUTOSAR communication and vehicle networks

• Draw the transmit and receive paths of one sender-receiver signal through RTE, COM, PduR, CanIf and the CAN driver, marking where timeouts and E2E checks apply.
• Build a comparison table of Classic CAN, CAN FD and automotive Ethernet: arbitration or switching, payload, bandwidth, determinism, error handling, security.
• Explain CAN arbitration bit by bit for two simultaneous transmitters, then explain how TSN gives Ethernet bounded latency.

Deliverable: An annotated AUTOSAR signal-path diagram, a one-page protocol comparison table and a spoken arbitration walk-through.

Day 3 — GPU drivers and the hardware-software interface

• Outline the kernel-mode and user-mode responsibilities of a GPU driver on a shared-memory automotive SoC, including IOMMU mapping and cache coherency.
• Write a hang-recovery sequence: detection by watchdog, per-context reset, keeping a safety-relevant display alive, and logging.
• Compare mutexes, spinlocks and interrupt disabling for driver code, and say when each one is correct.

Deliverable: A driver-layer outline, a step-by-step hang-recovery sequence and a three-row synchronization table, ready to talk through.

Day 4 — Safety and vehicle architecture design

• Learn the ISO 26262 terms: ASIL, safety goal, hazard analysis and risk assessment, FTTI, freedom from interference, ASIL decomposition.
• Whiteboard the fault-tolerant autonomous driving module: hazards, safe state, detection, diverse redundancy, arbiter, degradation ladder.
• Write a trade-off table for centralized and distributed vehicle compute, and place braking, perception and infotainment with a reason for each.

Deliverable: A glossary of the safety terms, one fault-tolerant design diagram and a placement table for three vehicle functions.

Day 5 — Cloud track: throughput and AI infrastructure

• Profile a CPU-heavy Python script, then speed it up with vectorization or multiprocessing. Write the same stage as a Go worker pool with a bounded channel and benchmark both.
• Outline a private-cloud GPU platform for training and inference: container image pinning, scheduling with quotas and preemption, checkpointing, data locality, monitoring.
• Solve the rolling failure-rate practice question and the practice debugging question about one endpoint stalling every other delivery. Note how each relates to backpressure.

Deliverable: Before-and-after benchmark numbers for the Python and Go stages, a one-page GPU platform outline and two worked practice solutions.

Day 6 — Behavioral stories and project deep-dives

• Write STAR outlines for the refactor, disagreement, deadline and fast-learning prompts, each with its result line written first.
• Write a one-page brief for each of two projects: constraints, rejected alternatives, measured outcome.
• Tell each story aloud and cut any part that describes the team's work rather than your own decision.

Deliverable: Four STAR outlines with measurable results and two project briefs you can defend in depth.

Day 7 — Mock both stages

• Run a mock Technical Screening: answer the RTOS and AUTOSAR questions cold, then field three internals questions about skills on your resume.
• Run a mock Deep-Dive: present one project brief, then design the fault-tolerant module from scratch and answer its follow-ups.
• Finish with the technical disagreement story and list the weakest answer of the day for a final review.

Deliverable: Notes from both mock sessions and a short list of the answers to tighten before the interview.

Behavioural preparation

Candidates report that the Deep-Dive Interviews cover hands-on experience and cultural alignment alongside design. The reported behavioral prompts are about refactoring legacy code, technical disagreement, deadline pressure and learning quickly. For this role, each story should show an engineering decision made under real constraints (timing, safety, schedule) and how you checked that it worked.

1. Tell me about a time you had to explain a software constraint to a hardware or systems engineer outside your specialty.
2. Describe a defect you found only during integration on target hardware, and how you tracked it down.

Describe a time you had to refactor a legacy codebase to improve performance or maintainability.

Medium · System Design and Architecture

Approach

1. Pick a refactor you led that had a measurable starting point: latency, memory, build time, defect rate, or a concrete maintainability cost such as how long a typical change took.
2. Show the safety net you built before changing anything: characterization tests that captured current behavior, profiling that located the real hot path and, for embedded code, timing checks on target hardware.
3. Describe an incremental path (interface seams, the strangler pattern, feature flags or a staged rollout) rather than a big-bang rewrite, and explain how features kept shipping while it was under way.
4. End with the before-and-after number, and say what you deliberately left alone and why. The story falls apart if there is no measurement or if the refactor was done for taste.

Follow-up

• How did you prove the behavior did not change?
• Which part of the legacy code did you leave untouched, and why?
• How did you get time for the work approved?

Tell me about a time you had to resolve a technical disagreement with a team member.

Medium · Behavioral and Leadership

Approach

1. Choose a disagreement over a real technical choice, such as an architecture, a protocol, a memory strategy or a test approach, where both positions were defensible.
2. Show that you stated the other engineer's position fairly, agreed on decision criteria (latency, safety, cost, schedule), and settled the question with evidence: a prototype, a benchmark, a specification reference or a third reviewer.
3. Give the outcome and the state of the working relationship afterwards. If you turned out to be wrong, say so and what you learned. A story in which the other person was simply wrong and you won does not work.

Follow-up

• What would you have done if the evidence had not settled it?
• How did you handle it if they still disagreed after the decision?
• What would you do differently next time?

How do you handle tight project deadlines while maintaining high code quality?

Medium · Behavioral and Leadership

Approach

1. Use a real deadline with a concrete driver, such as a vehicle integration date, a release train or a customer milestone, and say what was at risk.
2. Show how you prioritized: what you cut or deferred (scope, optional features), what you refused to cut (tests on safety-relevant paths, code review, static analysis), and how early you raised the trade-off with stakeholders.
3. Explain how you tracked the debt you took on and when it was paid back. Answers that rely only on overtime, or that claim nothing was compromised, come across as weak.

Follow-up

• What did you push back on, and with whom?
• Did any shortcut cause a problem later?
• How do you decide which tests cannot be skipped?

Describe a situation where you had to learn a new technology or tool quickly to solve a critical problem.

Medium · Behavioral and Leadership

Approach

1. Pick a case with a real forcing function: a tool, protocol or language you had not used before, needed to fix a specific defect or hit a milestone.
2. Describe how you learned it: primary sources (the specification or reference manual), a minimal reproducible prototype, targeted questions to someone who knew it, and how you checked your understanding before relying on it in production code.
3. State the result and what you left behind for the team, such as notes, a wiki page or a test harness. A story that amounts to reading documentation over a weekend, with no problem solved, does not show the skill.

Follow-up

• What did you get wrong at first?
• How did you know you understood it well enough to ship?
• How would you get a teammate up to speed on the same tool?