DEV Community: Warren de Leon

Setting up MSW v2 in React Native

Warren de Leon — Mon, 04 May 2026 12:37:29 +0000

Why MSW over manual mocks

Most React Native projects mock their API layer with jest.fn(). You mock fetch or your Axios instance, define what it returns, and test against that.

It works. Until it doesn't.

The problem: you're testing your code's interaction with a mock, not with an HTTP layer. If your API client changes how it constructs URLs, adds headers, or handles retries, the mock doesn't catch the regression. This matters even more if you're validating responses at runtime with something like Zod, because you want the validation layer to run against real response shapes, not hand-crafted mock objects. The mock always returns what you told it to return, regardless of what the code actually sent.

Mock Service Worker (MSW) intercepts requests at the network level. Your code makes real HTTP calls. MSW catches them before they leave the process and returns your mock responses. Everything between your component and the network is exercised: the Redux thunk, the Axios interceptors, the error handling, the response parsing.

💡 The key difference: manual mocks replace your code. MSW replaces the network. Your code runs exactly as it would in production, up to the point where the request would leave the device.

Assumptions

The setup below was written against:

React Native 0.74+ with the default react-native Jest preset
TypeScript with the standard RN Babel config
Redux Toolkit (the custom render wrapper assumes this)
Node 18 or later (Node 20 recommended)

If you're on an older RN version, an Expo Jest preset, or no Redux, the concepts still apply but a few snippets will need adjustment.

Installation

MSW v2 runs in Jest tests via the Node.js server. The browser service worker isn't relevant for mobile, so ignore everything in the MSW docs about service-worker registration.

yarn add -D msw node-fetch@2 web-streams-polyfill

msw is the obvious one. node-fetch and web-streams-polyfill are the polyfills MSW v2 needs in the React Native Jest environment, which I'll wire up in the next step.

💡 Why pin node-fetch@2? node-fetch v3+ is ESM-only and won't load through require() in a CommonJS Jest setup file. Either pin to v2 (what this post does), or migrate the polyfills file to ESM. v2 is the lower-friction path on a default React Native Jest preset.

💡 Don't trust posts that say "no polyfills required". MSW v2 is built on the Fetch API and Web Streams. Some Node + Jest combinations have these globals; the React Native Jest preset doesn't. Without the polyfills you'll see ReferenceError: Response is not defined or TextEncoder is not defined the first time MSW tries to construct a response.

Polyfills

Create jest.polyfills.cjs at the project root. It must be .cjs (not .ts) because Jest loads it before the TypeScript transformer is set up:

/**
 * MSW polyfills for React Native.
 * Required for Mock Service Worker v2 in Jest tests.
 */

// TextEncoder / TextDecoder
const { TextEncoder, TextDecoder } = require('util');
global.TextEncoder = TextEncoder;
global.TextDecoder = TextDecoder;

// Fetch API
if (!global.fetch) {
  global.fetch = require('node-fetch');
  global.Headers = require('node-fetch').Headers;
  global.Request = require('node-fetch').Request;
  global.Response = require('node-fetch').Response;
}

// ReadableStream (for response streaming)
if (!global.ReadableStream) {
  try {
    const { ReadableStream } = require('web-streams-polyfill');
    global.ReadableStream = ReadableStream;
  } catch {
    // web-streams-polyfill is optional for older MSW v2
  }
}

This file runs before the test framework loads, so beforeAll, jest, etc. aren't available here. It's purely for setting up globals.

Jest config

Wire the polyfills file and a separate setup file into jest.config.cjs:

module.exports = {
  preset: 'react-native',
  testEnvironment: 'node',
  setupFiles: ['<rootDir>/jest.polyfills.cjs'],
  setupFilesAfterEnv: ['<rootDir>/jest.setup.ts'],
  transformIgnorePatterns: [
    // The default RN preset ignores most of node_modules; MSW needs to be transformed.
    'node_modules/(?!(react-native|@react-native|msw|until-async)/)',
  ],
  moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node'],
};

Two keys do the work:

Key	When it runs	Use for
`setupFiles`	Before the Jest framework is installed	Polyfills, global variables, anything that doesn't need `jest`/`expect`
`setupFilesAfterEnv`	After Jest framework, before each test file	`beforeAll`/`afterEach` hooks, MSW server lifecycle, custom matchers

The transformIgnorePatterns line is the other gotcha: the default RN preset skips transforming node_modules, but MSW ships modern syntax that Jest can't run as-is. Add msw|until-async to the allow-list or you'll see SyntaxError: Cannot use import statement outside a module from inside node_modules/msw/.

The server

Create src/test-utils/msw/server.ts:

import { setupServer } from 'msw/node';
import { handlers } from './handlers';

/**
 * MSW server for Jest. Started/stopped in jest.setup.ts.
 * Use `server.use(...errorHandlers)` to override per test.
 */
export const server = setupServer(...handlers);

The server takes your default handlers (success responses) and intercepts matching requests.

Wiring up the lifecycle

In jest.setup.ts (which Jest loads via setupFilesAfterEnv), start the server before tests, reset between tests, close after:

import '@testing-library/jest-native/extend-expect';
import { server } from './src/test-utils/msw/server';

// MSW server lifecycle
beforeAll(() => server.listen({ onUnhandledRequest: 'warn' }));
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

Hook	What it does
`beforeAll`	Starts the server before any test runs
`afterEach`	Resets handlers to defaults between tests (so one test's overrides don't leak)
`afterAll`	Shuts down the server after all tests complete

The onUnhandledRequest: 'warn' option logs a warning if your code makes a request no handler matches. In CI, switch this to 'error' so missed handlers fail the build:

const onUnhandledRequest = process.env.CI ? 'error' : 'warn';
beforeAll(() => server.listen({ onUnhandledRequest }));

💡 If your tests use fake timers, flush pending timers in afterEach before resetting handlers. Otherwise an animation timer scheduled inside a component can fire after the next test starts and trigger spurious failures.

Writing handlers

Each handler is a function that matches a request method and URL, and returns a response.

A basic handler for a REST API:

import { http, HttpResponse } from 'msw';

const BASE_URL = 'https://api.example.com';

export const handlers = [
  http.get(`${BASE_URL}/items`, () => {
    return HttpResponse.json([
      { id: 1, name: 'Item One' },
      { id: 2, name: 'Item Two' },
    ]);
  }),

  http.get(`${BASE_URL}/items/:id`, ({ params }) => {
    const { id } = params;
    return HttpResponse.json({ id: Number(id), name: `Item ${id}` });
  }),

  http.post(`${BASE_URL}/items`, async ({ request }) => {
    const body = await request.json();
    return HttpResponse.json({ id: 3, ...body }, { status: 201 });
  }),
];

Key things to notice:

✅ http.get, http.post, etc. match the HTTP method
✅ URL params (:id) are extracted automatically
✅ Request body is available via request.json()
✅ HttpResponse.json() returns typed JSON responses with status codes

Separating fixtures from handlers

Inline response objects work for a sketch. They don't work in a real codebase: the same shapes show up in handlers, in component tests, and in Storybook stories, and you don't want to maintain three copies.

Pull the fixture data into its own file:

// src/test-utils/msw/mockData.ts
export const mockItems = [
  { id: 1, name: 'Item One', createdAt: '2026-01-01T00:00:00Z' },
  { id: 2, name: 'Item Two', createdAt: '2026-01-02T00:00:00Z' },
];

