HackTheRounds Interview Experiences

Susov Consulting Frontend Engineer Interview Experience (2026) - JavaScript, React, Rejected

Two frontend rounds covering JavaScript fundamentals, recursive array flattening, large list rendering, and a timed TypeScript data table assignment.

By HackTheRounds Team ยท 2026-05-01

Background

I interviewed for a frontend engineer position at Susov Consulting in May 2026. The process had two rounds. The first tested JavaScript and browser fundamentals; the second was a timed product-style assignment followed by discussion with the CPO. I did not receive an offer, but the loop was a useful example of a frontend interview that valued readable implementation and sound UI decisions more than difficult algorithms.

Process Overview

The sequence was compact:

  1. A technical screen covering JavaScript, browser APIs, React, and one recursive coding problem.
  2. A 50-minute assignment to build a searchable user table, followed by technical and behavioral questions.

The recurring theme was clarity. The interviewers wanted precise explanations of language behavior and code that another engineer could extend without first untangling it.

Round 1: JavaScript and Browser Fundamentals

The opening questions moved quickly across setTimeout and setInterval , including how each scheduler works and how to cancel it. I also compared var , let , and const , with attention to function scope, block scope, hoisting, and the temporal dead zone.

Another group of questions distinguished undefined , null , and an undeclared identifier. A strong answer needs to cover both meaning and runtime behavior: a declared variable can hold undefined ; null is an intentional value; directly reading an undeclared identifier normally throws. I was also asked to demonstrate shallow and deep copying rather than only define them. That meant showing how spreading an object copies its top level while nested references remain shared.

The browser portion covered the difference between window and document , common APIs exposed through each, React Router, and the structure of an accordion component. The interviewer then asked how I would render one billion records. The realistic answer was not to render them all. I discussed server-side pagination, list virtualization, incremental fetching, stable row keys, caching, and preserving scroll position.

The coding exercise was to flatten an arbitrarily nested array using recursion without flat or flatMap . I described the base case, traversed each element, recursed for arrays, and appended scalar values to an output accumulator. I also called out empty arrays and deeply nested input. In production, extreme depth could exceed the call stack, so an explicit stack would be a reasonable follow-up even though recursion was required in the interview.

Round 2: Timed Frontend Assignment

The second round centered on a 50-minute implementation. I needed to fetch users from an API and display name, email, and company in a table. Clicking a name had to open a modal with full details, while a search control filtered by name or email. Loading and failure states were part of the expected product behavior.

I approached the task by defining the response and view-model types first, then separating data fetching, filtering, table rendering, and modal state. This kept the UI predictable and made it easier to explain where a future field would propagate. For search, I normalized the query once and compared it with normalized name and email strings. I avoided recomputing unrelated work on every keystroke.

The review questions asked how I would extend the TypeScript interfaces, where lazy loading would help, and how the component structure could grow. For a small table, overengineering would have cost time. For a larger application, I would lazy-load a heavy modal or route, abort obsolete requests, debounce server-backed search, and move remote state into a dedicated query layer.

The discussion also touched on AI tools used in daily work and resolving disagreements over implementation. I framed AI-generated code as untrusted input that still needs tests, security review, and consistency with local conventions. For conflict, I described agreeing on the constraint, comparing options with evidence, recording the decision, and committing to the chosen path.

Edge Cases I Would Test

For the table, I would test an empty response, a network failure, missing company fields, repeated users, slow requests, and a search with different casing or surrounding whitespace. The modal should close by its button and keyboard, restore focus, and avoid displaying details from a previously selected row. If the query changes while a request is active, the older response must not overwrite newer data. For the recursive problem, I would cover an empty array, already-flat input, repeated empty arrays, mixed values, and the depth assumptions agreed with the interviewer.

Result

I was rejected after the second round. The experience reinforced that a frontend loop can be lost through vague fundamentals or messy delivery even when the feature appears to work.

What I Would Prepare

  1. Explain JavaScript scoping and scheduling with small executable examples.
  2. Practice deep versus shallow copy with nested objects and arrays.
  3. Implement recursion without convenience methods, then discuss stack-safety tradeoffs.
  4. Build a typed API table with loading, empty, error, filtering, and modal states under a time limit.
  5. Know when virtualization and pagination solve different parts of a large-data problem.
  6. Keep component boundaries proportional to the task and narrate the extension path.
  7. Treat naming, types, and edge states as part of the solution, not cleanup for later.