📞The Recruiter / HR Screen

Sure. I’m a low-level embedded and wireless PHY engineer, mainly working around real-time DSP, 3GPP-style systems, and the hardware/software boundary. The common thread in my work has been moving bits quickly and correctly under tight timing constraints, with C, embedded debugging, and close interaction with hardware teams.

What I’m looking for now is an adjacent move into low-latency networking and AI infrastructure. I’m not treating it as a career reset: the domain changes from wireless PHY to Ethernet/NIC datapaths, but the engineering shape is very familiar — constrained latency, hardware behaviour, software control paths, debugging at system level, and careful C.

The AMD Network Solutions role is interesting because it sits exactly at that boundary: NICs, drivers, PCIe, packet datapath, and work with the silicon team. I’ll be honest that I’d need to ramp specifically on Linux networking driver conventions and deeper Ethernet/TCP-IP implementation details — that’s the same engineer in an adjacent domain, not a beginner. But the real-time embedded base is strong and I’m deliberately targeting this kind of role.

The short version is that I want the next role to be closer to infrastructure systems where performance directly matters at scale. I’ve enjoyed wireless and PHY work because it is rigorous, timing-sensitive, and close to hardware. But the direction I’m most interested in now is AI infrastructure and low-latency networking, where those same engineering instincts apply to NICs, drivers, PCIe, queues, packet movement, and system behaviour under load.

There’s no negative story I need to tell about my current role. I’m looking because the next growth step for me is a role with a deeper software-visible hardware interface and a clearer path into networking systems. AMD’s former Solarflare team is a credible place to do that because the work is not abstract application software; it is still performance engineering at the hardware/software boundary.

AMD is compelling to me because it is one of the few companies where the hardware roadmap and the systems software actually meet in products that matter for AI infrastructure. The networking side is especially interesting because AMD now has the Pensando portfolio, including the Pollara 400 AI NIC, and is clearly positioning Ethernet networking as part of AI cluster performance rather than as a commodity peripheral.

For me, that matters because I’m trying to move toward infrastructure where latency, throughput, telemetry, reliability, and hardware behaviour are all first-order concerns. I also like that AMD has real silicon depth. Coming from embedded and PHY work, I’m more motivated by teams that work close to hardware than by pure software product roles.

So my reason is quite specific: AMD gives me a route into low-level networking while still using the instincts I’ve built in real-time embedded systems.

The team is attractive because it appears to be the former Solarflare networking group in Cambridge, so the heritage is high-performance NICs rather than generic platform software. The role description also lines up with the kind of work I want: low-level C, Linux drivers, PCIe, Ethernet/TCP-IP, packet datapath work, and close collaboration with silicon engineers.

The honest version is that I’m not coming in as a lifelong Ethernet driver specialist. My strongest base is wireless PHY, embedded C, real-time debugging, and hardware/software integration. But that is also why this role makes sense: it uses the same engineering muscle in an adjacent system. In wireless, I’ve had to care about timing, buffers, hardware state, error paths, and what happens when theory meets real hardware. In NIC software, I expect the details change, but the discipline is very similar.

I’m particularly interested in the driver/datapath side because it is measurable. You can reason about latency, drops, queue behaviour, DMA, interrupts, polling, CPU cost, and failure modes. That is the kind of engineering I enjoy.

I’m realistic about the ramp. The areas I would expect to refresh or deepen are Linux network driver structure, kernel APIs, Ethernet/TCP-IP specifics, and the conventions around NIC queues, NAPI, interrupts, DMA mapping, and ethtool-style observability.

But I don’t see it as a cold start. My background is already in systems where correctness depends on timing, buffers, hardware state, and careful interpretation of traces. Wireless PHY and NIC datapaths are different domains, but both force you to think about data movement, latency budgets, backpressure, error handling, and what the hardware is actually doing rather than what a clean abstraction says.

So my answer is: yes, there is a domain ramp, and I would be explicit about it. But I’m confident in the underlying engineering fit, and I’m already orienting my preparation around Linux drivers, PCIe/DMA, and Ethernet datapath fundamentals.

I’m looking for three things.

First, low-level systems work where performance and correctness are visible, not hidden behind layers of product code. I want C, hardware-facing software, debugging, and measurable behaviour.

Second, a domain with strong long-term relevance. AI infrastructure networking is attractive because cluster performance increasingly depends on the network: latency, congestion, reliability, telemetry, and efficient data movement.

Third, a team where I can work with strong engineers and ramp into a deeper networking stack. I’m not looking for a title-only AI move. I’m looking for a role where my embedded and real-time background is useful immediately, while I build the Ethernet/NIC driver depth expected of the team.

