Representative practice prompts
Four xAI frontend interview practice questions
For each prompt, clarify the contract, explain ownership and trade-offs, implement or diagram the smallest credible slice, and test the failure cases. Each prompt links to the public report or official posting it is modelled on and to a runnable practice page; the fourth prompt is modelled on the reported chat-interface round plus the product domain and carries no account of a design round.
Prompt 1
Build a chat interface in React during a one-hour pairing session
One London account describes a one-hour pair-coding session: build a chat interface in React while an engineer from the team reviews the code live, with React questions along the way such as what useCallback does. Practise the same shape: a message list, a composer, a status per message, and an assistant reply that renders as it arrives.
Practice version modelled on a reported round: Public report: xAI Frontend Engineer interview account, London, on Taro, August 2025
What this measures
Scoping under a clock, component and state boundaries, controlled inputs and list rendering, explaining hooks while typing, and taking live review without losing the thread.
Clarify first
- Confirm whether the reply arrives at once or as a stream, whether a mock is acceptable, and what the interviewer wants to see working first.
- Confirm the setup: TypeScript or JavaScript, any starter code, and whether styling matters inside the hour.
Strong answer should cover
- Say the plan before coding: one messages array as the source of truth, a composer with a controlled value, and a status per message (sending, sent, failed).
- Render the list from state, key each item by a stable id, and keep the scroll pinned to the latest message until the reader scrolls up.
- Explain each hook as you use it: useCallback keeps a stable handler reference for a memoised child and changes nothing where no child memoises.
- Keep Send disabled on a blank draft and while a reply is in flight, and give a failed send a visible retry that does not duplicate the user turn.
Common miss: Building a polished layout first and reaching the end of the hour with a composer that cannot send, or wrapping every handler in useCallback without being able to say what it changes.
Practice the chat UI with a streaming response (Premium) Prompt 2
Write a small app in React with TypeScript in 45 minutes
The closed grok.com & API and Enterprise postings describe a "Coding interview in TypeScript: Write a small app in React"; the closed London posting gave its React coding interview 45 minutes. Practise a complete small app: fetch a list, render loading, error and empty states, and add a filter, with types on the data and the props.
Practice version modelled on a reported round: Official posting: xAI React Frontend Engineer, grok.com & API, Built In, January 2026
What this measures
Typed React under time, request handling with cancellation, truthful loading, empty and error states, and whether the app works end to end before any polish.
Clarify first
- Confirm the data source (a real endpoint, a mock or a fixture) and which feature the interviewer wants first.
- Confirm the TypeScript strictness and whether any library beyond React is allowed.
Strong answer should cover
- Type the response and the component props before fetching, and keep the raw list separate from the filtered view.
- Start the request in an effect with an AbortController and ignore a response that belongs to a superseded render or an unmounted component.
- Render four explicit states, loading, error with retry, empty and populated, instead of inferring them from the length of an array.
- Finish a working vertical slice early, then add the filter and say what you would do with another hour.
Common miss: Spending the first fifteen minutes on folder structure and styling, so the fetch and its failure states are untested when time runs out.
Practice fetching and rendering a list with every state Prompt 3
Implement a UI from a screenshot in HTML and CSS
Three closed postings describe an "HTML/CSS interview: Given a screenshot of a UI, implement it"; the closed London posting gave the round 45 minutes and named Tailwind. Practise rebuilding a card gallery, then a navigation bar, from a picture alone: match spacing, alignment and responsive reflow without a design file.
Practice version modelled on a reported round: Official posting: xAI Frontend Engineer, London, Built In London, February 2026
What this measures
Reading layout from a picture, choosing grid or flexbox per region, spacing and typography discipline, responsive behaviour and semantic markup under time.
Clarify first
- Confirm which breakpoints matter, whether pixel accuracy or structure is being judged, and whether Tailwind or plain CSS is expected.
- Confirm the content: real text and images or placeholders, and whether hover and focus states are in scope.
Strong answer should cover
- Name the regions first (header, grid, card, footer) and decide grid versus flexbox for each before writing markup.
- Write semantic HTML (nav, ul, article, button) so the structure reads correctly without styles.
- Use a spacing scale and a handful of tokens instead of per-element magic numbers, so the result stays consistent when a breakpoint changes.
- Check reflow at a narrow width, keep focus styles visible, and move to the second drill, the responsive flexbox navbar, once the gallery holds.
Common miss: Positioning everything absolutely to match the screenshot at one width, so the layout breaks as soon as the viewport or the text changes.
Practice the grid card gallery from a layout brief Prompt 4
Design the AI chat composer and streaming turn for a grok.com-style product
Design the composer and the streaming turn for a grok.com-style chat product: Send that becomes Stop while a reply streams, regenerate that does not duplicate a turn, stale stream events that cannot touch the new turn, and token-by-token rendering that stays readable. This practice version is modelled on the reported chat-interface round plus the product domain of the Grok postings; no public account describes a design round for an xAI frontend role.
Practice version modelled on a reported round: Public report: xAI Frontend Engineer interview account, London, on Taro, August 2025
What this measures
State ownership across draft, active turn and history; stream and command identity; cancellation and recovery; rendering performance under a token stream; and accessibility of streamed text.
Clarify first
- Confirm the transport (SSE, WebSocket or a fetch stream) and whether the server can resume a stream by sequence number.
- Confirm what Stop must guarantee: a server-side stop or only a local abort with partial text kept.
Strong answer should cover
- Give each send and each stream a stable identity and drop events whose id does not match the active turn.
- Model the turn as a small state machine (idle, sending, streaming, stopped, failed) and derive the Send or Stop button from it instead of from scattered booleans.
- Batch rendered tokens per animation frame and keep the scroll pinned to the bottom until the reader scrolls up.
- Define regenerate as a new turn that reuses the prompt and retires the old stream, and announce status changes to assistive technology.
Common miss: Showing Stop as done while the old stream keeps appending, because the abort was local and the stream id was not checked.
Work through the AI chat composer case