Frontend Interviews at Fintech vs OpenAI vs Big Tech (2026)

The type of company changes what you build more than what you are quizzed on. As of 2026-10-26, TrueInterview's bank holds 35 frontend questions reported at 18 companies, and only 2 are filed as behavioral or knowledge questions. Reports at Robinhood and Coinbase lean to frontend system design and repo builds, OpenAI's to design plus a repo build, and Amazon's and Snowflake's to component coding. Our take: if you are senior, over-prepare frontend system design, where senior-or-above write-up links concentrate.

Disclosure: TrueInterview is an interview-preparation product and publishes this article. Facts about other products come from their public pages on the dates listed under Sources.

What does each type of company ask frontend candidates?

Fintech reports lean to frontend design and builds you extend stage by stage, OpenAI's reports to a product-shaped chat UI plus design, and big-tech reports to component coding. The table sets the three segments side by side using the companies with the most reported frontend questions in the bank. The segment labels are ours, and the AI-lab column is OpenAI alone; the counts and examples are candidate reports.

• Fintech: prepare a design round first and a build second; we would prioritise correct state handling over visual polish.
• AI lab (OpenAI): build the company's own product shape once, then be ready to defend it as a design.
• Big tech: drill two or three components until you can finish one in a phone-screen slot, and keep one search or calendar design ready.

Do not read these small per-company counts as how often a company asks frontend questions. It is what candidates wrote up, and its value is the format mix it reveals, which tells you which drills to prioritise.

How do fintech frontend loops at Robinhood and Coinbase differ?

Robinhood's reports lean to frontend system design, Coinbase's to builds you extend stage by stage. Robinhood's two most-linked titles are Photo Album System Design, with 4 candidate write-ups, and Frontend Calendar UI, with 3. Coinbase's include a multi-stage CodeSignal repo task and a validation component built to a mockup, each linked from 2 write-ups. Plan the two companies as different loops.

Robinhood: design first

Treat Photo Album System Design as a frontend architecture prompt. We would prepare two decisions in depth at senior level: how thumbnails load (pagination or a virtualised grid, responsive image sizes) and how upload state survives failure: per-file progress, retry, and what the grid shows while a file is still pending. Draw the data model for albums and photos before you draw any component.

Frontend Calendar UI sits between a build and a design. The hard parts of any calendar view are laying out overlapping events in one column, and handling time zones and recurring events without recomputing the whole month on every change. Decide early whether the month grid is derived from a flat event list or stored as its own structure, and say why.

Coinbase: staged builds and validation

Render Blog Posts (Multi-Stage CodeSignal) was reported as an online assessment, last in 2026-03. In a staged task, the structure you choose in stage one decides how fast the last stage goes, so separate data fetching, state and rendering from the first commit, even when stage one looks trivial.

Our take: the Card / Validation Component to Mockup report tests behaviour more than pixels. Field-level errors, disabled and loading states, and a submit path that cannot fire twice are what separate a passing build from a pretty one. Stripe has too few reports in the table to plan by format; if Stripe is your target, prepare as you would for Robinhood.

What does OpenAI ask frontend candidates?

OpenAI's most-linked frontend report is its own product: Implement a ChatGPT-like Chat UI in React (Streaming + Loading + Message Flow), linked from 2 candidate write-ups, both from candidates who reported a senior-or-above level. It is filed as behavioral / knowledge, but it asks you to build a working chat interface, so prepare it as a build that you will also defend as a design.

The rest of OpenAI's reported frontend set is two system design questions and one multi-file repo build, so frontend preparation transfers directly. What changes is the domain: streaming text, partial state and cancellation.

The chat UI practice page is worth one full build. The decisions we would prepare are standard engineering ones:

• The message state machine. Each message moves through pending, streaming, complete, error and cancelled. Model that explicitly instead of inferring it from whether text exists.
• Rendering partial output. Append chunks to one message without re-rendering the whole list, and keep auto-scroll from fighting a user who has scrolled up.
• Cancellation and races. If the user stops a response or sends a new prompt mid-stream, late chunks from the old request must not land in the new message.

For cancellation, MDN describes AbortController as "a controller object that allows you to abort one or more Web requests as and when desired." MDN adds that abort() can stop fetch requests, the consumption of response bodies, and streams. Wiring one controller per in-flight response, and aborting it in cleanup, settles the race question early in your answer.

