🧭The Hiring-Manager Interview (CV deep-dive)

Sure — the common thread in my CV is low-level C at the hardware/software boundary. I started with a hardware-heavy base: VLSI, FPGA training, and an MSc focused on communications and wireless networking. Commercially I've spent four years at MediaTek in Cambourne, first as an intern, now as a Wireless Software Engineer.

My current work is production embedded C for TX DSP firmware on RTOS-based modem SoCs: I take 3GPP PHY behaviour like TS 38.214 and 38.213, turn it into firmware, add Google Test coverage, support CI and releases, and debug across L1 firmware, RF, power amplifier, calibration and test. The examples I'd point to are UL-DAI, the missing DL DCI reporting feature, and an MCU-DSP interaction bug from my internship.

The reason this AMD role makes sense is that it's an adjacent move, not a reset: careful C on a constrained datapath, hardware-visible state, timing and ownership, and debugging from software down to hardware. I'll be upfront that I haven't shipped a Linux NIC driver and my protocol depth is wireless rather than Ethernet internals — I'm closing that deliberately, and I'm happy to go deep on it.

UL-DAI is one of the strongest examples on my CV because I owned it as a real production feature area rather than only fixing isolated bugs.

At a high level, UL-DAI is the Downlink Assignment Index carried in the uplink grant — it tells the UE how many downlink assignments it must acknowledge, so the device builds the right HARQ-ACK codebook to report back. So it's really about acknowledgement-codebook construction, not uplink scheduling. My work was to take the relevant 3GPP PHY requirements, reason through the edge cases, design the firmware behaviour, implement it in embedded C on the TX DSP side, add Google Test coverage, integrate through CI/CD and support release/debug activity.

The important part is that it was not just translating a paragraph from a spec into an if statement. I had to understand what state the firmware already had, what timing assumptions existed, how the arbitration logic interacted with other TX behaviour, and how to make the result deterministic enough for a constrained RTOS path. I also had to make the design reviewable by senior engineers and supportable when issues came back from integration or customer testing.

The bridge to a NIC role is feature ownership in a fast path. A NIC datapath feature might be a queue-management change, a TX/RX descriptor behaviour, a congestion-related feature, an offload path or diagnostic path. The pattern is the same: understand the external specification or architecture intent, map it to existing state machines, implement in C without violating timing constraints, test the edge cases, and support it when real hardware and real workloads expose assumptions.

My day-to-day work is production embedded C in TX DSP modules for RTOS-based MediaTek modem SoCs. That means the code is close to the hardware-facing path, has timing constraints, and cannot be treated like ordinary application code.

Typical work includes implementing PHY behaviour, maintaining arbitration logic, reviewing constrained execution paths, debugging firmware traces and core dumps, and making changes that have to survive integration with L1 TX/RX firmware, RF, calibration and test environments. I also write unit tests with Google Test where the logic can be isolated, and I use CI/CD results and simulation/test traces to avoid turning one fix into a regression.

The constraints are the important part. I have to care about things like bounded execution time, data ownership, fixed data structures, limited observability, and how a small C-level change affects timing in a real-time pipeline. I am used to asking: is this path called under a deadline, can this branch explode in a rare state, do we have enough traceability, and what happens when the hardware-facing state is not what the spec example assumed?

For AMD, I would expect the objects to change from TX DSP state and 3GPP scheduling structures to TX/RX rings, descriptors, DMA mappings, queues and driver/firmware interfaces. But the discipline transfers directly: write C that is predictable, measurable and correct under hardware timing pressure.

Arbitration in my context is deciding, under a hard deadline, which work the TX path does when several things contend for the same limited resource — processing budget, a shared structure, or a transmit opportunity. The constrained-execution-path part means the decision itself has to be cheap and bounded: it runs inside a real-time window, so I can't have a branch that occasionally does a lot more work, and I can't allocate or block. The logic has to be deterministic in the worst case, not just the average case.

What I learned doing this is that the hard part isn't the policy, it's the worst case. Average behaviour is easy; what bites you is the rare combination of state where the arbitration does more work than the budget allows, or where two consumers disagree about who owns a structure at the instant the decision is made. So I design for the tail: bound the loop, pre-validate inputs, and make the ownership of shared state explicit so there's no race at the boundary.