I’ll be straight with you because it helps you represent me well. [Pick the honest version and keep it brief.]

If you have other live processes: "I have one or two other conversations in low-level systems and networking, but nothing at offer stage yet, and AMD is the one I’m most interested in because of the Solarflare heritage and the AI-networking direction. I’m not running a wide scattergun search — I’m being selective about roles that are genuinely close to hardware."

If you don’t: "I’m not in other active processes right now. I’ve been deliberately selective rather than applying broadly, and this role is the one that fits what I’m trying to do, so I’m focused on it."

Either way, the message I want you to take away is that I’m serious about AMD specifically, and if there’s any timing pressure from another process I’ll tell you early so you’re never surprised.

Because I’m optimising for the kind of engineering and the direction of the field, not for staying in the domain I already know. I could take another wireless PHY role and be productive on day one, but I’d be deepening a track I’ve already spent four years on rather than building toward where I think the interesting low-level performance work is heading.

Low-latency Ethernet and AI-cluster networking is where a lot of the hard systems problems are concentrated now: NIC datapaths, congestion, tail latency, RDMA-style transports, hardware/software co-design. AMD’s networking group lets me move into that while still using the muscle I’ve built — real-time C, hardware-aware debugging, spec-to-code discipline. So it’s a deliberate adjacent step, not a sideways one.

I’d rather make that move now, while my embedded base is fresh enough to transfer cleanly and I’m still early enough to specialise deeply in a new domain.

Based on the role scope, Cambridge market, and the level of low-level C and driver work involved, I’m targeting around £70k base. My understanding from our discussion is that this may be achievable if the technical interview performance supports it, so I’d like to keep that as the working expectation.

I’m also open to looking at the full package: bonus, pension, equity or RSUs if applicable, and benefits. But for base salary, £70k is the number I’d like us to aim for, assuming the hiring team agrees the technical fit is there.

I’d rather anchor on the value of this role and the market for it than on my current number, because the two aren’t the same conversation — a domain move like this should be priced on the scope here, not on where I happen to sit today. So my target is £70k base for this role.

If you specifically need a current figure to build the case internally, I’m happy to share it with you confidentially as my recruiter, on the understanding that we’re representing me at £70k and not at my current number. [If you choose to disclose, state it plainly and immediately re-anchor: "That’s where I am now, but the target for this role is £70k."]

What I want to avoid is my current salary quietly becoming the ceiling for the offer when the role itself justifies the £70k.

I would want to understand the full package and the level they are hiring me into. My preference is still to target £70k base, because that reflects the seniority and the specialist low-level nature of the role.

If there were a gap, I’d look at whether there is a clear reason: for example leveling, bonus structure, equity, or a defined salary review path after proving myself in the role. But I would not want to create ambiguity now: £70k base is the figure I’d like represented, and I’m focused on performing well enough technically that the team is comfortable justifying it.

My notice period is [insert notice period, for example one month or three months]. For interviews, I can be flexible with some notice. I’d prefer early morning, lunchtime, or late afternoon slots where possible, but I can make time during the week for the hiring-manager call and the engineering rounds.

If the process moves quickly, I can keep momentum. My main request would be to know the expected format of each stage in advance, especially whether the engineering rounds are mostly CV-based, C/Linux debugging, networking fundamentals, or system-design style. That helps me prepare efficiently and gives the interviewers a better signal.

I’m ready to move at the pace of the process — I don’t need to stall, and I’m not trying to rush you either. Realistically the gating item on my side is my notice period of [insert notice period] once an offer is agreed.

The one thing I’d ask is predictability: if you can give me visibility on the stages and rough timing, I’ll keep my side moving and I’ll flag early if anything changes — for example if another process I mentioned starts moving faster. I’d much rather you hear that from me than be surprised by it.

So: no artificial urgency, but I’m engaged and responsive, and I’ll protect the momentum if the technical rounds go well.

The clean answer is: [insert exact status: British/Irish citizen, settled status, graduate visa, Skilled Worker visa, or sponsorship required].

If sponsorship is needed: I would say, "I would need Skilled Worker sponsorship. My understanding as of June 2026 is that the rules depend on the occupation code, salary threshold, going rate, and sponsor licence position, so I would want AMD’s immigration team to confirm the details. At the salary level we discussed, I’d expect it to be worth checking properly rather than guessing. I can provide documents quickly if the process moves forward."

If sponsorship is not needed: I would say, "I have the right to work in the UK and would not need sponsorship. I can provide evidence at the appropriate stage."

Yes — I’m based in Cambridge already and my CV says I’m willing to relocate, so location isn’t a blocker. [Adjust to your real situation: if you’re already in/near Cambridge, lead with that; if not, say where you are and that you’re prepared to move for the right role.]

