🗓️Logistics, Format & Follow-up

I should treat Graham's first call as a qualification and representation call, not as a deep technical interview. In about 30 minutes he needs to confirm that I match the role shape, that my motivation is credible, that compensation and location are workable, and that I am easy to put in front of the hiring manager.

My answer style should be short and organized. I want him to be able to repeat my story as: embedded C and wireless PHY engineer, production real-time firmware, hardware/software boundary, now making a deliberate adjacent move into low-latency NIC and networking software.

The prep is mostly logistics and positioning:

• Have the one-minute CV story ready.
• Be clear on why AMD Network Solutions Group, not just AMD generally.
• Be honest that I have not shipped a Linux NIC driver, then frame it as a focused ramp from embedded C and hardware-facing firmware.
• Know my salary target, notice period, right-to-work status, location, and interview availability.
• Ask what the next round will test so I can prepare efficiently.

I should not try to prove all of my technical depth in this call. The win is for Graham to finish thinking, "This candidate is relevant, realistic, serious, and worth scheduling quickly."

I should treat the hiring-manager call as a CV deep-dive and risk assessment. The manager is probably not trying to run a full algorithms round in 30 minutes. They are asking: does my background really transfer, can I explain my own work clearly, do I understand the role, and are the gaps manageable?

My best structure is to keep every CV answer anchored in a real project, then bridge it to NIC software:

• UL-DAI: spec-to-C ownership, edge cases, tests, release support.
• TX DSP firmware: constrained C, timing, state, traces, no casual abstraction.
• MCU-DSP bug: interface ownership and ordering, similar to host-driver-to-device problems.
• 100+ issues triaged: turning noisy reports into reproducible engineering problems.
• NTN PoC and KQLMS thesis: communications depth, but not my main selling point.

When the manager asks about gaps, I should say it plainly: "I have not shipped a Linux NIC driver, and my protocol depth is wireless rather than Ethernet/TCP-IP. The reason I still think this is a strong fit is that the engineering pattern is adjacent: real-time C, hardware-visible state, timing, buffers, ownership, and cross-layer debugging."

That sentence matters because it sounds honest without making the gap sound fatal.

I should expect variation, because public reports and platform norms do not prove the exact AMD team format. For this kind of SDE Networking role, I would prepare for four 45-minute rounds that may mix live coding, C and systems fundamentals, Linux/networking concepts, CV project probing, debugging scenarios, and behavioral collaboration.

My mindset should be that every engineer is asking a version of the same question: can Mohamed become useful on our low-level networking codebase without a long passive ramp?

I would prepare each round with a slightly different operating mode:

• For coding: clarify the problem, write simple correct C or C++ first, narrate tests, then optimize.
• For systems: draw the path in words - app, kernel or bypass path, driver, rings, DMA, device, completion.
• For CV probing: use STAR, but keep it technical and specific.
• For debugging: ask what is observed, what changed, how to reproduce, what counters or traces exist, and which layer is likely.
• For behavioral: show ownership, calm communication, and escalation with evidence.

The biggest mistake would be treating the engineering rounds as unrelated exams. I want a consistent signal across all of them: I am a low-level C engineer who thinks in timing, ownership, observability, and hardware/software contracts.

I should not assume a guaranteed platform. It could be CoderPad, HackerRank, a shared editor, screen share, or simply Zoom with a local editor. Public interview data and vendor docs show that live coding platforms are common, but the team and recruiter should confirm the actual tool.

My practical default is to prepare as if I will have a plain editor with limited help:

• Practice C without relying on autocomplete, snippets, AI tools, or my personal IDE shortcuts.
• Keep the browser, Zoom, and any coding pad tested before the call.
• Have a local backup editor ready in case the shared pad fails.
• Narrate while typing: "I am going to handle the empty case first, then the normal loop, then the boundary condition."
• Compile mentally, but also run tests if the platform allows it.
• Write two or three small tests by hand before chasing optimizations.
• Say tradeoffs out loud instead of silently rewriting code.

If I use C, I should be especially explicit about memory ownership, bounds, integer sizes, null handling, and whether a function mutates input. If the platform has no autocomplete or weak diagnostics, that is not an excuse. I should slow down, use simple names, and keep the code boring enough to debug live.

Because this role is tied to the UK team, I should make scheduling easy and precise. I should reply with UK local times, include the timezone explicitly, and offer several windows rather than one narrow slot.

A good scheduling reply sounds like this: "Thanks Graham. I can do Tuesday 09:00-11:00 UK time, Wednesday 12:30-14:00 UK time, or Thursday after 15:00 UK time. If the engineering panel needs a longer block, I can also make Friday morning work with notice."

For multi-round scheduling, I should protect energy, not just availability. Four 45-minute engineer rounds can be mentally expensive. If they offer all four in one block, I can accept if needed, but I should ask for short breaks between rounds. If they split them, I should avoid placing a demanding interview directly after a work meeting.