The NIC parallel is almost one-to-one. A NIC transmit scheduler arbitrates across queues — round-robin, strict priority, weighted, or something fancier for QoS or congestion response — and it has the same constraints: the decision is on the fast path, it has to be bounded, and it touches descriptor rings and doorbells where ownership and ordering between host, driver and device matter. Whether it's choosing which TX queue gets the next slot or how you respond to backpressure, it's the same engineering: a cheap, deterministic decision over contended state where the worst case and the ownership are what you actually have to get right.

I treat the spec as the starting point, not the implementation. My process is roughly: understand the requirement, identify the state the firmware needs, map the decision tree, write down edge cases, review assumptions, then implement and test.

With TS 38.214 and TS 38.213, the first challenge is that the spec describes behaviour in protocol terms, while firmware has existing state machines, timing boundaries and data structures. I usually start by translating the relevant clauses into concrete inputs and outputs: what configuration matters, what values are legal, what happens when information is missing, and which cases need default or error behaviour.

Then I look at integration constraints. Does the TX DSP path already have the data at the point where the decision is needed? Is the decision inside a constrained execution path? Is this state shared with another module? Are there race-like timing assumptions between MCU and DSP or between TX and RX sides?

Only after that do I write the C. I keep the implementation reviewable, add Google Test coverage around decision logic where possible, integrate with CI/CD, and use traces/simulations when behaviour depends on system state. For release quality, the key is not only passing the normal case; it is proving the rare combinations are handled and that the implementation fits the existing real-time architecture.

For a NIC team, I would use the same approach for Ethernet, UEC, offload or driver-visible hardware behaviour: translate the spec or architecture into a testable state machine, implement it in the right layer, and verify both correctness and timing.

That internship bug is a good hardware/software-seam story because the failure was not just one wrong line of C. It was an interaction problem between the Main Control Unit and the Digital Signal Processing side.

The issue showed up as a firmware interaction failure where the MCU and DSP did not agree cleanly on state at the boundary. My task was to help isolate whether the problem was control sequencing, data visibility, timing, or the interpretation of the interface contract.

The way I approached it was to reduce the failure to the smallest reproducible path, compare the expected MCU-DSP state transition against traces and logs, and reason about ownership: who writes the state, who consumes it, and when the value is guaranteed to be valid. The fix strengthened the MCU-DSP interface reliability by making the interaction sequence match the actual timing and state assumptions rather than the idealized version.

The NIC analogy is very direct. A Linux driver and a NIC, or host driver and firmware, can have exactly the same class of bug: descriptor ownership, doorbell ordering, completion visibility, reset sequencing or a register update that is correct in isolation but wrong relative to the device state machine. My instinct from that bug is to make the boundary observable, define ownership explicitly, and prove the ordering rather than assuming it.

The important point is that in modem firmware, a failure often surfaces in one place but originates somewhere else. A TX KPI regression, missing report, bad calibration interaction or unexpected RF behaviour can look like a TX DSP bug, an RX-side timing issue, a power amplifier problem, a calibration setup issue or even a test-environment artifact.

My approach is to avoid choosing a favourite culprit too early. I start from the symptom and build a chain of evidence: what changed, which KPI moved, which logs or traces confirm the timing, what the firmware believed the state was, what the RF or calibration side expected, and whether the test setup can reproduce it cleanly. I use core dumps, traces, simulations and KPI analysis to narrow the fault domain.

A typical pattern is to isolate whether the software made a wrong decision, made the right decision with wrong inputs, or made the right decision but the downstream hardware-facing module did not behave as expected. That distinction matters because the fix could be C logic, timing, configuration, calibration guidance or a test correction.

For AMD, I would expect the equivalent to be debugging packet drops, latency spikes, link issues, DMA errors or performance regressions across host driver, firmware, NIC hardware, PCIe, cables/switches and test tools. The skill is not knowing every domain on day one; it is being systematic enough to localize the issue across domains without guessing.

Triaging 100+ issues taught me that good engineering is partly technical depth and partly disciplined communication.

On the technical side, I learned to separate symptoms from causes. A customer or internal team might report a KPI regression, a missing report, a firmware crash, or an integration failure, but the first description is rarely the full root cause. I had to collect enough evidence, understand the configuration, compare against expected PHY behaviour, inspect traces or dumps, and decide whether it was a real product bug, misuse, a test issue, a known limitation, or an unclear requirement.

On the communication side, I learned to keep people unblocked while the technical work continues. That means giving integration guidance, explaining design-review decisions, saying clearly what evidence is missing, and escalating to senior engineers or system teams when the issue crosses ownership boundaries.

