AMD runs a resume-and-project-centric loop rather than a heavy algorithmic gauntlet: a recruiter or manager screen followed by two to five technical conversations that live mostly inside whatever the candidate claims on their CV. Hardware and verification candidates get digital-design fundamentals, Verilog/SystemVerilog, timing and protocol questions plus a deep tour of their own project; software, firmware and kernel candidates get C, Linux internals, computer architecture and one or two moderate coding problems. India campus and lateral hiring (Bengaluru/Hyderabad) dominate the public writeups, with a smaller stream of US intern accounts.
These 8 writeups cover design verification, digital design, silicon design and other roles, India-heavy, some US (Austin). 5 of them were posted under a pseudonym (Reddit, GeeksforGeeks or forum handles), so we could not verify the authors’ identities.
Typical rounds
2.51-5 range
Outcomes shared
3/1offer / not
Most common round
Technical
Sources span
2021 - 2025
Most frequently reported · Behavioral(4), Concurrency(4), Operating systems(4), Past projects(4), Arrays & strings(3)
AMD’s official process
AMD's own student-programs FAQ describes a short pipeline: recruiters review each application, contact matching candidates for a screening call, and then move them to a meeting with the hiring team before an offer. It says interviews are framed around the candidate's own skills and experience rather than a fixed question set, that no specific interview feedback is given, and that candidates can track status in their candidate profile. A separate FAQ item asks candidates not to use AI to generate or read answers during live interviews.
No test was administered: AMD screened the whole eligible M.Tech batch on resume alone and invited a small fraction to interview.
Covered · Resume deep-dive
2
Technical interviewTechnical
The interviewer walked through the candidate's machine-learning project layer by layer, then switched to a short C snippet with a deliberate memory-allocation mistake and two small scripting exercises.
Covered · Past projects, Deep learning, Pointers, Python, Recursion
3
Second technical interviewTechnical
A second interviewer joined immediately after the first and probed project conclusions and future work, everyday Linux troubleshooting commands, and C fundamentals such as storage classes and sizing a type without sizeof.
Covered · Past projects, Linux commands, Data structures & algorithms, Arrays & strings, Operating systems
A single hour-long manager conversation split roughly into resume and motivation questions, a block of language and OOP theory (abstract classes vs interfaces, synchronization, garbage collection, generators), and one short coding problem where the expected answer was parallelising the scan rather than a clever sequential trick.
A broad fundamentals sweep: universal gates and mux-based gate realisation, divide-by-two clocking, gray code conversion, latch versus flip-flop timing, Mealy versus Moore, and an FSM for a sequence detector, followed by Verilog modelling styles and serial-bus protocol knowledge, ending on C memory and bitwise questions.
Covered · Digital design, Finite state machines, Verilog, Embedded protocols, Pointers
After a project walkthrough the interviewer asked for an efficient mid-list insertion on a linked list, then spent the rest of the round on operating-system internals: threads versus processes, protecting shared resources, virtual versus physical addressing, address translation, caches and the boot sequence.
Covered · Past projects, Data structures & algorithms, Concurrency, Operating systems, Computer architecture
A short call built entirely around bit-level manipulation: conditionally reading and setting individual bits, and reversing byte order with bitwise operators and unions.
Covered · Bit manipulation, Endianness, Pointers
2
Embedded systems technicalTechnical
Covered ARM TrustZone and pipelining, memory protection, symmetric versus asymmetric cryptography, debug levels, how a program runs on a limited register file, and per-task stack supervision.
Covered · ARM architecture, Security, Debugging, Concurrency, Operating systems
3
RTOS and hardware interface technicalTechnical
Focused on runtime health of an embedded system: detecting and monitoring stack overflow and stack usage, what is specified when a task is created, the role of debuggers, cache memory, and how ADC resolution is chosen.
Why startup code is written in assembly, the startup sequence flow, what state is saved on switching to an interrupt stack, plus one small programming exercise on finding the most repeated number.
A 90-minute virtual screen mixing multiple-choice questions with code snippets at basic to medium difficulty, plus a hard string-matching problem.
Covered · Data structures & algorithms, Dynamic programming, Debugging
2
Technical interviewTechnical
A 45-minute live round with one tree problem (lowest common ancestor) followed by systems theory: locks and semaphores, sketching a producer-consumer design, and Linux kernel specifics such as the user-to-kernel transition and module init/exit.
Covered · Trees, Concurrency, Operating systems, Linux internals
3
Hiring manager roundHiring manager
A 30-minute closing conversation with the hiring manager on motivation for switching, team impact and five-year plans, with a classic water-jug measuring puzzle dropped in.
A ten to fifteen minute call covering academic background, why VLSI, prior Verilog/SystemVerilog exposure and industry-oriented training.
Covered · Resume deep-dive, Past projects, Verilog
2
Core digital electronicsTechnical
Fundamentals block inside a 40-45 minute technical interview: blocking versus non-blocking assignments, metastability and synchronisers, setup and hold violations, synchronous versus asynchronous FIFOs, and what STA actually checks.
Covered · Verilog, Metastability, Static timing analysis, Digital design
3
Resume project deep-diveTechnical
A walkthrough of the candidate's UVM router verification and AHB-to-APB bridge work, including how coverage closure was reached and which simulators and lint tools were used.
Covered · Past projects, UVM, Functional coverage, EDA tools
4
Advanced verification conceptsTechnical
Design-and-discuss questions on building a constrained-random testbench for a FIFO, FPGA versus ASIC implementation trade-offs, RTL optimisation ahead of synthesis, the RTL-to-GDSII flow, and debugging large UVM environments.
Covered · Constrained random verification, FPGA vs ASIC, RTL synthesis, Debugging
5
HR discussionBehavioral
Motivation for the semiconductor industry, the effect of external training and an internship, and how the candidate balanced academics with mentoring work.
Received an offerBase: 18 LPA; Relocation/Signing Bonus: 5L; Stock bonus: 33K USD vested over 4 yrs; Total comp: 30.5 LPA (for 1st year)2 rounds
1
Rounds 1-4: Technical interviewsTechnical
The candidate reported four technical rounds for a CPU design role after roughly three years at a product company, but did not describe the content of each round.
Covered · Digital design, Past projects
2
Managerial roundHiring manager
A closing managerial conversation completed the five-round loop before the offer.
AMD runs a resume-and-project-centric loop rather than a heavy algorithmic gauntlet: a recruiter or manager screen followed by two to five technical conversations that live mostly inside whatever the candidate claims on their CV. Hardware and verification candidates get digital-design fundamentals, Verilog/SystemVerilog, timing and protocol questions plus a deep tour of their own project; software, firmware and kernel candidates get C, Linux internals, computer architecture and one or two moderate coding problems. India campus and lateral hiring (Bengaluru/Hyderabad) dominate the public writeups, with a smaller stream of US intern accounts.
What topics does AMD test in interviews?
Commonly reported topics include Past projects, Resume deep-dive, Digital design, Verilog, SystemVerilog, UVM.
These guides summarize public, first-hand interview experiences shared by candidates. They describe the shape of each loop and the topics that came up, not a leaked question bank, and every experience links back to its original source. Processes change often; treat this as directional prep, not a script.