Senior Software Engineer
Arm — Software (CE-SW)

A sentence-by-sentence decode of the job description: what every line really means, and exactly how to answer it from Mohamed Nofal's background.

Location
Cambridge, UK · Hybrid
Salary band
£73,500 – £99,500
Requisition
careers.arm.com 95052486096 · iCIMS 2026-17352
Referral
Paul Toadere → iCIMS 17352

The honest framing of your fit

Your match is strong on the fundamentals this team lives on — low-level C/C++, model/simulation pre-silicon firmware, dump/trace/register debugging, test automation, specs→code, Arm SoCs. Your gap is the specific Arm reference boot-firmware stack (TF-A, SCP-firmware, UEFI/EDK2, U-Boot, FVP models, SystemReady/ACS) and public open-source upstreaming. You have NOT shipped these — don't claim you have.

Approach: (1) Show the transferable depth, (2) demonstrate you've studied the stack (see Arm crib + questions), (3) be explicitly curious and fast-learning.

CE-SW's own JD says: “if you are interested but unsure whether you tick all the boxes, we still would love you to reach out.” That line is aimed at exactly your profile.

Strength — answer from real experience Partial — transfer + study Gap — study, don't bluff
01

What CE-SW actually is

CE-SW = Client/Compute Engineering – Software: Arm's group that builds and upstreams the open-source platform-software stack partners use to bring up next-gen Arm application processors — often on IP not yet public.

What they own

Secure firmware: TF-A (BL1/BL2/BL31, PSCI, TBBR), Hafnium (S-EL2 SPM), OP-TEE, mbedTLS, RSS
System control: SCP-firmware / SCMI — clocks, power, interconnect, DDR, PCIe
Bootloader / firmware: U-Boot, EDK2 + edk2-platforms (UEFI/PI), GRUB
OS enablement: Linux kernel (DT or ACPI), Android (AVF, pKVM, Trusty), Buildroot
Standards / compliance: SystemReady (band/ES/DT/IR), BSA/SBSA ACS, FF-A, PSCI, SMC
Test: TF-A Tests, UEFI-SCT, FWTS, arm-enterprise-ACS

Three validation tiers

Pre-silicon models: Foundation FVP, Ecosystem FVPs, Fast Models
Dev boards: Juno, RD-N2 / RD-V2 (Neoverse), Total Compute reference designs
Shipping: Partner SoCs — phone, auto, IoT, server (same stack, partner porting)

Workflow

Read arch spec → implement/port in TF-A/SCP/EDK2/kernel → validate FVP → board → silicon → upstream via Gerrit (review.trustedfirmware.org, git review, Code-Owner/Maintainer/Verified +1, Jenkins CI) and mailing lists.

02

The job description, decoded