The NIC-team relevance is strong. In a networking product, issues from customers or internal validation can be noisy: packet loss, performance below expectation, link instability, latency outliers, driver crashes or interoperability problems. The engineer who is useful is the one who can turn a vague report into a reproducible failure, identify the likely layer, communicate next steps and then either fix it or route it accurately.

Those tools were built because I saw repeated friction in the team: manual steps, hard-to-maintain scripts, slow access to debugging information or repetitive developer workflows. I used Python and Flask where a lightweight backend made sense, Electron and React.js for desktop-style interfaces, C# where it fit the existing environment, and LLM-assisted workflows to improve developer productivity.

The important thing is that these were actively used internal tools, not side projects disconnected from the firmware work. I was careful to make them maintainable enough that the team could trust them: clear inputs, useful output, and workflows that fit how engineers already debugged and released code.

For this AMD role, I would not lead with the tooling as a substitute for low-level C. The low-level firmware work is the main fit. But the tooling experience is a useful multiplier. In a NIC team, better internal tools around trace analysis, counter comparison, regression triage, log summarization, test automation or lab workflows can save a lot of engineering time.

On the LLM side, I would be pragmatic. I would not use it to invent technical truth or touch confidential code carelessly. I would use it where it is good: summarizing logs, generating boilerplate tests under review, searching internal knowledge, or helping make repetitive analysis workflows faster while keeping human review on the engineering decision.

During my MediaTek internship I contributed to a 5G non-terrestrial-network proof of concept for connecting phones to satellites in coverage-limited environments. The value for my CV is not that it maps one-to-one to Ethernet, but that it exposed me to protocol-domain engineering where real physical constraints change the software assumptions.

In NTN, the channel is different from terrestrial cellular: longer propagation delay, different mobility assumptions, link-budget constraints and more unusual timing conditions. Even at PoC level, it forced me to think about how standards-driven behaviour meets real-world physical constraints.

That experience reinforces the same pattern I now want to bring to networking. In AI-cluster Ethernet, the physical and system constraints are different, but they are still real: cable/link behaviour, congestion, tail latency, packet loss, retransmission, queueing and recovery all affect the software-visible system.

So I would present the NTN PoC as evidence that I am comfortable stepping into a new but adjacent communications domain, learning the constraints quickly, and connecting protocol behaviour to the underlying physical/system reality.

My MSc thesis was Nonlinearity Compensation Using an Add-On Module Based on Quantized Kernel Least Mean Square Algorithm for Massive MIMO Systems. In plain terms, it was about compensating nonlinear distortion in a Massive MIMO communications setting using an adaptive algorithm, while keeping the approach practical through quantization.

The direct domain is wireless signal processing, not NIC drivers. I would not pretend otherwise. The relevance is in the engineering habits: modelling a communications impairment, understanding algorithmic tradeoffs, thinking about computational cost, and connecting a mathematical method to a system constraint.

That background helps me read complex technical material without being intimidated. It also gives me a good foundation in communication systems, digital communications and information theory from the MSc, which is useful when moving into Ethernet and data-centre networking. The protocols and layers change, but the questions around throughput, latency, error behaviour and efficient signal/data movement remain familiar.

For this AMD role, the thesis is not my main selling point. My production MediaTek C firmware experience is. But the thesis supports the bigger picture: I have a communications-systems foundation underneath the commercial embedded work, and I am comfortable with technical depth when the system demands it.

It helps because I do not treat hardware as a black box. My BSc was in Nanotechnology and Nanoelectronics Engineering with a VLSI design major, and I also did FPGA design and verification training using Mentor Graphics tools. I am not applying for a silicon-design role, but that background makes hardware-facing software more natural to me.

When I write or debug low-level C, I am already thinking about state machines, timing, register interfaces, data movement, verification and what assumptions the hardware might be making. In my MediaTek work, that mattered when debugging L1 firmware interactions, RF modules, calibration paths, power amplifier behaviour and MCU-DSP boundaries.

In a NIC team, I think that same hardware-aware mindset is useful. Driver code is not only a Linux API exercise. It is also a contract with a device: descriptors, MMIO, DMA, queues, interrupts, reset sequences, firmware interfaces and observability. A software engineer who understands that the device has its own timing and state machine is less likely to write code that is locally clean but systemically wrong.

So I would frame the VLSI/FPGA background as a base layer. It does not replace NIC experience, but it makes the hardware/software interface less foreign.