export const mockProfile = {
  id: 'user_1',
  name: 'Warren de Leon',
  email: 'hi@example.com',
};

Handlers then read from mockData:

import { http, HttpResponse } from 'msw';
import { mockItems, mockProfile } from './mockData';

export const handlers = [
  http.get(`${BASE_URL}/items`, () => HttpResponse.json(mockItems)),
  http.get(`${BASE_URL}/me`, () => HttpResponse.json(mockProfile)),
];

Same fixtures get reused in component tests where you bypass MSW and pass data directly. One source of truth.

Handler sets for every scenario

Default success handlers are the starting point. But real apps need to handle failures too. This is where most MSW setups stop. Don't stop here.

The bugs that actually reach production aren't the happy-path failures. They're the awkward ones: the 401 that comes back mid-session because a token expired five minutes ago, the 429 from a burst of refresh attempts after a brief network blip, the 422 with a different validation shape than your form expects, the 408 that should have been a retry but wasn't. None of those get caught if your error coverage is "what if the API returns 500?".

I create separate handler sets for every error scenario the app needs to handle:

// Success (default)
export const handlers = [...apiHandlers, ...authHandlers];

// Server errors
export const errorHandlers = [
  http.get(`${BASE_URL}/items`, () => {
    return HttpResponse.json(
      { message: 'Internal server error' },
      { status: 500 }
    );
  }),
];

// Unauthorized (expired token)
export const unauthorizedHandlers = [
  http.get(`${BASE_URL}/items`, () => {
    return HttpResponse.json(
      { error: 'invalid_token', message: 'Token has expired' },
      { status: 401 }
    );
  }),
];

// Rate limiting
export const rateLimitHandlers = [
  http.post(`${BASE_URL}/auth/token`, () => {
    return HttpResponse.json(
      { error: 'too_many_requests', message: 'Try again in 60 seconds' },
      { status: 429, headers: { 'Retry-After': '60' } }
    );
  }),
];

// Timeout (never resolves)
export const timeoutHandlers = [
  http.get(`${BASE_URL}/items`, async () => {
    await new Promise(resolve => setTimeout(resolve, 60000));
    return HttpResponse.json({}, { status: 408 });
  }),
];

// Offline (network failure)
export const offlineHandlers = [
  http.get(`${BASE_URL}/items`, () => {
    return HttpResponse.error();
  }),
];

In my project, I have 11 handler sets:

Handler set	Status	What it tests
`handlers`	200	Default success responses
`errorHandlers`	500	Server error handling
`unauthorizedHandlers`	401	Expired/invalid token flows
`forbiddenHandlers`	403	Banned/suspended accounts
`conflictHandlers`	409	Duplicate registration
`validationErrorHandlers`	422	Form validation errors
`rateLimitHandlers`	429	Rate limiting with Retry-After
`emailNotConfirmedHandlers`	400	Email verification required
`storageErrorHandlers`	413/404	File upload/delete errors
`timeoutHandlers`	408	Network timeout simulation
`offlineHandlers`	Error	Complete network failure

Each set is exported and can be swapped in per test.

💡 Tip: The timeout handler uses await new Promise(resolve => setTimeout(resolve, 60000)) to simulate a request that never completes. Your code's request timeout will fire first, testing the timeout handling path.

Using handlers in tests

The default handlers run automatically (registered in setupServer). To test error scenarios, override them per test:

import { server } from '@app/test-utils/msw/server';
import { errorHandlers, unauthorizedHandlers } from '@app/test-utils/msw/handlers';

describe('API error handling', () => {
  it('shows error message on server failure', async () => {
    server.use(...errorHandlers);

    // Render component, trigger fetch, assert error UI
  });

  it('redirects to login on 401', async () => {
    server.use(...unauthorizedHandlers);

    // Render component, trigger fetch, assert redirect
  });

  // No cleanup needed - afterEach in jest.setup resets handlers
});

The spread (...errorHandlers) replaces matching handlers. Non-matching handlers from the default set remain active. After the test, server.resetHandlers() restores the defaults.

The custom render wrapper

MSW works best with a real Redux store, not a mocked one. The whole point is to test the actual integration: component → Redux thunk → HTTP request → MSW intercept → response → state update → UI update.

// src/test-utils/renderWithProviders.tsx
import React from 'react';
import { Provider } from 'react-redux';
import { combineReducers, configureStore } from '@reduxjs/toolkit';
import type { RenderOptions } from '@testing-library/react-native';
import { render } from '@testing-library/react-native';

import { itemsReducer } from '@app/features/Items';
import { authReducer } from '@app/features/Auth';

const rootReducer = combineReducers({
  items: itemsReducer,
  auth: authReducer,
});

type RootState = ReturnType<typeof rootReducer>;

function createTestStore(preloadedState?: Partial<RootState>) {
  return configureStore({
    reducer: rootReducer,
    preloadedState,
    middleware: getDefaultMiddleware =>
      getDefaultMiddleware({
        serializableCheck: false,
        immutableCheck: false,
      }),
  });
}

type AppStore = ReturnType<typeof createTestStore>;

interface ExtendedRenderOptions extends Omit<RenderOptions, 'wrapper'> {
  preloadedState?: Partial<RootState>;
  store?: AppStore;
}

export function renderWithProviders(
  ui: React.ReactElement,
  { preloadedState, store, ...options }: ExtendedRenderOptions = {},
) {
  const createdStore = store ?? createTestStore(preloadedState);

  const Wrapper = ({ children }: { children: React.ReactNode }) => (
    <Provider store={createdStore}>{children}</Provider>
  );

  return {
    store: createdStore,
    ...render(ui, { wrapper: Wrapper, ...options }),
  };
}

That covers Redux. Real apps usually need more: i18n, navigation, theming, toast/notification context. The wrapper is the right place to compose all of them. Add providers around {children}:

const Wrapper = ({ children }: { children: React.ReactNode }) => (
  <Provider store={createdStore}>
    <I18nextProvider i18n={i18n}>
      <ThemeProvider>
        <ToastProvider>
          {children}
        </ToastProvider>
      </ThemeProvider>
    </I18nextProvider>
  </Provider>
);

If a screen uses react-navigation, wrap it in NavigationContainer and an in-memory navigator for the test. The principle is the same: every provider that wraps your app in App.tsx should wrap your component in renderWithProviders. Anything you forget is a difference between test environment and runtime, and those differences are where flaky tests live.

Now your tests render with a real store, dispatch real thunks, and MSW handles the network:

it('loads and displays items', async () => {
  // Default handlers return success response
  const { getByText } = renderWithProviders(<ItemList />);

  await waitFor(() => {
    expect(getByText('Item One')).toBeTruthy();
  });
});

it('shows error state on failure', async () => {
  server.use(...errorHandlers);

  const { getByText } = renderWithProviders(<ItemList />);

  await waitFor(() => {
    expect(getByText('Something went wrong')).toBeTruthy();
  });
});

No manual mocking of dispatch, selectors, or fetch. The entire stack is real except the network.

Inline handler overrides

Sometimes you need a one-off response that doesn't fit any handler set. Define it inline:

it('handles unexpected response shape', async () => {
  server.use(
    http.get('https://api.example.com/items', () => {
      return HttpResponse.json({ unexpected: 'shape' });
    })
  );

  // Test that the code handles malformed responses gracefully
});

This is useful for edge cases like malformed JSON, missing fields, or unexpected status codes that don't warrant a full handler set.

Running the tests

With everything wired up, a single test file run looks like this:

