Frontend Code Evaluation Specialist

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 1920x1080 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.

• 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.

• Render a reference page and two candidate replications at 1920x1080 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.

• 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 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 Dev Tools.
• Browser Dev Tools 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…