I have learned a lot at MediaTek, and I do not want to frame the move as running away from wireless. The work has given me real production experience: embedded C on TX DSP firmware, 3GPP spec implementation, UL-DAI ownership, cross-layer debugging and customer/internal issue triage.

The reason to move now is that I want the next stage of my career to be in low-level data-centre networking, where the same core skills apply but the system impact is different. AI clusters are making networking a first-order performance problem. Moving data predictably between hosts, GPUs and accelerators depends on NICs, Ethernet transport, congestion behaviour, driver efficiency and hardware/software co-design. That is exactly the kind of low-level, performance-sensitive work I want to grow into.

I also think now is a good time because I have enough production experience to bring value, but I am still at the stage where specialising deeply in an adjacent networking domain is realistic. This role lets me keep the same core identity - low-level C, hardware/software interface, real-time constraints - while moving into Ethernet/NIC datapaths.

So the honest answer is: MediaTek has been a strong foundation, but AMD networking is closer to where I want to build long-term depth.

The AMD attraction is the combination of serious low-level engineering and strategic relevance. This is not just generic networking software; my understanding is that the Cambridge Network Solutions Group carries the former Solarflare heritage: ultra-low-latency Ethernet NICs, Onload, ef_vi, kernel-bypass style datapaths and close work between host software, firmware and hardware.

That matters to me because Solarflare-style networking is exactly the type of system where small C and architecture decisions show up as latency, throughput, packet loss or tail behaviour. It is close to my current strength: production code at the hardware/software boundary under timing constraints.

The newer AMD direction also makes the role more compelling. Publicly, AMD positions the Pensando Pollara 400 as a 400G AI NIC for scale-out Ethernet, with UEC-ready transport features, a programmable Pensando P4 engine and hardware congestion control aimed at AI scale-out. I'd note those are a different datapath philosophy from the Solarflare lineage — Solarflare is about kernel-bypass and the lowest possible latency, Pollara is programmable RDMA-style transport for AI fabrics. I don't know how that work splits between Cambridge, Pensando and other AMD teams, so I'd treat Pollara as context for AMD's direction rather than claim it as this team's product. But I do understand the broader direction: Ethernet is becoming central to AI infrastructure, and NIC behaviour can affect cluster-level performance.

So my reason for AMD is specific: I want to work on low-level networking software where the product is close to silicon, performance-critical, and important to the future of AI data centres.

I'll take the contrast between the Solarflare lineage and the newer Pensando direction, because I find the tension between them genuinely interesting.

On the Solarflare side, the thing that catches my attention is how aggressive the latency philosophy is. The public material on the X4 adapters talks about cut-through programmed I/O — the idea that you can start putting a packet on the wire before it has even finished crossing the PCIe bus — plus kernel-bypass through Onload and ef_vi so the application talks to the adapter's datapath directly. That's a whole design stance: every microsecond and every avoidable copy or context switch is the enemy, which is why it wins in markets like trading. As someone who works under real-time deadlines, I find that mindset very natural — it's the same instinct as worst-case timing on a TX path, just with PCIe and the host stack as the budget instead of a radio frame.

What I find interesting is that the AI-cluster direction almost inverts some of those assumptions. Pollara and the Ultra Ethernet direction are about throughput and reliable RDMA-style transport at scale — things like packet spraying across many paths and then handling in-order delivery and congestion in the NIC. So one lineage minimises latency for a single small message, and the other maximises efficient, lossless bulk movement across a fabric. Both are Ethernet, both are NIC datapath, but the engineering pressure points are different, and I'd genuinely like to understand where those two philosophies meet inside AMD's roadmap. I'll caveat that this is my read from public material, not inside knowledge — but it's the kind of distinction I want to be working on.

The one I'd defend hardest is that in low-level, real-time systems, the worst case matters more than the average case, and you should design and measure for the tail from the start rather than bolting it on later.

It's easy to make the common path fast and call it done. But in the systems I've worked on, the bugs and the missed deadlines almost always live in the rare combination of state — the branch that occasionally does far more work, the timing window that only opens under a specific load, the assumption that holds until the hardware is in an unusual state. So I'm opinionated about bounding worst-case work, making ownership of shared state explicit, and instrumenting so the rare condition is visible when it happens, not invisible until a customer hits it.

The second, related opinion is that observability is a feature, not an afterthought. If I can't see what the system believed its state was at the moment it went wrong, I'm guessing — and guessing doesn't scale across a team. I'd rather spend the extra effort to make a path traceable, because it pays for itself the first time something breaks in the field.