What do Amazon, Snowflake, Uber and other big-tech companies ask?

Big-tech reports lean to component coding, with a search or calendar design alongside. Snowflake's dated example is a React / TypeScript Kanban Board, reported in an onsite in 2026-08. Autocomplete appears twice: Amazon's search bar is filed as coding, and Lyft's Frontend Autocomplete Component as object-oriented design in an onsite in 2025-11.

That double appearance is the most useful signal in the segment. If you build one autocomplete well, you have covered a phone-screen coding task and an onsite component-design task. Practise both framings: the Amazon autocomplete search bar as a timed build, and the Lyft autocomplete component as a component API you defend.

For autocomplete, the decisions that matter are debouncing input, discarding out-of-order responses so a slow request for a shorter prefix never overwrites newer results, caching by prefix, and keyboard navigation with combobox semantics for screen readers. For the Snowflake kanban board, decide who owns column and card state, how a move is applied optimistically and rolled back on failure, and what the keyboard alternative to drag and drop is.

On the design side, Uber's Design a Scalable Calendar Service was reported in a phone screen in 2026-06, and the title is linked from 4 write-ups across Uber and LinkedIn. Databricks' Design a Typeahead Search System was reported in an onsite in 2026-09. For a typeahead design, prepare prefix caching and where ranking happens, server or client; for a calendar service design, prepare how recurring events are stored and how conflict queries work across time zones.

Outside these segments, a small JavaScript warm-up also shows up: Salesforce's Frontend Curry: addTwoNumbers → addThreeNumbers(a)(b)(c) was reported in a phone screen in 2026-01 and is linked from 2 write-ups. Give utilities like this an evening, not a week.

Which rounds do frontend questions appear in?

Mostly the onsite. Across the 35 questions, candidates reported 25 in onsites, 14 in phone screens and 1 in an online assessment, and a single question can appear in more than one round. The one OA report is Coinbase's multi-stage CodeSignal task described above. Prepare for a build in the phone screen and a design in the onsite.

The phone screen is not reserved for trivia in these reports. Amazon's autocomplete search bar and Uber's calendar design were both reported at that stage, so a build and a design outline should both be ready before your first call. Our take: treat the onsite as the main event, but do not assume any single format waits for it.

What changes at senior and staff level?

Frontend system design is where senior write-up links concentrate. Links from candidates who reported a senior-or-above level outnumber junior-or-below links 11 to 2 for system design, while coding runs 5 to 10 and object-oriented design 2 to 7. Levels are the candidates' own self-reports. For an experienced hire, that makes design the round to over-prepare.

The overall split is even, at 22 senior-or-above links against 23 junior-or-below. So the signal is in the format mix, not in how many frontend questions each level sees. Several titles are linked only by senior-or-above candidates: Photo Album System Design (4 of 4) and Frontend Calendar UI (3 of 3), with Design a Scalable Calendar Service at 3 of 4. These per-title counts are small, and they show who wrote the reports, not what each level is shown; read them as a direction for preparation.

Design is not staff-only or onsite-only either. Uber's calendar design came in a phone screen, as the big-tech section notes, so a senior candidate who leaves design for the last week risks meeting it first.

Our take on what changes with level: a mid-level answer gets the component working. A senior answer names the decisions: where state lives, how data is fetched and cached, what the rendering strategy costs, and what happens on failure and cancellation. A staff answer adds scope: which parts other teams will reuse, what the component API commits you to, and what you would measure after launch.

Down-leveling note (our view): in a frontend loop the design round carries the level signal. A clean build with no trade-off discussion reads as mid-level, even when the code is correct. If you are aiming at senior or staff, narrate the trade-offs during the build too, so the level evidence is not left to a single round.

What does a senior frontend design answer cover?

Our take: a senior frontend design answer is judged on five decisions: the data model, the rendering strategy, where state lives, how the network layer behaves, and what happens on failure or cancellation. A component that renders is the floor. The published guidance below gives you defensible positions on rendering and on state, the two areas where a vague answer costs the most.

Rendering strategy

web.dev's rendering guide by Addy Osmani and Jason Miller, last updated 5 January 2026, says server-side rendering generally gives a faster First Contentful Paint. The same guide notes that generating the page on the server takes time and can raise Time to First Byte, and that the dynamic nature of server rendering can carry significant compute overhead. The web.dev guide adds that static rendering has its own cost: a separate HTML file for every possible URL. The guide's hybrid example is Netflix, which server-renders static landing pages and prefetches JavaScript for interaction-heavy pages, and its authors advise server or static rendering over full rehydration.

