Karol Modelski

Posted on Apr 2 • Originally published at javascript.plainenglish.io

The Senior Angular Take‑Home That Made Me Rethink Tech Interviews

#career #softwaredevelopment #development #angular

I spent an entire weekend building a “small” take‑home assignment.

Friday to Monday. Stock data app. Real‑time updates. Angular, WebSockets, Supabase mock.

On Monday, I submitted the repo.

On Tuesday, I got the rejection.

No call. No detailed feedback. Just “we’ve decided not to move forward.”

That was the moment I realized something: most companies have no idea what they’re actually testing when they give senior devs take‑home assignments.

The Assignment That Ate My Weekend

The brief, simplified, looked like this:

Build a small Angular app that displays stock data for up to 4 companies
Load initial data via HTTP from a public API
Implement real‑time price updates using: — a custom WebSocket server (backend) — and a mocked implementation in Angular
Allow toggling updates per stock card (enable/disable)
Reflect price changes visually (increase / decrease / disabled states)
Create a responsive UI (desktop + mobile)

On paper, it was reasonable.

It touched all the right buzzwords: HTTP, WebSockets, real‑time updates, responsiveness, toggles per card.

If you’ve only shipped todo apps, this is a sexy challenge.

If you’ve spent years in production Angular codebases, it’s just a very compressed slice of real work.

I got the task on Friday. I submitted on Monday.

In between, I did what seniors are supposed to do: I treated it like a real mini‑project, not a quick coding kata.

My Goal: Not Just “Make It Work”, But “Show How I Work”

I wasn’t trying to just tick boxes with the bare minimum implementation.

My goals were:

show architecture decisions ,
show how I handle messy APIs ,
show how I think about real‑time behavior ,
keep overall code quality at a level I’d be happy to merge into a real repo.

So I:

structured the app so HTTP and WebSocket logic weren’t glued to the UI,
made sure each card’s real‑time subscription could be toggled cleanly,
handled visual state for price up / down / disabled,
paid attention to responsiveness for both desktop and mobile.

And then the data source decided to be… the internet.

The API Was Flaky, So I Did What Production Me Would Do

The assignment used public, free stock data.

That sounds fine, until you remember what “public, free” usually means:

rate limits,
inconsistent responses,
occasional downtime,
weird edge cases on weekends and off‑hours.

The WebSocket data wasn’t consistent either.

Sometimes it would lag, sometimes it would drop, sometimes it would just stop updating.

For a weekend project, you have two choices:

Pretend it’s fine, hack around the issues, and hope the reviewer doesn’t notice.
Treat it like a real integration: build a mock , stabilize your domain logic, and make your app deterministic for review.

I chose option 2.

I built a mock WebSocket implementation in Angular so I could:

simulate consistent price updates,
test toggling updates on/off per stock card,
guarantee the app behaves correctly even if the real API is having a bad day.

From my perspective as a senior dev, that was the right call:

decouple the app from a flaky external system,
make real‑time behavior testable,
keep the “real API” path around, but not rely on it for correctness.

In other words: I tried to behave like someone who’s shipped production apps, not like someone doing a school exercise.

What the Company Probably Saw Instead

Here’s my guess about what happened on their side.

They cloned the repo.

They followed the steps.

They ran the app with the “real” public data.

And depending on the timing and the API mood, they may have seen:

delayed or missing updates,
weird lulls in price changes,
behavior that didn’t look “smoothly real‑time”.

If they didn’t read the README carefully, or didn’t flip into the mock mode, my architectural decision probably looked like… a bug.

No context. No understanding that I built the mock because the public stream is unreliable.

Just: “The WebSocket behavior is not solid. Next candidate.”

That mismatch is what made me rethink the entire premise of senior take‑home assignments.

What This Assignment Actually Tested (and What It Didn’t)

On the surface, it looked like it tested:

Angular skills,
HTTP and WebSocket handling,
real‑time UI,
responsiveness.

In practice, it tested something else:

who is willing to burn a weekend to impress a company,
who optimizes for the demo , not for production reality,
who can guess what the reviewer cares about , without any conversation.

Because here’s the thing: as a senior, you are constantly balancing trade‑offs.

If this were a real client project, I would have:

clarified API reliability up front,
negotiated scope (“do you want a pretty demo or a robust integration?”),
documented the limitations,
decided with the team how much time to spend on mocks vs building around the real feed.

In a take‑home, you get none of that.

You just guess, implement, and hope your guess lines up with whatever the reviewer imagines “good” looks like.

If you optimize for elegance and robustness, they might say you “over‑engineered a small task”.

