Firmware hiring and firmware pay run on two different signals. Interview loops screen for debug breadth: can you trace a fault across an unfamiliar stack, from a symptom to a plausible cause? Compensation tracks something else, the register-level depth that decides whether a board comes up in a week or a quarter. This piece breaks down where the two signals diverge, what bring-up work actually demands, and what an engineer optimising for depth trades away.

The Hiring Signal Is Debug Breadth

Most firmware loops hand a candidate an unfamiliar codebase and a symptom. The code might be a bootloader, a driver, or a state machine on a microcontroller nobody on the team has touched. The interviewer watches how the candidate narrows the search: what gets instrumented first, which assumptions get tested, when they reach for a schematic instead of a print statement. Register knowledge rarely comes up.

That is deliberate. Teams hiring at volume cannot verify register fluency in a 45-minute call, and the specific peripherals differ per product. What transfers is method. A candidate who can bisect a fault across a hardware abstraction layer, a board support package, and an application has shown the thing that predicts ramp speed: they will find their way around whatever silicon the team actually ships.

Depth gets assumed rather than verified. The loop rewards people who can talk credibly about interrupts, DMA, and memory-mapped access without ever asking them to read a timing diagram cold. A related piece on this site, Distributed SQL Demands Different Interview Questions, makes a similar point about interviews that test the wrong layer of the stack.

The format itself pushes the screen toward breadth. A take-home that asks for a small feature on a mock HAL rewards clean structure and readable commits. A live pairing session on a broken driver rewards narration and hypothesis testing. Neither leaves room to watch someone sit with a reference manual for an hour, cross-check a timing table against a scope capture, and decide that the peripheral is fine and the clock divider is wrong. That activity is slow, silent, and almost impossible to grade in a group debrief, so loops quietly drop it and lean on the signals they can score.

Depth Gets Priced After the Offer

Compensation catches up later, and unevenly. Datasheet fluency commands a premium because the supply is thin. An engineer who can open a several-hundred-page reference manual, find the register that controls a clock tree, and reason about the errata without a colleague holding their hand is scarce, and hiring managers know it. The work that needs that skill, board bring-up, silicon validation, low-level driver work, is also the work that blocks everything downstream.

The catch is timing. Offers land on the breadth signal, because that is what the loop measured. Depth gets priced only once scope proves out, usually after the engineer has shipped a bring-up or rescued a driver nobody else could debug. Engineers who negotiate hard at the offer stage on depth claims they cannot yet demonstrate tend to lose that argument.

Debug breadth becomes table stakes as a career advances. Everyone senior can trace a fault. What separates bands is whether the engineer can also reason about the hardware the software is talking to, and that distinction shows up in leveling conversations more than in interviews.

There is a second-order effect worth naming. Teams that price depth late tend to lose the engineers who have it, because the market for that skill is small enough that a competitor will pay for it on day one rather than after a proving period. The retention cost lands on the same manager who saved a band by hiring on breadth, and it usually shows up as a sudden gap in the only person who could bring up the next board revision.

What Register-Level Work Actually Demands

Reading a timing diagram cold is the entry skill. A diagram tells you setup and hold requirements, clock phase relationships, and how long a peripheral needs before it will answer. Getting this wrong produces intermittent failures that no amount of application-level logging will explain, because the bug lives in the gap between what the software assumed and what the bus actually did.

Errata sheets become primary documentation. Vendor reference manuals describe the intended behaviour; errata describe what the silicon does. Experienced bring-up engineers read errata before they write a driver, and they treat every documented workaround as a constraint on the design. Skipping that step is how teams lose weeks to a peripheral that works on the eval board and fails on the custom PCB.

The logic analyzer replaces print statements. When a device hangs mid-transfer, printf tells you almost nothing, and a bus trace tells you which transaction never completed, what the clock looked like, and whether the target ever acknowledged. Memory-mapped access has no operating system safety net underneath it: a misconfigured register can wedge the whole system, so the debug loop is slower and the cost of a wrong guess is higher. Boot flow familiarity, whether that is UEFI or a simpler vendor bootloader, matters for the same reason.

Power sequencing is the part that surprises people arriving from application work. A board does not simply turn on; rails come up in a defined order, each with its own ramp and settle window, and a driver that starts talking before a rail is stable will fail in ways that look like a software bug for days. The same is true of clock configuration: a peripheral clocked from the wrong source or at the wrong divider will behave erratically rather than fail cleanly, and the register that sets it is often buried several layers down in a vendor header. Learning to trace a signal path from a pin through a mux, a divider, and a gate before touching a single line of code is a habit that pays back on every subsequent board.

The Trades Nobody Mentions at Onboarding

Bring-up cycles are slow. A single hardware iteration can take weeks to arrive, and every fix that needs a board respin resets the clock. Feedback loops that a web engineer measures in seconds get measured here in days. That cadence suits some temperaments and grinds down others, and it is rarely discussed in the interview.

Hardware access gates productivity in a way software rarely does. One shared lab rig, a queue for the only board with the right revision, a debug probe that lives in another building: these become the real constraint. Remote work is harder here, not easier, because the thing under debug is physical. Fewer peers can review a register-level patch meaningfully, so the review burden concentrates on one or two people.

Vendor NDAs limit what can be shown publicly. An engineer who has done excellent bring-up work often cannot put the schematic, the part number, or the errata workaround in a portfolio. That creates a real asymmetry: the deepest work is the least demonstrable, and hiring teams that demand public evidence filter out exactly the people they need.

Tooling cost is a quieter trade. A decent bench, a probe with protocol decoding, and a scope that can actually resolve the edges you care about add up quickly, and most engineers fund the first setup themselves before an employer does. That outlay buys learning speed, and it also anchors the engineer to a physical place where the gear lives.

Building Depth Without a Lab

Cheap development boards close most of the gap. A board with a documented reference manual and a public errata sheet lets an engineer practise the full loop: read the manual, configure the registers directly, watch the bus on a low-cost analyzer, and debug the failures that follow. The skill being built is the reading, not the specific part.

Open firmware projects accept patches, and they carry the review culture that makes the work legible. Contributing a driver fix or a boot-path cleanup gives a public artifact that survives an NDA. Simulators cover boot paths where hardware is unavailable, and they are good enough to learn the sequence of early initialisation. Reading datasheets end to end, rather than following tutorials, is the habit that separates the two approaches.

One concrete exercise is worth more than a shelf of tutorials: pick a peripheral with a small, well-documented register set, such as a UART or a basic timer, and write the driver from the reference manual without copying an existing one. Then break it deliberately, misconfigure a divider, skip a status check, and watch what the bus does. The failures teach the register map faster than the happy path does, and the debugging is the same work a bring-up engineer does on a new board.

Actions for the Next Review Cycle

Document one bring-up end to end, including the dead ends, and keep the sanitized version as evidence of scope. Ask explicitly for hardware access and a named lab owner, because access granted informally tends to evaporate under deadline pressure. Write up a debug case that shows the reasoning from symptom to root cause, stripped of anything the NDA covers.

Target errata handling in the next interview loop by asking how the team tracks silicon workarounds and who owns them. Negotiate scope before salary: a written commitment to bring-up ownership is worth more at the offer stage than a depth claim nobody has verified. Treat register-level work as the thing that sets the ceiling, and breadth as the thing that gets you in the room.