Mercury Frontend Interview: 36 Q&A Scenarios

36 practice scenarios for a Mercury frontend interview focusing on React, TypeScript, performance, and the company's core values.

How should you answer the request to walk through your background as a frontend engineer at Mercury?

Focus on your seven years of experience, mentioning your time at Stitch Fix split between the Client Experience team and Frontend Platform. Highlight your stack ($React$, $Next.js$, $TypeScript$, and $GraphQL$) and emphasize your interest in 'leverage work'—systemic changes that benefit multiple teams.

What is a major piece of frontend work you are proud of, and why is it a good example for Mercury?

A platform built for distributing AI agent skills across the organization. It solved the problem of engineers rebuilding tooling in isolation and was adopted by 13 teams in six weeks. It demonstrates 'leverage,' a core Mercury value, by showing systemic impact without needing to be personally involved in every implementation.

How did you approach design system work, specifically regarding tokens and 'steel threads'?

You led an effort to tokenize a design system for over fifty components using a 'steel thread' approach—testing one thin end-to-end path to prove the model before scaling. This improved handoff speed, created an AI-ready foundation, and allowed brand styling changes without modifying every component.

Can you provide an example of performance work you have done independently?

After noticing poor Largest Contentful Paint ($LCP$) on a home feed, you ran a concurrency audit and used code splitting to separate concerns. This cut $LCP$ by approximately $300\,\text{ms}$ for roughly a million users, demonstrating 'high agency' by initiating the work yourself.

What is your philosophy on accessibility in frontend engineering?

Treat it as a baseline rather than an end-phase. A concrete detail to mention is that $ARIA$ state must be set through the $\text{setAttribute}$ method rather than assigning a JS property, as property assignment does not reliably reflect to the accessibility tree.

How do you view the relationship between AI and frontend architecture?

AI should be viewed as a consumer of your architecture rather than just a feature. Well-structured, tokenized systems are easier for AI tools to reason about and generate against, reward-ing good structural design with better AI leverage.

What are the two phases of a $React$ component re-render?

The 'render phase,' which is pure and involves calling the component to describe the UI without touching the $DOM$, and the 'commit phase,' which diffs that description against the previous one and applies the minimal set of changes to the $DOM$.

When is it appropriate to use $\text{useMemo}$ or $\text{useCallback}$?

Use them when a computation is genuinely expensive or when you need a stable referential identity to pass to a memoized child or an effect dependency. Skip them otherwise to avoid unnecessary memory costs and noise.

What is the principle of 'state colocation'?

Keep state as close to where it is used as possible and only lift it to the nearest common parent when shared. Prioritize derived state (computing values during render) over storing redundant values that require syncing, which causes bugs.

When should logic be placed in $\text{useEffect}$ versus an event handler?

$\text{useEffect}$ is for synchronizing with systems outside $React$ (subscriptions, $\text{DOM}$, network). Logic reacting to a user action belongs in an event handler. If a value can be computed from existing state, derive it during render instead of using an effect.

What is a 'stale closure' in $React$ hooks, and how can it be fixed?

It occurs when a callback or effect captures props or state from an old render because it wasn't listed as a dependency. Fixes include: adding the dependency, using a functional updater (e.g., $\text{setCount}(c \rightarrow c + 1)$), or reading from a $\text{ref}$ for the latest value without re-running the effect.

Why is using an array index as a 'key' in $React$ lists problematic?

Keys describe identity, but indices describe position. If the list reorders or items are deleted, $React$ may attach state and $DOM$ to the wrong rows because it thinks the item at index zero is the same as the previous item at index zero. Use stable $\text{ids}$ from your data instead.

If a component is re-rendering too much, what is a structural alternative to using memoization hooks?

Composition. By passing the expensive subtree as $\text{children}$, it maintains a stable reference when the parent updates, solving re-render issues through architecture rather than scattering memo hooks.

What is the tradeoff between controlled and uncontrolled components in large forms?

Controlled components offer instant validation but trigger a render on every keystroke, which can slow down large forms. Uncontrolled components use $\text{refs}$ to read from the $DOM$ only when needed, which is more performant but less reactive.

What is the mental model for Server versus Client components in $Next.js$?

Draw a boundary where Server Components handle data fetching and static structure (shipping no JS), while Client Components handle interactivity, state, and effects. The goal is to keep as much on the server as possible, marking only the interactive leaves of the tree as client.

How should you architect a frontend page featuring search, filters, and a list?

Decompose into separate components for search, filters, and the list. Use a single source of truth for query state, derive the filtered list during render, use explicit loading/error states, debounce the search input, and consider virtualization for large datasets.

How do you prevent data fetching responses from overwriting the UI when they return out of order?

Use the $\text{useEffect}$ cleanup function to either abort the previous request using $\text{AbortController}$ or set an 'ignore' flag in the closure so that stale responses are dropped when they resolve.

What are the downsides of using $React$ Context for global state?

