Designing a Take-Home Assignment for Senior Frontend Engineers

/
hiringengineering

I’ve reviewed dozens of take-home assignments at North. After a while, you start seeing patterns—what separates a great submission from a forgettable one, and what tells you everything you need to know before reading a single line of code.

Here’s how we designed our senior frontend take-home, and what I’ve learned from evaluating them.

The Assignment

We ask candidates to build a FinOps dashboard—a single-page summary view with data visualization and metrics. It’s similar to what we actually build at North, so it tests practical skills, not algorithm trivia.

The constraints:

  • Time: 5-6 hours of work, due within 5 business days
  • Stack: Svelte preferred (it’s what we use), but React or Vue are fine—I can read all three, and transitioning someone to Svelte isn’t hard

We’re intentionally limiting the time. We don’t want candidates spending a weekend on this. We also track how long they spend—it’s a useful signal.

What I Look For

I spend about 20-30 minutes per submission. Before I even open the code, I already know a lot.

The basics:

  • Did they complete the required points? (If not, it’s over)
  • Did they attempt any bonus points? (Shows initiative)
  • Did they add anything we didn’t ask for? (This is the real signal)

Before reading code:

  • Is it deployed? (Takes 5 minutes, tells me they care)
  • Is there a README with clear build instructions?
  • Public or private repo?
  • How much time did they spend?

In the code:

  • TypeScript usage—actual types, not any everywhere
  • Component structure—is it scalable or a single 500-line file?
  • Styling consistency—pick Tailwind or CSS files, not both randomly mixed
  • Design attention—colors, spacing, transitions, animations

Red Flags & Instant Rejections

Some things end the review immediately:

  • Required points not completed
  • No deployment AND no build instructions (I can’t even see it)
  • Design looks broken or zero-effort
  • The project doesn’t build

Minor things that hurt but aren’t instant rejections: inconsistent code style, TypeScript with escape hatches everywhere, over-engineered solutions for simple problems.

What Great Looks Like

The best submission I’ve reviewed wasn’t just complete—it was thoughtful.

They matched the design precisely. Transitions and animations were smooth. The code was clean and well-structured. Components were organized in a way that could actually scale.

But what stood out: they added testing without being asked. They deployed without it being required. They went beyond the checklist because they wanted to, not because we told them to.

That’s the difference between someone completing an assignment and someone showing you how they actually work.

Advice for Candidates

If you’re doing a take-home, here’s what I’d tell you:

  1. Deploy it. Always. Vercel and Netlify are free and take 5 minutes. Not deploying signals that you didn’t care enough.

  2. Do at least some bonus points. Only doing the required points is a C grade at best. The bonus points exist to let you stand out—use them.

  3. Add something that shows you care. Testing, documentation, an animation, a loading state we didn’t specify. Small things add up.

  4. Consistency over cleverness. Pick a styling approach and stick to it. Use TypeScript properly or don’t use it at all. A simple, clean solution beats a clever, messy one.

The take-home isn’t just about whether you can code. It’s about how you work when no one’s watching.