Generative AI Interview Questions You Must Know in 2026
Generative AI interview questions are becoming more complex in 2026 as companies expect deep understanding of GANs, LLMs, Transformers, and multimodal AI systems.
If you’re preparing for AI, ML, or GenAI roles in 2026, this guide is essential.
Interviewers now test not just definitions, but your understanding of why models work, when they fail, and how they scale in production.
This article covers Generative Models, GANs, VAEs, Transformers, LLMs, Multimodal AI, Embeddings, and real-world training challenges — written for Google Discover readers and serious candidates.
Why Generative AI Interviews Are Getting Harder in 2026
Generative AI has moved from research to production. Companies now expect engineers to understand:
Training instability and failure modes
Long-context limitations
Hallucination risks
Model alignment and safety
System-level trade-offs
That’s why interview questions now focus on conceptual depth + practical reasoning.
Generative vs Discriminative Models
Generative models learn the underlying data distribution and can generate new samples.
Examples include:
Generative Adversarial Networks (GANs)
Variational Autoencoders (VAEs)
Diffusion Models
Large Language Models
Discriminative models focus on learning decision boundaries and classifying data.
Interview tip: If a model can create data, it’s generative. If it only predicts labels, it’s discriminative.
How GANs Work (Explained for Interviews)
A Generative Adversarial Network consists of two competing neural networks:
Generator: Produces fake samples
Discriminator: Distinguishes real from fake
They are trained in a minimax game where the generator improves realism and the discriminator improves detection.
What Is Mode Collapse?
Mode collapse occurs when the generator produces repetitive outputs and fails to capture data diversity.
Common mitigation techniques:
Mini-batch discrimination
Gradient penalties (WGAN-GP)
Spectral normalization
Improved architectures (StyleGAN)
Variational Autoencoders (VAEs)
VAEs encode inputs into a probability distribution rather than a fixed latent vector.
This enables:
Smooth interpolation
Uncertainty estimation
Controlled sampling
Interview insight: VAEs trade sharpness for probabilistic structure.
Conditional Generative Models
Conditional models generate outputs based on additional inputs like labels or attributes.
Examples:
Text-to-image generation
Image-to-image translation
Category-specific generation
They provide better control and are preferred in real-world systems.
Transformers vs RNNs
Transformers solved key RNN limitations:
Sequential processing bottlenecks
Vanishing gradients
Poor long-range dependency handling
Self-attention enables parallelization and global context modeling.
Why Positional Encoding Matters
Self-attention has no inherent notion of order. Positional encoding injects sequence information so meaning is preserved.
Reinforcement Learning from Human Feedback aligns model outputs with human values.
It involves pre-training, human feedback collection, reward modeling, and reinforcement learning.
This is essential for safety, ethics, and high-quality responses.
Multimodal Models
Modern AI systems process text, images, and audio together.
Examples include CLIP, VisualBERT, and DALL·E.
Key challenge: Aligning semantic meaning across different data types.
Embeddings: The Backbone of GenAI Systems
Embeddings are dense vector representations that capture semantic meaning.
Used in:
Semantic search
Recommendations
Retrieval-Augmented Generation (RAG)
Handling Long Contexts in LLMs
Naively increasing context length is computationally expensive.
Effective techniques include:
FlashAttention
Sparse attention
RoPE and ALiBi
Multi-Query Attention
Hallucination in LLMs
Hallucination refers to confident but incorrect outputs.
Mitigation strategies:
Retrieval-Augmented Generation (RAG)
Log-probability analysis
Self-verification techniques
Human-in-the-loop systems
Final Thoughts
This guide is not about memorization.
Strong candidates understand:
Why techniques exist
When they fail
What trade-offs they introduce
That’s what interviewers look for in 2026.
Preparing for Generative AI interview questions requires not just technical knowledge, but also strong preparation discipline.
If you’re struggling to balance learning GANs, LLMs, Transformers, and practice interviews, these
time management tips for students and professionals
will help you plan your study schedule more effectively and reduce last-minute stress.
If you’re preparing for a QA, SDET, or automation-engineering interview — especially one involving modern browser automation — this guide is for you.
We’ve compiled 100 of the most commonly asked Playwright interview questions (from basics to advanced and real-world scenarios), each with a clear answer and, where helpful, code snippets.
Use it to revise, practice, or share with peers.
Section 1: Basics / Introductory Questions
Q1. What is Playwright?
A: Playwright is an open-source browser automation and end-to-end testing framework developed by Microsoft. It enables automation across major browser engines — Chromium, Firefox, and WebKit — via a unified API.
Q2. Which browsers and platforms does Playwright support?
A: Playwright supports Chromium (e.g. Chrome/Edge), Firefox, and WebKit (Safari engine), providing cross-browser coverage. It works on major operating systems — Windows, macOS, and Linux.
Q3. Which programming languages are supported by Playwright?
A: Playwright officially supports JavaScript / TypeScript. There are also community-supported bindings for languages like Python, Java, and .NET (C#), depending on your tech-stack.
Q4. How to install Playwright in a Node.js / JavaScript project?
A: Use npm: npm install -D @playwright/test
Then run: npx playwright install
This installs Playwright and downloads the required browser binaries.
Q5. How do you launch a browser and open a page using Playwright (JS example)?
Q6. What are BrowserContext and Page in Playwright — how are they different?
A:
Browser — the main browser instance (e.g. Chromium).
BrowserContext — an isolated session (its own cookies, storage, cache), useful for parallel independent tests.
Page — a single tab inside a BrowserContext, where you interact (navigate, click, input, etc.).
Q7. What are locators in Playwright? Why prefer them over raw selectors?
A: Locators are Playwright’s recommended API for finding elements on a page. They provide benefits such as auto-waiting (element is visible & actionable before interaction), retry logic, and greater stability — reducing flaky tests compared to raw CSS/XPath selectors.
Q8. How does Playwright handle waiting/synchronization when interacting with page elements?
A: Playwright uses built-in auto-wait: before performing actions (click, fill, etc.), it ensures the target element is visible, enabled, stable and attached to the DOM. For dynamic content or network delays, you can also use explicit waits — e.g. page.waitForSelector() or page.waitForLoadState().
Q9. How do you take a screenshot of a page using Playwright?
This captures the current page — useful for debugging, visual regression, or saving test evidence.
Q10. How to get the page title or current URL using Playwright?
const title = await page.title();
const url = page.url();
Q11. How to click an element using Playwright?
await page.click('selector');
// or
await page.locator('selector').click();
Q12. How to fill input fields in Playwright?
await page.fill('input[name="username"]', 'myUser');
// or with locator
await page.locator('input[name="username"]').fill('myUser');
Q13. Does Playwright rely on WebDriver (like Selenium)?
A: No. Playwright does not use WebDriver; it interacts directly with the browser engines’ internal APIs for faster and more reliable automation.
Q14. What are the advantages of using Playwright over older automation tools?
A: Advantages include built-in cross-browser support, auto-waiting and retry logic, ability to create isolated contexts (parallel tests), headless mode, modern APIs (network interception, multi-context), and a built-in test runner — resulting in faster, stable, more maintainable tests.
Q15. Does Playwright support headless mode? Why is it useful?
A: Yes — headless mode runs without UI. It’s useful for CI/CD pipelines, automated test runs, resource efficiency, and environments without graphical interface.
Q16. What kinds of testing scenarios can Playwright handle?
A: Playwright supports end-to-end UI testing, cross-browser testing, regression testing, headless CI testing, dynamic web apps (SPAs/AJAX), visual regression testing (via screenshots), API + UI integration testing, and responsive/mobile testing.
Q17. On which operating systems can Playwright be used?
A: Playwright is cross-platform — works on Windows, macOS, and Linux.
Q18. What is a configuration file in Playwright and why is it useful?
A: A configuration file (e.g. playwright.config.js / .ts) defines global settings: test directories, timeouts, retries, browser projects, fixtures, reporters, parallel execution — enabling consistent and scalable test suite configuration.
Q19. What test runner and assertion library does Playwright provide or support?
A: Playwright provides its own test runner (via @playwright/test) and a built-in assertion library (e.g. expect()), similar to popular JS testing frameworks — enabling writing tests and assertions seamlessly together.
Q20. How to write a simple Playwright test using the test runner and assertions?
Q21. Why is Playwright popular for modern web automation?
A: Because it supports modern browser engines, offers cross-browser and cross-platform support, includes robust features (auto-wait, isolation, headless mode, network interception, multi-context), has a built-in test runner, and is actively maintained — making it ideal for modern web apps and automation suites.
Q22. What are contexts in Playwright and what advantage do they provide?
A: A BrowserContext provides an isolated session — with its own cookies, localStorage, cache — enabling independent test sessions, test isolation, and simulating multiple users without interference.
Q23. Can Playwright tests be executed in parallel and across multiple browsers?
A: Yes. By configuring multiple browser projects (Chromium, Firefox, WebKit) and enabling parallel workers in config, you can run tests concurrently across browsers — enabling cross-browser coverage and faster execution.
Q24. What are best practices for writing maintainable and scalable Playwright tests?
A: Use stable selectors (e.g. test-ids or role-based), isolate test state, structure code modularly (Page Object Model), use fixtures for setup/teardown, avoid brittle timing (sleep), enable parallel execution carefully, and keep tests focused on user behavior — making the suite maintainable, readable, and stable.
Q25. What is the Page Object Model (POM) and how is it useful with Playwright?
A: The Page Object Model is a design pattern where each page (or logical UI section) is represented as a class or module encapsulating locators and actions. With Playwright, POM helps avoid code duplication, improves readability, maintainability, and scalability — especially for large applications.
Section 2: Intermediate / Common Use-Case Questions
Q26. How to handle dropdowns (select elements) using Playwright?
Q30. How to write API tests or combine UI + API tests using Playwright?
A: Playwright supports HTTP request APIs or a request context — you can make backend API calls (GET/POST), validate responses, then navigate UI and verify that frontend reflects backend state — useful for integration or full-stack flows.
Q31. How to run tests in parallel and across multiple browsers in Playwright?
A: Configure multiple projects (e.g. Chromium, Firefox, WebKit) in config file and enable parallel workers — allowing concurrent test runs across browsers for efficiency and cross-browser coverage.
Q32. How to switch between headless and headed mode in Playwright?
Headed mode opens browser UI, while default headless is without UI — useful depending on environment (e.g. debugging vs CI).
Q33. How to set default timeouts or navigation timeouts globally in Playwright?
A: Use methods like page.setDefaultTimeout(ms) or page.setDefaultNavigationTimeout(ms) (or configure in config file) to define global timeouts for actions and navigation, ensuring tests don’t hang indefinitely.
Q34. How to assert element properties and page state using Playwright’s test runner?
This lets you test how your app behaves on mobile / different screen resolutions.
Q37. How to handle asynchronous or dynamic content loading (e.g. in SPAs / AJAX) under Playwright?
A: Use locator/API auto-wait, explicit waits like page.waitForSelector() or page.waitForLoadState('networkidle'), avoid fixed delays — helps create stable tests in dynamic applications.
Q38. What are some best practices for writing stable, maintainable Playwright tests?
A: Use stable selectors (data-test id / roles), isolate tests (no shared state), structure code modularly (Page Object Model), use fixtures/setup-teardown, avoid brittle waits or sleeps, enable parallel execution carefully — helps avoid flakiness and improves maintainability.
Q39. How to debug a failing Playwright test (inspect, trace, screenshot, headful mode)?
A: Run test in headed mode, use developer tools, capture screenshots, trace or video on failure, log detailed steps — helps identify issues in test flow or environment.
Q40. How to organize test code for a large project — structure, maintainability?
A: Use clear folder structure (e.g. tests/, pages/, utils/, fixtures/), adopt Page Object Model for pages/actions, centralize configuration, keep tests independent — improves readability and scalability for large test suites.
Q41. How to handle browser dialogs (alert, prompt, confirm) in Playwright?
Q44. How to capture screenshots, videos, or traces for debugging and test reports in Playwright?
A: Playwright supports built-in screenshot, video and trace capturing — configure it in your test runner or call the APIs manually — useful for analyzing failures or reviewing test runs.
Q45. How to manage test configuration for different environments (dev/staging/prod) in Playwright?
A: Use environment variables or configuration files for base URLs, credentials, timeouts etc. This allows the same tests to run across multiple environments with minimal changes.
Q46. What is test isolation and how does Playwright support it?
A: Test isolation means that each test runs independently (separate cookies, storage, session) — avoiding interference. Using separate BrowserContexts per test helps achieve this in Playwright.
Q47. How to integrate Playwright tests into CI/CD pipelines?
A: In CI pipeline, install dependencies, install browsers (`npx playwright install –with-deps`), run `npx playwright test`, optionally capture artifacts (screenshots/traces), generate reports — enabling automatic testing on code changes or deployments.
Q48. How to combine API testing and UI testing in same Playwright test flow?
A: Use Playwright’s HTTP request capabilities (or request context) to perform backend API calls, then navigate UI to verify frontend reflects backend state — useful for end-to-end integration tests.
Q49. What are reporters in Playwright and how can you configure them?
A: Reporters define output format (HTML, JSON, JUnit etc.) — configure them in `playwright.config`. After test run, reports are generated for CI dashboards, logs, or review.
Q50. How to handle flaky tests in Playwright and reduce flakiness?
A: Use stable selectors, rely on auto-wait or explicit wait, avoid arbitrary timeouts/sleeps, isolate test data/state, mock external dependencies if possible, use fixtures and keep tests independent — these reduce flakiness significantly.
Section 3: Advanced / Expert-Level Questions
Q51. What is network interception in Playwright and how can you use it?
A: Use page.route() to intercept network requests, mock responses, simulate failures or offline mode — useful for testing edge cases, error flows or offline behavior.
Q52. How to perform visual regression testing or compare screenshots using Playwright?
A: Capture baseline screenshots (page or element), then on subsequent runs take new screenshots and compare using an image-diff tool or custom script — helps detect unintended UI changes/regressions.
Q53. How to reuse login/session state across multiple tests to avoid repeated login?
A: After login, save the storage/state: await context.storageState({ path: 'auth.json' }). Then create new contexts in other tests using that state: browser.newContext({ storageState: 'auth.json' }) — reusing session state across tests.
Q54. How to integrate Playwright tests in CI/CD pipelines (e.g. GitHub Actions, Jenkins)?
A: Typical pipeline steps: install dependencies, install browsers (e.g. npx playwright install --with-deps), run tests (npx playwright test), capture artifacts (screenshots, trace, video) on failures, generate reports — enabling automated testing on code changes or deployment.
Q55. What are fixtures and hooks in Playwright Test runner, and how are they used?
A: Fixtures provide reusable resources for tests (like browser, context, auth state, API clients, test data). Hooks (beforeAll, beforeEach, afterEach, afterAll) allow setup/teardown logic — ensuring consistent environment and cleanup for each test run.
Q56. How to run a subset of tests or filter tests in Playwright?
A: Use test filtering mechanisms (tags/annotations or grep-like filters), or configure projects/command-line options to run only certain tests — useful during development or debugging.
Q57. How to handle parallelism when tests share resources (like database, files)?
A: Avoid shared mutable state, isolate data per test (unique IDs or timestamps), use separate contexts or mock resources, or serialize tests that require shared resources — helps prevent interference and flakiness.
Q58. How to handle timeouts and navigation timing in Playwright?
A: Configure default action/timeouts (like page.setDefaultTimeout()), use navigation/wait options (e.g. page.waitForLoadState('networkidle')), and avoid arbitrary sleeps — improves test stability, especially under slow network or heavy pages.
Q59. How to debug a failing Playwright test (inspect, trace, pause)?
A: Run in headed (non-headless) mode, use browser devtools, enable tracing or video/screenshot capture, log actions — helps inspect DOM, network and environment at failure point to debug effectively.
Q60. How to design test architecture for large applications using Playwright (page objects, modular structure)?
A: Use the Page Object Model (POM), organize code into folders (e.g. pages, tests, utils, fixtures), centralize configuration, keep tests independent — yields maintainable and scalable test suites.
Section 4: Scenario-Based & Edge-Case Questions
Q61. Scenario: You need to test login, then perform several user-actions across multiple pages using the same session. How would you implement this?
A: Use state-reuse approach: log in once, save session/storage state, then create new browser/context sessions in other tests using that saved state — avoids repeated login and maintains continuity across multiple flows.
Q62. Scenario: Upload a file, then verify after upload that the file appears in a list, download it and validate content. How do you automate this flow?
A: Steps — upload using page.setInputFiles(); wait for upload completion or UI update; navigate to download UI; use page.waitForEvent('download'), download.saveAs(...); then verify the file (existence, name, size or content) to confirm correct behavior.
Q63. Scenario: Application is a Single Page App (SPA) with dynamic content (AJAX). Elements appear asynchronously. How to write stable tests?
A: Use locator-based API (auto-wait), explicit waiting (e.g. waitForSelector or waitForLoadState('networkidle')), avoid fixed delays — ensures reliability irrespective of timing or network latency.
Q64. Scenario: On page load a popup/modal (cookie consent, ad) appears — interfering with test. How to handle?
A: Detect popup via locator, wait until it appears, close or dismiss the modal (e.g. click close/“X”) before further actions — ensures test flow isn’t blocked by pop-ups or overlays.
Q65. Scenario: Application opens a payment gateway or external site in new tab — how to manage multi-tab behavior?
A: Use context.waitForEvent('page') with the action that triggers new tab, then switch to the new page, wait for load and perform actions — ensures correct flow across tabs/windows.
Q66. Scenario: Need to test responsive design / mobile + desktop layout in same suite. How to structure tests?
A: Use viewport & device emulation (via context config or device descriptors) for mobile, and default or desktop settings for desktop — run tests accordingly to verify responsiveness across viewports.
Q67. Scenario: Combine API + UI testing — create data via API then verify through UI. How to implement with Playwright?
A: Use Playwright’s HTTP request capabilities or request context to call backend API (create data), then navigate UI in same test and assert that UI reflects backend changes — useful for full-stack integration testing.
Q68. Scenario: Tests are flaky due to network instability or slow resource loading (e.g. images, third-party scripts). What strategies?
A: Use network interception to block or mock heavy or unreliable resources, rely on explicit waits for core elements, mock external dependencies, use retries where appropriate — improves test reliability.
Q69. Scenario: Running tests in CI/CD with parallel execution and report generation — how to configure?
A: In test config enable parallel workers and multiple browser/projects; in pipeline install browsers, run tests, capture artifacts (screenshots, trace, logs), generate reports; define pass/fail criteria — ensures automated, consistent test runs on commits or deployments.
Q70. Scenario: Site supports dark mode / light mode — you need to test both. How to write tests?
A: Parameterize theme setting (dark/light), switch mode via UI or configuration in test setup, then run same assertions for both modes — ensures UI and functionality works correctly in both themes.
Q71. Scenario: File download returns a dynamically generated filename — need to verify content without knowing filename beforehand. How to handle?
A: Use page.waitForEvent('download'), then inspect download.suggestedFilename() or download.path() to get the actual file name or path; save and then validate file content (size, checksum, content) — ensures correct download behavior.
Q72. Scenario: UI has animations or transitions that interfere with clicks or assertions. How to avoid flaky behavior?
A: Use locator’s auto-wait/stability check, or explicit wait for element to be stable or visible, wait for transition/animation end before interactions — avoids timing-based failures.
Q73. Scenario: Application supports multiple locales / languages — need to test UI across locales. How to automate locale-based tests?
A: Parameterize locale settings (via config or test data), run tests per locale, assert UI strings/text, formatting (date/time/currency), layout — ensures localization is validated.
Q74. Scenario: App uses dynamic frameworks (React/Vue), DOM changes often, class names are unstable — how to write robust selectors?
A: Prefer stable attributes like data-testid, ARIA-roles, text-based or role-based selectors instead of relying on classes or indexes — makes tests resilient to DOM changes and refactoring.
Q75. Scenario: Need to perform performance testing (page load times, network calls) as part of automation. Can Playwright help?
A: Yes — using Playwright you can record performance metrics, intercept network requests, measure load times, resource usage during tests — helps integrate performance checks into automated test flows.
Q76. Scenario: Simulate offline or degraded network conditions — test offline handling / fallback behavior. How to implement?
A: Use network interception or throttling (simulate offline or slow network), mock or block network requests where needed, and test application behavior (error messages, retries, UI fallbacks) under those conditions.
Q77. Scenario: Automating a multi-step form with data persistence across steps (and back/forward navigation) — how to ensure reliability?
A: Automate each step sequentially, after each step assert UI/data correctness, on navigation back assert persisted data, use isolated context per test run — ensures consistent results and avoids state bleed-over.
Q78. Scenario: Tests failing intermittently because of timing/race conditions — how to debug and stabilize?
A: Use Playwright’s trace, video or screenshot capabilities to analyze failure steps, inspect DOM/network timing, replace brittle waits with explicit waits or stable locators, possibly add retry logic — stabilizes flaky tests.
Q79. Scenario: Need to simulate multiple concurrent users (multi-browser / multi-context) interacting with the application simultaneously. Can Playwright handle this?
A: Yes — by launching multiple BrowserContexts (or separate browser instances) concurrently, each with isolated storage/state, performing parallel actions — useful to simulate multi-user flows or concurrency scenarios.
Q80. Scenario: Application uses WebSockets or real-time updates — need to test real-time behavior. How to automate this with Playwright?
A: Use event listeners or network interception to catch WebSocket messages or real-time events, trigger relevant actions, then assert UI updates or behavior — Playwright supports such network monitoring to handle real-time testing.
Q81. Scenario: Full flow: file upload → submission → UI update → cleanup (delete). How to automate end-to-end CRUD-like flow reliably?
A: Automate upload with setInputFiles(), submit, wait for server response/UI update, assert correct UI/data, then perform deletion/action, wait for confirmation/update — ensures full flow is automated and validated.
Q82. Scenario: Running tests across different environments (dev, staging, production) with different base URLs/configurations — how to manage config in Playwright?
A: Use environment variables or config files to parameterize baseURL, credentials, timeouts, flags — write tests to reference dynamic config — enables reuse across environments without code duplication.
Q83. Scenario: Application loads third-party scripts or ads that slow down or interfere with tests — how to mitigate?
A: Use network interception to block or mock third-party requests, stub heavy scripts, or mock responses — focus tests only on core app behavior — reduces noise and flakiness caused by external dependencies.
Q84. Scenario: Running many tests leads to slow browser instantiation and resource usage — how to optimize for performance?
A: Use a single browser instance with multiple contexts instead of repeatedly launching new browsers; reuse contexts where possible; close contexts/pages after tests; limit parallel workers — optimizes resource usage and speeds up test suite.
Q85. Scenario: Integrating Playwright tests with reporting dashboards (e.g. Allure, custom dashboards) — what’s the approach?
A: Use Playwright’s reporters (JSON, JUnit, HTML) or custom reporters, generate reports on test run, store artifacts (logs, screenshots), and configure dashboard/CI to parse & display results — enables team visibility and structured reporting.
Q86. Scenario: Application has dynamic state changes (real-time notifications, live updates) — need to test state update triggers UI changes. How to automate?
A: Use network/listener hooks (e.g. WebSocket or polling), trigger state change (via API or UI), then wait/assert expected UI updates — validates dynamic behavior under real-time conditions.
Q87. Scenario: Application uses locale-specific formatting (date/time/currency) — need to test across locales. How to structure tests?
A: Parameterize locale in test inputs or configuration, run tests per locale variant, assert UI text, formatting, date/time, currency display — ensures internationalization/localization correctness.
Q88. Scenario: File upload/download involves large or binary files — need to verify integrity after download. How to automate integrity checks?
A: After download, save file, then perform validation (file size, checksum, or parse binary content) via script or code — ensures file integrity is preserved end-to-end in automation.
Q89. Scenario: App uses feature-flags or A/B testing — need to test variant flows under different configurations. How to automate variant testing?
A: Parameterize feature-flag toggles in config or test data, run tests per variant path, assert behavior for each variant — ensures coverage across different feature states.
Q90. Scenario: Simulate server errors or network failures — test error handling and UI fallback behavior. How to implement?
A: Use network interception to mock error responses (e.g. 500, timeouts), trigger UI flow, then assert that application displays appropriate error messages or fallback UI — verifies robustness and error handling.
Q91. Scenario: Application uses CAPTCHA or two-step authentication — how to handle in automation testing with Playwright?
A: For test automation you may disable CAPTCHA/two-step auth in test/staging environment or use test-bypass credentials. If not possible, document limitation — automation may require manual steps or mock bypasses.
Q92. Scenario: Tests create data (like users, records) — need to clean up after tests to avoid data pollution. How to manage cleanup?
A: Use teardown logic (afterEach / afterAll) or fixtures to delete or reset test data via UI or API — ensures environment is clean for next runs and avoids side-effects between tests.
Q93. Scenario: Need to include performance regression tests along with functional tests in automation — how to integrate both?
A: Combine functional test steps with performance measurement (navigation/response times, resource load), record metrics during test run, assert thresholds or log performance data — creates mixed functional + performance automation flows.
Q94. Scenario: Need to automate accessibility testing (keyboard navigation, ARIA roles, screen-reader compatibility) — can Playwright help?
A: Yes — you can use Playwright to check element roles, ARIA attributes, simulate keyboard navigation/focus, verify accessibility attributes/behavior — helps automate accessibility validation.
Q95. Scenario: Application has complex multi-step workflows with conditional branching — how to structure tests for maintainability?
A: Use modular test functions or page-objects for each step, parameterize inputs, separate each branch into its own test case, use shared setup/teardown — keeps code clean and maintainable despite complexity.
Q96. Scenario: Application integrates third-party services (payment gateways, social login, external APIs) — how to handle external dependencies in tests?
A: Use network interception or mocking/stubbing for third-party API calls, avoid hitting real external services in tests, use test-mode or mocks — ensures tests remain reliable and independent of external factors.
Q97. Scenario: Need to run large end-to-end flows (hundreds of steps) — how to manage and optimize test suite execution?
A: Break flow into smaller modules/tests, reuse setup/fixtures, parallelize where possible, mock heavy dependencies, clean up properly — optimizes execution time while maintaining coverage and stability.
Q98. Scenario: Perform data-driven testing — run same flow with multiple data sets. How to implement with Playwright?
A: Use parameterized tests or iterate over data sets (arrays, JSON, CSV), feed input data dynamically to test logic, assert for each dataset — enables broad coverage with minimal code duplication.
Q99. Scenario: After a large test suite run, you want to re-run only tests that failed. How to implement retry or failure-based test runs?
A: Use test runner’s retry/failure-reporting features or custom scripts: capture IDs of failed tests and run them separately — useful for large suites or environments with intermittent flakiness.
Q100. Scenario: You want to integrate Playwright automated tests with reporting dashboards or notifications (Slack, email, dashboard). How to set up?
A: Configure Playwright reporters (like JSON, JUnit, HTML), generate artifacts (logs, screenshots, reports), then in CI/CD or your pipeline parse these reports, send notifications or feed dashboards — helps maintain visibility, traceability and reporting for test results.
SSC GD Constable 2025-26 Complete Guide: What, When, How & More
What is SSC GD?
The SSC GD exam is the recruitment examination conducted by the Staff Selection Commission (SSC) to hire General Duty Constables / Riflemen (GD) for various central and paramilitary forces across India. Clearing SSC GD allows eligible candidates to join forces such as Border Security Force (BSF), Central Industrial Security Force (CISF), Central Reserve Police Force (CRPF), Indo-Tibetan Border Police (ITBP), Sashastra Seema Bal (SSB), Assam Rifles (as Rifleman GD), and other CAPFs & forces.
Why Should You Consider SSC GD?
Accessible Qualification: The minimum academic requirement is Class 10 (matriculation), which means many aspirants are eligible.
Nationwide Deployments: Once selected, postings may be across different states — offering a wide distribution of opportunities.
Balanced Selection Process: Selection involves a written exam, followed by physical standard & efficiency tests and medical/document verification — ensuring selections are fair and based on merit + fitness.
Good Stability & Government Job Security: Since these are central government jobs under CAPFs/SSC, there’s job security, benefits and future growth potential.
When is the 2025-26 SSC GD Cycle & What is the Vacancy?
The latest recruitment cycle has been notified: for 2026 SSC GD — with notification and application forms released recently.
Vacancies are announced force-wise and category-wise. As the numbers vary each year, it’s essential to check the official notification PDF to know exact vacancy distribution when applications open.
Who Can Apply? Eligibility, Age & Physical Standards
Educational Qualification: A candidate must have passed Class 10 (matriculation) or equivalent from a recognised board.
Age Limit: Minimum age is 18 years, maximum 23 years for general category. Age relaxation applies for reserved categories as per official rules.
Physical Standards & Fitness (PST / PET): Shortlisted candidates must meet required physical standards and also pass a Physical Efficiency Test as laid out by the CAPFs.
Nationality / Citizenship: As per SSC norms — generally Indian citizens (or other eligible categories as mentioned in the notification) are allowed to apply.
Exam Pattern & Syllabus – What to Expect in Written Test
Computer-Based Test (CBT)
The written exam is conducted online (CBT). It includes 80 multiple-choice questions (MCQs), divided into four equal sections. Each correct answer gets 2 marks, so the total is 160 marks. Duration is 60 minutes. There is negative marking of 0.25 marks for each wrong answer.
Section
No. of Questions
Marks
General Intelligence & Reasoning
20
40
General Knowledge & General Awareness
20
40
Elementary Mathematics
20
40
English / Hindi Language
20
40
Syllabus (Subject-wise Details)
General Intelligence & Reasoning: topics like series, analogy, coding-decoding, classification, logical reasoning and mental ability.
General Knowledge & Awareness: includes Indian and world history, geography, polity, economy basics, science, environment and current affairs.
Elementary Mathematics: arithmetic (number system, percentages, ratios), time & work, time & distance, mensuration, basic algebra & geometry — mostly up to matriculation (10th class) level.
English / Hindi Language: grammar, comprehension, fill-in-blanks, sentence correction, error detection, vocabulary, etc., as per medium chosen.
Selection Process: All Steps from Application to Final Appointment
Computer-Based Examination (CBT): The first objective test — selects candidates for next rounds.
Physical Standard Test (PST) & Physical Efficiency Test (PET): Shortlisted candidates are evaluated for height, physical standards, and physical fitness as per norms set by CAPFs.
Medical Examination / Detailed Medical Test (DME): Medical fitness check — only medically fit candidates proceed further.
Document Verification & Final Merit / Force Allocation: Verification of certificates, identity, category etc; followed by final selection and posting in the chosen force.
How to Apply for SSC GD 2025-26 (Step-by-Step)
Keep a regular check on the official Staff Selection Commission website for the release of notification and application link.
Register or log in, then fill in personal details, educational qualification (Class 10), category, contact info, preferred exam centre, etc.
Upload scanned documents (photo, signature, identity proof) as per specification given in the notification.
Pay application fee if applicable — fee and exemption depend on your category (general male, female, reserved etc.).
Submit the application form. Download / print confirmation page and fee receipt for future reference.
When admit cards are released, download them, note exam centre and date. Appear for CBT. If shortlisted, proceed with PST/PET, medical & document verification as per schedule.
What Happens After Selection?
Candidates who clear all stages — CBT, PST/PET, medical, and document verification — will be appointed as GD Constable / Rifleman (GD) in their allotted force (CAPF / paramilitary). Posting location depends on force requirements, and candidates may be deployed anywhere in the country.
After selection, there will likely be training/induction as per force rules before regular deployment. This makes SSC GD not just an exam, but a gateway to a disciplined career in security forces.
How to Prepare for SSC GD – Strategy & Tips
Create a study plan covering all sections — reasoning, GK, maths, and language. Consistent revision helps.
Practice MCQs and previous-year question papers under timed conditions — speed & accuracy are key, especially with negative marking and time limit (60 min for 80 questions).
Focus on strengthening basic arithmetic and reasoning — since exam is roughly matriculation level.
Keep up with current affairs and general knowledge — topics like history, geography, polity, environment, current events often appear in GK section.
Maintain physical fitness — since clearing PST/PET is mandatory — regular running, stamina & endurance practice helps.
Keep all required documents ready (class 10 certificate, ID proof, category proofs etc.) so there’s no delay during application or verification.
Important Resources & Links
Official SSC Website — to check official notifications, apply, download admit cards & results.
Contact Us — for any guidance or help (replace with your actual contact page URL).
FAQ — Frequently Asked Questions about SSC GD
Q: What is the SSC GD exam pattern?
A: The exam is a Computer-Based Test (CBT) with 80 MCQs, divided into four sections — General Intelligence & Reasoning, General Knowledge & Awareness, Elementary Mathematics, and English/Hindi. Total marks: 160, time: 60 minutes, with negative marking (–0.25 for wrong answers).
Q: What are the selection stages for SSC GD?
A: Selection includes CBT, then Physical Standard Test (PST) & Physical Efficiency Test (PET), followed by Medical Examination / Detailed Medical Exam (DME), and finally Document Verification & force allocation.
Q: What is the minimum educational qualification to apply?
A: The minimum educational qualification is passing Class 10 (matriculation) or equivalent from a recognized board.
Q: Is there any negative marking in SSC GD exam?
A: Yes — for every wrong answer in CBT, 0.25 marks will be deducted.
Q: What are the physical requirements for PST / PET?
A: Shortlisted candidates must meet the physical standards and pass physical efficiency tests as per force-specific norms. Height, physical fitness, and medical fitness are checked.
Q: Where can I get previous year question papers for SSC GD?
A: Previous-year papers and mock tests are often available on SSC prep portals — practicing them helps understand exam pattern and improves readiness.
Q: How to stay updated with current affairs for GK section?
A: Read newspapers, follow monthly GK magazines/lists, stay aware of national & world events, history, geography, polity — these topics are commonly asked in GK/Awareness section.
Q: After clearing the written exam, what next?
A: Shortlisted candidates are called for PST & PET, followed by medical exam and document verification. Those meeting all requirements are then selected and allotted to a paramilitary force.
Conclusion
The SSC GD exam remains a great opportunity for matriculation-level candidates who wish to serve the nation and build a stable career in the paramilitary forces. It offers a fair selection process combining knowledge test, physical fitness, and medical standards. With correct preparation — both academic and physical — and timely application, “SSC GD Constable / Rifleman (GD)” can be a realistic and rewarding career goal.
Keep track of official notifications, prepare smartly, stay fit — and you might soon be part of India’s security forces. Wishing you all the best for your SSC GD journey!
