Frontend Developer Job Description Template (With Screening Tips)

Frontend roles are the easiest to describe badly. Post a list of framework names and you'll get a pile of applications from people who have used those frameworks and can't build an interface anyone wants to use. The candidates worth hiring are filtering for something else: who owns design decisions, how much say they'll have, and whether the codebase is a pleasure or a punishment.

Here's a template that answers those questions, followed by the parts specific to hiring frontend engineers.

The template

Frontend Developer at [Company]

Location: [City / Remote — [region] / Hybrid] Compensation: [$X – $Y] base, plus [equity / bonus] Level: [Mid-level / Senior]

About the role

[Company] builds [product] for [users]. Our interface is [the primary surface customers use / the thing customers judge us on], and we're hiring a frontend developer to own [the specific area — the new dashboard, the design system, the customer-facing app].

You'll work closely with [n] designers and [n] backend engineers. [State plainly whether frontend here means product engineering, design-system work, or both.]

What you'll do

• Build user-facing features in [framework], from design handoff through production.
• Turn design files into interfaces that match the intent — and push back when something won't work in a real browser.
• Own [the design system / component library], keeping it consistent and documented.
• Improve performance and accessibility across [the app] — we care about both and measure them.
• Work with backend engineers on API shape rather than accepting whatever gets returned.

What we're looking for

• [n]+ years building production frontends.
• Deep [JavaScript / TypeScript] fundamentals — not just framework familiarity.
• Solid [React / Vue / Svelte] experience, or the ability to demonstrate equivalent depth elsewhere.
• Real CSS ability: layout, responsive design, and comfort debugging cross-browser issues.
• Working knowledge of accessibility — semantic HTML, keyboard navigation, ARIA where appropriate.
• An eye for detail. You notice when spacing is off by four pixels and you care.

Nice to have

• Experience with [your build tooling / SSR framework / testing library].
• Performance work: bundle size, Core Web Vitals, rendering.
• Design ability, or a track record of working closely with designers.

Our stack

[Framework, language, styling approach, build tool, testing setup, hosting.] Be specific about styling — "we use Tailwind" and "we use CSS-in-JS" attract different people.

Interview process

1. [30 min] Intro call.
2. [60 min] Walk us through frontend work you've built — decisions, trade-offs, what you'd change.
3. [90 min] Practical session: build or extend a small interface, either paired with us or as a paid exercise.
4. [45 min] Meet the design and engineering team.

Benefits and how to apply

[Benefits.] [Application link.] Send anything you've built that we can look at — a live site, a component library, a side project. We read every application.

[Company] is an equal opportunity employer.

Hiring frontend engineers: what's different

Ask for things you can look at

Frontend is the one specialty where the work is publicly inspectable. A live URL tells you more in two minutes than an hour of questions: does it work on a phone, does it survive keyboard navigation, does it load quickly, does it fall apart at 320 pixels wide? Always invite links, and always open them.

Screen for fundamentals, not framework trivia

Framework knowledge is learnable in weeks; the underlying skills take years. Weight your evaluation toward the things that transfer:

• CSS and layout ability — still the most consistently underrated frontend skill, and the most common real-world gap.
• Browser fundamentals — the event loop, rendering, network waterfalls, why something is slow.
• Accessibility instincts — whether they reach for a semantic element before a div with a click handler.
• Judgment about state — knowing when something needs a global store and when it obviously doesn't.

An engineer strong in all four will be productive in your framework within a month. The reverse is not true.

Describe the design relationship honestly

This is the detail experienced frontend candidates care most about and the one job posts almost always omit. There's a wide gap between "designers hand over finished files and you implement them," "you and a designer figure it out together," and "there's no designer and you'll be making these calls." All three are legitimate roles. Only one of them matches any given candidate. Say which it is.

Don't disguise a full-stack role

If the job is sixty percent backend, saying so costs you a few applications and saves you a resignation at month five. Candidates who applied to build interfaces and ended up writing services do not stay.

What to delete

• A list of ten frameworks. Nobody is expert in all of them, and asking signals you don't know what you need.
• "Pixel-perfect" paired with an impossible deadline — candidates recognize the contradiction.
• "Must have an eye for design" with no designer on staff and no design budget.
• jQuery in the requirements unless you genuinely mean it, in which case say why.

The takeaway

Great frontend hires are evaluated on fundamentals — CSS, browser behavior, accessibility, and taste — not framework checklists. Write the post to reflect that: name the specific surface they'll own, be honest about the design relationship and the backend split, publish the range, and invite links to real work. Then actually go and look at what they send.

Hiring for frontend? Post your role on JobsList.dev and reach developers directly.