If you optimize for a quick, hard‑coded demo, they might say you “lacked senior‑level architecture thinking”.

You’re taking a test with no answer key.

That’s not a tech interview. That’s a silent compatibility test with someone’s private taste.

The Senior Work That Never Shows Up in Take‑Homes

The more I thought about it, the more I realized how much real senior work this assignment couldn’t see:

Clarifying incomplete or unrealistic requirements.
Pushing back on scope when someone tries to cram a sprint into a weekend.
Deciding when to build a mock, when to live with flakiness, and when to say “this API is not acceptable for production”.
Communicating trade‑offs to non‑technical stakeholders.
Designing an architecture that won’t explode in six months.

Instead, the process mostly evaluated:

how quickly I could implement a small greenfield UI,
how much free time I had between Friday and Monday,
how well my decisions matched a reviewer I’ve never spoken to.

That’s not a tech interview.

That’s a silent compatibility test with someone’s private taste.

Why I Think Most Senior Take‑Homes Are Misaligned

This experience clarified a few things for me.

1. They confuse “time sacrifice” with “commitment ”

If you’re willing to burn your weekend to build a polished app, it’s read as “motivated”.

If you timebox yourself and refuse to over‑invest, it’s read as “not hungry enough”.

In reality, the person who protects their time and still delivers a solid, well‑scoped solution is probably a better long‑term hire.

2. They test mid‑level implementation, not senior judgment

Building a small stock app from scratch shows you can:

wire up components,
call APIs,
handle events,
add some responsiveness.

That’s mid‑level baseline.

It doesn’t tell you how someone:

handles legacy code,
refactors a 500‑line component,
improves CI,
unblocks a team stuck on a bad architecture decision.

If you want to know whether I can rescue your Angular app, don’t ask me to build a toy in a weekend.

If you want to know whether I can rescue your Angular app, don’t ask me to build a toy in a weekend.

Show me your worst component and ask how I’d detox it.

3. They ignore how seniors actually work in 2026

In real life, I use Claude Code and Antigravity heavily.

Not to cheat, but to:

scaffold modules,
explore alternative designs,
generate boring boilerplate,
fuzz‑test APIs and policies.

If your assignment bans AI and expects me to pretend it’s 2014, you’re not testing my real workflow. You’re testing my ability to role‑play a slower version of myself.

The future senior is the one who brings the architecture and judgment , uses AI to implement faster, and still understands what’s happening under the hood.

What a Better Senior Angular Take‑Home Could Look Like

Instead of “build a stock app from scratch over the weekend”, here’s what I’d consider a good senior‑level assignment:

1. Smaller, paid, time‑boxed task

2–3 hours max.
Paid at a reasonable rate.
Clear that they care more about how you think than how many screens you can ship.

2. Refactor an existing messy component

Give a real‑world Angular component that:

is 400+ lines,
mixes data fetching, state, and UI,
has a couple of hidden bugs.

Ask the candidate to:

refactor it,
explain their decisions,
write a couple of tests,
list what they’d tackle next.

That’s a senior skill.

3. Architecture review, not pixel‑perfect clone

Provide a small codebase and ask:

“How would you introduce real‑time updates here?”
“How would you make this testable?”
“Where would you put toggles and state?”

Let the candidate use real tools, real patterns, and real AI support — just like they would on the job.

What I’ll Do Differently Next Time

I don’t regret doing this assignment.

It gave me a free, honest look at how I behave when nobody is watching.

Here’s what I’m changing going forward:

I won’t spend full weekends on unpaid assignments.

I’ll timebox, signal my priorities in the README, and let the result speak for itself.
I’ll over‑communicate constraints and trade‑offs.

If an API is flaky and I build mocks, I’ll make that impossible to miss — in the README and in the UI.
I’ll focus on clarity over cleverness.

Clean, readable, obviously structured code beats elegant but over‑abstracted architecture, especially in a small assignment.
I’ll treat take‑homes as two‑way interviews.

If a company expects free, multi‑day work with vague feedback, that’s a data point.

I’m not just being evaluated — I’m evaluating them.

I’m not just being evaluated in take‑homes anymore; I’m evaluating the companies that ask for them.

I’m still going to build things on weekends.

But from now on, I’d rather ship my own AI‑driven SaaS and fix real bottlenecks than over‑optimize for silent reviewers I’ll never meet.

If you’re a senior dev:

What’s the last take‑home you did that actually tested your real job — not just your free time?

I fix the Angular apps that generalists break.

Karol Modelski is a senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start here: https://www.karol-modelski.scale-sail.io/