AMD Interview Guide (2026)

1Snapshot, read this first#

2Getting the call (the part most guides skip)#

AMD hires through three main doors. Pick the one with the highest yield for your situation.

• Campus recruiting. Strong at IITs, NITs, IIITs, BITS, and top VLSI-focused programs.
• Referrals. The single highest-yield path for experienced folks.
• Online applications. Through the careers portal, lowest yield but always open.

A VLSI-flavored degree moves the needle for hardware. A relevant M.Tech or MS in VLSI, microelectronics, or embedded systems raises your shortlist odds.

• The design and DV reqs often list it as preferred, and the keyword filters weight it.
• If you have it, put the specialization in your headline, not buried in an education block on page two.

Referrals route your resume to a human with context attached. That skips the pure keyword filter and lands you in a recruiter's queue.

• Ask to be referred to the specific req ID, not a generic "I applied."
• Give your referrer two lines they can paste: the exact team, and the one project that maps to that team's work.
• Example paste line for a CPU-core DV req: "built a UVM testbench for a UART controller, hit 100% functional coverage, want the CPU DV req 12345."
• A vague referral is almost as weak as none, because the recruiter still cannot tell which pile you go in.

Resume rules: one or two pages, every project led with impact and scale. A bullet with no number should be found a number or cut.

• Weak bullet, could be anyone: "Worked on UART verification."
• Strong bullet, below, has a methodology (UVM), a quantity (40+ tests), an outcome (100% coverage), and a stakes marker (before tape-out).

Built a UVM testbench for a UART controller, wrote 40+ constrained-random tests, and closed 100% functional coverage, catching 6 RTL bugs before tape-out signoff.

• Hardware reviewers scan for: coverage %, clock frequency, area reduction, bug count, latency, throughput.
• Software reviewers want the same shape: "reduced driver init latency 35%," "cut kernel memory footprint by 12 MB."
• A resume of ten vague bullets loses to a resume of four sharp ones.

ATS keywords, use only what is true. Every term on the page is a question the interviewer is allowed to ask.

• Hardware: Verilog, SystemVerilog, UVM, RTL, synthesis, STA, timing closure, CDC, DFT/scan/ATPG, low power, place-and-route.
• Software: C, C++, Python, Linux kernel, device drivers, firmware, GPU, OpenCL/HIP/ROCm, assembly, Git, debugging.
• Put the ones that match the req in the top third of page one, where a 10-second scan lands.
• Do not keyword-stuff things you cannot defend.

3The loop at a glance#

Not everyone gets all rounds, and the shape bends by level.

• Campus loops compress into a day or two and may fold fundamentals and domain into one longer session.
• Experienced loops add a round or two and go deeper on architecture and ownership.
• Expect at least one round that is purely "walk me through a project you built and defend every decision."
• The fundamentals rounds filter you in. The project defense round is what the panel actually argues about in the debrief.

4The coding / technical rounds, patterns not problems#

AMD reuses a predictable set of topic patterns. Master the pattern and the specific problem on the day barely matters.

For hardware (RTL/DV) candidates, the patterns cluster into four buckets.

• Digital logic from first principles. FSM design (Moore vs Mealy, and when each saves a cycle), setup/hold time, metastability, clock domain crossing (two-flop synchronizer, FIFO depth sizing from the rate mismatch), reset strategies (sync vs async, and async-assert sync-deassert), gray code and why it matters for pointers across clocks, latch vs flip-flop.
• Combinational and sequential puzzles. Detect a sequence (1011 with overlap), a clock divider by an odd number like 3 with 50% duty, a glitch-free mux, a counter with specific wrap behavior. They ask you to draw the state diagram and then write the Verilog, so practice both. The odd-divide-with-50%-duty is a classic trap: the naive answer gives an unequal duty cycle, and they want to see you catch it.
• CMOS and basics. Pull-up and pull-down networks, propagation delay, power split into dynamic vs leakage, and why a timing path closes or fails (which term in setup = Tclk - Tcq - Tcomb - Tsetup + Tskew went wrong). Name the fix for each term: shorten Tcomb by restructuring logic, or borrow from Tskew with useful skew.
• Number systems and C overlap. Fixed-point, two's complement, bit manipulation (count set bits, reverse bits, swap two numbers without a temp).