Filter:
Job Overview
PartialThe Software (CE-SW) group is responsible for developing and improving the software ecosystem around Arm's next generation architectures and systems.
MeansYou build the platform / reference software (firmware, bootloaders, kernel enablement) — not silicon or end apps. “Ecosystem” = what partners and the open-source community consume.
Your playPosition yourself as already at the HW/SW boundary delivering software others depend on (your firmware ships in MediaTek modems). Bridge: “I've worked one layer up; I'm keen to move into the boot/platform-firmware layer.”
StrengthThis means working with processors and other hardware technology not yet available to the public.
MeansPre-silicon work on unreleased IP under NDA; heavy reliance on models/simulation because the hardware doesn't exist yet.
Your playThis is your model/simulation-based firmware story — you genuinely develop & validate firmware on software models ahead of stable hardware and triage model-vs-hardware mismatches. Lead with it; rare, wanted skill.
StrengthYou will join a team of Software Engineers who share a passion for leaving their mark on the future of computing.
MeansCulture/motivation filter — genuine interest in low-level/architecture, not just a paycheck.
Your playHave a real “why low-level / why Arm” answer. Mention your VLSI / computer-architecture background — you understand the silicon side most app engineers don't.
StrengthWe are looking for highly capable engineers to work in the areas of Client/Server/Automotive/IoT, ready to use their knowledge and experience to ensure we continue to deliver software with the level of quality demanded by our customers.
MeansTeam spans market segments; “customers” = silicon partners who demand release-grade quality. Quality discipline (test, CI, review) is non-negotiable.
Your playYou ARE one of those customers today (MediaTek consumes Arm IP/software) — rare perspective. Stress your release-quality bar: unit tests, CI/CD, 100+ customer issues triaged, features owned end-to-end.
StrengthIf you are similarly passionate about innovative technologies, then we would love to hear from you!
MeansStandard close.
Your playJust confirms enthusiasm matters.
Responsibilities
PartialActive involvement in the software design and test of reference application processor firmware.
MeansYou design AND test firmware for reference platforms — boot/security/power flows, EL3 services, SCP↔AP handoff, DT/ACPI. Probe: draw the boot chain; “where would you add a new IP block?”
Your playMap your real work: you design & test production real-time firmware for Arm SoCs. Be honest it's modem/L1, not the BL1→BL33 chain — but the design-and-test discipline transfers 1:1. Pre-study the TF-A boot flow.
StrengthYour day to day role will involve low level software development, test and debug on various platforms, including software models, development boards and shipping products.
MeansThe literal three-tier workflow: model → dev board → shipping silicon. Fluent debugging across all three; aware of what only breaks on real silicon (timing, cache errata).
Your playDirect hit — you work across software models, simulation, dev boards and shipping products today. Have a story: a bug that reproduced on the model but masked a real silicon-timing issue (or vice-versa).
Gap to studyCreating software stacks for Arm's reference platforms for future Arm devices.
MeansIntegrate pinned TF-A/SCP/U-Boot/EDK2/kernel/Android into reproducible reference builds; enable new arch features (PAC/BTI, MTE, MPAM, RME).
Your playHonest gap on the specific stack integration. Lean on: building/owning firmware components end-to-end, cross-compilation for embedded Arm, reproducible builds. Show you've read the stack layers.
StrengthDevelopment of test code.
MeansWriting tests is a first-class deliverable (TF-A Tests, ACS, unit/integration).
Your playStrong — Google Test, test code as a deliverable, test automation. Give numbers.
StrengthCreate automation solutions to streamline and minimize manual testing and development tasks.
MeansBuild CI pipelines + Python/shell to launch FVP headless, run ACS, parse logs, nightly build matrices; gate Gerrit patches on smoke tests.
Your playStrong — your Python/shell automation + CI/CD + Google Test. Frame a pipeline you built (build matrix → run → parse → fail on PANIC/regression).
StrengthWe want you to be able to analyse industry specs, roadmap requirements, breakdown tasks and help implement the project plans.
MeansRead DEN/DDI specs (PSCI, FF-A, SCMI, BSA), turn requirements into epics/stories, estimate, plan. Senior-level autonomy.
Your playStrong — you translate 3GPP TS 38.214/38.213 PHY specs into release-quality C and break down features. Specs are specs — demonstrate the muscle; you'd ramp on Arm's DEN corpus the same way.
Gap to studyYour activities will involve upstreaming and maintenance.
MeansPublic open-source contribution via Gerrit/mailing lists — small logical series, addressing maintainer review, LTS backports, fixing CI breakages. Long-tail ownership of platform ports.
Your playLikely your biggest gap — MediaTek work is internal. Be candid. Mitigate: you use Gerrit-style review internally; you know patch hygiene (Signed-off-by, Change-Id, small series). HIGH LEVERAGE: land one real upstream patch before the interview.
Required Skills & Experience
StrengthExcellent C/C++ programming skills with the ability to add significant new functionality, analyse and fix complex defects. Some knowledge of assembly and strong debugging skills are preferred.
MeansCore gate. Bare-metal C (no STL, explicit MMIO, linker scripts, boot asm), reading AArch64 asm, deep debugging.
Your playCore strength — 4+ yrs production real-time C, complex HW/SW defect root-cause. Have a “complex defect” war story with the actual debug sequence. Brush up AArch64 asm + what volatile does/doesn't guarantee for MMIO.
StrengthDemonstrated experience with software testing or software development.
MeansLow bar / inclusive — either side counts.
Your playYou have both. Trivially satisfied.
PartialExpertise in application and low-level systems, with a strong understanding of system architecture (preferably ARM), OS fundamentals, bootloaders, and device drivers.
MeansWhole-stack literacy — system arch (Arm preferred), OS internals, bootloaders, drivers.
Your playStrong on system arch (Arm SoCs, AArch64, VLSI background), OS fundamentals, drivers/HAL. Bootloaders = study area — narrate ROM→BL1→BL2→BL31→BL33→OS even if you haven't shipped it. Don't bluff depth.
PartialProficiency in Linux/Windows operating systems and driver development is preferred.
MeansLinux primary; Windows-on-Arm via UEFI+ACPI. “Preferred” = not a hard gate.
Your playLinux/Android kernel + driver-level firmware = real. Windows = honestly minimal; don't oversell. Pivot to driver bring-up (PCIe/IRQ/DMA, probe() failures).
StrengthGood understanding of test methodologies, CI and test automation.
MeansRepeat emphasis — they care a LOT about test/CI.
Your playStrong. Reinforce with the automation pipeline story.
StrengthStrong interpersonal skills; excellent written and spoken English.
MeansUpstream + cross-team work needs clear communication; written English matters for mailing-list/review culture.
Your playCross-team firmware/RF/driver collaboration; mentoring; clear review comments. Use the HW-arbitration proposal as your “influenced a decision across teams” story.
Nice To Have
StrengthExperience with Python programming and writing shell scripts.
MeansAutomation glue.
Your playDirect hit. Mention freely.
StrengthBasic understanding of the Linux kernel, system software and device drivers, and Android internals.
MeansKernel/driver/Android literacy.
Your playReal strength — your agentic-AI crash tool correlates dumps against the full Android (Linux) kernel source tree. Concrete story.
Gap to studyFamiliarity with open-source project development cycles and contribution processes.
MeansGerrit / mailing-list / patch-series culture.
Your playGap — study Gerrit / Signed-off-by / Change-Id; a small real patch would convert this.
StrengthExperience of software profiling, instrumentation, and optimization.
MeansPerf/power tuning.
Your playReal — you profile/optimise real-time firmware on constrained targets. Bottleneck→optimisation story.
StrengthVerification and validation of firmware on both pre-silicon platforms.
MeansModel/Fast-Model validation before tape-out.
Your playReal — model/simulation pre-silicon validation. Strong, and rare.
StrengthA knowledge of how to test software using various techniques alongside an awareness of the value of CI and automated test systems.
MeansRestated test/CI value.
Your playReal — restate test/CI.
Gap to studyExperience with Security Development Lifecycle (SDL) practices.
MeansChain-of-trust / measured boot / anti-rollback.
Your playGap — study TBBR / measured boot conceptually; don't claim hands-on.
StrengthFamiliarity and flexibility in the use of various software development lifecycle methods including Agile.
MeansAgile/sprints.
Your playReal. Trivial.
03