Every consumer re-renders whenever the provider's value changes by reference, regardless of which specific part of the context they use. This can cause a 're-render fan-out' if the value changes frequently or contains fresh object literals.

Why is $\text{unknown}$ preferred over $\text{any}$ in $TypeScript$?

$\text{any}$ disables type checking and is contagious. $\text{unknown}$ is the 'safe' version; it can hold any value but forces the developer to perform type narrowing (checking the type) before the value can be used.

What is a 'discriminated union' and why is it useful for modeling state?

A union of object types sharing a common literal field (the discriminant). It makes illegal states unrepresentable (e.g., having both $data$ and $error$ simultaneously) and allows $\text{TypeScript}$ to narrow to the correct variant inside a switch statement.

What makes a good prop type for a generic component in a design system?

It should make correct usage easy and incorrect usage impossible, often using discriminated unions for grouping props that only make sense together. For native wrappers, it should extend the native element's props to include standard $\text{aria}$ attributes and handlers.

Why are $\text{generics}$ better than $\text{any}$ for reusable helpers?

$\text{Generics}$ capture and preserve the relationship between input and output types, whereas $\text{any}$ erases all type information. $\text{Generics}$ allow for type safety and precise return types without sacrificing flexibility.

What is the risk of using the $\text{as}$ assertion in $TypeScript$?

It tells the compiler to ignore its checks and has zero effect at runtime. If the assertion is wrong, the code will not error immediately but will 'blow up' later when the value is used as something it is not. It represents the developer taking responsibility away from the type system.

When should you choose $\text{interface}$ over $\text{type}$?

Use $\text{interface}$ for public object shapes and when you need declaration merging (augmenting library types). Use $\text{type}$ for unions, tuples, or computed types. Otherwise, follow the existing consistency of the codebase.

How does using a discriminated union for loading/success/error states improve the UI?

It forces the developer to handle each case and ensures data is only accessible when the state is narrowed to 'success.' This prevents 'nonsense states' where $\text{loading}$ and $\text{error}$ could technically be true at the same time if modeled as separate booleans.

What is the function of the $\text{satisfies}$ operator in $TypeScript$?

It validates that a value matches a type without 'widening' the value to that type. This allows you to check a config object against a schema while preserving the specific literal types of its keys and values.

How does $\text{TypeScript}$ handle types for event handlers in $JSX$?

If the handler is inline, $\text{TypeScript}$ infers the type contextually from the attribute. If extracted, the type must be manually annotated, often by typing the whole function with a handler alias (e.g., $\text{React.ChangeEventHandler<HTMLInputElement>}$).

What is $\text{keyof}$ and how is it used for type-safe property access?

$\text{keyof}$ produces a union of an object's keys. Combined with indexed access ($\text{T[K]}$), it allows you to write functions where the key parameter is constrained to existing keys, ensuring the return type is exactly correct for that specific property.

What is the 'sequential-await' smell in an $\text{async}$ function?

Using multiple $\text{await}$ keywords line-by-line for independent requests. This makes the total time the sum of all requests. It should be improved using $\text{Promise.all}$ to run them in parallel, cutting time to the single slowest request.

Why should you avoid $\text{setFullName}(first + " " + last)$ inside a $\text{useEffect}$?

It is an anti-pattern of storing derived state. It causes the component to render twice (stale state then updated state) and can lead to desync bugs. The correct approach is to compute the value directly during the render path.

In a code review, which issue is more severe: an index key or an inline arrow handler?

The index key is a 'correctness' issue for dynamic lists and is more severe because it causes silent state bugs. The inline handler is usually a negligible performance concern unless the component is memoized with $\text{React.memo}$, which would break the memoization.

How do you tighten a loose helper typed as $\text{function getProp(obj: any, key: any): any}$?

Make it generic: $\text{function getProp<T, K extends keyof T>(obj: T, key: K): T[K]}$. This prevents passing non-existent keys and ensures the return type matches the property's type.

How does a debounce implementation in $\text{useEffect}$ handle cleanup?

The cleanup function calls $\text{clearTimeout}$. This ensures that if the dependency (the query) changes within the timeout period, the previous timer is cancelled, and only the last keystroke triggers the function after the delay.

What is the architectural benefit of using a discriminated union for component props like $\text{isLink}$?

It prevents invalid prop combinations, such as having a link without an $\text{href}$. It moves the validation from runtime/manual review into the compiler, guiding the consumer toward correct usage.

How does Mercury's value of 'leverage' relate to a design systems role?

Leverage refers to 'quiet infrastructure' and systemic changes that raise the floor for all teams. A design systems role specifically targets this by creating reusable, high-performance, and accessible components that provide broad organizational impact.

What are strong questions to ask a Mercury interviewer to show alignment with their values?

Questions about how they balance systemic work versus product-driven work, examples of recent leverage-driven changes, the design system's AI-readiness, or the hardest frontend problem the team has recently faced.