What this prompt does
This prompt runs a timed frontend coding interview against you rather than just handing over a finished component. It asks the AI to assign a build task for a [component] in [framework] with no UI libraries, then enforces a realistic requirement set: keyboard accessibility across Tab, Enter, Escape, and arrow keys, ARIA attributes for screen readers, a defined list of [states], responsive behavior, performance discipline, and a specific [styling_approach]. It plays the interviewer, so you build first and get evaluated after, which mirrors the pressure of a real onsite far better than open-ended practice does.
The variables define both the scope and the bar you are held to. [edge_cases] forces you to handle the gnarly parts a real interviewer probes, like debouncing rapid input, surviving an API failure, or escaping untrusted result text. [test_count] sets how many unit tests you must write covering the key interactions, and [time_limit] adds the clock that changes how you prioritize. After you submit, the AI scores Functionality, Accessibility, Code Quality, and Edge Cases at 25% each, then provides an ideal solution to compare against so you see exactly where you lost points.
When to use it
- Practicing for frontend onsite rounds where you build a component live in front of an interviewer
- Drilling keyboard and ARIA handling, which candidates routinely under-prepare for
- Rehearsing under a time limit so you pace yourself correctly on interview day
- Pressure-testing your re-render discipline and state handling in
[framework] - Reviewing an ideal solution after your own attempt to find blind spots
- Practicing the styling constraint cleanly when component libraries are off the table
Example output
First you get a structured interview brief: the component task, the explicit requirement list, the [states] to handle, the edge cases, the test count, and the clock. After you submit your code, the AI returns a scored evaluation broken into the four weighted categories with specific written feedback on each, followed by an ideal reference implementation you can diff against your own to spot the gaps.
Pro tips
- Set
[component]to something genuinely hard for you (autocomplete, modal, virtualized list) rather than a button - Match
[framework]exactly to your target role so the patterns and idioms transfer directly - Keep
[time_limit]honest; finishing late tells you more about your readiness than a generous clock does - List the
[edge_cases]you personally tend to forget so the drill targets your actual weak spots - Treat the four-part rubric as a checklist while you build, not just an after-the-fact score
- Ask for the ideal solution only after you submit, so you do not anchor your own attempt on it