Arm crib sheet — self-check

If you can't say each of these unprompted, revise it. These are the topics the interview will reach for.

Boot flow BL1/BL2/BL31/BL33
BL1 (ROM) minimal init → BL2 loads/verifies FIP + platform setup → BL31 EL3-resident (PSCI, SMC runtime) → BL33 non-trusted bootloader (UEFI/U-Boot) → OS. BL32 = optional secure payload (OP-TEE).
Exception levels EL0–EL3
EL0 user · EL1 OS kernel · EL2 hypervisor · EL3 secure monitor (TF-A). Higher EL traps lower; firmware lives at EL3/secure.
TrustZone / secure world
NS bit tags memory/peripherals; EL3 monitor arbitrates SMC between secure/non-secure; secure memory enforced via TZASC/SAU.
PSCI
Standard power/CPU API over SMC: CPU_ON/OFF/SUSPEND, SYSTEM_SUSPEND, affinity. Implemented in BL31.
SMC calling convention
AArch64: x0 = function ID, x1–x3 args, return in x0–x3; smc #0 from EL1/EL2.
Memory barriers
DMB orders memory accesses · DSB waits for completion before next instr · ISB flushes pipeline after context-changing ops (MMU/vector/sysreg writes).
MMU / page tables
4KB granule, ~4 levels; TTBR0/1; MAIR (device vs normal mem); TCR (sizes); enable via SCTLR.M; invalidate TLB after changes.
Cache coherency
PoC/PoU; clean/invalidate around DMA and before releasing secondary CPUs; HW coherency via ACE/CHI. volatile ≠ ordering.
GIC (v3)
Distributor + per-core redistributor; SPI/PPI/SGI/LPI; ICC_* sysregs; firmware configures, kernel owns runtime.
Device Tree vs ACPI
DT (mobile): compatible/reg/interrupts, firmware fixes up memory/chosen. ACPI (server/UEFI): MADT/GTDT/MCFG/IORT installed by EDK2; required for SystemReady band.
SCP-firmware / SCMI
Separate system-control processor brings up clocks/power/DDR before AP boots; talks to AP via SCMI.
SDL / chain of trust
TBBR: each stage verifies the next (hash + ROTPK), anti-rollback counters, measured boot.
SystemReady / BSA / SBSA
Compliance tiers; ACS (Architecture Compliance Suite) certifies a platform boots standard OSes.
04

