Practice Pitches

Hi, I'm [name] — a frontend / full-stack engineer with [X] years building with React, and the last [Y] focused on Next.js and the App Router. I build web apps that feel fast and hold up under real traffic.

Most recently I [shipped / owned] [a product or surface] — [one concrete thing: e.g. a checkout flow, a marketing site, a dashboard] — used by [scale: e.g. tens of thousands of visitors a day], with a focus on rendering strategy, performance, and clean component boundaries.

I'm drawn to this role because it's senior, frontend-focused, and Next.js at its core.

I'm [name], a frontend / full-stack engineer with [X] years in JavaScript and TypeScript, the last [Y] building product in Next.js and React.

What I do well: I design component architecture that scales — clear boundaries between Server and Client Components, sensible data-fetching patterns, and layouts that don't force a full page re-render for a small change. I make deliberate rendering and caching decisions instead of defaulting to “just make it a client component,” and I care about what the user actually feels: load time, interactivity, layout stability.

A recent highlight: [a specific project — what it did, your role, and one measurable result, e.g. cut LCP by 1.2s, dropped the client bundle by 40%, or moved a page from client-rendered to streamed and users noticed].

I'm looking for a senior frontend role where I can own rendering and performance decisions and raise the team's bar — which is exactly what this looks like.

Start at the arc, not the resume. [I started building static sites / plain React SPAs, and moved toward frameworks because I got tired of solving routing and data-fetching from scratch on every project.]

Then 2–3 chapters, each one sentence of context + one thing you're proud of: “At [company] I [built X], which taught me [Y].” Show a progression — more ownership, bigger surfaces, more say in how things render.

Land on the present: “Now I'm strongest at [rendering/caching strategy / performance / component architecture], and I want a role where I [own the frontend platform / mentor / scale a design system].” Tie it back to this job.

Plain React (or CRA) gets you components but leaves routing, data fetching, and rendering strategy entirely up to you — every team reinvents them slightly differently. Next.js gives me file-system routing and a real rendering model out of the box, so those decisions are consistent instead of ad hoc.

Concretely: Server Components mean a lot of my UI never ships as JavaScript at all — the bundle only carries what's actually interactive. The built-in caching and revalidation story lets me choose static, dynamic, or somewhere in between per route, deliberately. And it's one framework that carries a project from a weekend prototype all the way to a production app without a rewrite.

It scales from a marketing page to a full application without changing the mental model — that's rare and valuable.

Three honest reasons, tailored: (1) the problem — [what they're building and why it's interesting to you]; (2) the technical fit — [their stack/scale matches what I do: Next.js, [their rendering approach], [their scale]]; (3) the role — [senior ownership / the team / remote / the product surface].

Close with a forward-looking line: “I'd want to spend my first weeks understanding [their core user flow] and finding where rendering or performance work has the most leverage.”

Two things define the App Router: the Server/Client Component split and the RSC payload.

By default every component is a Server Component — it renders on the server (or at build time) and never ships its JavaScript to the browser. Add "use client" and a component opts into the client bundle, which is what lets it use state, effects, and browser APIs. The rule of thumb: push interactivity to the leaves and keep everything above it on the server.

The RSC payload is the serialized description of the server-rendered tree — not HTML, a compact format the client uses to reconcile. That's how a Server Component can render deep in a Client Component's tree via children without becoming client code itself. Knowing exactly which parts of a page ship JS, and why, is what separates “it works” from “I designed this deliberately.”

Situation: [a page / flow] was [slow to load / janky on interaction] — [LCP was at X seconds / the bundle was Y KB / users were bouncing before it finished loading].

Task: I owned finding and fixing the root cause without a rewrite.

Action: I profiled instead of guessing — [ran Lighthouse / opened Chrome DevTools' performance panel / checked Vercel Analytics] and found [the cause: a client component that didn't need to be one / an unoptimized image / a waterfall of sequential fetches / a huge unused dependency]. I [converted it to a Server Component / used next/image / parallelized the fetches / removed the dependency], and added [a bundle-size check / a Lighthouse budget in CI] so it can't silently regress.

Result: [LCP dropped from X to Y / bundle shrank by Z%], and the regression check means the win sticks.

Situation: we had to [choose between X and Y — e.g. SSR vs. static generation, a client state library vs. leaning on Server Components, one Next.js app vs. splitting into micro-frontends].

Task: I had to make the call and get the team aligned.

Action: I framed it by the constraints that actually mattered — [content freshness, team size, deploy cadence, SEO requirements] — and named the trade-off explicitly: “[option A] buys us [benefit] at the cost of [downside].” I [prototyped both / benchmarked the rendering cost / wrote a short doc] and recommended [the choice], with a fallback if [assumption] proved wrong.

Result: [outcome], and because I'd written the trade-off down, we didn't relitigate it every sprint.

Think of a restaurant. A Server Component is food the kitchen preps before the doors even open — it's ready, it doesn't need the customer there, and nothing about assembling it has to happen at the table. A Client Component is a made-to-order dish at a live station — it has to happen in front of the customer because it reacts to what they choose right then.

Most of a menu can be prepped ahead. Only the parts that truly depend on the customer's live choices — clicking, typing, toggling — need that live station. That's why we default to Server Components and only reach for "use client" when something genuinely needs to run in the browser.

The payoff: the more you prep ahead, the less the customer waits at the table — which, translated back, means less JavaScript the browser has to download and run.

Always have 3–4 ready. Good ones signal seniority:

“What's the rendering strategy on your main product today — mostly static, dynamic, streamed — and what's the biggest pain point with it?”

“How do you track Core Web Vitals and performance budgets, and what happens when a PR regresses one?”

“What does testing and CI look like for the frontend — unit, e2e, visual regression?”

“Where is the frontend paying down tech debt right now, and where would I have the most leverage early?”