yarn jest src/features/Items/__tests__/ItemList.rntl.tsx

PASS  src/features/Items/__tests__/ItemList.rntl.tsx
  ItemList
    ✓ loads and displays items (218 ms)
    ✓ shows error state on failure (94 ms)
    ✓ redirects to login on 401 (102 ms)
    ✓ surfaces rate-limit message (89 ms)

Test Suites: 1 passed, 1 total
Tests:       4 passed, 4 total

If you see a warning like [MSW] Warning: captured a request without a matching request handler, that's onUnhandledRequest: 'warn' doing its job. Either add a handler for the URL or fix the request your code is making.

If the suite hangs and never finishes, MSW is usually waiting on a request that never resolves. Most often this is a timeoutHandlers set that uses setTimeout(..., 60000) while the test environment still has real timers. Switch to fake timers in that test (jest.useFakeTimers() then jest.advanceTimersByTime(...)) or shorten the simulated delay.

Common pitfalls

Handlers are matched in order. If two handlers match the same request, the first one wins. When you server.use(...overrides), the overrides are prepended, so they take priority over defaults.

HttpResponse.error() simulates a network failure, not an HTTP error. The request never gets a response. Use this for offline/no-network scenarios. For HTTP errors (500, 401, etc.), use HttpResponse.json() with a status code.

Async handlers need await. If your handler reads the request body (request.json()), the handler function must be async. Forgetting this causes the handler to return undefined instead of a response.

Unhandled requests are silent by default. Always use onUnhandledRequest: 'warn' (or 'error' in CI) to catch missing handlers. A silent unhandled request means your test passes for the wrong reason.

Response is not defined / TextEncoder is not defined means the polyfills file isn't loading. Check that setupFiles: ['<rootDir>/jest.polyfills.cjs'] is in your Jest config, that the file extension is .cjs (not .ts), and that the file path is correct relative to rootDir.

SyntaxError: Cannot use import statement outside a module from node_modules/msw/ means MSW isn't being transformed. Add msw|until-async to the allow-list inside transformIgnorePatterns.

Trailing slashes matter. http.get('/api/items') does not match a request to /api/items/. Match exactly what your code sends, or use a path pattern (http.get('/api/items*', ...)).

Tests pass locally and fail in CI. Usually onUnhandledRequest: 'error' catching a request you didn't realise your code was making in the CI environment (often analytics or crash reporting). Either add a handler for it or strip those calls in test mode.

The full file structure

project-root/
  jest.config.cjs           # Jest config (preset, setupFiles, setupFilesAfterEnv)
  jest.polyfills.cjs        # TextEncoder, fetch, ReadableStream globals
  jest.setup.ts             # Server lifecycle, custom matchers, global mocks
  src/
    test-utils/
      msw/
        handlers.ts         # All handler sets (success, error, 401, etc.)
        server.ts           # setupServer with default handlers
        mockData.ts         # Fixture data used by handlers
      renderWithProviders.tsx  # Custom render with real store + providers
      index.ts              # Barrel export

The barrel export (index.ts) lets tests import common utilities from one place. For specific handler sets, import directly from the handlers file:

import { server, renderWithProviders } from '@app/test-utils';
import { errorHandlers, unauthorizedHandlers } from '@app/test-utils/msw/handlers';

The bottom line

Yes. The setup is about 30 minutes. After that, every new test is simpler than the manual mock equivalent. You write server.use(...errorHandlers) instead of jest.fn().mockRejectedValue(new Error('Network error')). The handlers are reusable across every test file. And you're testing real integration behaviour, not mock behaviour.

The 11 handler sets in my project cover every error path the app handles. When I add a new API endpoint, I add handlers for it once, and every test that touches that endpoint gets correct mocking for free. The same handler-set approach also pairs well with E2E tests, where Detox + Cucumber drives the user flows and a separate runtime-mocking layer controls the API responses, but those are topics for later posts.

If writing the next test is harder than skipping it, your test infrastructure is the problem.

The code examples in this post are from rn-warrendeleon, my personal React Native project. The full MSW setup, handler sets, and custom render wrapper are all in the repo.

I built an app the hiring panel will never open

Warren de Leon — Mon, 27 Apr 2026 07:30:22 +0000

The hiring panel will never see the app

That was the constraint I kept forgetting. I built a whole interview tool with wizards, timers, auto-save, keyboard shortcuts, colour-coded scores. The hiring panel gets none of that. They get a 7-page PDF attached to an email.

The app exists for one person: the interviewer, during the call. The PDF is what actually matters. It carries the scores, the notes, the strengths and growth areas, the hire/reject decision, and four appendices of detailed evidence. Everything the panel needs to make an offer or move on.

Getting to that point took three attempts. And a bug that nearly cost a candidate their score.

The format problem

I designed the scorecards for our React Native hiring process earlier this year. Three assessments: a 100-check code review, a walkthrough interview scored 1–5, and a behavioural interview mapped to our five values. The scoring worked. The format I was using to capture those scores during a live call did not.

Picture the walkthrough interview. A candidate is sharing their screen, walking you through the tech test they've built, explaining their decisions. I need to read them a scripted question, listen to the answer, score it 1–5, write notes, check the time, then move to the next question. All on a video call where I'm trying to maintain eye contact and keep the conversation natural.

Now imagine doing that in a markdown table in VS Code.

Three attempts

Notion was my first thought. I use it for everything personal. But it's not a tool we use at work. Building on a platform I'd be the only one using felt like a dead end, so I dropped it before starting.

Markdown files came next. One .md per scorecard, with tables for scores and space for notes. The code review worked well this way. It's 100 yes/no checks you complete after the interview at your own pace. But the walkthrough and behavioural scorecards needed to work during the call. Finding the right row, typing a number, scrolling to the next section. All while a candidate is talking to me. The markdown was accurate but slow, and I was spending more attention on the document than on the person.

The worst part came after the interview. Three separate markdown files, each with different formats. I had to manually combine them into one coherent document for the recruitment team. Every time, it took longer than I wanted.

A localhost React app was the third attempt. No backend, no database, no deployment. Just npm run dev and a browser tab. Everything persists in localStorage. The app dies when I close the tab and comes back when I open it again.

Staying present during the call

The whole point was to stop fighting the tool during the interview. Three things made the difference:

One question per screen. The walkthrough is a wizard. Each step shows the script to read aloud (in a blue blockquote so I can find it instantly), the questions with large 1–5 buttons, and a notes field. No scrolling. No hunting for the right section. When I'm done, I press "Next" and the next group appears. For senior candidates, the wizard extends from 4 steps to 8 with an additional Part B on system design.

Keyboard scoring. Press 1 through 5 and the score registers immediately. No clicking, no dropdown menus, no confirmation dialogs. My eyes stay on the video call. The scoring happens in my peripheral vision.

A section timer in the corner. Not a countdown. Just a quiet elapsed time display. I glanced at it during the first walkthrough interview and realised I'd spent 8 minutes on a section that should take 4. Without the timer, I'd have run over and cut the last section short. The candidate would have lost the chance to answer questions that could have lifted their score.

The bug that scored everyone the same

Here's where the technical decisions got interesting. The app is built with React 19, TypeScript, Vite, and Tailwind v4. No state management library. Just a custom useLocalStorage hook and React Router.

During testing, I scored a candidate's walkthrough. Every section. Every question. Full notes. I pressed "Next" to the summary screen and saw that every section had the same score: whatever I'd entered on the last step.