Likely questions — tap to reveal

Green = answer from real experience (your home turf). Amber = answer from study; at your knowledge edge, say so and reason from fundamentals — they probe to the edge, bluffing is fatal.

Boot & TF-A
study
Narrate the AArch64 cold-boot path from reset to Linux.
tap to reveal what they're checking
study
What is in a FIP image?
tap to reveal what they're checking
study
BL31 vs BL2 — what runs where, what persists after boot?
tap to reveal what they're checking
study
How does TF-A load and authenticate the next stage (TBBR)?
tap to reveal what they're checking
study
SCP firmware's role before the AP boots?
tap to reveal what they're checking
Arm architecture
study
Explain EL0–EL3 and which firmware runs at each.
tap to reveal what they're checking
study
Secure vs non-secure world — how does the CPU enforce it?
tap to reveal what they're checking
study
What is an SMC? Give a PSCI CPU_ON example.
tap to reveal what they're checking
experience
When do you need DMB vs DSB vs ISB?
tap to reveal what they're checking
study
How do you bring up the MMU in firmware?
tap to reveal what they're checking
Drivers & platform
study
Device Tree vs ACPI — when does CE-SW use each?
tap to reveal what they're checking
experience
How does Linux receive a device interrupt on GICv3?
tap to reveal what they're checking
experience
Linux hangs after “Starting kernel…” — debug it.
tap to reveal what they're checking
study
What is FF-A and how does it relate to OP-TEE / Hafnium?
tap to reveal what they're checking
Low-level C & debug
experience
Find a stack-corruption bug in bare-metal code — approach?
tap to reveal what they're checking
experience
What does volatile guarantee (and NOT) for MMIO?
tap to reveal what they're checking
experience
Explain cache coherency during secondary-CPU bring-up.
tap to reveal what they're checking
Test & CI
experience
How would you test PSCI SYSTEM_SUSPEND?
tap to reveal what they're checking
study
What is SystemReady band / BSA / SBSA?
tap to reveal what they're checking
study
Design a CI job for a TF-A platform port.
tap to reveal what they're checking
05

Reading list

Prioritised for this role, not a generic pile. Tap a book to mark it read (saved on this device). ★ = read these three first if time is short. green sharpens a strength, red closes a gap.

0 of 12 read · 0%

Tier 1 — read these first (close your gaps, highest ROI)

These map 1:1 to the Arm crib sheet and are exactly what interviewers quote.

closes gap
★ Learn the Architecture + the Arm ARM (ARMv8-A)free
Arm Developer — free online guides
Work through the AArch64 exception model, memory management, memory ordering (barriers), GIC and TrustZone guides, then skim the Arm Architecture Reference Manual. Nothing in print is as current. Biggest gap, fastest to close.
open resource ↗
closes gap
Bare-Metal Embedded C Programming
(+ build a QEMU AArch64 boot project)
Bring the linker-script / startup-asm / MMIO model to the front. Best single hands-on: a bare-metal AArch64 program that boots on QEMU virt, enables the MMU, prints over UART — answers half the boot questions.
strength
★ Operating Systems: Three Easy Piecesfree
Remzi & Andrea Arpaci-Dusseau
Cleanest refresher for the 'OS fundamentals' they explicitly ask for — virtual memory, scheduling, concurrency. Short and free; read the VM + concurrency parts.
open resource ↗
Tier 2 — Linux kernel & drivers (own the Android-kernel angle)

