Articles
HackerRank Front-End Assessment: Preview the App, Preserve Test Hooks, and Submit Working UI
Prepare for a HackerRank front-end project by previewing the app, preserving tested DOM hooks, verifying behavior, and submitting a working UI.
A front-end assessment can fail even when the JavaScript function you wrote is correct. If the app never starts, a button cannot be found by its expected selector, or a new item does not appear in the preview, the submitted UI is incomplete. Treat a HackerRank front-end project as a running application with a visible behavior contract. Start with the invitation and supplied files, then make one user flow work before polishing every screen.
This guide distinguishes HackerRank's candidate documentation, one limited candidate account, and original rehearsal exercises. It does not claim every employer chooses the same framework, task count, hidden tests, or AI policy. If your gap is component behavior, begin with Implement a Reusable Dropdown Component, then use the app-level checks below.
Identify whether you have a project or a coding question
Official platform guidance: HackerRank's candidate guide to developer assessments distinguishes a single-file coding question from multi-file code repository and project questions. A repository may contain several tasks in one scaffold; a project task can ask for a feature or bug fix in an existing app. The guide describes a VS Code-like IDE and preconfigured environment. These are platform capabilities, not a guarantee that your invitation includes React, a repository, or any particular number of questions.
Before starting, write down the assessed language, framework, question types, time limit, submission action, and permitted tools. Take the platform's sample test if your invitation provides one. The official guide says initialization may take up to two minutes; leave space for it instead of treating the first loading screen as an unsolvable code problem. If a dependency install stalls, the guide points to the Run menu's Install Dependencies action. Use the support path for genuine environment failures and record the time and visible symptom.
One self-reported graduate candidate on Reddit described an invitation with multiple choice, JavaScript coding, and a front-end task after mostly practicing Python algorithms. The same poster later said their own completed UI task involved adding elements to the DOM in vanilla JavaScript. This is an unverified individual account, not the platform's standard paper or a prediction of your test. Its useful lesson is to check the assigned output format early enough to shift preparation from algorithm-only drills to building and inspecting UI behavior.
Read the scaffold as a contract before changing it
In a project, the supplied application is part of the prompt. Locate the entry point, task description, package scripts, existing tests, and any fixtures. Start the app before editing so you know the baseline. Then list each visible requirement as an action and an expected observation: clicking Add creates a row, an empty input shows an error, a completed item changes state, and reloading either preserves or intentionally discards data according to the instructions.
Official warning: HackerRank says existing UI element IDs and classes may be crucial for unit tests. Avoid changing them casually. An identifier might be a test hook, a CSS selector, an accessibility label relationship, or a JavaScript target. When a visual redesign is needed, change styling around the stable element; keep the tested identifier unless the instructions explicitly require a new one. If an ID must change, inspect every reference and run the relevant tests. This is a concrete reason to read the scaffold before a cleanup pass.
Use a short trace table for your own work:
| Existing artifact | What to inspect | Risk if changed without checking |
|---|---|---|
| App entry and run script | How the preview starts | A feature may be correct but never render. |
id and class selectors | Tests, CSS, event handlers | Tests or behavior may lose the element. |
| Fixture data | Initial and empty states | The UI may work only with one sample. |
| Test script | Actual assertion and command | A green unrelated test may hide a broken flow. |
| Submit control | Whether code is saved and sent | An unsent working preview has no final artifact. |
This table is editorial practice, not a HackerRank form. Its purpose is to stop you from discovering the scaffold's rules after replacing it.
Rehearse one original UI task end to end
Build a tiny original reading-list app locally. The starter page has an input, an Add button with id="add-book", a list with id="book-list", and an empty-state message. Your task is to add a nonempty title, render each title as text, mark an item complete, and show the empty message only when no items remain. The IDs are part of this made-up exercise. It is neither a leaked HackerRank question nor a claim about hidden tests.
Define an acceptance table before coding:
| Action | Expected visible result | Focused check |
|---|---|---|
| Open with no items | Empty message visible; no list rows | Inspect preview and DOM. |
| Submit whitespace only | No item added; useful message shown | Test trimmed input and count. |
Add The Left Hand of Darkness | One row with exact text | Check list text and #book-list child count. |
| Complete the row | Completion state visible | Check state and accessible control. |
| Remove last row | Empty message returns | Verify no stale row remains. |
Keep state explicit: an array of items with stable IDs, or a small model suited to the task. Decide how IDs are generated for the lifetime of this local app and whether reload persistence is in scope. If the prompt says nothing about persistence, state the assumption rather than adding local storage and its edge cases under time pressure. If the prompt does require persistence, test a reload and malformed stored data. A feature list without an observable state transition is too vague to guide implementation.
Use textContent for user-entered titles so a title containing <script> stays text rather than executable markup. Do not attach a new listener to every row on every render without considering duplicate handlers. One delegated listener on the stable list container is often simpler, but the best choice depends on the scaffold. The goal is a coherent flow you can test, not a particular fashionable pattern.
See the failure caused by changing a test hook
The supporting visual shows one small counterexample. Suppose an existing test locates #save-item. You can change the button color, layout, or explanatory text while retaining that identifier. If you rename it to #submit-new as part of a refactor, the original selector no longer finds the button—even if the human-visible label still says Save. This is not evidence that all tests are good or that IDs should never change; it shows why a selector change requires a deliberate test update or preservation decision.
For your reading-list rehearsal, first write a test that locates #add-book and adds one title. Make it pass. Then rename the ID and verify that the test fails for the expected reason. Restore the stable ID and rerun. This small mutation check tells you whether the test actually protects the hook. A test that passes both before and after the rename is probably not checking the behavior you thought it was.
Distinguish hooks from accessible semantics. A stable ID helps an automated test, while a button's accessible name helps people using assistive technology. When the task permits it, preserve both. Avoid treating a hidden selector as a substitute for keyboard operation, focus behavior, or a visible error message. If the existing test uses a brittle class but the assignment requires a class change, explain the conflict and follow the assessment's stated requirement; do not secretly tailor the page to one known assertion at the cost of the task.
Use preview and tests as different kinds of evidence
Official candidate instructions describe Run for application preview and Run Tests for project tests. They also describe a preview panel and an IDE debugger. Use each for its own purpose. A preview shows whether the page mounts, the layout works, and the user can complete the flow. Tests check named assertions. A green test suite may miss an awkward loading state; a convincing screenshot may hide a broken selector or error path.
A disciplined loop is short: make one change, run the focused tests, start or refresh the preview, perform the user action, and inspect the result. If the preview is blank, check the console and runtime error before rewriting CSS. If the test says an element is missing, inspect whether the scaffold mounted the correct component and whether you changed its selector. If a click appears to work twice, inspect event listeners and state updates. Debug the first failing layer rather than making three speculative edits at once.
For asynchronous UI, create three states deliberately: pending, success, and failure. In a local mock, use a controllable Promise or fixture response; do not rely on a live service that may change or be unavailable inside an assessment. If a search returns late after a newer search, decide whether the old response should be ignored. A simple request sequence number can protect the visible result, but only introduce it when the task actually includes overlapping requests. Describe what you tested locally rather than implying that HackerRank will use the same network behavior.
A useful final check runs from the entry point you will submit, not from an isolated component demo. Start the app with its documented command, perform the primary flow in the preview, run the provided tests, and inspect the resulting files. Keep any generated build files only if the assessment asks for them. If instructions specify a particular file or function signature, ensure your working UI lives behind that interface.
Handle AI, timing, and submission according to the invitation
HackerRank's guide says its AI Assistant appears only for AI-supported tests. The presence of platform documentation about an assistant does not grant permission to use external AI in your employer's assessment. Check the invitation and in-test policy. If permitted, verify any suggestion against the existing code and tests. A generated “cleanup” that changes IDs, class names, or output shape can break the task while sounding helpful.
The official guide says the IDE automatically saves code and allows revisions and resubmissions before the test ends. It also says that when total time elapses, the most recently auto-saved code is evaluated. Do not turn that into a reason to delay a deliberate final submission. Check the visible save state, use Submit as instructed, and inspect any confirmation. If your browser crashes or the workspace fails, record what you observed and use the platform's support channel; do not infer that an unfinished local copy reached the grader.
Reserve a closing pass for the actual deliverable. In the reading-list rehearsal, verify empty input, one item, multiple items, completion, deletion, selector integrity, and no runtime error. In a real assessment, substitute the task's exact acceptance criteria. State a known limitation honestly if one remains; do not claim an unrun test passed. A small working UI with clear boundaries can be more defensible than a visually polished screen with a broken main action.