Before each call, I should check the calendar invite for the actual timezone, meeting link, expected duration, and whether there are attachments or platform links. If anything is unclear, I ask early, not five minutes before.

I should set up as if the interview starts 20 minutes before the calendar time. The goal is to remove every avoidable distraction so my brain is only solving the interview.

My day-of checklist:

• Laptop charged and plugged in.
• Camera, microphone, and headphones tested.
• Zoom or Teams opened and updated.
• Browser ready for CoderPad, HackerRank, or any shared document link.
• Backup internet ready, usually phone hotspot.
• CV open locally, plus the job description and my short notes.
• A plain local editor open as backup.
• Water nearby.
• Quiet room, notifications disabled, phone on silent but available for recruiter calls.
• Pen and paper for quick sketches, but not a script I read from.

My notes should be sparse: one-line reminders, not paragraphs. For example: "same engineer, adjacent domain", "no shipped NIC driver - real ramp", "UL-DAI = spec-to-C ownership", "MCU-DSP = ordering/ownership". If I read long notes on camera, I will sound less present.

If something breaks, I should handle it calmly and make the recovery easy for the interviewer. I do not need to over-apologize. I need to communicate, recover, and continue.

If the connection drops, I reconnect immediately and send a short message to Graham or the interviewer if I have contact details: "I dropped from the call and am reconnecting now. If needed, I can switch to my phone hotspot."

If the coding platform fails, I say: "It looks like the pad is not responding on my side. I can refresh once, or I can continue in a local editor and share my screen if that works for you." Then I keep narrating instead of going silent.

If I mishear a question, I should ask directly: "Sorry, I missed the last part of the question. Could you repeat the constraint after the input size?" That is better than answering the wrong problem for five minutes.

If I realize I misunderstood after starting, I should stop early: "Let me reset that. I answered as if the buffer was owned by the caller, but your constraint says this function owns allocation. I will adjust the design." Correcting course is a good signal if I do it clearly.

My default answer length should depend on the round.

For the recruiter screen, most answers should be 30 to 60 seconds. Graham needs crisp signal: who I am, why AMD, compensation, availability, right to work, and risk areas.

For the hiring-manager CV call, most answers should be 90 seconds to two minutes, with permission to go deeper if asked. A good answer is: context, what I personally did, result, and why it maps to this role.

For engineer rounds, I should think aloud continuously but in small chunks. I should not monologue for five minutes before writing code or answering the actual question. A strong rhythm is: clarify, state a plan, do one step, check with the interviewer, continue.

A useful phrase is: "I can go deeper on that if useful." It gives the interviewer control. If they interrupt, I should take it as steering, not rejection. If they look rushed, I shorten. If they ask follow-ups, I go deeper with concrete details.

The rule is simple: answer the question in the first sentence, then support it. Do not make them wait two minutes to find out whether I know the answer.

I should watch for steering signals. If the interviewer says "let's move on", I move on cleanly. If they ask "can you be more specific", I give an example. If they ask several follow-ups on one detail, that is probably the area they care about, so I slow down and make the reasoning explicit.

For coding, I should avoid disappearing into my own head. The interviewer needs to see how I think, not just the final code. I can use short narration:

• "I am checking the boundary case first."
• "This loop is safe because i only advances while it is less than n."
• "I am choosing the simpler version first, then I can improve memory use if time allows."
• "This is where I would add a test for empty input and a one-element input."

For CV questions, I should not turn every answer into the entire MediaTek story. I choose the relevant project and bridge it to the AMD role. If the interviewer already understands a point, I stop explaining basics and move to tradeoffs.

The strongest pacing signal is collaborative: I am not performing a memorized speech; I am helping the interviewer collect evidence.

I should send a short thank-you within 24 hours. It should be specific, low-pressure, and useful for Graham to forward or remember. I should not write a long essay or try to relitigate every answer.

Concrete template:

"Hi Graham,

Thank you for taking the time to speak with me today. I appreciated the overview of the AMD Network Solutions role and the next stages.

The conversation reinforced my interest in the team, especially the low-level C, hardware/software boundary, and networking datapath work. As discussed, I see the move from wireless PHY firmware into NIC/networking software as an adjacent step: I bring production embedded C, real-time debugging, and spec-to-code ownership, while ramping deliberately on Linux networking, Ethernet/TCP-IP, and NIC driver conventions.

Please let me know if there is anything else you need from me before the hiring-manager stage. I would also appreciate any detail you can share on the format of the next round so I can prepare in the most relevant way.

Best regards, Mohamed"

If the email is after the hiring-manager call, I can change the middle paragraph to reference one concrete topic we discussed, such as TX DSP timing, MCU-DSP interface debugging, or the Solarflare/low-latency networking direction.

I should first ask Graham during the call what the expected timeline is. Then my follow-up should match that timeline.

