The Frontend Interview Landscape
Interview Formats by Company
Each major tech company has a distinct frontend interview process. Knowing the format in advance lets you prepare strategically instead of generically.
Read the tables below as a dated snapshot, not as a contract. Round names, counts, and ordering change without announcement, they differ between orgs inside the same company, and every published guide — this one included — is describing what was true when it was written. The person who knows your actual loop is your recruiter, and they will send it to you in writing if you ask. Do that as soon as a phone screen is scheduled. Use these tables to know what to expect and what questions to ask; use the recruiter's reply as the source of record.
Meta (Frontend Engineer)
Meta posts a Front End Engineer job family, and prep sources consistently describe a loop whose coding rounds are JavaScript-first. Meta does not publish the round list, so treat the table below as reported rather than official — the recruiter's written breakdown is the only authoritative version, and asking for it is the point of this lesson.
| Round | Duration | Focus |
|---|---|---|
| Recruiter Screen | 30 min | Behavioral, role fit |
| Technical Phone Screen | 45 min | JavaScript coding, DOM manipulation |
| Onsite Round 1: Coding | 45 min | Vanilla JS problem — no frameworks allowed |
| Onsite Round 2: Coding | 45 min | Algorithmic or UI implementation from scratch |
| Onsite Round 3: Frontend System Design | 45 min | Design a news feed, autocomplete, or spreadsheet |
| Onsite Round 4: Behavioral | 45 min | Collaboration, conflict resolution, project impact |
Key Meta notes:
- The coding rounds are widely reported to be plain JavaScript and the DOM rather than React or any framework. This is the single highest-value thing to confirm in writing, because it decides whether weeks of your preparation are aimed at the right target — and it is the question recruiters answer most readily
- The system design round is frontend-specific — component architecture, state management, data flow, rendering performance
- Meta uses a hiring committee model — interviewers submit independent feedback and a separate committee makes the hire/no-hire decision
Google (Frontend / SWE)
Google's frontend process is less differentiated from general SWE than Meta's:
| Round | Duration | Focus |
|---|---|---|
| Recruiter Screen | 30 min | Background, role expectations |
| Phone/Video Technical Screen | 45 min | Coding on shared editor (algorithms or frontend-specific) |
| Onsite Coding x 2-3 | 45 min each | Mix of algorithms/DSA and frontend-specific (DOM, CSS, JS) |
| Onsite Frontend System Design | 45 min | Frontend architecture with scalability considerations |
| Onsite Behavioral | 45 min | "Googleyness & Leadership" assessment |
Key Google notes:
- Google historically weights algorithms more heavily than Meta for frontend roles
- The hiring committee is separate from the interviewers — they review written feedback and decide
- Candidates can be "pooled" — approved by committee but waiting for a team match
- Some Google teams still run a generic SWE loop even for frontend candidates
Amazon (Frontend / SDE)
Amazon's process is unique because Leadership Principles (LPs) are evaluated in every single round:
| Round | Duration | Focus |
|---|---|---|
| Recruiter Screen | 30 min | Background, LP alignment |
| Online Assessment | 60-90 min | Coding problems on HackerRank or Amazon's platform |
| Onsite Coding x 2 | 60 min each | Algorithmic + frontend-specific (15-20 min LP per round) |
| Onsite System Design | 60 min | Frontend or full-stack depending on team |
| Onsite Behavioral/LP | 60 min | Deep LP assessment (often a "Bar Raiser" round) |
Key Amazon notes:
- Every round starts with 15-20 minutes of behavioral/LP questions — this is not optional
- The 16 Leadership Principles (Customer Obsession, Ownership, Bias for Action, etc.) are the backbone of Amazon's hiring
- LP performance can override technical performance — a strong technical showing with weak LP signals can result in rejection
- Build the story bank around scenarios, then map it onto the Leadership Principles as a final pass. Module 6 derives the size from the scenarios rather than the principles, and explains why a bank built per-principle produces thin stories: sixteen principles times two stories is a reading list, not a set of experiences you can actually tell
- The "Bar Raiser" is a specially trained interviewer from another team whose job is to maintain hiring standards
Apple
Apple is the most opaque of the major tech companies about their process:
| Round | Duration | Focus |
|---|---|---|
| Recruiter Screen | 30 min | Background |
| Technical Phone Screen | 45-60 min | Team-specific coding |
| Onsite Coding x 2-3 | 45-60 min each | Practical, applied problems related to the team's product |
| Onsite System Design | 45-60 min | Frontend or full-stack |
| Onsite Behavioral x 1-2 | 45 min | Culture fit, attention to detail, craft |
| Manager Interview | 30-45 min | Hiring manager and sometimes skip-level |
Key Apple notes:
- The process is team-specific — the hiring manager has significant influence
- Apple values craft, attention to detail, and passion for user experience
- They ask about accessibility, performance optimization, and cross-browser compatibility more than other companies
- Questions may involve real-world scenarios relevant to the team's product (Safari, Maps, Music, etc.)
Startups
Startup interview processes are more varied but typically shorter:
| Format | Description | Time |
|---|---|---|
| Take-Home Assignment | Build a small React app or implement a feature | 2-8 hrs |
| Pair Programming | Build something collaboratively with an interviewer | 60-90 min |
| Portfolio Review | Deep-dive discussion of past projects and decisions | 45-60 min |
| System Design Lite | Informal whiteboard architecture discussion | 30-45 min |
| Paid Trial Day | Work on real codebase issues for 1-2 days | 1-2 days |
Key startup notes:
- Total process is typically 2-3 rounds (vs. FAANG's 5-6)
- Many startups are moving away from long take-homes toward shorter, timed exercises (2-4 hours max)
- Pair programming is increasingly popular — it tests collaboration and communication alongside coding
- Culture fit often matters more than algorithmic ability
Quick Comparison
| Company | Coding Emphasis | System Design | Behavioral | Total Rounds |
|---|---|---|---|---|
| Meta | Vanilla JS | Frontend-specific | Standard | 6 |
| Algorithms heavy | Frontend + scale | Googleyness | 6-7 | |
| Amazon | Mixed | Team-dependent | LP in every round | 5-6 |
| Apple | Applied/practical | Team-specific | Craft & detail | 5-7 |
| Startups | Practical/pair | Informal | Culture fit | 2-3 |
The Round That Was Not Here Last Year: AI-Assisted Coding
Every table above assumes a coding round where you type into an empty editor with nothing helping you. That assumption is now the thing most likely to be wrong about your loop.
Meta began piloting a coding round in which the candidate has a working AI assistant inside the editor, and its recruiting team's framing is worth quoting because it tells you what is being scored: "It's not 'cheating,' it's how the job is evolving." An engineer on the Threads product team described the format as one that "enables engineers to actually execute their code, dive deeper into real practical problems, and leverage AI to brainstorm and iterate" (CoderPad, on running the format for Meta). Other companies are moving the same direction at different speeds, and none of them announce it on a careers page.
So the question to send your recruiter is no longer only "what are the rounds?" — it is "is any round AI-enabled, and if so, which tools, and what am I allowed to paste in?" The answer changes what you practise, not just what you bring.
The trap is assuming an assistant makes the round easier. It removes the part you rehearsed and keeps the part you did not.
Same problem, two rooms
Empty editor
- The thing you practised is the thing being tested
- A partial answer still shows how you think
- Nothing to configure, nothing to distrust
- Rewards memorising method signatures you would look up at work
- One forgotten argument can stall a whole round
- Bears little resemblance to how you actually ship
AI-enabled editor
- Recall stops being the bottleneck, so harder problems fit in 45 minutes
- You can run the code, which turns 'I think this works' into evidence
- Closer to the job, so your day-to-day habits are worth something
- The bar moves up with you — expect a problem you could not have finished alone
- Accepting a wrong suggestion confidently is worse than writing nothing
- Reading and rejecting generated code under time pressure is a skill nobody practises
- You still have to explain every line as if you wrote it, because you are answering for it
How to practise for it: take a problem you have already solved, ask an assistant for a solution, and then find the bug in it out loud, on a timer. That is the round. Candidates who lose this format are not the ones who used the tool — they are the ones who could not say why they kept what they kept.
Reading Your Own Loop
Company names go stale; loop archetypes do not. When your recruiter sends the round list, match it to one of these four shapes and your preparation follows from the shape, not from whose logo is on the offer letter.
Your recruiter just sent the round list — where does your prep time go?
Look at the coding rounds. What are you told you may use?
Next, we'll build your personalized 8-week study plan based on your target companies. :::
Sign in to rate