Turns your crash-dump-over-the-Android-kernel-tree story into deep, confident answers.

strength
★ Linux Kernel Development
Robert Love
The single best conceptual kernel book — read cover to cover. Directly sharpens your real strength.
both
Linux Device Drivers (LDD3) + Linux Kernel Programming (2nd ed)free
Corbet/Rubini/Kroah-Hartman · Kaiwan Billimoria
LDD3 (free) is best for the driver model (probe, IRQ, DMA); Billimoria is the modern companion on current kernels. Together they cover 'device drivers' properly.
open resource ↗
both
Mastering Embedded Linux Programming (3rd ed)
Frank Vasquez & Chris Simmonds
Bootloader → kernel → rootfs → device tree bring-up flow. Hits 'bootloaders, device drivers, embedded Linux' head-on.
Tier 3 — C/C++ depth & debugging (polish the core strength)

They say C/C++ and value strong debugging — close the C++ side and sharpen GDB.

closes gap
Effective Modern C++
Scott Meyers
Your CV leans C; the JD says C++. Close that gap so a C++ defect question doesn't surprise you.
strength
Expert C Programming: Deep C Secrets
Peter van der Linden
The low-level C subtleties (declarations, memory, undefined behaviour) that show up in 'fix this complex defect'.
strength
Debugging with GDB (manual) / The Art of Debuggingfree
GNU · Matloff & Salzman
They value 'strong debugging skills'. Know GDB on QEMU/JTAG cold.
open resource ↗
Tier 4 — testing/CI & the coding round

A role-specific differentiator plus the screen prep.

strength
Test-Driven Development for Embedded C
James W. Grenning
Perfectly on-target for 'test code, test methodologies, CI'. Most candidates won't have read it — a differentiator.
both
Cracking the Coding Interview / LeetCode patterns
Gayle Laakmann McDowell
Arm's screen includes ~LeetCode-medium C/C++. ~30 problems on arrays/strings/bit-manipulation/linked-lists in C is enough.
Not a book — but it beats them for upstreaming

Where the 'upstreaming and maintenance' gap actually closes.

closes gap
TF-A docs + real Gerrit reviews + kernel 'Submitting Patches'free
trustedfirmware.org · kernel.org
Read the TF-A documentation, browse a few real reviews at review.trustedfirmware.org, and the kernel 'Submitting Patches' doc. Landing one small real patch would beat any reading here.
open resource ↗
06

Your pitch

Strongest talking points (all true)

  • Model/simulation-based pre-silicon firmware development & validation — rare and directly wanted.
  • Production real-time C across model → dev board → shipping silicon.
  • Complex HW/SW defect root-cause via core dumps, traces, register state, KPI triage.
  • Specs→code (3GPP PHY) — the spec-analysis muscle they ask for.
  • Test automation + CI/CD + Google Test — they emphasise it three times.
  • Agentic-AI crash-dump tool over the full Android (Linux) kernel tree — 2000+ engineers, ~2h→minutes.
  • HW/SW co-design judgement: the channel-arbitration weakness you found + proposal to move arbitration into dedicated hardware.
  • “Customer of Arm” perspective + VLSI / computer-architecture background.

The one war story

Bring ONE war story in STAR form: the channel-arbitration finding → your proposal to offload it to hardware. It shows deep system understanding, initiative, cross-team influence, and the exact “analyse specs/architecture, break down, propose” senior behaviour the JD asks for.

“Why this team”

CE-SW is the choke point between new Arm IP and the whole ecosystem — your patch in Cambridge ships on every partner SoC. You've been on the consuming side at MediaTek; you want to move to the source.

07

Pre-interview checklist

0 of 7 done · 0% — saved on this device.