Apply that to the bank's prompts. A photo album has a stable shell and a highly interactive grid, so a server-rendered shell with a client-rendered grid is a position you can defend. A chat UI is interaction from the first keystroke, so arguing for full server rendering there would cost you.

State and effects

The React documentation says "Effects are an escape hatch from the React paradigm." The React docs also say "You do need Effects to synchronize with external systems." The docs note that modern frameworks provide more efficient built-in data fetching than Effects written directly in components, and that React Compiler can memoize expensive calculations automatically in many cases.

In interview terms: a streaming connection or a drag-and-drop library is an external system, so it earns an Effect with cleanup. Derived values, such as the filtered card list in a kanban board or the visible week in a calendar, do not. Saying that distinction out loud is a fast way to show senior judgement.

Accessibility as a design decision

Treat accessibility as part of the component API, not a polish pass. An autocomplete needs combobox roles and focus that stays in the input; a streaming chat needs a live region that announces finished messages without reading every chunk; a kanban board needs a keyboard path for moves.

Are trivia questions like cookies vs localStorage still asked?

Less than generic lists imply, at least as standalone questions. Only 2 of the 35 reported frontend questions are filed as standalone behavioral or knowledge questions, against 10 coding, 10 system design, 7 object-oriented design and 6 multi-file repo questions. One of the two is OpenAI's chat UI, which is a build. The bank does not record quick knowledge checks asked inside other rounds, so keep trivia on a one-page review list rather than dropping it.

The generic lists lead with definitions. An open GitHub repository, which describes itself as a curated list of lists of frontend interview questions, includes the difference between script, script async and script defer, cookies versus sessionStorage and localStorage, what CORS addresses, and the box model. Simplilearn's guide says to expect questions on HTML, CSS, JavaScript and popular frameworks. They are useful definitions, but a list like this cannot tell you what your target company reports.

In the bank, the 15 questions filed under other formats carry the subtypes frontend (9) and frontend build (6). Our take: learn the storage question in the form a build will test it. theSeniorDev's authors put it bluntly: "Never store JWTs in localStorage if you care about security." That sentence belongs in your validation-component or chat-UI design answer, where you choose where a session lives, not on a flashcard.

How has the frontend interview format changed?

Our bank cannot show a before-and-after comparison, but it does show what current loops look like: 31 of the 35 questions were last reported in the 12 months before 2026-10-26. Several recent reports are product-shaped builds, listed below. Our take: prepare for working software, not recall.

Examples from the last year include Build UI from Mockup with API, reported at DoorDash in a phone screen in 2026-03 and filed as object-oriented design, alongside Coinbase's staged repo task and OpenAI's chat UI. Our take: each of these rewards a component that fetches, renders and recovers from errors.

Practitioners describe the same direction, as opinion rather than data. theSeniorDev's authors write that "The days of knowing a bit of React and getting hired are gone." theSeniorDev's authors also say layoffs, recession, remote work and AI have shifted job-market power from developers to companies. Treat both as one training company's view; the bank's evidence is the format mix above.

What do interviewers reward, and which mistakes cost offers?

The practitioner advice that holds up is to answer at system level, not component level. theSeniorDev's authors, who report running over 150 frontend technical interviews in the past year, say candidates fail because they do not demonstrate senior-level skills while answering. That is their observation from their own interviews, not a measured rate.

theSeniorDev's authors call the number one mistake a narrow focus: "They focus way too much on the UI - and almost ignore the backend of that frontend." The theSeniorDev authors also advise answering a slow-site question by thinking like a product engineer rather than only a frontend developer, and say this multidimensional view is what separates rejected juniors from hired seniors.

Our take, mapped onto the reported prompts, the mistakes that cost the most are specific:

• In the chat UI, no cancel path and no plan for chunks that arrive after the user has moved on.
• In autocomplete, results from an older request overwriting newer ones.
• In a staged repo task, stage-one shortcuts that force a rewrite in stage two.
• In a design round, a happy-path diagram with no failure, retry or empty states.

Which prep should you do first?

Start from your segment, then let level override it: if you are senior or above anywhere, frontend system design moves to the top of the list. The target is narrower than a generic list implies. A company such as Robinhood has four reported frontend questions. Our take: working through your target's reported set takes about three weeks alongside a job, but treat that set as a floor, because a real loop can include prompts nobody has reported yet.