For software (driver/firmware/SWE) candidates, three buckets.

• C/C++ depth. Pointers and pointer arithmetic, struct memory layout and padding, volatile (a register read needs it, or the compiler caches the value and you read a stale register), const, memory alignment, endianness, stack vs heap, what malloc/free actually do under the hood, and classic undefined behavior like signed overflow or use-after-free.
• DSA at medium level. Arrays, strings, hash maps, linked lists, trees, two pointers, sliding window, basic DP. Not LeetCode-hard competitive stuff. Correctness and clean code matter more than exotic tricks.
• OS and systems. Processes vs threads, scheduling, virtual memory and paging, interrupts, DMA, cache coherence (MESI at a conceptual level), and synchronization (mutex, spinlock, semaphore, and when a spinlock is wrong because you might sleep while holding it).

Difficulty is mostly easy-to-medium, weighted toward understanding over cleverness.

• A CDC question answered well, where you reason about metastability and FIFO depth, beats a hard DP solved sloppily.
• They are checking whether you write code that is correct at 3am during a bring-up, not whether you win contests.
• The bar is "would I trust this person to not corrupt the register map," not "can this person golf a solution."

How to practice: build, do not just read.

• Hardware: write and simulate real Verilog (EDA Playground or Icarus Verilog). You catch your own reset and latch bugs in simulation, which is exactly the reflex they want.
• Software: do ~100 medium DSA problems plus deep C exercises: your own memory pool, a ring buffer, a simple allocator.
• A ring buffer forces you to get wrap-around and the full-versus-empty ambiguity right, which is the same reasoning as a hardware FIFO.

How to win the round, in order:

1. Clarify. Ask about clock, reset type, input constraints, and edge cases before writing anything. For software, confirm input size, whether input is sorted, and what to do on empty or malformed input.
2. Communicate. Narrate your approach out loud. Interviewers score your reasoning, not just the final answer. A silent candidate who gets the right answer often scores below a thinking-out-loud candidate who gets 90%.
3. Complexity / timing. State time and space complexity for software; state your critical path and whether timing closes for hardware.
4. Test. Walk a concrete example through your logic. For RTL, sanity-check reset behavior and one normal cycle, then one corner (back-to-back transactions or full/empty).

5Domain round and CS fundamentals (track-specific)#

This round separates "took the class" from "can engineer." Pick the block that matches your track and go deep.

RTL Design.

• Pipelining and hazards (structural, data, control, and how forwarding or stalling fixes each).
• FIFO design and depth sizing; arbiter design (round-robin, priority, and the fairness vs latency trade).
• Low-power techniques: clock gating, with the savings coming from killing the clock toggle on idle flops so you stop paying dynamic power.
• AMBA basics: AXI/AHB handshake, VALID/READY, and what causes a deadlock.
• Structural vs behavioral coding.
• Expect "design this block, then I'll add a constraint," where the constraint (back-to-back writes or a stall) breaks your first design and you adapt live.

Design Verification.

• The UVM component hierarchy (driver, monitor, sequencer, scoreboard, agent, env, and how a sequence item flows through it).
• Constrained-random vs directed testing and when each pays off.
• Functional coverage vs code coverage, and why 100% code coverage still misses bugs: code coverage only proves lines ran, not that the interesting input combinations hit them.
• Assertions (SVA, immediate vs concurrent), and how you would verify a given spec from scratch.
• "How would you achieve coverage closure on X?" is a staple. Real answer: build the coverage model, run many random seeds, then write directed tests aimed at the holes the random run never reached.

Physical Design / STA.

• Setup and hold analysis, clock tree synthesis and skew, slack, timing paths (reg-to-reg, input-to-reg, reg-to-output), IR drop, congestion, floorplanning trade-offs.
• Read a timing report and fix a negative-slack path: upsize cells, restructure logic, add a pipeline stage, or adjust placement.
• Say which fix you reach for first and why: adding a pipeline stage changes behavior, while upsizing a cell does not.