A stale closure bug. Each wizard step's useCallback captured the walkthrough data from the previous render. When step 3 saved, it overwrote steps 1 and 2 because it was still holding the old state. The classic React problem where state inside a callback doesn't update when you think it does.

The fix was to bypass React state entirely on writes. Every mutation reads the current candidate data directly from localStorage instead of relying on the closure. A freshCandidate() helper that hits localStorage.getItem on every save operation. It's not elegant. It works every time.

function freshCandidate(id: string): Candidate | undefined {
  const raw = localStorage.getItem('hl-ik-candidates');
  if (!raw) return undefined;
  return JSON.parse(raw).find((c: Candidate) => c.id === id);
}

This pattern repeats across three hooks: useWalkthrough, useBehavioural, and useCodeReview. Each one reads fresh, writes fresh, and dispatches a custom event (ls-sync) so other hook instances pick up the change. Twenty lines of persistence code. No Redux, no context providers, no middleware.

The PDF nobody sees me build

After the interview, I press "Print / PDF" and the browser generates a Candidate Assessment Report. No PDF library. Just print CSS.

Page 1 is the summary: a score table, the recommended level band, the hire/reject decision, and the offer level. Pages 2 and 3 show strengths and growth areas pulled from all three assessments, grouped by source. Then four appendices: code review breakdown, walkthrough scores with every question and note, behavioural scores by value, and a level bands reference table with the candidate's band highlighted in navy.

That level bands table maps the combined score to one of 12 tiers: Graduate 1 through Senior 2+. The 2+ tier is intentionally hard to reach. It means someone at the very top of their category, pushing into the next one. When a panel member sees "Associate 2+" on the PDF, they know immediately: strong for Associate, not quite SE. That single label carries more signal than a paragraph of explanation.

The behavioural gate adds a second check. A candidate scoring below 10/25 on values alignment doesn't proceed, regardless of their technical score. Between 10 and 14 triggers a panel discussion. 15 or above clears the gate. Technical skills can be taught. Values misalignment creates problems that grow over time.

Print CSS is its own discipline

I wrote more CSS for @media print than for screen. It deserves its own section because it's the part that surprised me the most.

The navy background on the combined score box? Doesn't print. Browsers strip background colours by default. I had to convert it to a white box with a heavy black border using [style*="background: #002147"] selectors in the print stylesheet. Tailwind utility classes like bg-white get targeted with attribute selectors ([class*="bg-white"]) to override padding, borders, and margins for print.

page-break-inside: avoid is a suggestion, not a command. The browser will break inside an element if the alternative is a mostly-empty page. I spent an hour debugging why a strengths section split across two pages until I realised the content was simply too tall for the remaining space.

Heading styles needed explicit inline border-bottom because Tailwind classes get stripped or overridden by the print reset. Font sizes switch from rem to pt. Interactive elements (textareas, checkboxes, dropdowns) are hidden. The entire print layout lives in a separate CandidatePrintReport component that renders inside hidden print:block. Clean separation. The screen never sees the print layout, the print never sees the buttons.

If I built this again, I'd design the print layout first and the screen layout second. The PDF is the deliverable. The screen is just the input form.

What I'd change

Tests before scoring logic. Red flag deductions, stretch bonuses, level band lookups, the behavioural gate threshold. These are all pure functions now, extracted into utils/scoring.ts. They're the kind of code that breaks silently when you tweak a boundary. I wrote them last. They should have been first.

The markdown import parser is fragile. It uses regex to read Y/N values from scored code review files. It works for the specific format I designed, but it's brittle. A different table alignment or an extra column breaks it. A proper parser with error recovery would be more resilient.

Accessibility was added late. WCAG AA compliance (dynamic page titles, heading hierarchy, colour contrast ratios, roving tabindex on score selectors, aria-live on save indicators) was retrofitted rather than built in. It all passes now, but it would have been cleaner to build accessible from the start. Internal tools deserve the same standards as public-facing ones.

The real test

I used this app for the first time in an actual interview last week. The candidate didn't know I was using anything unusual. They presented their take-home submission, I scored, we talked. I wasn't scrolling, I wasn't typing into markdown tables, I wasn't losing my place. After the call, I pressed one button and had the PDF ready in seconds.

That's the whole point. The best interview tool is the one that disappears. The candidate should feel like they're having a conversation, not being processed by a system. The scoring, the timers, the level calculations, the PDF generation: all of that should be invisible. If the tool is doing its job, nobody notices it's there.

How to write a take-home tech test that candidates actually want to do

Warren de Leon — Mon, 20 Apr 2026 07:30:11 +0000

The test nobody finishes

Most take-home tech tests fail before the candidate writes a single line of code.

They clone the repo. They run npm install. Something breaks.

45 minutes later, they're debugging a Ruby version mismatch, a missing CocoaPod, or a Node version that doesn't work with the bundler. By the time the app runs, they've burnt through their patience and half their evening.

The best candidates, the ones you actually want to hire, are the most likely to walk away. They have options. They'll pick the company that respects their time.

🚩 This happened to us. Our first candidate spent two hours fighting Ruby version issues before writing any application code. His system Ruby was too old. He upgraded to Ruby 4, which broke the bundler. He downgraded to 3.3, but the vendored bundler was incompatible. Each step was a back-and-forth message. Two hours. Zero lines of application code written.

That experience changed how I thought about the test. The questions were fine. The developer experience was the problem.

Treat the test like a product

This became my guiding principle. The tech test is the first real interaction a candidate has with your engineering culture. Everything they experience tells them something about you.

If the setup is broken → they think your codebase is broken.
If the brief is vague → they think your specs are vague.
If the timeline is unrealistic → they think your deadlines are unrealistic.

I started treating the test the same way I'd treat a product:

Product thinking	Applied to the tech test
User research	What frustrates candidates about tech tests?
Clear requirements	A detailed brief with wireframes and rules
Developer experience	Starter project, setup script, path aliases
Documentation	Linked guides for every question they might have
Continuous improvement	Update after every round based on what went wrong

After the Ruby incident, I added a setup script, pinned the Ruby version, committed a Gemfile.lock with a modern bundler, and added a troubleshooting section to the README.

The next candidate was coding in under two minutes.

The setup script

The single biggest improvement: a setup.sh that handles everything.

./setup.sh

One command. It:

✅ Checks Node version (installs via nvm if needed)
✅ Checks Ruby version (supports rbenv, rvm, and asdf)
✅ Checks for Xcode CLI tools and CocoaPods
✅ Runs yarn install
✅ Runs bundle install and pod install
✅ Tells you exactly what to fix if something is wrong

The key design choice: the script asks before installing anything. It detects what the candidate already has and works with it. A candidate using rbenv gets rbenv. A candidate using rvm gets rvm. Their environment is respected, not overwritten.

💡 Tip: Pin your versions in the repo: .ruby-version, .nvmrc, Gemfile.lock with a modern bundler. Then write a setup script that reads them. Every minute a candidate spends on setup is a minute they're not spending on code.

The starter project

I give candidates a fully configured project. Not a blank repo. A working app.

Included	Why
TypeScript in strict mode	No ambiguity about language expectations
React Navigation v7 with typed params	Navigation is boilerplate, not a test of skill
Jest + React Native Testing Library	Configured with native module mocks, ready to write tests
ESLint + Prettier	Consistent code style from line one
Path aliases (`@app/*`)	No `../../../` import chains
Custom test render wrapper	NavigationContainer included, just render and assert
Three placeholder screens	"Replace me", clear starting point
A passing smoke test	Proof the setup works before they change anything

