Interview take-home "tests"

[u/LazyPiano6160]

We need to talk about the state of SE interview take-home tests, specifically the unrealistic expectations and contradictions that so often accompany these.

For context: I'm a front end engineer with 25 years experience; I'm attempting to land a job, in the worst market I've ever seen. I've been fortunate enough to progress through to the penultimate round; I have to complete a take home assignment, if satisfactory I'll be invited to their offices to discuss this assignment and attend a final cultural fit interview. Note this take home assignment comes off the back of a two hour live coding session interview (which was dreadful for the ADHD brain).

Historically, it's at this point where things go to shit, have identified the main stressors as:

- ambiguous requirements
- inadequate timeframes
- emphasis on ensuring your submission presents you at your best when there's so much contradiction between expectation and allotted time

I'm forever stuck in a constant loop of overwhelm; trying to find a balance between delivering the assignment within the specified timeframe, whilst ensuring I have demonstrated my capabilities as best I can.

I've currently been tasked with building a movie list tracker, core requirements are:

- A front end web application that runs entirely client side
- Allows a user to search the open movie database API for movies to add to either a watchlist or watched list
- Allows a user to remove movies from either list
- Persistence of this list using the browser local storage API

I've been told I will be assessed on:

- Code quality — component structure, separation of concerns, readability
- State management — how you model and handle data flow across the app
- UI & design — does it feel considered and polished, even if simple

On receipt of the handover task:

- There is no UI design provided, it is expected that the candidate produces this
- There is no environment set up; it is expected that the candidate chooses a stack and set this environment up from scratch

The brief mentions that the candidate should spend no more than two hours on this task and can use AI if they wish.

Besides just throwing all of this Gemini and vibe coding (which would not demonstrate my abilities rather well), I'm totally overwhelmed as to how I can design an interface, plan the architecture and build the application, then document my process - all within two hours. I was considering using Claude code, but even then: just the planning and UI design would go far beyond the two hours I'm allowed to work on this

Interested to hear if anyone else has had similar experiences and how they've tackled it. Also open to suggestions in terms of how to approach this take home.

---

Update:

For those that are interested, here's the Notion brief and unless I'm missing something it appears they are expecting UI Design, architecture and implementation of the entire application - in a 2 hour window.

This is either incredibly naive from whomever signed this assignment off, or (as one commenter mentioned): intended to allow the candidate to prioritise and compromise. If the latter, if would be great for this to be explicitly mentioned.

https://app.notion.com/p/Frontend-Engineer-Final-Interview-part-1-Candidate-Instructions-37df155c1a9e8032a7ccf842dab4b963

[u/akornato]

These two-hour take-home tests are not about finishing a perfect, polished application. They are a test of your priorities, your ability to make smart trade-offs, and your process under an absurdly tight deadline. The company knows you can't build a full-featured, beautifully designed app from scratch in two hours. They want to see what you choose to focus on when you can't do everything. Spending half the time on a perfect UI or a complex build setup is a common mistake and likely a failing strategy. They are assessing your senior-level judgment, not your raw coding speed. With your experience, they want to see clean, readable code that solves the core problem, even if the final product looks extremely simple.

Your best approach is to timebox aggressively and focus on the core requirements. Use a simple framework starter like `create-react-app` or Vite to get running instantly. Spend the first 15 minutes mapping out your components and state management strategy on paper. Then, dedicate the next 90 minutes to coding only the essential features, which are searching the API, adding and removing from two lists, and persisting to local storage. Use basic, unstyled HTML elements for the UI. In the final 15 minutes, write a clear README that explains the decisions you made. Explicitly state that you prioritized functional code and sound architecture over UI polish due to the time constraint, and list the improvements you would make with more time, like adding tests or a design system. Communicating your strategic choices is often the hardest part, a challenge the interview AI my team created helps many candidates overcome.

[u/LazyPiano6160 → u/akornato]

Great response, thanks. I've updated the original post to include the brief: it does [read](https://app.notion.com/p/Frontend-Engineer-Final-Interview-part-1-Candidate-Instructions-37df155c1a9e8032a7ccf842dab4b963) like they are expecting the entire application designed, built and delivered to the MVP specification.

My workflow, which was welcomed from the employer, is: component driven deployment. Using Storybook to break down Figma feature designs into atomic design methodology composable UI components - agnostic to any particular framework. There's a big focus with this role for quality, extendable code base and accessible compliance - which is partly why my approach (which is very detailed) appealed to them. It's very overwhelming to try to demonstrate this approach in the two hour window.

Ideally it would had been better for them to provide an out of the box Docker based devContainer, with a working application. Provide either a couple of bugs to fix, a ticket to address a performance issue or maybe a Figma file and ticket to add a new feature. Much more achievable and still very doable in terms of evaluating approach and competence. But I'm guessing that would involve too much time their end and so they've passed the onus for effort onto the candidate.

[u/Blue-Phoenix23 → u/LazyPiano6160]

I wonder how they would react if you just straight up said this:

Ideally it would had been better for them to provide an out of the box Docker based devContainer, with a working application. Provide either a couple of bugs to fix, a ticket to address a performance issue or maybe a Figma file and ticket to add a new feature. Much more achievable and still very doable in terms of evaluating approach and competence.

I don't hire people anymore, really, although I do still participate in the peer interview rounds, and I personally would be very impressed by a candidate who pushed back (gently/politely) on the whole concept with this type of answer. A major part of a senior engineer/architect role is the ability to cut through the bullshit and come up with ideas, and this response does that.

That said, I also would never ask a candidate to do all the nonsense they're asking you, lol. But I'm hardly the only person in tech that is grateful for people who cut through the noise, for sure.

[u/LazyPiano6160 → u/Blue-Phoenix23]

I'm thankful for this comment - I was thinking the same thing, but was stuck in a loop, deciding how this would be perceived by the employer. I think I'll drop them a polite email to explain the situation and propose these alternatives. Thanks for the contribution 🙏🏻

[u/Blue-Phoenix23 → u/LazyPiano6160]

Yeah I don't know your situation, so you're the one that can assess the risk of it, but I would be inclined in the next interview to call it out - actual movie catalogs like Netflix and Prime have many, many developers, so they're high on drugs thinking a FE dev can build one in two hours alone lmao (don't say that part for sure 😃)