What I actually mark in a 45-minute frontend screen

What I actually mark in a 45-minute frontend screen

Photo by Nemuel Sereti on Pexels.

I have hired frontend engineers for more than a decade — EO Charging, THRIVE, and the loops in between. A 45-minute screen is not a puzzle contest. It is a short pairing session. I am trying to decide whether I can put you on a product surface without babysitting the browser. I mark screens the way I mark a PR: can I ship this person into a messy form and trust the next engineer to read the interface?

Most candidates prep the wrong exam. They grind a question bank until the happy path is muscle memory, then go silent until the tests go green. I do not mark that. I mark how you name the work, what you put on the page when the API lies, and whether I can still follow you when the clock is ugly.

If you already ship UI and still walk out of screens unsure why it was a no, this is usually the gap. The Shortlist Scorecard already says it in one line: I need you to name the interface before you chase the happy path. This post is the full list behind that line.

The eight things I actually mark

I am not marking whether the tests go green. I am marking whether you can name the interface, put the ugly paths on the page, talk trade-offs out loud, and leave something a teammate could extend. Silence until green is a no. A partial UI with a clear contract, loading and error states, and a spoken plan is a yes. Below is the eight things I actually mark.

1. Restate the problem and name the interface

Before you type, one sentence: the user, the finished flow, the output. Then name the interface — props, URL, form fields, events that leave the component. I leave when you start typing useState with the prompt still in your head. I stay when you say the list is filterable, parent owns the query, and you will stub the fetch so we can see loading and error first. That sentence is the interview. The code is evidence.

2. Questions that would change the code

Clarifying questions are not politeness. Ask the ones that change the code: keyboard-first? 404 versus a network drop? Form button or a div you should refuse? Two sharp questions beat ten vague ones. “Can I use Google?” does not change a line. If you do not ask, I assume you will invent a happy path and be surprised later.

3. A plan I can interrupt

I need a spoken order of attack I can redirect: markup, state, data, ugly paths, polish. Ship in slices. A labelled form I can tab through at minute twelve beats a clever reducer at minute forty with no DOM. If I say skip the animation and show empty state, I am testing whether you can take a note.

4. Ugly paths before the happy path

Happy path is table stakes. I mark empty, loading, error, and the disabled button that still submits. Say the ugly path before you write the map. Mid-level puts retry on the page. Senior chooses which ugly path to skip because twelve minutes remain, and tells me why. The seven skills I still ask about sit under this: HTML, async, CSS you can debug, React without a buzzword parade.

5. Markup and CSS you can debug

I need a heading that is a heading, a button that is a button, a label that is not a placeholder, and a layout you can explain when it breaks. Forms: form, label, submit, Enter. Lists: list markup and stable keys. Framework comfort is allowed. Framework instead of the document is not. If the layout collapses, I want box model in English, not “Tailwind will fix it.”

6. State you can defend

Props down, events up, one source of truth, effects with a reason. Say why this state lives here and what re-renders. Context for a form value will get a question. I would rather a naive useState you can defend than a cache library you cannot. If you fetch in an effect, tell me what happens on unmount or when the query changes.

7. Accessibility as a default, not a closing remark

I am not running a WCAG audit. I am checking labels, names, keyboard, focus, a real button. “We would run axe in CI” is fine after you have labelled the input. It is not a substitute. Mention a11y before I prompt you. Tab through the form unprompted and I write that down. That difference is the hire.

8. Trade-offs out loud, and a recap

Silence is the fastest no. I cannot quote “typed quickly” in a debrief. I can quote the trade-off: client filter because the list is small; virtualisation skipped, with a reason; debounce goes here. Leave five minutes. Recap what works, what is stubbed, what is next. That recap is how I argue for you after you leave.

Photo by Markus Spiske on Pexels.

What I do not mark

I do not mark a memorised polyfill list, a finished happy path with no contract, or LeetCode speed unless the loop is actually DSA. Most frontend screens are not. See LeetCode is not frontend interview prep. I do not mark a library parade. Name the problem the library solves, then keep building. I do not mark perfect CSS. I mark whether you can change it when I resize the panel. Quiet and clear beats loud and lost. If you are stuck, say so and what you would try.

