The SDET Take-Home Assignment: Build a Portfolio Project That Gets You Hired

Introduction: Your Portfolio Is Your Resume Now

In 2026, the SDET job market has fundamentally shifted. Resumes listing years of experience and tool names are no longer enough to stand out. Hiring managers are drowning in applications from candidates who all claim to know Playwright, Selenium, and CI/CD. What separates the candidates who get interviews from those who get rejected is evidence: a portfolio project that demonstrates not just what tools you know, but how you think about test architecture, code quality, and engineering practices.

🎭 Want to master this with real projects? Join the Playwright Automation Mastery course at The Testing Academy.

A well-crafted portfolio project is worth more than ten years of resume bullet points because it shows rather than tells. It demonstrates your coding ability, your architectural thinking, your CI/CD skills, your documentation practices, and your understanding of modern test automation patterns. When a hiring manager opens your GitHub repository and sees a clean, well-documented Playwright framework with passing CI badges and Allure reports, they immediately know you are a serious engineer.

In this guide, I will walk you through building a complete SDET portfolio project from scratch in one weekend. I will show you exactly what hiring managers look for, provide complete code examples for every component, highlight the common mistakes that kill applications, and give you a before-and-after resume comparison that shows how to leverage your portfolio for maximum impact.

What Hiring Managers Actually Look For

I have been on both sides of the SDET hiring process, and I can tell you that most candidates miss what actually matters. Hiring managers are not looking for the most complex or feature-rich framework. They are looking for evidence of engineering maturity. Here is what they evaluate in order of importance:

1. Code quality and readability. Can you write clean, well-structured code that another engineer can understand without explanation? This includes naming conventions, file organization, consistent style, and appropriate abstractions.
2. CI/CD integration. Does your project have a working pipeline? A green CI badge on your README immediately signals that you understand the full test automation lifecycle, not just writing tests locally.
3. Meaningful assertions. Do your tests validate business logic or just check that elements exist? Tests that assert specific text content, data values, and state transitions demonstrate deeper understanding than tests that only verify element visibility.
4. Documentation. Does your README explain the architecture, setup instructions, and design decisions? Engineers who document their work are engineers who can communicate with teams.
5. Test design variety. Do you test happy paths, error scenarios, edge cases, and cross-browser? A portfolio that only tests the golden path suggests limited testing thinking.

The Ideal Project Structure

Here is the complete project structure for a portfolio-ready Playwright TypeScript framework testing SauceDemo (a free public test application). This structure demonstrates all the patterns hiring managers want to see:

sdet-portfolio-project/
|-- .github/
|   |-- workflows/
|       |-- playwright.yml          # GitHub Actions CI pipeline
|-- tests/
|   |-- ui/
|   |   |-- login.spec.ts           # Login feature tests
|   |   |-- inventory.spec.ts       # Product listing tests
|   |   |-- cart.spec.ts            # Shopping cart tests
|   |   |-- checkout.spec.ts        # Checkout flow tests
|   |-- api/
|       |-- products.api.spec.ts    # API tests for products
|       |-- auth.api.spec.ts        # API tests for authentication
|-- pages/
|   |-- LoginPage.ts                # Login page object
|   |-- InventoryPage.ts            # Inventory page object
|   |-- CartPage.ts                 # Cart page object
|   |-- CheckoutPage.ts             # Checkout page object
|   |-- components/
|       |-- Header.ts               # Header component
|       |-- ProductCard.ts          # Product card component
|-- fixtures/
|   |-- auth.fixture.ts             # Authentication fixture
|   |-- test-data.fixture.ts        # Test data fixture
|-- utils/
|   |-- test-data.ts                # Test data generators
|-- playwright.config.ts            # Playwright configuration
|-- package.json
|-- README.md                       # Project documentation
|-- tsconfig.json

