The Interview Loop That Works for Hardware-Software Mobility Teams

Most interview loops were designed for one discipline. A software team at a SaaS company built their process for software engineers. A traditional OEM built theirs for mechanical and systems engineers. Both frameworks assume the candidate lives mostly in one domain.

Mobility does not work that way. The roles that matter most at eVTOL companies, AV programs, and EV startups sit at the intersection. An embedded systems engineer at Joby Aviation is writing real-time flight control code and designing hardware interfaces. A powertrain integration engineer at an EV startup is running simulations in software and specifying components for physical manufacturing. An autonomy systems engineer is balancing sensor fusion algorithms with thermal constraints on the hardware stack.

When you run a software interview loop on these candidates, you surface software signal and miss the systems thinking and hardware constraints awareness that actually predict success. When you run a hardware interview loop, you miss the software depth. Most companies do one or the other. Very few have built the loop for the intersection.

Here is what I have built and seen work across 1,000+ hires in mobility.

Start With the Role Layer Map

Before you design any interview loop, map the role along three axes:

• What does this person decide alone? Algorithm parameters, software architecture choices, hardware specifications, material selection. The things they own and ship without a review cycle.
• What do they interface with daily? Are they handing specs to a vendor, consuming data from sensors, writing code that runs on physical hardware, or reviewing test data from a physical rig?
• Who do they need to align with across disciplines? A firmware engineer who has to work daily with mechanical and electrical teams needs different alignment skills than one who writes backend infrastructure alone.

This map tells you what the loop actually needs to test. If the role decides alone in software but interfaces heavily with hardware, your loop needs one strong software depth round and at least one cross-discipline scenario round. If the role makes hardware decisions but uses software tools as part of the process, you need hardware depth and a practical exercise that involves both.

Most hiring managers skip this step and inherit whatever loop the last engineering manager used. That is where the mismatches start.

Assign Interviewers to the Interface, Not Just the Discipline

The standard move is to staff the loop with domain experts: two software engineers for a software role, two hardware engineers for a hardware role. This works when the role is clean. At mobility companies, the role is rarely clean.

Instead, assign one interviewer per interface the role will actually touch. For a vehicle software role that ships code running on real hardware:

• One software systems interviewer testing architecture and code quality at the relevant layer (embedded, real-time, cloud, whatever applies)
• One hardware-adjacent interviewer who is not assessing hardware design, but testing whether the candidate understands hardware constraints and can reason about them
• One cross-functional interviewer: a test engineer, systems integrator, or program manager who can surface how the candidate operates at the seam between disciplines
• A hiring manager who covers systems-level thinking, role fit, and operating style

The cross-functional slot is the one most teams omit. It is also the one that predicts the most about how someone will actually perform at a company where hardware and software teams share launch milestones.

Define the Signal Before the Loop Runs

Every interviewer needs a written signal definition before the loop starts. Not a job description excerpt. An actual signal definition: what does strong look like in this round, what does weak look like, and what is the one question or scenario that best separates them.

Without this, the debrief becomes a collection of impressions with no common axis. Software engineers will advocate for the candidate who impressed them on software. Hardware engineers will advocate for the candidate who talked fluently about physical constraints. Nobody will have explicitly tested cross-discipline judgment, and the hire decision will be driven by whoever makes the most confident argument in the room.

For hardware-software intersection roles, two signal definitions I have found particularly useful:

Constraint reasoning: Can this person hold both software and hardware constraints in their head at the same time and reason about tradeoffs between them? Give them a scenario where a software solution has a hardware implication and ask them to walk through their thinking. Strong candidates surface the hardware constraint unprompted and articulate the tradeoff. Weak candidates either solve the software problem cleanly without noticing the hardware implication, or defer entirely to "the hardware team would handle that."

Interface ownership: When something breaks at the boundary between hardware and software, does this person lean in or defer? Ask about a specific incident from their history where a problem lived in the gap between their domain and an adjacent one. Strong candidates describe the steps they took to understand both sides and drive to resolution. Weak candidates describe escalating to someone else or waiting for the right team to own it.

The Debrief Structure That Works

Structured debriefs are standard advice. The version that works for hardware-software roles has one specific addition: a mandatory cross-discipline flag.

Before anyone gives a hire or no-hire signal, each interviewer must answer one question explicitly: "Based on your round, how did this candidate handle the intersection with the adjacent domain?" Not "were they good at software" or "were they good at hardware," but specifically: how did they navigate the boundary?

This does three things. It forces every interviewer to consider cross-discipline performance even if their round was single-discipline. It creates a structured data point the hiring manager can use to triangulate. And it surfaces cases where a candidate was excellent in their domain but showed no awareness of the constraints on the other side, which is a reliable predictor of friction in exactly the kinds of roles mobility companies are staffing.

Where These Roles Are Concentrating

The demand for engineers who work across hardware and software is not evenly distributed across the board. It concentrates at eVTOL companies and AV programs, where the product depends entirely on the integration working.

Joby Aviation currently has 242 open engineering roles. Archer Aviation has 155. These are not clean software or clean hardware shops: they are building certified aircraft, which means every software system has a physical consequence and every hardware design decision shows up in flight control code. Applied Intuition, with 140 open roles, builds simulation and validation software for autonomous vehicle development, which means their engineers need to understand physical sensor behavior and real-world edge cases to write useful tests. The intersection is the product.

Across all mobility verticals on my board, there are currently 2,195 open engineering roles. A significant share of them live in this intersection. The companies competing for candidates at this level are competing for a relatively small pool of people who have genuine experience on both sides. A well-designed loop that tests for the right signal will outperform a generic loop in close calls, which is almost every call at this level.

You can browse the current engineering roles across EV, AV, eVTOL, electric marine, and autonomous delivery companies here: larrysherwoodjr.com/jobs/?function=engineering.

The Three Most Common Failure Modes

Running the wrong loop entirely. A software-only loop for a role that ships code running on physical hardware. The candidate who passes will be excellent at software and have no intuition for hardware constraints. They will create friction from their first integration review.

Informal cross-discipline assessment. "We just kind of asked about hardware in the software round." This produces inconsistent signal. The interviewer asked because it occurred to them, not because they had a defined question or a clear view of what strong looked like. The data from these questions is nearly useless in a debrief.

Discipline siloing in the debrief. Separate software and hardware votes with no shared framework for the intersection. The debrief becomes two teams arguing past each other. The hire decision defaults to consensus or seniority, not signal.

All three are fixable with upfront design. The loop and the debrief structure need to be decided before sourcing starts, not after the first candidate is already in flight.