Everything compiles. Everything runs. The smoke test passes.

I'm not testing whether someone can configure a bundler or debug a TypeScript path alias. I'm testing whether they can build application code. The starter project removes every obstacle between "I cloned the repo" and "I'm writing my first component."

Some candidates start from scratch anyway. That's fine. The starter is optional. But most use it, and the result is the same: instead of spending their first hour fighting config, they spend it making architectural decisions.

The brief: clear about what, not how

Some tech tests specify exactly how to build things: which state management library, which folder structure, which API client. That approach works when you want consistency. But for us, those decisions are the most interesting part of the submission.

Our brief takes a different approach. It explains what the app should do in detail, and says nothing about how.

Screen wireframes show the data and interactions (ASCII layouts, not pixel designs)
A requirements table spells out the rules (max 6 items, add from detail, remove from list)
A technical requirements table lists the non-negotiables (React Native, TypeScript, React Navigation)

What's deliberately missing: architecture prescriptions. The candidate chooses the state management, the folder structure, the API client, the testing strategy.

A candidate who picks Redux Toolkit tells me something different from one who picks Zustand. Neither is wrong. Both are interesting. And the reasoning behind the choice is what the walkthrough conversation is built on.

💡 Tip: If your brief specifies the architecture, you're testing compliance, not engineering. The best briefs describe the what in detail and leave the how completely open.

Respecting people's time

Candidates get 7 days. The work should take 4 to 6 hours.

We say this explicitly. In the brief and in the submission guide. Twice, because people miss it the first time.

7 days gives flexibility. Some people work across a weekend. Some do an hour each evening. Some block a Saturday morning. The timeline respects that candidates have jobs, families, and lives outside of interviewing.

The 4-to-6-hour estimate is honest. I built the test myself to verify it. A competent React Native developer can build all three screens with state management, API integration, basic tests, and a README in that time. Some choose to invest more. That's their choice, not our expectation.

If a candidate needs more time, we give it. No questions asked.

ℹ️ Going silent and submitting three days late with no explanation is a different signal from sending a message saying "I need a couple more days." Communication matters.

Tell them what you're looking for

Early on, a candidate told us they'd spent an hour styling buttons because they assumed UI polish mattered to us. It didn't. We were looking at architecture and testing. That hour was wasted because we hadn't told them what counted.

Now we're explicit:

✅ How you think about architecture and code organisation
✅ How you break down a problem into components and data flows
✅ How you make and justify technical decisions
✅ How you handle edge cases and error states
✅ How well you know your own code

❌ We're NOT judging visual design or pixel-perfect UI
❌ We're NOT expecting a production-ready app in a take-home

When candidates know we care about architecture and trade-offs more than styling, they allocate their time accordingly. Better signal for us. Better experience for them.

We also tell them upfront that we might use AI tooling as a pre-check, but every submission is manually reviewed and scored by the hiring panel. Transparency builds trust.

The walkthrough is not an interrogation

The walkthrough is a conversation. The candidate drives for the first 10 minutes:

Demo the app: walk through all screens, show the features working
Run the tests: show them passing live
Walk through the code: explain structure and decisions

After the presentation, we ask questions. But the framing matters. We say:

"Don't worry if something doesn't work as expected during the demo. That happens. If it does, just talk me through what you think went wrong and how you'd fix it. That tells me more than a perfect demo would."

This isn't just being nice. Watching someone diagnose a bug in their own code is one of the strongest signals you can get. A candidate who says "Oh, I think the useEffect dependency array is wrong here" is showing you exactly how they work.

A perfect demo shows you nothing except that they rehearsed.

Documentation as a first-class feature

The test comes with proper documentation. Not just a README. A set of linked markdown files:

Document	What it covers
Assessment Brief	Requirements, screen wireframes, party rules, technical requirements
API Guide	Endpoints, GraphQL vs REST options, client recommendations
Starter Project	What's included, project structure, available commands, testing setup
Submission & Walkthrough	How to submit, what happens in the walkthrough, tips
Stretch Goals	Optional extras and what each one demonstrates

Every question a candidate might have is answered before they need to ask it. This isn't just about being helpful. It's about removing ambiguity as a variable. I don't want to evaluate how well someone interprets a vague brief. I want to evaluate how they build software when the requirements are clear.

What I'd change next time

The test isn't perfect. What's on my list:

A video walkthrough of the starter project. A 3-minute Loom showing the folder structure, how to run it, and where to start. Some people learn better from video than docs.
A .env.example file. Even though the test uses a public API with no keys, it sets the right pattern.
Testing the setup on a clean machine. I built the test on my own laptop with years of tooling. Every assumption about "everyone has this installed" was wrong. The first candidate proved it.

The structure is right though. Setup script. Starter project. Clear brief. Honest timeline. Proper documentation. Transparent evaluation criteria.

If you're designing a tech test and candidates keep dropping out, don't look at the questions first. Look at the developer experience. The best tech test is one where the candidate spends 100% of their time on the thing you're actually evaluating, and 0% on everything else.

This is the last in a series about building a hiring process from scratch. The earlier posts cover why I redesigned the test, advice for candidates taking one, and how the scoring works.

We're hiring! We're looking for React Native engineers to join the Mobile Platform team at Hargreaves Lansdown. View open roles.

How I designed a tech test scorecard that works from Graduate to Senior

Warren de Leon — Mon, 13 Apr 2026 07:30:10 +0000

The problem with "is this a 3 or a 4?"

When I started building the hiring process for my squad, I knew I wanted a structured scorecard from day one. I wrote about the tech test itself in an earlier post. The test worked. The scoring didn't. At least, not the way I first designed it.

My first scorecard used a 1–5 scale for each criterion. "TypeScript usage: score 1 to 5." "State management: score 1 to 5." Each criterion had a rubric describing what each score meant. It looked thorough on paper.

Then I tried to use it.

Two people reviewed the same submission. One scored the TypeScript a 3 ("types are there but not strict"). The other scored it a 4 ("clean types throughout, good use of typed hooks"). They were both looking at the same code. They just interpreted the rubric differently.

💡 Tip: If two reasonable people can disagree on the score, the rubric isn't specific enough. The problem isn't the reviewers. It's the tool.

Checklists over rubrics

The fix was embarrassingly simple: replace every subjective score with a yes/no checklist.

A single criterion, before and after. This is TypeScript usage:

Before: subjective rubric

Score	Description
5	Strong typing throughout, strict mode, generics where appropriate
4	Clean types, minimal `any`, props and navigation typed
3	Types for main structures, some `any` leakage, works but not strict
2	TypeScript used poorly, frequent `any`, adds little safety
1	`any` everywhere, effectively JavaScript with `.tsx` extensions

The problem: "clean types" and "types for main structures" are both reasonable descriptions of the same code. One reviewer sees a 3, another sees a 4. Both are right.

After: observable checklist

✅ Source files use .ts/.tsx extensions
✅ Interfaces or types exist for API data, state shape, and component props
✅ Navigation params are typed
✅ Zero any in production code
☐  Typed hooks used (useAppSelector, useAppDispatch)
☐  Strict TypeScript enabled
☐  Zod or Yup schemas for validation

Same criterion. Seven checks. Each one is a fact you can verify by looking at the code. Two reviewers will tick the same boxes because there's nothing to interpret.