DFT.

• Scan insertion and stitching, ATPG, fault models (stuck-at, and conceptually transition and bridging), boundary scan/JTAG, MBIST for memories, and what drives test coverage numbers.

Software / Driver / Firmware.

• OS. Scheduling, memory management, IPC, interrupts and the top-half/bottom-half split, where the top half acknowledges fast and defers the real work.
• Architecture. Pipelines, caches, memory hierarchy, coherence.
• C/systems. Drivers talking to hardware registers over MMIO, DMA setup and the cache-coherency gotchas when the device writes memory the CPU has cached, concurrency.
• Debugging. Root-cause a kernel panic from a stack trace, or a GPU hang from the last submitted command.
• For GPU/compute roles: parallelism, memory models (host vs device, coalescing), and the ROCm/HIP stack if it is on your resume. Only put it there if you can talk about kernels and memory movement.

6Behavioral and culture fit#

AMD's culture centers on a short set of values: execution, innovation, and a strong team-first "we" mindset, backed by a public commitment to inclusion and integrity. The team-first part is not fluff here.

• A chip ships only when design, verification, physical design, and software all land together.
• The behavioral round probes whether you own your work end to end, collaborate across those teams, and push through hard problems without blaming the next team over.
• The interviewer listens for "I" on the work you did and "we" on the outcome, and for whether you escalated a cross-team problem or sat on it.

Write 5-6 STAR stories in advance, each with a number attached.

• A hard bug you found, a conflict you resolved, a deadline you hit under pressure, a time you took initiative, a failure you learned from, and your proudest technical win.
• A story that ends "and it worked" is forgettable. One that ends "closed timing at 220 MHz, 10% over target" sticks.

One full worked STAR example:

• Situation: During my final-year project, our RISC-V core failed timing at the target 200 MHz after synthesis, with a critical path of -0.6 ns slack through the ALU.
• Task: I owned timing closure and had two weeks before the demo.
• Action: I profiled the path, found the multiplier was combinational and dominating delay, and pipelined it into two stages. I then re-balanced the forwarding logic and re-ran synthesis, checking that I had not introduced new hazards by adding a stall in the hazard unit.
• Result: The core closed timing at 220 MHz (10% above target) with no functional regressions across our 50-test suite, and we demoed on the FPGA on schedule.

Notice the structure. One clear owner (I, not we), concrete actions with a real technical decision, and a measurable result.

• That is exactly the shape AMD interviewers want.
• If your draft uses "we" everywhere, rewrite until your specific contribution is unambiguous.
• The panel's job in the debrief is to decide what you personally can do.

7Your prep plan#

4-week plan.

• Week 1: Lock your track. Rebuild fundamentals: digital logic plus CMOS (hardware) or C plus OS plus architecture (software). Re-read your own resume projects until you can defend every line to the transistor or syscall level.
• Week 2: Domain deep-dive. DV folks live in UVM and build a small testbench end to end; RTL folks design and simulate 10 classic blocks (FIFO, arbiter, sequence detector, clock divider, synchronizer); SWE folks do 40 medium DSA plus deep C exercises (ring buffer, allocator).
• Week 3: Mock interviews. Solve problems out loud, on a whiteboard or shared doc. For hardware, write synthesizable Verilog under a 30-minute timer and simulate it. For software, do timed coding with someone watching.
• Week 4: Behavioral STAR stories, comp research, company and product reading (know what AMD builds: Ryzen and EPYC CPUs, Radeon and Instinct GPUs, adaptive SoCs from the Xilinx side), and light review to stay sharp without burning out.

2-week plan.

• Days 1-5: Fundamentals plus one domain pass (CDC, FSMs, timing, or OS, C, DSA core).
• Days 6-10: Domain depth plus 30-40 practice problems or 8 RTL designs simulated, not just written.
• Days 11-14: 3 mocks, STAR stories, resume defense out loud, comp prep.

2-day crash plan.

