Frontend Code Evaluation Specialist

Mercor; Greater London; On-site; GBP 40,000 - 70,000; Full time

Job summary

Mercor seeks a practicing web developer to evaluate real pages by comparing a reference site with two candidate replications at 1920×1080. You will assess visual fidelity, structure, and responsiveness, then read and critique the source code of both attempts with precise, evidence-backed rationales.

Strong knowledge of HTML/CSS, dev tools, and hand-written markup is essential. This is a rigorous, desk-based evaluation task intended for skilled frontend professionals.

Qualifications

• 3–8 years of professional web development experience, shipping frontend interfaces.
• Fluency with hand-written HTML and CSS, semantic markup, flexbox, grid, media queries, legacy layouts.
• Ability to read scripts and understand DOM effects; navigate a site with DevTools.

Responsibilities

• Render reference and two reproductions at 1920×1080 and judge state-by-state fidelity.
• Diff visual fidelity: box model, typography, color, borders, assets, z-order, overflow.
• Read source of attempts and grade construction quality, distinguishing accurate replication from visually correct only pages.
• Provide evidence-based justifications for each preference.

Skills

Frontend web dev

HTML/CSS

DevTools proficiency

Semantic markup

Responsive design

JavaScript basics

Tools

DevTools

Job description

About the work

We're building a high-quality dataset of human preference judgments on AI-generated frontend code. Each task hands you a reference web page — crawled from the real internet, delivered as a full zipped site tree plus screenshots of its default view and, on some pages, additional states reached by hovering, clicking, or scrolling. Alongside it come two model attempts, A and B, each a zipped self‑contained site tree. The models only ever saw the screenshots; they never had the source.

You download all three, run them locally, view each at a 1920×1080 viewport, interact with them to reach every required state, then open the source of both attempts and grade them against each other — on visual fidelity per state, and on how the code is actually constructed. Structure and responsiveness are explicitly part of the rubric, not just the render.

This is evaluation work, not authoring. The defining skill is not that you can build a page — it's that you can open someone else's page and tell how it was built and where it cheats.

Please read before applying

• Each unit takes roughly 2-3 hours and is timed. This is not microtask work; if you can only offer scattered 15-minute windows, you will not be able to finish a unit.
• You need a real local development environment. A tablet, a Chromebook, or a locked-down work machine that cannot run a local static server will not work for this project.
• You need at least one completed Mercor engagement, delivered in full. We are not onboarding net-new experts to this project.

What you'll do

• Render a reference page and two candidate replications at 1920×1080 and judge which is the closer reproduction, state by state.
• Diff visual fidelity in detail: box model and spacing, typography (family, size, weight, line-height, letter-spacing), color and border treatment, image and asset handling, z‑order and overflow.
• Read the source of both attempts and grade construction quality — distinguishing a replication that is genuinely correct from one that merely looks correct at one viewport. Hardcoded pixel offsets, absolute positioning standing in for real layout, inline style soup, a single undifferentiated div tree, or a screenshot pasted in as an instead of a rebuilt section.
• Test responsiveness: a nav bar that looks right at 1920px but collapses at 1400px is a defect, and you should be able to say precisely why.
• Write a specific, evidence‑cited justification for every preference. We need "B nests the article body in a single absolutely‑positioned div, so the text overlaps the footer below 1600px, while A uses normal document flow" — not "A looks closer."
• Use the "this task is broken" escape hatch with judgment: distinguish a task that genuinely cannot be completed from the screenshots provided from one that is merely hard. Over‑flagging and under‑flagging are both failure modes.

You're a fit if you have

• 3-8 years of professional web development experience, shipping web interfaces for a living, primarily in frontend or full‑stack work.
• Fluency across web eras. The reference pages are real crawled sites — one is a small charter‑fishing business built in the table‑and‑image‑map tradition, another a corporate press‑release page with stacked navigation rows and social share widgets. If your entire career happened inside a modern component framework and you have never authored raw CSS or seen a table used for layout, you will misjudge many of these pages.
• Command of hand‑written HTML and CSS: semantic markup, flexbox, grid, media queries, and legacy float‑ and table‑based layouts you can read and reason about. You should be able to look at a rendered layout and predict what's holding it together before opening DevTools.
• Browser DevTools as muscle memory — setting an exact viewport, walking the element tree, checking computed styles, watching what a hover handler mutates.
• Command‑line comfort: unzipping an archive, standing up a static local server because the relative asset paths demand it, and untangling a broken image reference rather than giving up and grading from the screenshot.
• Enough JavaScript to read a page's scripts and understand what they do to the DOM, even if you don't write JS daily.
• Professional written English. Every task ends in a free‑text justification, and a rating without a specific rationale is worth very little.

Equipment

• A desktop or laptop that displays a 1920×1080 viewport.
• Administrator rights on your own machine, so you can install and run a local server.

Nice to have

• Prior RLHF, preference‑labeling, model‑evaluation, or structured code‑review work — the strongest single signal. Rubric‑driven comparison at volume needs almost no ramp here.
• Pixel‑perfect design‑to‑code experience: agency work, design systems, template production. Anyone who has had a designer reject a build over four pixels has exactly the fidelity eye this needs.
• Accessibility expertise (ARIA, semantic landmarks, heading hierarchy) — you'll notice immediately when an attempt renders a heading as a styled .
• Familiarity with how LLMs fail at code generation.
• Web scraping, archiving, or DOM‑parsing background — comfort with messy crawled site trees.
• More than one completed Mercor project, and availability in contiguous multi‑hour blocks.

Note:

This seat is for practicing web developers. Backend‑only, ML/data‑science‑only, mobile‑native‑only, and DevOps‑only engineers do not have the UI instincts this requires, however strong they are otherwise. Designers who do not code cannot grade the source axes at all. Framework‑only engineers who have never authored CSS outside a component library will struggle with the legacy reference pages.