The first four checks are baseline (any competent candidate will have these in a 4–6 hour submission). The last three are signals of deeper experience. The ordering does the levelling for you.

I did this for every criterion across four sections:

Core Functionality: does the app work?
Data Layer & API: how does it fetch and manage data?
Code Quality: is the code well-written and well-organised?
Testing: is it tested, and how?

100 checks. 100 points. One point each.

Same test, different ceiling

This is the part I'm most excited about. The checks are ordered by how much investment they represent.

The first few checks in each criterion are things any competent candidate will achieve in 4–6 hours:

Does the FlatList render items?
Does pagination work?
Does the party screen have an empty state?
Are there types for the main data structures?
Is there at least one test file?

These are the baseline. If you built the thing the brief asked for, you pass these.

The later checks require more time, deeper experience, or both:

GraphQL instead of REST
Runtime response validation with Zod
MSW for HTTP mocking in tests
Feature-first project structure
BDD with Cucumber
Coverage thresholds enforced

These aren't things you do in a weekend. They're patterns you've learnt from building real production apps.

💡 Key insight: A candidate investing 4–6 hours scores in the 50–65 range. A candidate investing a full week with years of experience might score 85–95. The brief is the same. The expectations scale with the score.

How the levels map

The total score maps directly to a level:

Level	Code review score
Graduate	20–45
Associate	46–64
Software Engineer	65–88
Senior	89–100

The code review score isn't the whole picture. The walkthrough call adds more signal. But the code review is the foundation.

Respecting the time constraint

A tech test is not a production app. Candidates have jobs, families, lives. They're giving you their evening or their weekend. Penalising someone for not implementing a caching layer or not co-locating their styles would be like marking down a timed essay for not having footnotes.

That's why the baseline checks matter. Getting all of them right scores you around 50–60 out of 100. That's Associate to Software Engineer territory. On my old rubric, a "3 out of 5" sounded like a consolation prize. 55 out of 100 on the checklist is a positive result with a clear path to the next level.

What "above baseline" looks like

The later checks are where candidates differentiate themselves. These aren't requirements. They're signals.

A candidate who adds Detox E2E tests with extracted helpers is telling me something about their testing culture.

A candidate who implements GraphQL with Apollo is telling me something about their API thinking.

A candidate who sets up MSW with multiple handler sets (success, error, 401, timeout, offline) is telling me they've debugged production API failures before.

None of these are required. All of them are noticed.

The stretch goals sit on top of the 100 points as bonuses: search, dark mode, accessibility, i18n, feature-first structure, Storybook, ErrorBoundary. These are the marks of someone who had time and chose to invest it wisely.

The walkthrough changes everything

The code review gives me a number. The walkthrough gives me context.

A candidate who scores 65 on the code review might jump to 85 after the walkthrough if they can articulate every trade-off, explain what they'd change with more time, and navigate their codebase from memory. The number measures what they built. The conversation measures how they think.

I designed the walkthrough as a set of question tables. Each question has five signal descriptions, from "can't find the code" to "explains it from memory with edge cases." The interviewer ticks one row per question. No more "was that walkthrough a 3 or a 4?"

For Senior candidates, there's an additional system design section in the same call. No separate interview. The last 15–20 minutes shift from "show me your code" to "how would you design this for a team of 20 engineers?" The same question tables, the same tick-one-row format.

What I learnt building this

Building this scorecard taught me more about hiring design than anything I've read about it. The lessons that stuck:

Start with checklists, not rubrics. Every time I wrote a rubric ("5 = excellent, 3 = good, 1 = poor"), it turned into a debate about what "good" means. Checklists end the debate. Either the thing exists in the code or it doesn't.

Order the checks by investment, not importance. The first checks aren't more important than the last. They're just more achievable in 4–6 hours. A Senior candidate who skips check 3 but nails check 7 isn't penalised for the skip because the total still reflects their level.

Separate what you can see from what you need to ask. The code review scorecard is 100% observable from the code. No "is the architecture clean?" questions. The walkthrough is 100% conversational. No code-reading during the call. Each document has one job.

Respect the time constraint. If a check would require more than 6 hours of work from a competent Software Engineer, it belongs in the upper half of the checklist, not the baseline. I kept catching myself writing baseline checks that were really Senior expectations. The question I kept asking: "Would I expect this from someone doing this test after work on a Wednesday evening?" If the answer was no, it moved up.

It's still evolving

I've used this scorecard for our first round of React Native hiring. My peer EM reviewed it and adopted it for his squad's hires too. That's the test of a good system: someone else can pick it up and use it without you in the room.

I'm not pretending it's perfect. The levels might need recalibrating after more candidates go through. Some checks might turn out to be too easy or too hard. The stretch goals might need rebalancing.

The structure is right though:

✅ Checklists, not rubrics
✅ Observable facts, not opinions
✅ Ordered by investment
✅ Same test for everyone
✅ Different ceiling for different levels

If you're building a hiring process and your interviewers keep disagreeing on scores, try replacing your rubric with a checklist. You might be surprised how much agreement you get when you stop asking "how good is this?" and start asking "is this here?"

If you want the candidate's perspective on what this scorecard evaluates, I wrote a companion post: How to pass a React Native tech test.

The best scoring systems don't measure how you feel about the code. They measure what's in the code.

How to pass a React Native tech test

Warren de Leon — Mon, 06 Apr 2026 07:30:11 +0000

This is from the other side of the table

I review React Native tech test submissions. I've seen what gets people hired and what gets them rejected. Most of the rejections aren't because the candidate can't code. They're because the candidate didn't show the right things.

This post is the advice I'd give a friend before they submitted a take-home tech test. Not theory. Specific, practical things that move you from "maybe" to "yes."

I wrote about why I redesigned a tech test from the hiring manager's perspective in a separate post. This one is the other side: how to pass one.

Read the brief twice. Then read it again.

Sounds obvious. It's the most common mistake.

If the brief says "build three screens with navigation," don't build two. If it says "use TypeScript," don't use JavaScript. If it says "manage a list of up to 6 items," make sure adding a 7th is handled gracefully.

Reviewers check requirements like a checklist. Every missing requirement is points dropped. Not because we're pedantic, but because following a spec is part of the job. If you miss requirements in a tech test with a clear brief, what happens with a vague Jira ticket?

💡 Tip: Read the brief before you start. Read it again halfway through. Read it one final time before you submit.

Project structure matters more than you think

The first thing I do when I open a submission is look at the folder structure. Before I read a single line of code, the structure tells me how you think.

Type-first structure (screens/, components/, hooks/, services/):

src/
  components/
  hooks/
  screens/
  services/
  types/

Feature-first structure (each feature is self-contained):

src/
  features/
    product-list/
    product-detail/
    favourites/
  shared/
    components/
    hooks/

Neither is wrong. But feature-first shows you've thought about how the app scales. If I ask "what happens when 5 teams work on this codebase?" and your structure already answers that question, you're ahead.

🚩 Red flag: Everything in a flat src/ folder with no organisation. It suggests the coding started before the architecture was planned.

TypeScript is not optional

Even if the brief says "TypeScript preferred," treat it as required. Submitting plain JavaScript in 2026 is an automatic downgrade.

But it's not enough to just use TypeScript. Use it well:

Do this	Why it matters
Type your props	Every component should have a typed props interface
Type your API responses	Don't use `any` for data from the server
Type your navigation params	React Navigation has excellent TypeScript support

The one any I'll forgive: complex third-party library types that would take an hour to figure out. Acknowledge it in a comment. "// TODO: type this properly — ran out of time" is better than pretending it doesn't exist.

