The short answer
A frontend mock interview is a practice machine coding round where you build a small working interface, like an autocomplete box, an infinite list or a form with validation, while an experienced engineer plays the interviewer. On Revvox it lasts 60 minutes on video with a shared editor, in plain JavaScript, TypeScript or React. You are marked 1 to 5 on working UI, component design, state and data flow, accessibility and polish, and communication. The written report arrives within 24 hours. A single round costs ₹2,499 ($32).
What a frontend machine coding round tests
Frontend interviews have moved away from trivia about the language and towards building. The interviewer describes a small feature, often one you have used every day, and asks you to make it work in the browser within the hour. They watch how you break it into components, where you keep state, how you fetch data, and whether the result works with a keyboard and a slow network.
A working result matters most: a plain component that behaves correctly beats a beautiful one that does not. After that, interviewers look at structure. Can the component be reused? Are loading and error states handled? Would another engineer understand the code? At senior levels expect questions on performance, such as debouncing input or rendering long lists, and on how you would test what you built.
How it is scored
After the 60-minute round, the interviewer marks each line below 1 to 5 in your written report, due within 24 hours, with notes on what you said and wrote behind each mark. The verdict is one of Strong hire, Hire, Lean hire, Lean no hire or No hire.
| Skill (1 to 5) | What the interviewer looks for |
|---|---|
| Working UI | The core feature works in the browser by the end, including the main edge cases. A working plain version beats a polished broken one. |
| Component design | Components split along clear lines, with sensible props, reusable parts and no copy-and-paste. |
| State and data flow | Each piece of state has one owner, data flows predictably, and async work handles loading, errors and out-of-order responses. |
| Accessibility and polish | Works with the keyboard, has labels and roles, manages focus, and looks tidy without spending the hour on styling. |
| Communication | You plan out loud, explain trade-offs as you code, and keep the interviewer with you to the end. |
Frontend practice questions
Tasks in the style of real machine coding rounds, written by us. In a mock, the interviewer picks one at your level and adds requirements as you go.
- Build a search box that suggests matching cities from an API as the user types, with keyboard selection.Debouncing, cancelling or ignoring stale responses, arrow-key navigation and an accessible listbox.
- Build a table of orders that can be sorted by any column and filtered by status.Derived state rather than copied state, stable sorting, and a component you could reuse for another table.
- Build a feed that loads more posts as the user scrolls to the bottom.An intersection observer or scroll handling, avoiding duplicate loads, and what happens with ten thousand items.
- Build a sign-up form across three steps, with validation and a summary before submitting.Where form state lives, field-level and step-level validation, and clear error messages tied to their inputs.
- Build a modal dialog that any part of the app can open.Focus trapping, closing on Escape, returning focus afterwards, and a simple API for other components.
- Build a nested comment thread where users can reply and collapse branches.A recursive component, a sensible data shape, and keeping updates cheap.
- In plain JavaScript, build a tabbed panel without any framework.DOM manipulation, event delegation, and the right roles and keyboard behaviour for tabs.
How a Revvox frontend mock runs
- Five minutes: the brief. The interviewer describes the feature and the constraints: framework or plain JavaScript, any API to call, what must work by the end.
- Five minutes: the plan. You outline the components, the state each one owns and the order you will build in, so a working version exists early.
- Thirty minutes: the build. You code in a shared editor with a live preview, getting the core behaviour working first, then the edge states.
- Ten minutes: the stretch. The interviewer adds a requirement: keyboard support, caching, a slow response, a thousand rows. You adapt the code.
- Ten minutes: feedback out loud. The interviewer tells you how it went while it is fresh. The written report, with marks and next steps, follows within 24 hours.
How to prepare
- Build the classics from scratch, timed to 40 minutes each: autocomplete with debouncing, a paginated or infinite list, a sortable data table, a modal, a multi-step form with validation, a star rating.
- Practise once in plain JavaScript and once in React. Some rounds ban frameworks to see how well you know the DOM.
- Know the JavaScript underneath: closures, the event loop, promises and async functions, event delegation, and how this is bound.
- Check every component with the keyboard only. Focus order, labels and roles are often what separates a pass from a strong pass.
- Get comfortable without your usual setup: no component library, no CSS framework, and sometimes no autocomplete.
Common mistakes we see
- Spending the first twenty minutes on styling, leaving no time to make it work.
- Keeping the same state in two places, so the UI shows stale or conflicting values.
- Forgetting loading, empty and error states when data comes from an API.
- Firing a request on every keystroke, and showing results from an older request after a newer one.
- Clickable divs with no keyboard support or labels.