How the 45 minutes actually run

This is how I run my own screens. Other companies vary. First five minutes: restate, questions, interface, spoken plan. The middle: slices I can see — markup, state, one fetch with loading and error. I will interrupt. That is the job. Last five to eight: stop. Recap. Same muscle as the GitHub pass: what it is, the hard call, what is next. If we never leave the happy path, I already know the debrief.

How to practise this without a live interviewer

A list you have only read is a blog post. Pick one small UI. Time 45 minutes. Talk out loud. Listen back for silence, missing error, missing recap. Do not collect seventy-five named questions and call it a screen.

On CodePrepped that is the daily loop: Arena for timed judgement, Keywords for the words you narrate, Sandbox for the build. Pro adds AI Trainer and Mock Interview — real-time voice practice, four a month. Live pricing: Basic $19/month or $190/year with a 7-day trial on Basic monthly; Pro $39/month or $299/year. One scored loop on these eight marks beats another catalog you will not narrate. Trainer modes are covered in What Pro unlocks.

What to do this week

1. Keep the eight marks next to the editor. Same eight marks every session.
2. One 45-minute sandbox: form or list. Ugly paths first. Recap at minute forty.
3. One Arena bout in your weakest of HTML, CSS, React, or async. One Keywords round on the words you hand-waved.
4. If you have Pro, one Mock Interview or Trainer session against these eight marks, not against “did I finish.”
5. Run the scorecard on the repo you would pin. A strong screen still dies if the profile is expensive to figure out.

Then stop. Repeat the same eight marks. Other notes live on the blog.

What do frontend interviewers look for in 45 minutes?

They look for a person they can pair with on a UI. Restate the problem, name the interface, put empty and error on the page, and talk trade-offs. Finishing every feature is optional. Silent speed-coding is not a pass. If the debrief cannot quote a decision you made, you did not give them anything to hire.

Do I have to finish the exercise to pass a frontend screen?

No. I would rather a labelled form with loading and error, plus a spoken list of what is left, than a complete happy path with no contract. Unfinished work you can defend is a yes. Finished work you cannot explain is a no. Recap beats one more CSS tweak.

Is LeetCode what a frontend screen is testing?

Usually not. Most frontend screens test HTML, CSS, React, async, accessibility, and narration. LeetCode helps when the posting is a generalist DSA loop with a UI title attached. Default to a UI you can explain. I wrote the split in LeetCode is not frontend interview prep.

How should I talk while I code in a screen?

Narrate decisions, not keystrokes. Say what you will build, which ugly path is first, and what you are skipping. If you go quiet to think, say give me twenty seconds. I can work with that. I cannot work with five minutes of typing and a surprise component at the end.

What accessibility do you actually mark in 45 minutes?

The defaults: labels, names, keyboard, focus, a button that is a button. Bonus if you mention contrast or a focus trap and can point at the code. I am not expecting a WCAG recital. I am expecting you not to ship a div with an onClick and call it done.

How do I practise this if I do not have an interviewer?

Timer. One small UI. Voice memo. Same eight marks. Listen for silence, missing error states, and a missing recap. CodePrepped Arena, Keywords, and Sandbox are that weekday loop. Pro Mock Interview is the voice version, four a month. Repeat the same exercise after feedback rather than collecting a new prompt.

What should I do in the last five minutes of a frontend screen?

Stop. Recap what works, what is stubbed, and the next three steps. Offer the trade-off you would still make with another hour. This is the paragraph I quote in the debrief. Chasing a visual bug in the last minutes often costs more than the bug would have.

Does what I mark change for senior frontend interviews?

The eight marks stay. The bar on each one moves. Mid-level can build the error path when asked. Senior names it first, skips the right thing because of time, and defends the interface as if a teammate will own it next week. Senior also turns a portfolio project into decisions, not a tour.