🚩 Red flag: any scattered throughout the codebase with no acknowledgment.

State management: pick something and own it

I don't care whether you use Redux Toolkit, Zustand, React Context, or Jotai. I care that you picked it deliberately and can explain why.

Choice	What it signals
Context for a three-screen app	Perfectly reasonable. Lightweight, no dependencies.
Redux Toolkit for a three-screen app	Fine, but I'll ask why. "It's what I know best" is an honest answer.
Zustand with a clean store	Shows you're current with the ecosystem.

If you go with Redux, use Redux Toolkit. Not the old switch/case reducer pattern. If I see createStore instead of configureStore, or manual action type constants instead of createSlice, it suggests the Redux knowledge might need refreshing.

What actually matters:

✅ State logic separated from the UI
✅ Actions, reducers, and selectors in their own files
✅ Business rules (like max party size) enforced in the state layer
✅ Updates are predictable
❌ Business logic living inside components
❌ State scattered across useState calls with no pattern

Don't dispatch a fetch every time a screen mounts. If I navigate to a detail screen, go back, and navigate to the same detail screen, I shouldn't see a loading spinner again. A simple if (!data[id]) check before your dispatch(fetchDetails(id)) is enough.

Tests: quality over coverage

You don't need 90% coverage. You need meaningful tests. Three good tests beat twenty snapshot tests.

What I want to see:

Test type	Example
Business logic	If there's a rule (max 6 in a list, no duplicates), test it. Reducers and selectors are the highest-value tests.
User interactions	Render a component with RNTL, press a button, check the result. Use `render`, `fireEvent`, `waitFor`.
Edge cases	What happens when you add a duplicate? When the list is empty? At the pagination boundary?
Passing tests	Run them before you submit. Failing tests signal unfinished work.

What I don't want to see:

❌ Snapshot tests everywhere. They break on every UI change and prove nothing about behaviour.
❌ Tests that mock everything. If your test mocks the function it's testing, it's testing the mock.
❌ No tests at all. This is a hard one to recover from in the walkthrough.

💡 Tip: 5-10 focused tests covering the critical paths. Reducers, selectors, key interactions. That's enough.

Handle loading, errors, and empty states

This is where candidates stand out. Anyone can build the happy path. The question is: what happens when things go wrong?

State	What to do
Loading	Show a spinner or skeleton on first load. Show a subtle indicator during pagination. Don't flash a full-screen spinner for 100ms.
Error	If the API fails, tell the user. A retry button is better than nothing. An informative message is better than "Something went wrong."
Empty	If the list is empty or there are no saved items, show something useful. Not a blank screen.

🚩 Red flag: The app crashes on a slow network. No loading state, no error handling. The reviewer opens DevTools, throttles the network, and the app falls apart.

The API call matters

GraphQL vs REST: if the brief offers both, GraphQL is the stronger choice. It shows you can work with modern API patterns. But a well-implemented REST client beats a messy GraphQL setup.

Use FlatList or FlashList. Never ScrollView for lists. ScrollView renders every item at once. With 100+ items, you'll see frame drops, memory spikes, and eventual crashes. FlatList virtualises the list, only rendering what's on screen. If I see a ScrollView wrapping a .map() for a data list, it suggests a gap in understanding React Native's rendering model.

Other things that get noticed:

✅ Caching: don't refetch data you already have
✅ Pagination: don't fetch 1000 items on first load
✅ ErrorBoundary: catches JavaScript errors and shows a fallback instead of a white screen

Edge cases are where you stand out

The happy path is the minimum. What separates a Software Engineer submission from a Senior one is edge case handling:

Full list? What happens when someone tries to add a 7th item? A toast, a disabled button, a modal. Anything except silently failing.
Empty list? Show a meaningful empty state, not a blank screen.
Rapid taps? Does pressing "add" five times fast cause duplicates or crashes?
Back navigation? When I go from detail back to the list, is my scroll position preserved?
End of list? Does pagination stop cleanly when there's no more data?

You don't need to handle all of these. But handling some of them shows you think about real users, not just passing requirements.

The README is part of the test

Write a README. Not a novel. A short document that covers:

Section	What to write
How to run it	`yarn install`, `yarn ios`, done. Extra steps documented.
What you built	One paragraph summary.
Decisions you made	Why this state management? Why this folder structure? Two sentences each.
What you'd improve	This is the most important section. It shows self-awareness.

💡 The "what I'd improve" section is a cheat code. It lets you acknowledge shortcuts without the reviewer discovering them as flaws. "With more time, I'd add E2E tests with Detox and implement proper caching" turns a missing feature into a demonstration of judgement.

The walkthrough: this is where jobs are won

If the test has a walkthrough call, prepare for it. The code got you into the room. The walkthrough gets you the offer.

Know your code. If I say "show me where you handle the API response," you should navigate there in under 5 seconds. If you hesitate, it can raise questions about how well you know the codebase.

Explain your trade-offs. Don't wait for me to ask. When you show a section of code, say "I chose this approach because X, but I know the trade-off is Y." That's the answer I'm looking for before I even ask the question.

Be honest about shortcuts. "I used Context here because it was faster, but in a production app I'd move to Zustand once the state got more complex." That's a strong answer. "I think Context is the best approach" is a weaker one.

Have a list of improvements. When I ask "what would you change with more time?" the worst answer is "nothing, I'm happy with it." The best answer is a prioritised list: "First I'd add caching, then E2E tests, then refactor to feature-first folders."

Ask questions back. The best walkthroughs are conversations, not presentations. Ask about the team's architecture, their testing approach, their deployment process. It shows you're evaluating the role too, not just hoping to pass.

Stretch goals: do them, but do them well

If the brief mentions optional extras, pick one or two that you can do well. Don't try to do all of them poorly.

Worth picking	Why
Search/filter	Quick to implement, immediately visible, shows UX thinking.
Accessibility	Labels, roles, contrast. Most candidates skip this. Even basic accessibility makes you stand out.
Error/offline handling	A retry button when the network fails. Shows real-world thinking.

Avoid unless you can do them properly	Why
Animations	Half-finished animations look worse than no animations.
Dark mode	If it's not consistent across every screen, it's a liability.

💡 One well-executed stretch goal is worth more than three half-finished ones.

The mistakes that actually cost people the job

These aren't about code quality. They're about signals.

Mistake	Why it hurts
Not reading the brief properly	Missing a core requirement. Building two screens when the brief says three.
No tests at all	Even two or three tests show you care about quality. Zero is a strong negative signal.
AI-generated code you can't explain	Using AI to help is fine. Submitting code you don't understand is not. This becomes apparent during the walkthrough.
Overengineering	A tech test doesn't need a design system and a micro-frontend architecture. Build what the brief asks for, well.
Submitting late without communicating	If you need more time, ask. Going silent and submitting three days late is a red flag.

The one thing that matters most

Show that you think. Not just that you code.

Anyone can build screens. The candidates who get hired are the ones who demonstrate judgement: why they chose this approach, what they'd do differently, where the code would break at scale, what tests actually matter.

The tech test isn't testing whether you can write React Native. It's testing whether you can make good decisions and communicate them clearly.

Build something clean, test the important parts, document your thinking, and be ready to talk about it honestly. That's it. That's the whole secret.

We're hiring! We're looking for React Native engineers to join the Mobile Platform team at Hargreaves Lansdown. View open roles.