The Complete playwright.config.ts

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  forbidOnly: !!process.env.CI,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 4 : undefined,
  reporter: [
    ['html', { open: 'never' }],
    ['allure-playwright'],
    ['list'],
  ],
  use: {
    baseURL: 'https://www.saucedemo.com',
    trace: 'retain-on-failure',
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
  },
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
    },
    {
      name: 'webkit',
      use: { ...devices['Desktop Safari'] },
    },
  ],
});

Sample Page Object: LoginPage.ts

// pages/LoginPage.ts
import { type Page, type Locator, expect } from '@playwright/test';

export class LoginPage {
  readonly page: Page;
  readonly usernameInput: Locator;
  readonly passwordInput: Locator;
  readonly loginButton: Locator;
  readonly errorMessage: Locator;

  constructor(page: Page) {
    this.page = page;
    this.usernameInput = page.getByPlaceholder('Username');
    this.passwordInput = page.getByPlaceholder('Password');
    this.loginButton = page.getByRole('button', { name: 'Login' });
    this.errorMessage = page.getByTestId('error');
  }

  async goto() {
    await this.page.goto('/');
  }

  async login(username: string, password: string) {
    await this.usernameInput.fill(username);
    await this.passwordInput.fill(password);
    await this.loginButton.click();
  }

  async expectError(message: string) {
    await expect(this.errorMessage).toContainText(message);
  }

  async expectLoginSuccess() {
    await expect(this.page).toHaveURL(/inventory/);
  }
}

Sample Test File: login.spec.ts

// tests/ui/login.spec.ts
import { test, expect } from '@playwright/test';
import { LoginPage } from '../../pages/LoginPage';

test.describe('Login Feature', () => {
  let loginPage: LoginPage;

  test.beforeEach(async ({ page }) => {
    loginPage = new LoginPage(page);
    await loginPage.goto();
  });

  test('successful login with valid credentials', async () => {
    await loginPage.login('standard_user', 'secret_sauce');
    await loginPage.expectLoginSuccess();
  });

  test('displays error for locked out user', async () => {
    await loginPage.login('locked_out_user', 'secret_sauce');
    await loginPage.expectError('locked out');
  });

  test('displays error for invalid credentials', async () => {
    await loginPage.login('invalid_user', 'wrong_password');
    await loginPage.expectError('Username and password do not match');
  });

  test('displays error for empty username', async () => {
    await loginPage.login('', 'secret_sauce');
    await loginPage.expectError('Username is required');
  });

  test('displays error for empty password', async () => {
    await loginPage.login('standard_user', '');
    await loginPage.expectError('Password is required');
  });
});

GitHub Actions CI Pipeline

# .github/workflows/playwright.yml
name: Playwright Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1-5'  # Weekdays at 6 AM UTC

jobs:
  test:
    timeout-minutes: 30
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm ci

      - name: Install Playwright Browsers
        run: npx playwright install --with-deps

      - name: Run Playwright tests
        run: npx playwright test

      - name: Upload Playwright Report
        uses: actions/upload-artifact@v4
        if: ${{ !cancelled() }}
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

      - name: Upload Allure Results
        uses: actions/upload-artifact@v4
        if: ${{ !cancelled() }}
        with:
          name: allure-results
          path: allure-results/
          retention-days: 30

Step-by-Step Weekend Build Guide

Saturday: Foundation and Core Tests (6-8 hours)

1. Hour 1: Initialize project with npm init playwright@latest. Set up TypeScript, configure ESLint, create folder structure.
2. Hours 2-3: Build Page Objects for Login, Inventory, Cart, and Checkout pages. Focus on clean locator strategies using getByRole and getByLabel.
3. Hours 4-5: Write UI tests for the login flow (valid login, invalid credentials, locked user, empty fields). Write inventory tests (product display, sorting, add to cart).
4. Hours 6-7: Write cart and checkout tests. Include both happy path and error scenarios. Ensure tests use meaningful assertions.
5. Hour 8: Run all tests locally, fix any issues, ensure all tests pass consistently.

Sunday: API Tests, CI, and Documentation (6-8 hours)

