7.2 ★ core [B][J] 10 interview Q's

Frontend for backend devs

The browser-side vocabulary a server dev needs to direct an AI to build good UI — components, state, rendering, styling — without becoming a frontend specialist. (Module 5 is the interview-depth version.)

You own the server. Now a project needs a UI, and the AI will happily write the React for you — but only if you can describe what you want in the right words. This chapter is the frontend vocabulary a backend dev needs to direct the work, not to become a frontend specialist. (The interview-depth version — render pipeline, closures, CORS — is Module 5; this is the orientation map.)

Components, props, and state

A modern UI is a tree of components. Data flows down as props; a component’s own changing data is state. That’s 80% of the mental model — the rest is which library draws the tree. If you’ve written server code, the analogy is clean: a component is a function, props are its arguments, and the returned markup is its return value. State is the one new idea — a value the component remembers between renders and can change, triggering a re-render when it does.

FIG 1 · a component tree Data flows down as props; a component's own changing data is state.

Library vs framework vs styling — they’re different jobs

When an AI says “I’ll use Next.js with Tailwind and shadcn,” it just named four different layers. Knowing which is which means you can swap one without panicking, and you can tell when a suggestion is mixing concerns (e.g., proposing two UI libraries).

Layer	What it is	Canonical example	Reach for it when
UI library	draws + updates components	React, Vue, Svelte	you need reusable, stateful UI
Meta-framework	adds routing, server rendering, build	Next.js, Astro, SvelteKit	you're building a whole site/app
Styling system	how it looks	Tailwind, plain CSS, CSS Modules	always — pick one and be consistent
Component kit	pre-built styled components	shadcn/ui, MUI, Radix	you want polished UI fast, not from scratch

Four layers, four jobs. An AI prompt can name one per layer.

Where the HTML gets built: client vs server rendering

The single biggest architectural choice in frontend is where the first HTML comes from. Either the server builds it and sends ready-to-show markup, or the server sends a near-empty page plus a blob of JavaScript that builds the UI in the browser. Hydration is the hybrid most modern frameworks use: server-rendered HTML for an instant first paint, then JS attaches to make it interactive.

FIG 2 · who builds the HTML? Server rendering ships ready HTML; client rendering ships JS that builds it; hydration does both — fast HTML, then JS wakes it up.

The tradeoff is real and worth a sentence to an AI: server rendering is fast to first paint and friendly to search engines, but needs a server (or build step) to produce the HTML. Pure client rendering ships a blank page until the JS downloads and runs — fine for an internal dashboard, bad for a public landing page. This very site server-renders (actually build-time-renders) almost everything and ships zero JS except where a widget genuinely needs it — that’s the “islands” idea.

	Server rendering	Client rendering
First paint	instant (HTML arrives ready)	blank until JS runs
SEO	strong — crawlers see content	weaker — content is JS-built
Needs	a server or build step	just static hosting + JS
Best for	content, marketing, e-commerce	app-like dashboards behind a login

Most meta-frameworks let you mix both per route. Default to server-render for public pages.

What a bundler actually does

You write dozens of small .ts/.tsx/.css files; the browser shouldn’t download dozens of files (slow) or understand TypeScript and JSX (it can’t). A bundler (Vite is the modern default) compiles, combines, and minifies your source into a few small files the browser can fetch fast — which is why you never deploy raw source.

Telling the AI what you want

A backend dev’s instinct is to describe data. Frontend output gets dramatically better when you describe components, their props, and their states instead.

Weak prompt → strong prompt

WEAK:  "Make a nice product page."

STRONG: "Build a <ProductCard> component (React + Tailwind).
 Props: name, price, imageUrl, inStock (boolean).
 States: a quantity counter (default 1) and an 'added!' flash after click.
 If inStock is false, disable the button and show 'Sold out'.
 Match the dark card style already in src/components/."

The strong version names the component, its props, its states, the edge case, and a visual reference. The AI now has no room to guess — which is exactly when AI output stops drifting.

01 Learning objectives

0 / 6 done

02 Curated reading

React — Thinking in React
essential 20m — Components, props, and state from the source. Interview depth lives in Module 5.
Astro — Why Astro?
optional 12m — Meta-framework + server-first rendering — the model this very site uses.
Tailwind CSS — Styling with utility classes
optional 12m — What “utility-first styling” actually means.

03 Knowledge check

knowledge check4 questions · pass ≥ 70%

01easy
Which best describes component state (vs props)?
02easy
Browser (client) code can safely hold secret keys.
03medium
React is a UI library; Next.js / Astro are…
04medium
A strong frontend prompt to an AI should name… (select all)

04 Interview questions

browse all ↗

What gets asked on this topic — tap a card for how to approach it, the follow-ups, and the trap. Company tags are best-effort & sourced.