• Day 1: Fundamentals rapid review (setup/hold, metastability, CDC, FSM, or processes, virtual memory, pointers), plus re-derive the 5 most common blocks or problems for your track from a blank page.
• Day 2: Re-read every project on your resume and prepare to defend it; write 4 STAR stories; do 5 warm-up problems the morning of so your hands are warm when the real one starts.

8Why people get rejected at AMD#

1. Shallow fundamentals. Can quote "CDC" but cannot size a FIFO from the clock-rate mismatch or draw a two-flop synchronizer. Hardware rejections are overwhelmingly about weak basics, not a missing advanced trick.
2. Can't defend their own resume. Listed UVM or a Linux driver, then freezes when asked to explain the architecture they supposedly built. The single fastest way to lose the room, because it reads as dishonesty even when it is just rust.
3. Buzzword-driven answers. Naming tools and frameworks (AXI, ROCm, UVM) without showing you understand what is underneath. The next question is always "okay, how does it work," and that is where the buzzword candidate goes quiet.
4. Messy code in the coding round. Memory leaks, no edge-case handling, no testing. A clean 90% beats a buggy 100% here.
5. No structured communication. Jumping to code without clarifying the spec, or going silent for five minutes while thinking. Silence reads as "stuck," so narrate even when you are unsure.
6. Wrong-track preparation. Generic DSA for a DV role, or VLSI theory for a driver role. The interviewers come from that exact team and will spend the whole hour in their own domain.

Shallow is the number one rejection reason here. Pick one domain and go deep enough to derive it from a blank page.

9The offer, comp and negotiation#

AMD comp has three parts.

• Base salary.
• RSUs, vesting over roughly 3-4 years.
• Annual bonus, tied to company and individual performance.

The numbers, by region and level.

• India, entry: total comp commonly lands ~₹18-32 LPA, with specialized DV/PD and strong masters at the higher end.
• India, mid: ~₹35-70 LPA depending on track and years.
• US, new grad: total ~$150k-210k (base $120k-160k plus RSU and bonus).
• US, senior IC: base $180k-250k+ once RSUs are meaningful.

Negotiation tips.

1. Negotiate total comp, not just base. RSUs and sign-on bonus are often where the room is, especially in the US. Ask for the full breakdown (base, target bonus %, RSU value and vest schedule) before you react to the headline number. A lower base with a bigger RSU grant can beat a higher base with none.
2. Use competing offers factually. A real competing offer, even from another semiconductor firm, is the strongest lever. State it calmly with the number. Do not bluff: recruiters in this space talk, and a called bluff tanks your credibility.
3. Anchor on your scarcity. Specialized skills (PD/STA, advanced DV, GPU driver/compiler experience) are genuinely hard to hire. Lean on that rather than "I worked hard." When you can, let the recruiter name a number first, then negotiate up.

10FAQ#

Q: Do I need VLSI experience for hardware roles? A: For design/DV/PD roles, yes: strong digital logic plus either coursework, projects, or internships in RTL/verification. A VLSI-focused M.Tech/MS helps a lot, but a serious FPGA/RTL project portfolio you can defend end to end can substitute. One simulated, debugged core or controller you built beats a degree you cannot talk about.

Q: Is LeetCode-hard required for AMD software roles? A: Rarely. Expect easy-to-medium DSA with heavy emphasis on C, systems, and OS depth. Clean, correct, well-tested code beats exotic one-liners, because the job is debugging real hardware, not winning contests.

Q: How much do they focus on my projects? A: A lot. Assume at least one full round is "defend every decision in your project." Only put things on your resume you can explain to the transistor or syscall level, and be ready for "why did you do it that way and not the other way."

Q: Hardware vs software, which pays more? A: They are broadly comparable. Comp tracks seniority and specialization more than hardware vs software. Scarce skills (PD, advanced DV, GPU/compiler SWE) command premiums on either side.

Q: How should I prepare for the behavioral round? A: Write 5-6 STAR stories with numbers, emphasizing ownership and cross-team collaboration. AMD values team-first execution, so show how you worked with design, verification, and software peers to ship something, not just solo heroics.

Want this turned into a personalized, dated study plan around your exact track and interview date? Tell me your timeline and I'll map these weeks onto real calendar days for you.