🎯Curveballs & Meta-Scenarios

I wouldn't bluff. I'd separate what I know, what I can infer, and what I'd verify.

For example, if you asked me a specific Linux driver API I hadn't used, I'd say: "I haven't implemented that exact kernel path, so I won't pretend to remember the API name. The model I'd start from is — what context am I in, can this sleep, who owns the buffer or device state, and what ordering does the hardware require? Then I'd check the kernel docs or an existing in-tree driver and map the API onto those constraints."

That's genuinely how I work in firmware. On the MCU-DSP interface bug I didn't start by knowing the answer — I knew how to reason about ownership, timing and which side last held correct state. I may not know a given register block or kernel primitive on day one, but the reasoning transfers. For this role I'll be explicit where my Linux NIC-driver experience is newer, and keep the discussion on the fundamentals I do have: moving data correctly across a hardware/software boundary under real-time constraints.

I'd call it out briefly and keep the signal in the problem. Something like: "I'm blanking on the exact spelling of that helper, so I'll write it as helper_name(...) for now and focus on the ownership and error path — the important part is that allocation, mapping, publication and cleanup happen in this order. I'll tidy the exact name after."

If it's core C, I'd just correct myself rather than spiral: "Let me rewrite that as a pointer to the element rather than copying the struct — I want the update to hit the ring entry, not a local copy."

That's better than freezing. In production embedded work the value was never in never looking up syntax — it's in knowing what must be true: no use-after-free, no stale ownership bit, no missing cleanup on a partial failure, no unbounded work in a time-critical path. I keep talking about those while my memory catches up on the spelling.

I'd treat that as a useful signal, not a threat. My response: "Let me check my assumption. I'm assuming X because Y. If that assumption is wrong, the answer changes like this."

Concretely, if I'd just claimed some handler could safely take a particular lock and you pushed back, I'd step back to context: "If this can run in a context that must not sleep, then anything that might block is out — I'd need a non-sleeping primitive or to defer the work to a slower path. So the safe answer depends on which context this actually runs in, and I'd want to confirm that before committing." If I'm genuinely unsure which context applies — because that's Linux-specific detail I'm still ramping on — I'll say so rather than invent it.

That shows I'll revise. In low-level work, being confidently wrong is dangerous; the right posture is confidence in the method, not stubbornness about the first sentence. But I won't flip my answer just because I was challenged — I only move if the reasoning moves.

Fair concern, and I'd frame it as an adjacent-domain move, not a career change.

The core of my experience is real-time hardware/software engineering: bits moving through constrained systems, timing budgets, buffers, event-driven processing, and correctness at the boundaries where software assumptions meet hardware behaviour. In wireless PHY and DSP firmware I've had to care about latency, throughput, memory layout, hardware-visible representation, and debugging problems where the symptom shows up far from the cause — the MCU-DSP interface bug is a clean example of exactly that.

The gap is that I've spent more time in wireless stacks than in Linux Ethernet drivers, and I haven't shipped a production NIC driver. I won't pretend otherwise. My plan to close it is specific: read and trace existing in-tree NIC drivers, get fluent in net_device, NAPI, the DMA API, PCIe probe/remove, ethtool and kernel debugging, and map each onto concepts I already use — descriptor ownership, producer/consumer indices, backpressure, interrupt moderation, hardware bring-up.

What I bring isn't generic software experience — it's the same kind of engineer: comfortable at the hardware/software seam where correctness depends on timing, ordering and precise ownership. The domain changes from radio samples and protocol timing to Ethernet packets and PCIe DMA; the engineering muscles transfer strongly.

I use a short loop:

• Restate the problem in one sentence.
• Ask one or two clarifying questions that actually change the solution.
• State assumptions.
• Walk the main path.
• Call out edge cases and failure modes.
• Summarise the decision.