I hold these strongly, but not rigidly — I've changed my mind when someone showed me the tail genuinely didn't matter for a given path, or that the instrumentation cost outweighed the benefit. I think that's exactly the right kind of opinion for NIC datapath work, where tail latency and debuggability are the whole game.

You should treat it as a real ramp item, not ignore it. I have not shipped a Linux Ethernet NIC driver, and my deepest protocol experience is wireless PHY/3GPP rather than Ethernet/TCP-IP implementation.

The reason I still think I am a strong candidate is that the underlying engineering substrate is aligned. I have shipped production embedded C in constrained RTOS modem firmware. I have implemented spec-driven behaviour from TS 38.214 and TS 38.213. I have debugged core dumps, traces, simulations and KPI regressions across firmware, RF, PA, calibration and test environments. I have worked on MCU-DSP interface bugs where ownership and timing mattered. Those are the same instincts a NIC team needs, even though the Linux driver surface is new.

I am closing the gap deliberately. My study plan — and I'm careful to separate what I've studied from what I've shipped — covers the Linux RX/TX datapath: NAPI polling, descriptor rings and ownership, DMA mapping, interrupt-vs-poll tradeoffs, PCIe and memory-ordering basics, and kernel-bypass concepts like Onload and ef_vi. I'm at the stage where I understand the model and can read the code; I haven't driven it in production yet.

If I joined, I would not ask for a vague onboarding period. I would ramp through real contained work: learn the build/test flow, trace one RX and TX path end to end, understand the queue/descriptor model, take diagnostics or bug fixes first, and then move into performance or feature work as my domain depth catches up.

I'd split it into three rough phases, and the theme is: earn trust through contained, real work rather than asking for a long passive ramp.

First few weeks — get productive in the machinery. I'd want to stand up the build and test flow, get a board or test setup in front of me, and learn how the team actually develops, reviews and releases. In parallel I'd trace one RX path and one TX path end to end — from the application or socket layer down through the driver, the descriptor rings, DMA, and into the device — so I have a concrete mental model rather than a textbook one. I'd expect to lean on a buddy or owner here and ask a lot of questions, deliberately, early.

Weeks roughly four to eight — start contributing where the risk is contained. I'd take diagnostics, small bug fixes, observability or test improvements first. That does three things: it gives the team real signal on my engineering, it deepens my knowledge of the queue and descriptor model and the failure modes, and it's where my debugging background transfers immediately even before my Ethernet depth is complete.

Weeks roughly eight to twelve — take a bounded feature or performance item end to end. Something where success is measurable — a latency or throughput characteristic, a packet-loss case, a driver/firmware interface behaviour — and where I own the spec interpretation, implementation, tests, debuggability and release impact, the same way I owned UL-DAI.

Across all of it I'd want one or two clear success criteria agreed with you up front, so we both know whether I'm tracking. And I'd be explicit about the gap I'm closing — Linux driver conventions and Ethernet internals — so my ramp is visible rather than a black box.

I want to grow into an engineer who can reason from application-visible networking behaviour down to driver, firmware, PCIe/DMA and hardware behaviour.

In the first phase, I want to become productive in the team's codebase: build and test workflow, TX/RX datapath, queue model, diagnostics, traces and release process. Then I want to own bounded driver/datapath changes where success is measurable: correctness, latency, throughput, packet loss, observability or reliability.

Longer term, I want to sit confidently at the software/silicon boundary. I want to be able to discuss what belongs in host software, firmware or hardware, how to expose the right counters and traces, and how to design fast paths that are still debuggable when a customer hits an edge case.

The AI-cluster networking direction is the growth path that excites me. I want to understand not only individual Ethernet packets, but how NIC behaviour affects collective communication, congestion, tail latency, recovery and cluster efficiency. That is a natural extension of my current background: performance-sensitive data movement, but at data-centre scale.

The best example is the support and debug work around MediaTek firmware issues. I have triaged more than 100 customer and internal issues, and many of them required collaboration across customer engineering, system teams, senior engineers and module owners.

In those cases, collaboration was not just having meetings. It was turning a noisy report into a technical problem everyone could reason about. I would collect the configuration, logs, traces, KPI data and reproduction steps; identify whether the likely fault domain was TX firmware, RX interaction, RF module, power amplifier, calibration or test setup; then communicate clearly what we knew and what evidence was missing.