Worked example: a senior candidate targeting Robinhood

Robinhood's four reported frontend questions split into system design 2, object-oriented design 1 and coding 1. Start with its two most-linked titles from the fintech section.

• Week one: Photo Album System Design. Data model for albums and photos, paginated or virtualised thumbnails, upload state with retry, and a rendering choice argued from the FCP versus TTFB trade-off above.
• Week two: Frontend Calendar UI as a build, with Design a Scalable Calendar Service as the design follow-up, since a senior candidate should expect the build to turn into a design discussion.
• Week three: one timed mock of each, narrating the trade-offs as you go.

How we counted

Counts come from TrueInterview's question bank as of 2026-10-26 and cover frontend questions candidates reported at 18 companies. These are candidate-reported questions reconstructed for practice, not any company's official question list. TrueInterview says reports are written up right after the interview and checked against other reports of the same round.

Write-up links measure what candidates wrote up, not how often a company asks a question. Level splits use the level each candidate reported. The fintech, AI-lab and big-tech labels are our grouping, not the companies' own.

FAQ

Is there a GitHub list of frontend interview questions by company?

The GitHub repository cited above describes itself as a curated list of lists of frontend interview questions and articles. That is useful for definitions, but it will not tell you what your target company reports. For company-level preparation, start from your target's reported set in the question bank and its format mix in the table above.

Do AI labs test ML knowledge for frontend roles?

Not in the reports we hold for OpenAI, whose frontend set is design questions, a repo build and the chat UI covered above. Your frontend preparation transfers directly. The difference is the product domain, so learn streaming responses, partial rendering and cancellation well enough to build them under a timer and defend them in a design round.

What do mid-level frontend developers get asked compared with seniors?

Our data splits levels only into senior-or-above and junior, new-grad or intern, so it says nothing directly about mid-level candidates. Within that split, coding and object-oriented design links skew junior and system design links skew senior. Our view: a mid-level candidate should expect the same builds, with a design round becoming more likely as the target level rises, so prepare one level above the role you want.

Should I still learn cookies vs localStorage?

Yes, briefly, and in context. The definition appears on generic lists, but the reported rounds test it inside a build or design, where you have to decide where a session token lives and defend that choice. Spend thirty minutes on the storage options and their security trade-offs, then move on to builds.

How long does it take to prepare for a frontend loop?

Our view: three weeks alongside a full-time job is enough to work through one company's reported set, though a real loop can include prompts nobody has reported yet. TrueInterview says the first few questions at every company are free, no card needed. Use them to confirm your target's format mix before you commit your evenings to one format.

Your practice plan

1. Today: look up your target company's row in the segment table and put the formats it reports first, keeping at least one rep of every other format.
2. Week one, first evenings: build one product-shaped component from your segment: the streaming chat UI with a cancel path, the validation component to a mockup, or the autocomplete search bar.
3. Week one, weekend: write a one-page design outline for Photo Album System Design covering data model, rendering strategy, state, network and failure modes.
4. Week two: rehearse Design a Scalable Calendar Service or Design a Typeahead Search System end to end, out loud, against a timer.
5. Week two, weekend: do one staged build such as Render Blog Posts or Build UI from Mockup with API under a timer, keeping fetching, state and rendering separate from the first stage.
6. Week three: run one timed mock of a build and one of a design, then review trivia from a single page, including the currying warm-up.

Sources

• TrueInterview question bank — frontend interview at big-tech companies — counted 2026-10-26
• AbortController - Web APIs | MDN — checked 2026-10-26
• वेब पर रेंडरिंग | Articles | web.dev — checked 2026-10-26
• You Might Not Need an Effect – React — checked 2026-10-26
• GitHub - IgnaciodeNuevo/frontend-development-interviews: A curated list of lists of frontend interview questions. · GitHub — checked 2026-10-26
• Top 80 Frontend Interview Questions and Answers — checked 2026-10-26
• 7 Tricky Frontend Interview Questions (How To Answer Like a Senior Dev) — theSeniorDev — checked 2026-10-26
• Real FAANG Interview Questions by Company · TrueInterview — checked 2026-10-26
• Interview prep compared: your application, end to end · TrueInterview — checked 2026-10-26

Last reviewed: 2026-10-26.