My understanding is this is primarily an on-site or hybrid role given it’s hardware-adjacent work — lab access, boards, and close collaboration with silicon and validation people. That suits me; a lot of the work I’m drawn to genuinely benefits from being physically near the hardware and the team.

The only things I’d want to understand at the right stage are the expected on-site pattern and whether there’s any relocation support if it becomes relevant, but neither changes my answer: I’m happy to be where the team and the hardware are.

Example to personalize:

Situation: In a wireless PHY/embedded project, we had a real-time performance issue where a processing path was occasionally missing its timing budget under certain radio conditions. It was not a simple algorithm question; it involved DSP workload, buffer timing, hardware behaviour, and software scheduling.

Task: My responsibility was to narrow down whether the issue came from algorithmic load, embedded implementation, hardware interaction, or measurement error, then propose a fix that was safe for the product.

Action: I instrumented the relevant path, separated average load from tail behaviour, checked buffer boundaries and timing assumptions, and worked with hardware/system colleagues to understand what the traces were really showing. I avoided treating it as a pure code optimization problem until we knew where the time was going. Once we had evidence, I changed the implementation to reduce worst-case work in the critical path and added checks so we could see the condition earlier.

Result: The system met the timing budget more consistently, and we had a clearer debug method for similar issues later. The reason I’d connect that to this AMD role is that NIC/driver work has the same character: tail latency, queues, hardware state, and careful low-level debugging matter more than clean high-level theory.

I’m serious, and I’d put it concretely so you can repeat it. I’ve already done the homework on this team: I know it carries the Solarflare heritage — Onload, ef_vi, sub-microsecond Ethernet — and I understand how that contrasts with the newer Pensando direction like Pollara and Ultra Ethernet for AI clusters. That’s not the prep of someone casually applying.

Why me over a generic candidate: I bring four years of shipped, production low-level C at the hardware/software boundary, real-time debugging across firmware and hardware, and spec-to-code discipline. Where a pure-networking candidate might have the Ethernet driver depth I’m still building, I’d argue many of them don’t have the real-time embedded and hardware-debug instincts I already have. I’m the adjacent engineer who ramps fast, not a beginner.

And I’ll make your job easy: I’m responsive, I’ll prep hard for the rounds, I’m clear on compensation, and I’ll communicate early about timing. You won’t get surprises from me.

Yes, a few.

• From the hiring manager’s point of view, what would make someone perform strongly in the first technical CV call?
• Is the main concern likely to be Linux driver experience, Ethernet/TCP-IP depth, low-level C, or general hardware/software debugging?
• How is the role split between existing NIC product work, new AI-cluster networking work, and collaboration with the silicon team?
• For the engineering rounds, are they mostly resume-led, or should I expect live C, Linux kernel, networking, or PCIe/DMA problem solving?
• What does the rest of the process look like after this call, and roughly over what timeframe?
• On compensation, you mentioned £70k base could be possible depending on interview performance. Is there anything specific I should make sure the hiring team sees to support that level?

Those answers would help me prepare in a targeted way and give the team the best signal.

I should keep the anchor consistent, but connect it to the evidence from the process rather than repeating a number mechanically.

A strong answer is: "My target is still £70k base. After the manager and technical discussion, I think that is the right level to represent because the role is specialist low-level C and hardware/software work, and I was able to show the relevant production background: embedded C, UL-DAI ownership, spec-to-code implementation, and hardware-facing debug. I understand I have a Linux NIC driver ramp, and I am not hiding that, but I think the interview evidence should support the higher end of the range."

If he asks whether I would accept less, I should not negotiate against myself. I can say: "I would look at the full package and leveling if an offer comes, but I would like you to continue representing me at £70k base. If the team has concerns, I would rather understand the specific concern than lower the target before we have an offer."

That is firm without being difficult.

The safest answer is to show flexibility and also understand the nature of hardware-adjacent work.

I would say: "For this role I would expect some onsite or hybrid work because NIC driver and hardware/software integration often benefits from lab access, boards, and close collaboration with silicon, firmware and validation engineers. I am comfortable with that. I am not looking for a fully remote-only arrangement if the team needs presence near the hardware."

Then I can ask a practical question: "What is the team's normal pattern for onsite days, lab work and remote focus time?"

If relocation comes up, I keep it simple: "Location is not a blocker for the right role. My CV says I am willing to relocate, and for this kind of team I would rather be close enough to work effectively with the people and hardware."

The trap is making remote flexibility sound like the deciding factor. For a low-level NIC role, fit and access to the team matter more.