DEV Community: Warren de Leon

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 at Hargreaves Lansdown, 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 at HL. 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.

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

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.