For example, asked to debug packet drops, I'd say: "First I want to locate *where* they drop — before DMA, in the Rx ring, under NAPI budget pressure, in the stack, or at the application. I'd look at hardware counters, ring stats, interrupt/NAPI behaviour, and whether drops correlate with packet size, queue, CPU affinity or burstiness. My assumption is the link is up and it's load-dependent; if it happens at idle I'd first suspect configuration, MTU, filters or a reset/link-state bug." I'd flag that some of those Linux specifics are areas I'm still ramping on, so I'm reasoning by analogy to producer/consumer and backpressure problems I've debugged before.

That keeps you inside my reasoning without a stream of consciousness. If I notice I'm going wide I'll pause: "Let me narrow to the highest-probability path first."

I'd correct it directly and preserve trust: "I want to revise something I said. I treated that as if it ran in a context where blocking was fine, but if it can't sleep then the design needs a non-sleeping primitive there and the blocking work pushed to a slow path."

Then I'd explain the corrected *reasoning*, not just the corrected conclusion — you need to see the mechanism that failed and the one I'm using now.

I learned to do this from embedded bring-up. A wrong assumption about whether a value is CPU-owned, hardware-owned, stale, or time-aligned wastes a lot of time if nobody names it — that was literally the shape of the MCU-DSP bug. In an interview I'd rather lose five seconds correcting myself than spend five minutes defending an answer I no longer believe. And if I realise the thing I got wrong is a Linux detail I was unsure of, I'll say that honestly too.

Only questions that change the implementation. For a low-level C task my default list:

• What are the input constraints and ownership rules?
• Can the function allocate, sleep, or block?
• Single-threaded, interrupt-context, or concurrent?
• What happens on invalid input or partial failure?
• Are we optimising for clarity first, or is latency/throughput part of the spec?

For a ring buffer I'd ask: single-producer/single-consumer or multi-producer, is overwrite allowed, must capacity be power-of-two, can indices wrap naturally — those answers change the synchronization and the structure. That maps onto the producer/consumer handoffs I dealt with on the MCU-DSP interface, so it's familiar ground.

I wouldn't ask a long list to buy time. I'd ask the two or three that determine correctness, then state assumptions and start. If you say "make a reasonable assumption," I'll say it out loud: "I'll assume single producer/single consumer, fixed capacity, no allocation after init, and return an error when full."

I'd name it rather than keep spinning silently: "I'm stuck on this branch — let me say where I am and what I'd try next, and you can redirect me if I'm off."

Then I'd do three things. First, restate what I'm confident is true versus what I'm guessing, so we're not building on a shaky assumption. Second, shrink the problem — solve a smaller or more constrained version, or handle one concrete case end to end, and generalise from there; getting *something* correct moving usually breaks the logjam. Third, ask a targeted question if there's a fact that would unblock me — I'd rather spend one question than five minutes guessing.

That's exactly how I work on a hard bug. On the MCU-DSP issue the move that unstuck me wasn't more thinking, it was building a reduced repro and instrumenting one boundary so the data told me which side was wrong. In an interview I treat being stuck as a normal state to manage out loud, not a failure to hide.

I'll be honest and calibrated rather than buzzword-led. My day-to-day protocol depth is wireless — 3GPP PHY, the TS 38.214/38.213 layer, arbitration on the modem side — not Ethernet and TCP/IP internals. I have working foundations in Ethernet/IP and TCP/IP and I understand the data-centre networking direction at a concepts level: why AI clusters stress the fabric, why lossless/low-tail-latency transport matters, and why efforts like UEC and lossless RoCE-style approaches exist to make the network keep up with collective traffic. I follow it because it's why this role exists — Pollara and UEC put networking at the centre of AI infrastructure rather than treating it as support.

What I won't do is overstate it. I haven't implemented an RDMA path or a transport stack in production. So my honest position is: strong real-time low-level systems engineer, genuine interest and conceptual grasp of the AI-networking direction, and a deliberate gap to close on Ethernet/TCP/IP depth and the specific transport mechanics. The fundamentals I'd lean on while ramping — backpressure, ordering, tail latency, ownership at a hardware/software boundary — are exactly the ones that matter for that fabric.