Commonly asked junior concept very common What do HTML, CSS, and JavaScript each do, and what is the DOM?
HTML is structure (the content and its meaning), CSS is style (how it looks), JavaScript is behavior (what happens when you interact). The DOM (Document Object Model) is the browser's live, in-memory tree representation of the HTML — JS reads and changes the DOM, and the browser re-renders.
The one-liner that lands: HTML is the skeleton, CSS is the skin, JS is the muscles, and the DOM is the object you manipulate to change any of it at runtime.
Follow-ups they push on
- When JS changes the page, is it changing the HTML file or the DOM?
- What's the difference between the DOM and the source HTML?
Red flag Thinking JS edits the .html file. It edits the DOM — the in-memory tree — not the file on disk.
source: MDN — How does the web work? ↗
Commonly asked junior concept very common What's the difference between props and state in a component?
Props are inputs passed in from the parent — read-only from the component's view, like function arguments. State is data the component owns and can change over time, which triggers a re-render when it does.
Framework-agnostic rule of thumb: if the data comes from above and the component shouldn't mutate it, it's a prop; if the component manages it and updates it (a toggle, a form field, a counter), it's state.
Follow-ups they push on
- What is a component, in one line?
- If a parent and child both need the same value, where should it live?
Red flag Mutating props directly. Props flow down and are read-only; to change them you lift state to the parent.
source: React — Thinking in React ↗
Commonly asked mid concept common Explain client-side rendering vs server-side rendering, and what 'hydration' means.
CSR: the server sends a near-empty HTML shell plus a JS bundle; the browser builds the whole DOM in JS. Fast to deploy, but slower first paint and weaker SEO. SSR: the server renders real HTML up front so the user sees content immediately and crawlers get real markup.
Hydration is the step after SSR where the JS bundle loads and attaches event listeners to the already-rendered HTML, turning the static markup into an interactive app. The HTML the server sent and the HTML React expects must match, or you get a hydration mismatch.
Follow-ups they push on
- Why does SSR help SEO?
- What causes a 'hydration mismatch' error?
Red flag Thinking SSR means 'no JavaScript.' SSR sends HTML first, then still hydrates with JS for interactivity.
source: GreatFrontend — Explain what React hydration is ↗
Commonly asked junior concept occasional A UI library, a meta-framework, a styling system, a component kit — what's the difference?
Different layers of the stack: a UI library (React/Vue/Svelte) gives you the component model. A meta-framework (Next/Astro/SvelteKit) wraps a UI library with routing, rendering modes, and a build pipeline. A styling system (Tailwind or plain CSS) decides how you apply styles. A component kit (shadcn/MUI) is pre-built, styled components you drop in.
They stack, not compete: e.g. Astro (meta-framework) + React (UI library) + Tailwind (styling) + shadcn (components).
Follow-ups they push on
- Is Next.js a replacement for React?
- What does a bundler like Vite do?
Red flag Calling Next.js 'a JavaScript framework like React' — Next is built on React; they're different layers.
source: Astro — Why Astro? ↗
Commonly asked junior concept occasional You're asking an AI to build a UI component. What makes a good frontend prompt?
Name four things: the component (what it is — 'a comment card'), its props (the data it takes in), its states (loading, empty, error, hover/disabled), and a visual reference (a screenshot, an existing component to match, or a design system).
Vague prompts ('make a nice form') produce generic output. Specifying props and states is what turns the model from guessing into building to a contract — the same discipline you'd use describing the component to a teammate.
Follow-ups they push on
- Why list the empty and error states explicitly?
- How does giving an existing component as reference help?
Red flag Only describing the happy path — you get a component that breaks on empty/error data you forgot to mention.
source: Anthropic — Prompt engineering overview ↗
Commonly asked junior concept very common What is a component, and why break a UI into components at all?
A component is a reusable, self-contained piece of UI — markup plus its own logic and styling — that takes inputs (props) and renders a piece of the screen. A Button, a CommentCard, a Navbar are all components.
You break a UI into components for the same reasons you break code into functions: reuse (write the card once, render it 50 times), isolation (a bug in one is contained), and composition (build complex screens by nesting small pieces). It also maps cleanly to how you reason and how you prompt an AI — one component, one clear responsibility.
What a strong answer covers
- A component = reusable UI unit: markup + logic + style, driven by props.
- Reuse: define once, render many times with different props.
- Isolation and composition: small pieces nest into whole screens; bugs stay contained.
- Mirrors functions — one component should have one clear responsibility.
Follow-ups they push on
- How do you decide where one component ends and another begins?
- What's the downside of one giant component that does everything?
Red flag Building one massive component for a whole page — it becomes unreusable, hard to test, and a nightmare to change or describe to an AI.
source: React — Your First Component ↗
Commonly asked mid concept common Why does a list of rendered items need a stable `key`, and what goes wrong if you use the array index?
When you render a list, the framework needs to know which rendered element corresponds to which data item across re-renders — that's what key provides. A stable, unique key (an item's id) lets it correctly match, reorder, insert, and remove elements while preserving each item's state.
Using the array index breaks this when the list reorders, filters, or has items inserted/removed: the index→item mapping shifts, so the framework reuses the wrong DOM node and component state (a half-typed input, a checkbox) sticks to the wrong row. Index keys are only safe for a static, never-reordered list.
What a strong answer covers
- key lets the framework match rendered elements to data items across renders.
- Use a stable, unique id from the data — not the array index.
- Index keys break on reorder/insert/delete: state and DOM attach to the wrong item.
- Index is acceptable only for a fixed list that never changes order or length.
Quick self-check
You render a reorderable todo list using the array index as each item's `key`. After dragging an item to the top, the checkboxes appear checked on the wrong todos. Why?
Follow-ups they push on
- Why does a half-typed input jump to the wrong row with index keys?
- Where should the key come from if your data has no id?
Red flag Reaching for the array index as the key by default — it silently corrupts state when the list is dynamic (the exact case keys exist for).
source: React — Rendering Lists (keys) ↗
Commonly asked mid concept common When the data on screen changes, what makes the UI update? Contrast the imperative DOM approach with the declarative component approach.
Imperative (vanilla DOM): you change the data *and* manually issue the DOM edits — el.textContent = count — keeping the screen in sync by hand. It works but every state change means hand-written update code, which is where bugs breed.
Declarative (React/Vue/Svelte): you describe what the UI should look like *as a function of state*, and when state changes you just update the state — the framework figures out the minimal DOM changes and applies them. You stop writing 'how to update the screen' and only write 'what the screen is for this state'. That's the core mental shift for a backend dev moving to the frontend.
What a strong answer covers
- Imperative: you manually mutate the DOM on every change — error-prone bookkeeping.
- Declarative: UI = f(state); you update state, the framework re-derives and patches the DOM.
- The win is removing hand-written sync code, the classic source of UI bugs.
- You think in 'what the screen is', not 'what DOM operations to perform'.
Follow-ups they push on
- What is a 're-render' in a declarative framework?
- Why is manually syncing the DOM so bug-prone at scale?
Red flag Trying to manually edit the DOM inside a React component — you fight the framework; instead change state and let it re-render.
source: React — Reacting to Input with State ↗
Commonly asked mid concept occasional What does it mean to 'lift state up', and when do you do it?
Lifting state up means moving a piece of state out of a child component into the closest common parent, then passing it back down as props (plus a callback to change it). You do it when two or more components need to read or stay in sync with the same value.
The rule: state should live at the lowest common ancestor of everything that needs it. If a child owns state that a sibling also needs, neither can see the other's local state, so you hoist it to the parent that contains both. The parent becomes the single source of truth and hands it down.
What a strong answer covers
- Move shared state to the closest common parent, pass it down as props.
- Do it when 2+ components must read or stay in sync with the same value.
- The parent becomes the single source of truth; children get value + a change callback.
- Keeps duplicate, drifting copies of the same state from existing.
Follow-ups they push on
- If two sibling components both need a value, where does it live?
- What's the risk of each sibling keeping its own copy of the same state?
Red flag Duplicating the same state in two siblings and trying to keep them in sync manually — they drift; lift it to the shared parent instead.
source: React — Sharing State Between Components ↗
Commonly asked junior concept common Why do component states like loading, empty, and error matter as much as the happy path?
Any component that fetches or depends on real data has more than one state: while the data is in flight (loading), when it arrives but is empty (empty — zero results), when the request fails (error), and finally the populated success state. Real users hit all four.
If you only build the success path, the component shows a blank or broken UI the moment data is slow, missing, or failing — exactly the moments users notice. Designing the loading skeleton, the empty message, and the error/retry up front is what separates a demo from a shippable feature, and it's why you list these states explicitly when prompting an AI to build the component.
What a strong answer covers
- Data-driven components have ≥4 states: loading, empty, error, success.
- Users hit the non-happy states constantly (slow networks, no results, failures).
- Skipping them yields blank/broken UI at the worst moment — when something's already wrong.
- Naming all states up front is what makes a component (and an AI prompt) production-grade.
Follow-ups they push on
- What's the difference between an empty state and an error state?
- Why is a loading state about perceived performance, not just correctness?
Red flag Building only the populated success view — the component looks done in the demo but breaks on the first slow or failed request in production.
source: Anthropic — Prompt engineering overview ↗