Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About AMD hiring for Playwright Testing roles
AMD is an American semiconductor company that designs CPUs, GPUs, adaptive chips and data centre accelerators, including Ryzen, EPYC, Radeon and Instinct products. It acquired Xilinx, adding FPGA and adaptive computing products. In India it has large design centres that hire chip design, verification, physical design, software and firmware engineers.
For Playwright Testing roles, this AMD practice set focuses most on JavaScript and TypeScript (7), API Testing (6), Framework Design and CI/CD (5), Locators and Assertions (5). It has 1 easy, 29 medium, 10 hard questions, so you can start easy and work up to the harder ones.
Company type
Hardware & semiconductors
Headquarters
Santa Clara, California, USA
Main India offices
Bengaluru, Hyderabad
AMD Playwright Testing interview process
Online assessment or resume screening
Technical round 1 (digital design or programming)
Technical round 2 (domain depth)
Hiring manager round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for AMDStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
How do you assert that a request was sent with the correct payload?
Load a .env file with a package like dotenv in playwright.config, then read process.env.BASE_URL. Values are string | undefined, so validate them early and throw a clear error if a required one is missing. Keep .env out of git and commit an .env.example instead. In CI, set the same names as secret variables.
testInfo is passed as the second argument to tests and hooks. It gives the test title, project name, retry number, status and output path. You can attach files, add annotations, change the timeout with testInfo.setTimeout, or skip conditionally. For example, attach extra logs only when testInfo.status differs from testInfo.expectedStatus.
06
How do test.slow() and longer timeouts help or hurt debugging?
test.slow() triples the timeout for a test that is genuinely long, such as a report export. It is honest and visible in code. But raising timeouts to make a flaky test pass hides the real cause, such as a missing wait or slow backend, and makes failures take longer. Investigate the trace first and change timeouts only with a reason.
07
How do you write data-driven API tests with many inputs?
TypeScript + POM + custom fixtures, environment configs, API helpers for test data, tags like @smoke, sharding across CI machines, retries with traces, HTML/Allure reports, lint and review rules.
10
How do you manage flaky tests without hiding real failures?
Use retries in CI so one-off failures do not block merges, but treat any test marked flaky in the report as a defect. Track flaky tests on a dashboard, quarantine repeat offenders with a tag and an owner, and set a deadline to fix or delete them. Never retry without investigating, or real intermittent bugs will be missed.
11
Write a typed helper that retries an async function a few times.
Use a web-first negative assertion such as await expect(banner).toBeHidden() or not.toBeVisible(); they pass as soon as the element is absent, so they do not wait the full timeout. The real problem is timing: assert after a positive signal, such as the success message appearing, otherwise the banner may simply not have rendered yet and the check passes too early.
13
How do you debug a test in VS Code with the Playwright extension?
Install the Playwright Test for VS Code extension. Open the Testing panel to see tests, then set a breakpoint in the test file and click Debug Test. Execution stops at the breakpoint with the browser open, so you can inspect variables. Turn on Show browser to watch runs, and use Pick locator or Record at cursor to add steps.
14
How do you create test data through the API before a UI test?
In a fixture or beforeEach, call the API (request.post) to create the user or order, use it in the UI test, then delete it in teardown. It is faster and more reliable than creating data through the UI.
15
How do you verify a page's URL and title after navigation?
await page.getByRole('link', { name: 'Orders' }).click();
await expect(page).toHaveURL(/\/orders$/);
await expect(page).toHaveTitle('My Orders | Shop');
// both retry, so no need to wait for navigation manually
16
How do you keep test code, page objects and utilities organised as a repository grows?
Use a clear layout: tests grouped by feature, a pages folder for page objects, a fixtures folder that exposes them, and api and data folders for helpers and builders. Add path aliases in tsconfig, a lint config with the Playwright plugin, and a short contributing guide. Review new helpers in pull requests so duplicate utilities do not spread.
17
Write a test that updates a user with PUT and verifies the change.
Destructuring pulls values from arrays or objects into variables; spread expands an array or object into another, useful for copying and merging config.
19
A test checks a price that is formatted differently per locale. How do you make the assertion robust?
Fix the locale for the test with the locale and timezoneId options so the format is predictable. Build the expected string with Intl.NumberFormat using the same locale, rather than hard-coding it. If you test several locales, run them as projects or parameterised tests. For business logic, also assert the raw number through the API response.
Chain locators: find the container first, then search inside it. Example: page.getByRole('row', { name: 'INV-104' }).getByRole('button', { name: 'Download' }). Each step narrows the search area, so short names like Edit or Download stay unique. Chaining also documents intent clearly and avoids long CSS paths that break when markup changes.
22
How would you design API test coverage for a new endpoint?
The test code runs in Node while the component runs in the browser. When you write mount(<Button title='Save' />), Playwright serialises the JSX and props and rebuilds them in the browser bundle. So props must be plain data such as strings, numbers, arrays and objects, plus callbacks, which Playwright proxies back to Node. Class instances, complex objects or live references cannot cross that boundary directly.
A fixture defined with { auto: true } runs for every test even when the test does not ask for it. It is useful for cross-cutting work such as attaching console logs on failure, setting a feature flag or checking for leftover data. Keep auto fixtures light, because they add cost to every test in the suite.
Run it alone with --project=webkit --headed and record a trace. Compare it with the Chromium trace to see where behaviour differs, such as date input format, scrolling, font rendering or a missing browser API. Check the app's support matrix. If it is a real product bug, raise it, and skip the test for WebKit with a linked ticket until it is fixed.
27
Write a custom fixture that gives a logged-in page.
const texts = await page.getByTestId('price').allTextContents();
const prices = texts.map(t => Number(t.replace(/[^0-9.]/g, '')));
const sorted = [...prices].sort((a, b) => a - b);
expect(prices).toEqual(sorted);
// wait for the list first with toHaveCount
Turn on trace: 'on-first-retry', open the trace viewer, check network and timing, replace hard waits with web-first assertions, isolate test data and check for sharding conflicts.
readonly and as const stop test data from being changed by accident, for example one test editing a shared user object and breaking the next. as const also keeps literal types, so ['admin', 'viewer'] as const gives the type 'admin' | 'viewer'. That lets TypeScript reject invalid roles at compile time instead of during a run.
32
A product list uses infinite scroll. How do you test that more items load?
Count the items, then scroll the last item into view with lastItem.scrollIntoViewIfNeeded() or page.mouse.wheel. Assert with expect(items).toHaveCount greater than before, for example using expect.poll on items.count(). Repeat until an end-of-list message appears. Also check no duplicates appear and that a loading indicator shows while fetching.
33
How do you test a dropdown component's keyboard support in a component test?
Mount the dropdown, focus the trigger and press Enter or ArrowDown to open it. Assert the listbox is visible and the first option has aria-selected or focus. Press ArrowDown again and check the active option moves, then press Enter and assert the trigger shows the chosen value and the list is closed. Finally press Escape on an open list to confirm it closes without changing the value.
Situation: many inputs had no labels, so our tests relied on long CSS selectors that broke often. Task: get stable hooks without slowing developers. Action: I listed the worst screens, showed how getByLabel tests read and how the same labels help screen reader users, and offered to raise small pull requests myself. Result: the team added labels to new work as a rule and locator breakages dropped sharply.
37
How do you rerun only the tests that failed in a sharded CI run?
--last-failed works only on the machine that kept the .last-run.json file, so it does not help across shards. Instead collect the failed tests from the merged JSON report or the blob reports, then run them in a follow-up job by file and line or with --grep on their titles. Many teams simply rely on retries and treat any test needing a rerun as flaky.
38
Component tests fail because imports like @/utils cannot be resolved, though the app builds fine. How do you fix it?
The app uses a bundler alias that the component test bundle does not know. Add the same alias in ctViteConfig under resolve.alias, or reuse the project's Vite config by importing it. Also make sure tsconfig paths match, so editors and type checks agree. After that, clear the cache folder that the component bundler writes under playwright/.cache so the bundle rebuilds.
Use page.waitForResponse(res => res.url().includes('/api/orders') && res.ok()) together with the action that triggers it.
Tips to crack the AMD Playwright Testing interview
Revise digital electronics, computer architecture, Verilog and verification basics for silicon roles, with clear explanations of timing concepts.
For software and driver roles, revise C, C++, operating systems and parallel computing basics, including GPU programming concepts.
Prepare detailed explanations of VLSI or embedded projects, including tools used, problems faced and how you solved them.
Keep a one-minute story ready for every project on your CV: problem, your part, tools, result.
Practise the hard questions on this page aloud; AMD interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the AMD Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment or resume screening; Technical round 1 (digital design or programming); Technical round 2 (domain depth); Hiring manager round. The exact rounds change with the role, team, location and your experience, so confirm the process with the recruiter.
Which topics should I prepare for the AMD Playwright Testing interview?
This practice set leans on JavaScript and TypeScript (7), API Testing (6), Framework Design and CI/CD (5), Locators and Assertions (5). Revise those first, then practise explaining one or two of your own projects end to end, because most AMD interviewers ask you to walk through real work.
Are these the exact questions asked at AMD?
No. These are curated practice questions that match the skills and difficulty usually tested in hardware & semiconductors interviews like AMD's. They are not a leaked or verified list of past questions.
Where does AMD hire Playwright Testing professionals in India?
AMD has large teams in Bengaluru, Hyderabad. Openings and locations change often, so check the AMD careers page and filter by city and experience.
Playwright Testing questions for similar companies