Yes — a small number that show I understand the role and am choosing it deliberately:

• "For this Cambridge role, how much of the day-to-day is Linux driver development versus hardware modelling, bring-up, performance analysis, or customer/debug support?"
• "Where's the team putting most engineering pressure right now — classic low-latency Ethernet, PCIe/DMA performance, kernel integration, or the newer AI-cluster networking work around Pollara, UEC and UALink?"
• "For someone coming from wireless PHY and embedded systems, what would you expect them to be productive on in the first three months?"
• "What distinguishes someone merely competent on this team from someone who becomes trusted quickly?"
• "How closely does this role work with the silicon team when a behaviour might be hardware, firmware, or driver?"

If time's short I'd pick two — one on day-to-day work, one on what success looks like. I wouldn't lead with salary in the technical interview; Graham has already indicated the base range, so the engineering conversation should make the case for it.

I'd close with a concise positioning statement:

"The main thing I want to leave you with is that I'm not treating this as a random switch from wireless into networking. My background is already real-time, low-level systems where hardware behaviour, timing, buffers and software correctness meet — production RTOS firmware, TX DSP work, 3GPP-to-C under slot budgets, and debugging across the MCU-DSP and L1/RF boundaries. The new domain for me is Linux Ethernet/NIC-driver depth, and I'm actively closing it. The core engineering pattern is familiar: understand the datapath, respect ownership and ordering, measure latency and failure modes, and work closely with hardware teams."

Then I make the ask easy: "If anything in this conversation raised a concern, I'd be glad to address it now. Otherwise I'd be very interested in continuing to the engineering rounds."

That ending is calm and senior — it reinforces fit, names the gap without fear, and invites objections while there's still time to handle them.

I wouldn't argue with the premise. I'd narrow the risk.

"I understand that concern. The distinction I'd make is between domain-specific API familiarity and the underlying low-level systems judgement. I'm newer to Linux NIC-driver APIs than someone who's lived in netdev for years — I haven't shipped a production driver. But I'm not new to embedded C, hardware-facing debugging, real-time constraints, buffer ownership, timing budgets, and working across hardware/software boundaries."

Then proof, from a real project: "On the MCU-DSP interface bug in my internship, the failure depended on timing and shared state at a hardware/software boundary. The fix meant isolating whether it was the MCU side, the DSP side, the handshake ordering, or timing — and proving it with instrumentation at the boundary. That's the same reasoning a NIC datapath needs: where's the packet, who owns the descriptor, what's been made visible to hardware, where's backpressure building."

Then a ramp plan: "If I joined I'd make the Linux ramp explicit — trace an existing driver end to end from PCI probe to open, Tx/Rx rings, NAPI, DMA mapping, ethtool, reset, stats — then take small bugs or instrumentation tasks before larger datapath changes. That makes the risk manageable."

Honest answer: it's not a stepping-stone, and I'm not running away from wireless — I'm moving toward the part of the work I like most.

What's kept me engaged at MediaTek isn't the radio domain specifically; it's the seam — being where software meets hardware under real-time constraints, where a timing or ownership mistake is a correctness bug, where you debug from a symptom that's far from the cause. The MCU-DSP work, the DSP timing budgets, turning a spec into C that has to hit a deadline — that's the part I'd happily do for the rest of my career. Networking at AMD is the same seam with the centre of gravity shifting to the thing that's now bottlenecking AI infrastructure. That's more interesting to me, not less.

Will I miss some wireless-specific things? Probably the PHY signal-processing depth I built up — the thesis work, the 3GPP detail. But I'd rather carry the transferable engineering muscle into a domain that's central to where computing is going than stay narrow in one I've already learned. I'm choosing this deliberately, and I'd want the role to be the next several years, not a layover.