The frontend loop: browser knowledge, a live component, and design talk
Sergei Skrylkov, Founder, Trippi · facts checked against the product on 2026-09-30
A frontend loop is wider than most engineering loops. In one day you may be asked how the browser renders a page, why a promise resolves before a timeout, how to make a dropdown usable with a keyboard, and how you would build the client side of a chat app. The questions are rarely hard in isolation. What makes the loop hard is switching between these layers in English, on a call, while someone watches you type.
The loop, round by round
Recruiter screen — 20–30 minutes
Framework, years, salary. Say “React and TypeScript, mostly” rather than a list of every library.
Technical screen — 45 minutes, an engineer
Quick questions on JavaScript, the browser and CSS, sometimes a small exercise. The general mechanics are on the technical interview page.
Live coding: build a component — 60 minutes, shared sandbox
An autocomplete, a modal, a star rating, an infinite list. Graded on state, edge cases and accessibility, not on styling. See the coding interview page.
Frontend system design — 45–60 minutes, a senior engineer
The client side of a feed, a chat, a design system. Data flow, caching, pagination, what happens offline. The general round is on the system design page.
Behavioral / collaboration — 45 minutes, an engineering manager or a designer
Disagreements with design, a launch that broke something, how you review code.
Some companies replace live coding with a take-home — a small app in a day — and then spend the next round asking why you built it that way.
Ten questions, and what each one tests
| Question | What it tests | What a strong answer does |
|---|---|---|
| “What happens when you type a URL and press Enter?” | Breadth: network to pixels | Goes in order — DNS, connection, HTML, CSS, JavaScript, layout, paint — and stops to ask where they want depth. |
| “Where do promises run compared with setTimeout?” | The event loop, microtasks and macrotasks | Predicts the order of a small example, then says why it matters in real code. |
| “What does the dependency array in useEffect do, and when did you get it wrong?” | React’s model, stale closures | A real bug from missing dependencies, and the fix. |
| “This page loads slowly. What do you do?” | Measuring before optimising | Names LCP, INP and CLS, measures first, then picks the biggest cause. |
| “Build an autocomplete input.” | State, async, keyboard, accessibility | Debounce, out-of-order responses, arrow keys, and an accessible list. |
| “How would you make a custom dropdown accessible?” | Real accessibility knowledge | Focus management, keyboard support, the right ARIA roles — and why a native select is often better. |
| “Where should this state live: component, context, store or URL?” | State ownership | Chooses by who needs it and whether it should survive a reload or a shared link. |
| “How does CSS specificity work, and how do you stop fighting it?” | The cascade | Explains the order, then a system: modules, layers or a naming convention. |
| “Design the frontend of a chat app.” | Client-side system design | Message list, sending with optimistic updates, reconnecting, loading history in pages. |
| “Tell me about a time design and engineering disagreed.” | Collaboration | The disagreement, the evidence, the compromise, and what shipped. |
Worked example: the autocomplete that shows old results
This follow-up comes in almost every autocomplete exercise, usually after your first version works. The interviewer types fast, a slow response arrives late, and the list shows results for an older query. They want to hear you name the cause before you touch the code. Here is the kind of structure a card offers for it.
Example of a card’s shape — written for this page, not a screenshot
The line it grew from
“Your list is sometimes showing results for what I typed before. Why is that happening?”
Points to speak from
- 1Name the cause: responses come back out of order — the slow request for “ap” arrives after the one for “app”.
- 2Fix it by ignoring stale responses: keep the latest query and compare, or cancel the previous request with AbortController.
- 3Add that debounce reduces the number of requests but does not fix the ordering on its own.
The card cannot see your code. It answers the spoken question; the change in the editor is yours.
If English is your second language: frontend terms said out loud
| What you hear | What it is |
|---|---|
| “Debounce” vs “throttle” | Close in sound, different in meaning: debounce waits for a pause; throttle allows one call per interval. |
| “Reflow”, “repaint”, “layout shift” | The browser recalculating positions, redrawing pixels, and content jumping on screen. |
| “A-eleven-y”, sometimes “ally” | Accessibility, abbreviated a11y. |
| “Hydration” | The client-side JavaScript taking over HTML that the server already rendered. |
| “Prop drilling”, “lift state up” | Passing data through many components, and moving state to a shared parent. |
| “Z-index” — “zee” or “zed” | The same property; American and British pronunciation of the letter. |
| “L-C-P”, “I-N-P”, “C-L-S” | Core Web Vitals, always said as letters. |
| “Happy path” | The case where everything works. The follow-up will be about the other cases. |
In live coding the interviewer often talks while you type — hints phrased as questions, like “what happens if the input is empty?”. That is not small talk; it is a nudge, and missing it is expensive.
What Trippi Cue does in a frontend loop, and what it cannot
Trippi Cue is a Chrome extension. One click on its icon in the call’s tab in Google Meet, Zoom on the web or Teams on the web, and it listens to that tab’s audio — not the microphone, and no bot joins. The interviewer’s lines appear as they are recognised, with a translation under each if you choose a language. When a question or a nudge is addressed to you, a short card follows with two or three points to speak from. A note before the call — “React, TypeScript, component round in a sandbox” — keeps the answers in your stack.
Limits, plainly: it does not see the sandbox, the browser devtools or the Figma file. It cannot write or check your component. It hears speech, not your screen, and not your own voice. It runs in browser tabs only. If you share the screen with its window open, the window is visible — whether to use it is decided by the interviewer’s rules.
FAQ
Frontend engineer, specifically.
What is asked in a frontend developer interview?+
JavaScript fundamentals (event loop, closures, promises), browser rendering, CSS, a framework such as React, accessibility, performance, and usually a component built live.
Is there system design for frontend?+
Yes, at mid and senior levels. It is about the client: data flow, caching, pagination, real-time updates and failure states, not databases.
Do I need to know algorithms?+
Some companies still ask them; most frontend loops prefer a practical component. Ask the recruiter which format your loop uses.
Can Trippi Cue read my code in the sandbox?+
No. It hears the call’s audio only. It helps with the spoken part — explanations, trade-offs, follow-up questions — not with the code.
Does it work if the interview is in the Zoom desktop app?+
No. Join from the browser. Zoom on the web works, and Zoom asks for a one-time Chrome permission.
Read next
The nudge, heard. The answer, yours.
Trippi Cue is in the Chrome Web Store. One click on the icon when the call begins, and nothing before that.