When senior engineers or system teams were involved, I tried to make their time useful by bringing a narrowed hypothesis rather than just forwarding a complaint. If the issue required a design-review decision, I would present the tradeoff: correctness versus timing, compatibility versus cleanup, or quick workaround versus proper fix.

That style should transfer well to AMD because NIC issues are also cross-functional. A performance regression might involve driver code, firmware, hardware counters, PCIe, switch behaviour or customer workload. I am comfortable being the engineer who connects those pieces and keeps the discussion evidence-based.

UL-DAI is the example I would use. I owned that feature area from specification analysis through design, C implementation, Google Test unit testing, CI/CD integration and release support.

The ownership was important because the work crossed several stages. It was not enough to write the implementation and hand it off. I had to understand the TS 38.214/38.213 behaviour, align the design with existing TX DSP architecture, make sure the code worked under RTOS timing constraints, add tests around the decision logic, respond to CI or integration failures, and support questions during release.

What I learned is that ownership means keeping the feature coherent as it moves through the system. If a test fails, it is still my problem until I understand whether the code, test, spec interpretation or environment is wrong. If another module depends on my state, I need to make the interface clear. If a senior engineer challenges the design, I need to explain the reasoning and be willing to adjust.

For this role, I would apply the same behaviour to NIC work. If I owned a queue-management change or a driver/firmware feature, I would expect to own the spec interpretation, implementation, testing, debugability and release impact, not just the patch.

I am strongest at problems where software behaviour depends on hardware state, timing or protocol rules. That includes spec-to-code implementation, real-time embedded C, debugging across firmware and hardware-facing modules, and turning vague failures into a root-cause path.

Concrete examples are UL-DAI ownership, TS 38.214/38.213 implementation, the MCU-DSP interaction bug, and debugging across L1 TX/RX, RF, power amplifier, calibration and test environments. Those are all situations where a purely local software view is not enough.

I am still growing into Linux Ethernet driver depth. I understand the broad concepts I need - TX/RX rings, DMA, descriptors, interrupts, NAPI, PCIe, TCP/IP, kernel bypass - but I have not yet shipped production code in that stack. I would rather state that clearly and then show that my learning path is focused.

The reason I think the growth is realistic is that I am not changing the kind of engineer I am. I am changing the communications domain. The core remains low-level C, hardware/software contracts, timing, data movement and disciplined debugging.

I would suggest they test three things.

First, low-level C judgement: pointers, struct layout, alignment, endian handling, bounds checks, undefined behaviour, bit manipulation and how I reason about code that talks to hardware. That is core to my current work and should transfer directly.

Second, systems reasoning around a NIC datapath. Even if I have not shipped your driver stack, they can test whether I understand the concepts: RX/TX rings, descriptors versus buffers, DMA ownership, memory ordering, interrupts versus polling, NAPI, packet parsing and where latency or packet loss can enter.

Third, debugging across layers. Give me a scenario like intermittent packet loss, a completion that never appears, a performance regression after a fast-path change, or a firmware/driver mismatch. I think that is where my MediaTek background should show well, because I am used to tracing failures across L1 firmware, RF, PA, calibration and test environments.

I would also expect them to probe my gaps honestly: Linux driver APIs and deeper Ethernet/TCP-IP details. I am prepared for that, and I would rather be tested fairly on both my current depth and my ability to ramp.

I would ask focused questions that help me understand the team and prepare for the engineer rounds:

• Which part of the stack would this role touch most: Linux host driver, firmware interface, datapath features, diagnostics, bring-up, performance/debug, or a mixture?
• For someone coming from strong embedded PHY work rather than shipped Linux NIC drivers, what would you expect them to learn first to become productive?
• What are the hardest bugs your team sees most often: PCIe/DMA issues, packet drops, latency outliers, firmware/driver interface bugs, concurrency, reset/recovery or hardware bring-up?
• How much does the Cambridge team still work on the Solarflare/Onload/ef_vi lineage versus newer AI-networking products and features?
• How is AI-cluster networking changing the requirements compared with traditional ultra-low-latency Ethernet?
• What would make you confident after this call that I should move to the four engineer interviews?
• Is there anything in my CV that gives you concern, especially around the wireless-to-Ethernet transition, that I can address directly?

If compensation comes up, I would keep it short: Graham mentioned the base could be around GBP 70k depending on interview performance. For this call my priority is proving technical fit; I'm happy to handle the package and level with Graham at the right stage.