Frontend interviews often give you a prompt and expect you to build something. The difference between a junior response and a senior response isn’t just the code — it’s what you do before you code. Senior engineers clarify requirements, ask questions, consider edge cases, and write specs. They think aloud. They sound like they’ve shipped production systems before.
This guide teaches you how to do that — especially when you’re using AI to help you code. The goal: make interviewers think you know exactly what you’re doing, even if you’re leaning on AI for implementation.
The Interview Flow: What Senior Engineers Do
The candidate who spends 5 minutes clarifying and writing a spec before coding looks like they’ve done this before.
The Mindset: Requirements First, Code Second
Interviewers are evaluating whether you can own a feature end-to-end. That means:
- Understanding the problem before solving it
- Asking clarifying questions instead of assuming
- Considering non-functional requirements (performance, security, a11y)
- Writing a spec that you (or AI) can implement against
- Thinking aloud so they hear your reasoning
The candidate who jumps straight to “I’ll build a React component” looks different from the one who says: “Before I start, I want to clarify a few things about the users and constraints.”
Phase 1: Taking Requirements — Questions to Ask
When the interviewer gives you a prompt (e.g., “Build a product search page” or “Create a dashboard for viewing analytics”), don’t start coding. Start clarifying.
Users & Context
| Question to Ask | Why It Matters | Example Phrasing |
|---|
| Who are the primary users? | Informs UX, a11y, and feature prioritization | ”Who’s the main user for this — internal admins, end consumers, or both?” |
| What’s the primary use case? | Shapes the information architecture | ”Is this for quick lookups, deep analysis, or something else?” |
| What devices/screen sizes matter most? | Affects responsive strategy | ”Is this primarily desktop, mobile, or do we need to support both equally?” |
| Are there accessibility requirements? | Legal/compliance and inclusive design | ”Do we have specific a11y targets — WCAG 2.1 AA, screen reader support?” |
| What’s the user’s technical context? | Affects complexity and error messaging | ”Are these power users or general consumers?” |
“Before I dive in, I want to understand the user context. Is this for internal stakeholders who might be on desktop all day, or end users who could be on mobile? That’ll affect how I structure the layout and what I prioritize above the fold.”
Scalability & Scale
| Question to Ask | Why It Matters | Example Phrasing |
|---|
| How much data are we dealing with? | Drives pagination, virtualization, caching | ”Roughly how many items could we be displaying — hundreds, thousands, or tens of thousands?” |
| Is this real-time or static? | Affects polling, WebSockets, or static fetch | ”Does the data need to update in real time, or is a page load sufficient?” |
| Will this grow over time? | Informs architecture choices | ”Is this a one-off view or something that might add more features later?” |
“I’m thinking about scale here. If we’re showing hundreds of results, I’ll need pagination or infinite scroll. If it’s thousands, I might need virtualization to keep the DOM performant. What order of magnitude are we talking about?”
| Question to Ask | Why It Matters | Example Phrasing |
|---|
| What’s the existing stack? | Consistency with codebase | ”Are we using React, Vue, or something else? Any design system or component library?” |
| Is there an API already, or am I mocking? | Shapes data layer and error handling | ”Do I have a real API to integrate with, or should I mock the data for this exercise?” |
| Any state management preferences? | Redux, Zustand, React Query, etc. | ”Is there a preferred approach for server state — React Query, SWR, or something custom?” |
| Build tooling? | Affects how I structure imports and assets | ”Vite, Next.js, Create React App — what’s the setup?” |
“I’ll assume React since that’s common, but I want to check — is there a specific framework or design system I should align with? That’ll help me stay consistent with what you’d expect in production.”
Observability & Debugging
| Question to Ask | Why It Matters | Example Phrasing |
|---|
| Do we need error tracking? | Production readiness | ”Should failed API calls or client errors be logged somewhere?” |
| Any analytics or event tracking? | Product and UX insights | ”Do we need to track user interactions for analytics?” |
| How do we surface failures to users? | UX for error states | ”What’s the expected behavior when the API fails — toast, inline message, retry?” |
“I’m thinking about observability. In production, I’d want to know when this fails. For this exercise, I’ll at least add structured error handling and maybe a simple error boundary — does that align with what you’d expect?”
API Requirements
| Question to Ask | Why It Matters | Example Phrasing |
|---|
| What does the API contract look like? | Shapes types and data handling | ”Do you have an OpenAPI spec or example response I can work from?” |
| Pagination, filtering, sorting? | Affects URL params and state | ”Does the API support pagination, or do we get everything in one response?” |
| Rate limits or auth? | Affects retry logic and headers | ”Is the API authenticated? Any rate limiting I should handle?” |
| Error response format? | Consistent error handling | ”What does a 4xx/5xx response look like — standard JSON with a message field?” |
“I’ll need to understand the API shape. Does it return paginated results, or a flat array? That determines whether I need to manage page state or just render what we get. And is there a standard error format I should handle?”
| Question to Ask | Why It Matters | Example Phrasing |
|---|
| Any performance budgets? | Core Web Vitals, bundle size | ”Are there LCP or FCP targets I should aim for?” |
| Heavy assets (images, charts)? | Lazy loading, optimization | ”Will we have large images or charts that need special handling?” |
| Offline or low connectivity? | Service workers, caching | ”Do users need to work offline or in low-connectivity environments?” |
“For performance, I’m planning to lazy-load below-the-fold content and keep the initial bundle lean. If we have large lists, I’ll use virtualization. Are there specific metrics you care about — LCP, TTI?”
Security
| Question to Ask | Why It Matters | Example Phrasing |
|---|
| Sensitive data displayed? | XSS, sanitization | ”Is any user-generated or sensitive data rendered — do I need to sanitize?” |
| Auth required? | Protected routes, token handling | ”Is this behind auth? How do we handle expired sessions?” |
| CSRF or other concerns? | Form handling, API calls | ”Are we doing mutations that need CSRF protection?” |
“On security — if we’re rendering user input or data from the API, I’ll make sure we’re not vulnerable to XSS. I’ll use React’s default escaping, but if there’s any HTML content, I’ll sanitize. Does that match your expectations?”
Accessibility (a11y)
| Question to Ask | Why It Matters | Example Phrasing |
|---|
| WCAG level? | Compliance target | ”Are we targeting WCAG 2.1 AA, or is basic keyboard/screen reader support enough?” |
| Keyboard navigation? | Essential for many users | ”Should all interactions be keyboard-accessible?” |
| Screen reader support? | Semantic HTML, ARIA | ”Do we need full screen reader support, or is that out of scope for this exercise?” |
| Color contrast, focus states? | Visual a11y | ”Any design system constraints for focus indicators or contrast?” |
“For accessibility, I’ll use semantic HTML, ensure keyboard navigation works, and add ARIA where needed. I’ll avoid div soup for interactive elements. Is there a specific WCAG level you’re targeting?”
Phase 2: Writing the Spec Before Giving to AI
Once you’ve gathered answers (or made reasonable assumptions and stated them), write a short spec. This does two things: (1) it shows the interviewer you think in specs, and (2) it gives AI a clear target so the output is higher quality.
Spec Template for Interview Exercises
# Feature: [Name]
## Overview
[1-2 sentences]
## Users & Context
- Primary user: [who]
- Primary use case: [what]
- Devices: [desktop/mobile/both]
## Requirements
- [ ] R1: [Concrete requirement]
- [ ] R2: [Concrete requirement]
## Data / API
- Endpoint: [if known]
- Response shape: [if known]
- Error handling: [assumption]
## Non-Functional
- Performance: [lazy load, virtualize if needed, etc.]
- Accessibility: [keyboard, semantic HTML, ARIA]
- Security: [XSS, auth if applicable]
- Error states: [loading, error, empty]
## Edge Cases
- [Empty state]
- [Error state]
- [Loading state]
- [Long content / overflow]
Example: Product Search Page
Interviewer says: “Build a product search page where users can search and filter products.”
You say (think aloud):
“I’ll clarify a few things first, then write a quick spec before I start building. Let me assume we’re on React with a REST API unless you tell me otherwise. I’ll also assume we need basic a11y and responsive layout.”
Your spec (written or verbal):
# Feature: Product Search Page
## Overview
A searchable, filterable product list. Users can search by text and filter by category/price.
## Users & Context
- Primary user: E-commerce shoppers (assumed)
- Use case: Find products quickly
- Devices: Responsive, mobile-first
## Requirements
- R1: Search input with debounced API calls (300ms)
- R2: Filter dropdowns: category, price range
- R3: Product grid with image, name, price
- R4: Loading, empty, and error states
- R5: Accessible: keyboard nav, semantic HTML, focus management
## Data / API
- GET /api/products?q=...&category=...&minPrice=...&maxPrice=...
- Response: { products: [...], total: number }
- Errors: 4xx/5xx → show user-friendly message, retry option
## Non-Functional
- Performance: Debounce search, lazy-load images, virtualize if >100 items
- A11y: aria-live for results count, role="search", skip links if needed
- Security: Sanitize any user-rendered content
## Edge Cases
- Empty query: show "Enter a search term" or recent/popular
- No results: "No products found. Try different filters."
- API error: "Something went wrong. Try again." + retry
- Slow network: Loading skeleton, avoid layout shift
“I’ve got a spec. Now I’ll implement against it. I’ll start with the structure — search bar, filters, results grid — then wire up the data layer and handle the edge cases. I’ll use AI to scaffold the components, but I’ll review everything against this spec.”
Phase 3: Phrases That Sound Technically Strong
How you phrase things matters. These patterns signal senior-level thinking.
When Clarifying
- “Before I start, I want to make sure I understand the constraints…”
- “I’m going to assume [X] unless you’d prefer otherwise — that’ll shape how I handle [Y].”
- “What’s the expected behavior when [edge case]? I want to get that right from the start.”
When Making Decisions
- “I’ll use [approach] here because [reason]. The tradeoff is [tradeoff], but for this scope it’s acceptable.”
- “I’m choosing [X] over [Y] because [constraint]. In a different context I might do [Y].”
- “For performance, I’m going to [specific technique] — that should keep [metric] under control.”
When Handling Edge Cases
- “I need to handle the empty state — users will see this when [condition].”
- “Error handling: I’ll show [UI] and optionally [retry/log]. In production I’d also [observability].”
- “For accessibility, I’ll ensure [specific behavior] so [user type] isn’t excluded.”
When Talking About Architecture
- “I’m keeping the data layer separate from the UI so we can swap the API implementation later.”
- “I’ll use [pattern] for state — it keeps [concern] contained and makes testing easier.”
- “The component structure will be [hierarchy] — that gives us [benefit] and keeps things maintainable.”
When Using AI
- “I’ll use AI to scaffold the boilerplate, but I’ll review everything against the spec and handle the edge cases myself.”
- “The spec gives the AI a clear target — I’ve found that produces better output than vague prompts.”
- “I’m going to generate the structure first, then iterate on the parts that need careful handling — error states, a11y, performance.”
Phase 4: Full Question Bank — Copy-Paste Ready
Use these as a checklist. You don’t need to ask all of them — pick the ones that fit the prompt.
Users & Context
- Who is the primary user for this feature?
- What’s the main use case — quick lookup, deep analysis, or something else?
- Desktop, mobile, or both? Any specific breakpoints?
- Any accessibility requirements — WCAG level, screen reader support?
- Are these power users or general consumers?
Scale & Data
- Roughly how many items could we be displaying?
- Is the data real-time or static? Do we need polling or WebSockets?
- Will this feature grow — more filters, more views, more integrations?
- What framework and version should I use?
- Is there a design system or component library?
- Do I have a real API, or should I mock the data?
- Any preferred state management — React Query, Redux, Zustand?
API
- What does the API contract look like — do you have a spec or example?
- Does it support pagination, filtering, sorting?
- Is it authenticated? Any rate limits?
- What’s the error response format?
- Any performance budgets — LCP, FCP, bundle size?
- Large images or charts that need lazy loading?
- Offline or low-connectivity requirements?
Security
- Any user-generated or sensitive data that needs sanitization?
- Is this behind auth? How do we handle session expiry?
- Any CSRF or other security considerations?
Accessibility
- WCAG 2.1 AA or basic keyboard/screen reader support?
- Should all interactions be keyboard-accessible?
- Any design system constraints for focus or contrast?
Observability
- Should we log errors or track events?
- How should we surface failures to the user — toast, inline, retry?
Example: End-to-End Interview Flow
Prompt: “Build a dashboard that shows user activity over the last 7 days.”
You (out loud):
“I’ll start by clarifying a few things. Who’s the user for this dashboard — internal team, admins, or end users? And do we have an API that returns activity data, or should I mock it? I’m also thinking about scale — could we have thousands of events, or is it more like hundreds? That’ll affect whether I need to virtualize or paginate. For a11y, I’ll assume we need keyboard nav and semantic structure. I’ll write a quick spec and then build against it.”
You (write or type):
# Dashboard: User Activity (7 days)
## Context
- User: Internal team (assumed)
- API: Mock for now, assume GET /api/activity?from=&to=
- Scale: Hundreds of events (assumed) — table or list, no virtualization
## Requirements
- Date range: last 7 days (configurable if time)
- Activity list: timestamp, user, action, metadata
- Filters: by user, by action type
- States: loading, empty, error
## Non-Functional
- A11y: table/list semantics, keyboard nav
- Perf: debounce filters, lazy load if many rows
- Security: no PII in logs (assumed)
“Spec’s done. I’ll build the layout first — header with date range, filters, then the activity list. I’ll use AI to scaffold the components and data fetching, then I’ll add the edge cases and verify a11y. Let me start.”
Canvas App (Drag, Drop, Zoom)
Prompt: “Create a Canva-like app page with a canvas, drag-and-drop elements, zoom, and other regular stuff.”
You (out loud):
“I’ll clarify scope. What elements should be draggable — shapes, text, images, or a subset? For zoom — mouse wheel, pinch, or both? Do we need undo/redo, snap-to-grid, or layers? Is this single-user or collaborative? I’ll assume desktop-first with mouse + keyboard, and mock the element palette. I’ll write a spec covering canvas state, zoom limits, and a11y for keyboard users.”
Spec:
# Canvas App
## Context
- User: Content creator (assumed), desktop-first
- Elements: Shapes (rect, circle), text, images (mock URLs)
- Interactions: Drag, drop, resize, delete, zoom, pan
## Requirements
- R1: Canvas with zoom (0.5x–2x), pan (drag background)
- R2: Element palette (left sidebar) — drag to add
- R3: Elements: draggable, resizable, selectable, deletable
- R4: Toolbar: zoom in/out, reset view, clear canvas
- R5: Keyboard: Delete, Escape to deselect, arrow keys to nudge
## Non-Functional
- Perf: Use transform for zoom/pan (GPU), throttle resize
- A11y: Keyboard nav, focus management, aria-labels
- State: Local state (Zustand/Context) — no persistence for interview
Facebook Feed
Prompt: “Create a Facebook feed.”
You (out loud):
“I’ll scope this. Is it infinite scroll or pagination? Do we need likes, comments, share — or just the post list? Real-time updates or static? I’ll assume infinite scroll, mock data, and basic interactions: like, comment count. I’ll handle loading states and empty feed. For a11y, I’ll use semantic structure and aria-live for new posts if we add real-time later.”
Spec:
# Facebook Feed
## Context
- User: Social media consumer, mobile + desktop
- Data: Mock posts (author, avatar, content, timestamp, likes, comments)
## Requirements
- R1: Feed list: post card (avatar, name, time, content, image optional)
- R2: Like button (toggle), comment count (link or expand)
- R3: Infinite scroll or "Load more"
- R4: States: loading, empty, error
- R5: Responsive, touch-friendly
## Non-Functional
- Perf: Virtualize or paginate if many posts, lazy-load images
- A11y: Semantic article/header, focus order, like button accessible
- Security: Sanitize any user-generated content (XSS)
Todo List
Prompt: “Create a todo list.”
You (out loud):
“I’ll clarify. Single list or multiple? Filters — all/active/completed? Persistence — localStorage or API? Do we need due dates, priorities, or just title + done? I’ll assume single list, filter tabs, localStorage persistence. I’ll handle empty state, clear completed, and keyboard add. For a11y, proper list semantics and ARIA for dynamic updates.”
Spec:
# Todo List
## Context
- User: General consumer, mobile + desktop
- Persistence: localStorage (or API if specified)
## Requirements
- R1: Add todo (input + Enter, clear on submit)
- R2: List: checkbox (toggle), label, delete button
- R3: Filters: All, Active, Completed
- R4: Footer: count, "Clear completed"
- R5: States: empty, loading (if API)
## Non-Functional
- A11y: list role, aria-live for add/remove, keyboard nav
- Perf: Debounce if syncing to API
- Edge cases: empty input, max length, XSS on user input
Users Dashboard
Prompt: “Create a users dashboard.”
You (out loud):
“I’ll clarify. What’s the dashboard for — admin view, analytics, or user management? What actions — view, edit, delete, invite? Do we need search, filters, pagination? I’ll assume admin user management: table of users, search, pagination, basic actions. I’ll mock the API. For a11y, table semantics and keyboard nav for actions.”
Spec:
# Users Dashboard
## Context
- User: Admin, desktop
- Data: Mock users (id, name, email, role, status, created)
## Requirements
- R1: Table: columns, sortable headers, row actions
- R2: Search (debounced), filter by role/status
- R3: Pagination (page size, page nav)
- R4: Actions: view, edit, delete (confirm)
- R5: States: loading, empty, error
## Non-Functional
- Perf: Virtualize or paginate for large lists
- A11y: table semantics, sortable headers, action menu keyboard
- Security: No PII in logs, confirm destructive actions
Invoices Table
Prompt: “Create a table for a list of invoices.”
You (out loud):
“I’ll clarify. What columns — invoice #, date, amount, status, client? Do we need filters, sorting, export? Any row actions — view, download, mark paid? I’ll assume standard columns, sortable, filter by status. I’ll mock the data. For a11y, proper table with scope, and for amounts I’ll format as currency. I’ll handle empty and error states.”
Spec:
# Invoices Table
## Context
- User: Finance/admin, desktop
- Data: Mock invoices (id, number, date, amount, status, client)
## Requirements
- R1: Table: invoice #, date, amount, status, client, actions
- R2: Sortable columns (click header)
- R3: Filter by status (dropdown)
- R4: Row actions: view, download (mock)
- R5: States: loading, empty, error
## Non-Functional
- A11y: table with th scope, status badges accessible
- Perf: Paginate if many rows
- Format: Currency locale, date format
Signup Flow
Prompt: “Create a signup flow.”
You (out loud):
“I’ll clarify. Single page or multi-step? What fields — email, password, name, etc.? Validation rules — password strength, email format? Do we need OAuth, captcha, terms acceptance? I’ll assume multi-step: email → password → profile (name), with validation. I’ll mock the API. For a11y, form labels, error announcements, and focus management between steps. For security, I’ll validate client-side and mention server-side validation.”
Spec:
# Signup Flow
## Context
- User: New user, mobile + desktop
- Flow: Multi-step (email → password → profile)
## Requirements
- R1: Step 1: email (validation, format)
- R2: Step 2: password (strength, confirm)
- R3: Step 3: name, optional fields
- R4: Progress indicator, back/next navigation
- R5: Submit → success/error state
## Non-Functional
- A11y: labels, error messages linked, focus trap per step
- Security: No password in logs, client + server validation
- Validation: Email regex, password strength (length, complexity)
- Edge cases: duplicate email, network error, session timeout
Login Page
Prompt: “Create a login page.”
You (out loud):
“I’ll clarify. Email/password only or OAuth? Forgot password link? Remember me? Redirect after login? I’ll assume email + password, forgot password link, optional remember me. I’ll mock the API. For a11y, form labels, error announcements, and no autocomplete=off on password (unless required). For security, I’ll mention rate limiting and CSRF in production.”
Spec:
# Login Page
## Context
- User: Returning user, mobile + desktop
- Auth: Email + password (mock API)
## Requirements
- R1: Form: email, password, submit
- R2: Forgot password link
- R3: Remember me checkbox (optional)
- R4: Signup link (if no account)
- R5: States: loading, error (invalid credentials, network)
## Non-Functional
- A11y: labels, error messages, focus on error
- Security: No password in logs, mention rate limit/CSRF
- Validation: Email format, non-empty password
- Edge cases: 401, 500, network error
Summary: The Interview Playbook
- Don’t code first. Clarify requirements. Ask questions. State assumptions.
- Use the question bank. Pick 5–8 questions that fit the prompt. Ask them out loud.
- Write a spec. Even a short one. It shows you think in systems, not just components.
- Think aloud. Explain your decisions, tradeoffs, and edge-case handling.
- Give AI a spec. When you use AI, feed it the spec. Review output against it.
- Signal seniority. Use phrases that show you’ve shipped production code before.
The interviewer isn’t just evaluating your code. They’re evaluating whether you can own a feature. Requirements-first, spec-driven, think-aloud — that’s the playbook.
The candidate who asks “What happens when the API returns 500?” before writing a single line of code has already differentiated themselves. Questions and specs are free. Use them.