If he says I should hear back in a few days, I follow up after three or four business days. If he gives no timeline, I follow up after one week. If the process is between engineering rounds, I can be a little more proactive because scheduling is the bottleneck.

Short template:

"Hi Graham,

I hope you are well. I wanted to check whether there is any update on the AMD Network Solutions process or any feedback from the last stage.

I remain very interested in the role and am happy to share availability for the next round if the team would like to continue.

Best regards, Mohamed"

If there is a competing process, I should be transparent but not threatening: "I also wanted to flag that another process has started moving, but AMD remains the role I am most interested in. If there is any update on timing, it would help me manage that properly."

To justify the top of the band, I need to do more than be likeable or generally smart. I need to reduce the team's risk calculation.

Strong performance looks like this:

• I explain my MediaTek work with enough depth that it is clearly production engineering, not resume decoration.
• I am honest about no shipped Linux NIC driver, but I show a credible ramp plan and enough networking preparation to be dangerous in the right way.
• In coding, I produce correct, simple code, narrate tradeoffs, test edge cases, and stay calm when constraints change.
• In systems discussions, I reason about ownership, queues, DMA, interrupts, polling, ordering, counters, and failure modes rather than only naming concepts.
• In behavioral answers, I show ownership, collaboration, escalation with evidence, and customer/internal issue maturity.
• I ask questions that sound like someone who wants to contribute to the codebase, not someone shopping for a brand name.

The line I want the interviewers to land on is: "He has a domain ramp, but the underlying low-level engineering is strong enough that we can justify hiring him at the higher end." That is the argument Graham can use in compensation discussions if I give the panel the evidence.

I should treat live coding as a collaboration, not a silent exam. My default loop is:

• Clarify the contract: inputs, outputs, ownership, error handling, allowed assumptions, and whether this is production-style C or pseudocode.
• Create one or two examples, including a boundary case.
• State the simple correct approach first, even if it is not perfectly optimized.
• Write clear C with bounds checks and readable names.
• Test aloud against the examples.
• Then discuss optimization, memory layout, concurrency, or hardware-facing concerns if time remains.

For this role, the important signal is not only algorithmic cleverness. It is C judgement. I should say things like: "I am passing len explicitly because the function cannot infer buffer size", "I am avoiding unaligned casts here", "I am checking that the Ethernet header is present before reading EtherType", or "I would use endian helpers in kernel code."

If I see a better approach halfway through, I do not throw away ten minutes silently. I say: "The simple version is now clear. I can either finish it and test it, or switch to the more efficient version. Which would you prefer?" That keeps the interviewer involved.

The red flag to avoid is staring at the pad without narration. A few seconds of silence is fine, but if I need time I should say: "Let me think for ten seconds about the ownership and boundary cases."

The main red flags are all avoidable.

• Do not claim I have shipped a Linux NIC driver. Say I have studied and traced the concepts, and I am ramping from production embedded C and hardware/software debugging.
• Do not imply wireless PHY is basically Ethernet. Say the protocol surface differs, but timing, buffers, ownership, hardware state and low-level C judgement transfer.
• Do not blame MediaTek or sound like I am escaping my current role.
• Do not lead with remote work, benefits, or compensation before fit is established. Compensation can be clear without dominating the call.
• Do not use buzzwords like AI networking, RDMA, RoCE, or kernel bypass unless I can explain the engineering tradeoff behind them.
• Do not hide uncertainty. If I do not know an API or detail, I should name what I know, name the gap, and reason from first principles.
• Do not ramble through every project on the CV. Pick the project that answers the question.

My safest pattern is: precise claim, concrete evidence, honest boundary. For example: "I have not shipped that driver code, but I have studied the RX/TX path and can reason about descriptor ownership, DMA visibility and NAPI polling. The shipped experience I bring is production RTOS firmware, UL-DAI ownership, and hardware-facing debug across DSP, MCU and RF boundaries."

The thank-you should match the stage.

After the recruiter call, keep it administrative and momentum-focused: thank Graham, confirm interest, confirm availability, and ask for the next-stage format.

After the hiring-manager call, make it technical but short. Mention one specific discussion point and reinforce the honest bridge: production embedded C and hardware/software debugging now being applied to NIC/networking software, while ramping on Linux Ethernet driver details.

After an engineer screen, do not relitigate answers unless there is a clear correction worth making. If I made a small mistake, I can write one sentence: "I also checked the point we discussed about DMA-visible descriptor ordering; my corrected understanding is that the descriptor contents must be visible before ringing the doorbell." Then stop. A follow-up should not look like a second interview by email.

A good engineer-screen follow-up would be:

"Thank you for the discussion today. I appreciated the packet-path and C details, especially the focus on ownership, bounds checks and hardware-visible ordering. The conversation reinforced that this is the kind of low-level networking work I want to move into. Please let me know if there is anything else useful from my side before the next stage."

Do not mention salary in engineer thank-yous. Keep compensation with Graham unless the hiring team raises it directly.