Why I redesigned our React Native tech test in my first week

Warren de Leon — Sun, 29 Mar 2026 14:48:16 +0000

A test built for a different time

Four days before I officially started at Hargreaves Lansdown, I went into the office for a passport check. While I was there, my manager mentioned I'd be hiring a team. My first question was whether I could change the interview process. He said yes. I hadn't even had my first day yet. By the time I started on the 23rd, I was already building the new test.

I'm the new Engineering Manager for the Mobile Platform squad. We're rebuilding HL's mobile app in React Native, a brownfield migration from the existing native iOS and Android apps. I need engineers who can work at the platform level.

I didn't need to ask to see the tech test. I'd been through it myself just weeks earlier. It's how HL hired me: a live coding exercise where you build a small app in about an hour with the interviewer watching, followed by technical questions from a questionnaire. The whole interview ran about 90 minutes.

The test made sense for its original context. When the team was smaller and hiring for different roles, it was a reasonable way to screen candidates quickly. But our needs had changed. We weren't hiring someone to build simple screens anymore. We were hiring platform engineers who'd own the architecture that every other mobile team at HL would ship through.

I needed the test to answer different questions:

Can they structure a multi-screen app with navigation that doesn't fall apart?
Can they call a real API and handle what happens when the network fails?
Do they write tests because they care about working software, or because someone told them to?
Can they sit across from me and explain why they built it that way?

The existing test was designed for different questions. I needed to build something around ours.

The limits of live coding

Live coding can tell you whether someone codes comfortably under observation. For some roles, that matters. For ours, I needed to see something different.

I've been on both sides. As recently as January this year, I bombed a live coding exercise for a role I was perfectly qualified for. The problem was simple. I knew how to solve it. But with someone watching my every keystroke, my mind went blank. I didn't pass.

As an interviewer, I've watched the same thing happen to candidates. Strong engineers who freeze on problems they'd solve in five minutes at their own desk. Live coding measures composure under observation. That's a valid signal for some roles, but it wasn't the signal I needed.

For a platform engineering role, where the work is architecture decisions, design system components, and CI/CD pipelines, I wanted to see how candidates approach problems with time and context. The kind of thinking the job actually requires.

Showing vs telling

The previous process also included a technical questionnaire. The interviewer would pick questions from a reference sheet covering React Native architecture, state management, testing strategies, and platform differences, then compare answers against expected responses. Sometimes candidates would naturally cover the topics during the live coding, and the interviewer would skip those questions.

These are all valid topics. They're exactly the things I want my engineers to understand. Asking someone to explain a concept tells you whether they understand the theory. Seeing how they apply it in their own code gives you a different kind of signal.

The new process tests the same topics through the candidate's own code. Instead of asking "how would you structure navigation in a complex app?", I can open their submission and see how they approached it, then have a richer conversation about the choices they made. The walkthrough still covers architecture, trade-offs, and technical depth, but it's grounded in something the candidate built.

What I built instead

I designed a take-home assessment. A small but real app: multiple screens, a public API, navigation, state management with actual business rules, TypeScript throughout. Not a toy. Not a weekend project either. Something that requires genuine architectural thinking.

Four principles guided the design:

Mirror the actual job. The test should feel like the work. If a candidate can build this app, they can contribute to our codebase on day one. If they can't, that's useful information too.

Remove the boilerplate tax. I give candidates a fully configured starter project. TypeScript, ESLint, Prettier, Jest, React Native Testing Library, path aliases. All set up. I don't care whether someone can configure a bundler. I care whether they can write application code.

Be clear about what, not how. The brief explains what the app should do. It never says which state management library to use, how to structure the folders, or which API client to pick. Those decisions are the most revealing part of the submission. A candidate who picks Redux Toolkit for a three-screen app tells me something different from one who picks Zustand or React Context. Neither is wrong. Both are interesting.

Respect people's time. Candidates get a week. The work should take 4 to 6 hours. People have jobs, families, lives. No one should have to take a day off to do a tech test for a company that might not hire them.

The walkthrough is where the magic happens

The take-home code is half the evaluation. The other half is a walkthrough call: the candidate demos the app, runs their tests live, and walks through the code.

This is where you learn how deeply someone understands what they built. In the age of AI-assisted development, that understanding matters more than ever.

Three things I'm looking for:

Ownership. "Navigate to the file where you handle the API response." If they wrote it, they'll jump straight there. If they're not fully comfortable with the codebase, that becomes clear quickly.

Trade-off thinking. I ask about every significant decision. "Why this state management approach?" The answer I want isn't "because it's the best." The answer I want is "because it fits this scope, but here's where it would break down, and here's what I'd move to." Engineers who think in trade-offs build better systems than engineers who think in absolutes.

Self-awareness. "What would you change if you had more time?" Strong candidates light up at this question. They have a list. They know where they cut corners. They know what's fragile. They've been thinking about improvements since they submitted. Less experienced candidates tend to say "I'm happy with it" and move on.

Structured scoring

One thing I wanted from day one was a structured scorecard. When you're scaling a team and multiple people are involved in hiring, everyone needs to evaluate the same things in the same way. Without that, two interviewers can review the same candidate and reach different conclusions because they're weighting different things.

I built a scorecard that breaks the evaluation into weighted sections: does the app work, is the data layer sound, is the code well-structured, are there tests, and can the candidate explain it all in the walkthrough. Each section has specific criteria on a consistent scale. Every interviewer evaluates the same things in the same order.

The scorecard also maps scores to levels. A number tells you whether someone is Graduate, Associate, Software Engineer, or Senior level. This removes ambiguity from the levelling conversation. The rubric does the thinking. The humans verify it.

Senior candidates get a harder round

For senior hires, there's an additional system design conversation. No whiteboard. No "design Twitter in 45 minutes." We talk through real scenarios relevant to the platform we're building. What changes when 20 teams build on the same mobile platform? How do you handle shared dependencies? What's your approach to backwards compatibility?

It's a conversation between two engineers, not a performance for an audience. The best candidates push back on my assumptions and ask clarifying questions. That's exactly the behaviour I want from a senior on the team.

Early days

In my first week at HL, I hired a Senior Engineer through the existing process (that happened on day two, before the new test was ready). Going forward, the new process is the standard for all React Native hiring across the UCX-Core tribe. My peer EM, who runs another squad, reviewed the test and the scorecard and agreed to adopt it for his team's hires too. That's the advantage of a well-documented system: it scales beyond one manager's squad.

I'm about to hire two Software Engineers using the new process. Every candidate will get the same test, the same starter project, the same evaluation criteria, and the same scoring rubric. The bias surface area shrinks when you standardise.

The lesson

If you're joining a new team as an engineering manager, look at the hiring process early. Don't wait until you've "learned the codebase" or "understood the culture." Hiring is one of the highest-leverage activities you have. Every person you bring on shapes the team for years.

And if your tech test no longer matches what you're hiring for, it's worth revisiting. The best hiring processes evolve alongside the team's needs.

Design a test that mirrors the actual job. Give candidates a starter project so you're testing engineering, not configuration. Make the requirements clear but let them make their own decisions. Then sit across from them and ask why.

The combination of thoughtful take-home code and a structured walkthrough gives you more signal in two hours than any live coding exercise gives you in two days.

If you're preparing for a React Native tech test, I wrote a companion post with practical advice: How to pass a React Native tech test.

We're hiring! We're looking for React Native engineers to join the Mobile Platform team at Hargreaves Lansdown. View open roles.