1. Hour 1-2: Add API tests using Playwright APIRequestContext. Test authentication endpoints and product data endpoints.
2. Hours 3-4: Set up GitHub Actions workflow. Push code, verify pipeline runs and passes. Add the CI badge to your README.
3. Hour 5: Install and configure Allure reporting. Verify reports generate correctly.
4. Hours 6-7: Write a comprehensive README with project overview, architecture diagram (use ASCII art or Mermaid), setup instructions, test execution commands, and design decisions explanation.
5. Hour 8: Final review, clean up code, ensure everything is polished and professional.

Common Mistakes That Kill Applications

Mistake	Why It Hurts	How to Fix
No CI/CD pipeline	Shows you only know local development	Add GitHub Actions workflow with green badge
No README	Suggests poor communication skills	Write architecture overview, setup, and design decisions
Weak assertions (element exists only)	Shows shallow testing understanding	Assert text content, data values, state transitions
Only happy path tests	Indicates limited test design thinking	Add error scenarios, edge cases, boundary tests
Hardcoded test data	Shows lack of engineering maturity	Use test data generators and fixtures
No parallel execution config	Misses a key Playwright advantage	Enable fullyParallel in playwright.config.ts
Copied tutorial code	Obvious to experienced reviewers	Customize for your target app, add your own patterns
No cross-browser config	Misses testing fundamentals	Add Chromium, Firefox, and WebKit projects

Before and After Resume Comparison

Before: Generic Resume Bullet Points

• 3 years experience in test automation using Selenium and Playwright
• Wrote automated test scripts for web applications
• Worked with CI/CD tools like Jenkins and GitHub Actions
• Experience with Page Object Model design pattern

After: Portfolio-Backed Resume Bullet Points

• Built a Playwright TypeScript test framework with POM, API testing, and Allure reporting – github.com/yourname/sdet-portfolio
• Designed component-based page object architecture supporting 50+ tests across 3 browsers with full parallel execution
• Implemented GitHub Actions CI pipeline running on every push with automated test reporting and artifact retention
• Achieved 100% pass rate across Chromium, Firefox, and WebKit with zero flaky tests through proper auto-wait patterns

Conclusion: Build It This Weekend

The difference between SDET candidates who get hired and those who do not often comes down to one thing: proof. A portfolio project is proof that you can do what you claim. It transforms vague resume claims into verifiable evidence. And in a competitive job market where hundreds of candidates apply for each SDET position, evidence is what gets you to the interview stage.

You do not need to wait for the perfect time to build your portfolio. Block out one weekend, follow the guide in this post, and ship it. The project does not need to be perfect. It needs to be done, documented, and visible. You can always iterate and improve it later. But a portfolio project that exists and is public is infinitely more valuable than a perfect project that only exists in your plans.

Frequently Asked Questions

What should an SDET portfolio project include to impress hiring managers?

An impressive SDET portfolio project should include a Playwright TypeScript framework testing a real public application like SauceDemo, Page Object Model architecture, API tests alongside UI tests, GitHub Actions CI pipeline with a green badge, Allure reporting integration, parallel execution configuration, and a comprehensive README with architecture diagram. The project should demonstrate both technical skill and engineering practices like clean code, meaningful assertions, and proper error handling.

How long does it take to build a complete SDET portfolio project?

A well-structured SDET portfolio project can be completed in one weekend (approximately 12-16 focused hours) if you follow a systematic approach. Day one focuses on project setup, Page Object Model implementation, and core UI tests. Day two focuses on API tests, CI pipeline configuration, reporting setup, and documentation. The key is having a clear plan before you start coding rather than building incrementally without direction.

What are the most common mistakes in SDET portfolio projects?

The most common mistakes are: no CI/CD integration (shows you only know local development), no README or documentation (suggests poor communication skills), weak assertions that only check element exists rather than validating business logic, testing only happy paths without error scenarios, hardcoded test data instead of dynamic generation, no parallel execution configuration, and copying tutorial code without understanding or customizing it for the target application.