Looking for work with a US company? Apply to the Rolemote talent roster — free →
Rolemote
How it worksHow we screenTry the screenerSample shortlistsCompare us honestlyDone-for-you searchWhat the search costs
Free researchAgency fee tableSalary guidesJD templatesInterview kitsStatisticsBlog
PricingFor talent
Start free

Sample shortlist · candidates written by us, real screener output

Shopify Developer

This is what every search delivers: finalists screened against the brief, each with a score, screening notes, structured answers, and a graded work sample. These sample candidates were written by us and run through the real screener — the scores and notes are its unedited output, not a mock-up.

The brief they were screened against

Role: Shopify Developer · Band: $800–1,350/mo

Must-haves: Liquid and Online Store 2.0 sections, customises a theme without breaking its updates, diagnoses before rebuilding, mobile performance on product pages

Nice to have: metafields and app integrations, reading Shopify and GA4 analytics, checkout extensibility

Scored by the same rubric the production screener runs on real applicants (junior-developer, claude-sonnet-4-6), on 2026-09-23. Nothing below was edited afterwards — including where it went against a candidate. The rubric and weights are published.

Dominic T.

SCREEN 84/100

Philippines · asking $1,150

Screening notes

Strongest evidence: the work sample is genuinely instructive — independently caught the 110KB JS problem on a duplicate theme before committing, proposed a metaobject-driven architecture that separates content from markup, built a native <dialog> with real accessibility testing (VoiceOver, keyboard, focus return), and tracked a business outcome (14%→9% return rate) rather than just a performance delta; none of that detail was supplied by the question, and the decision to document the vendor-file edit in the README so a future update can be patched with one block rather than a rebuild reflects production-level thinking. The scenario answer is methodical and honest — the caveat about 'a week of data / a few hundred sessions' being a signal not a verdict is exactly the kind of calibrated judgment the role requires, and the 'diff both theme copies into one Git repo' step is concrete tradecraft rather than generic advice. The LCP 4.6s→2.2s result with specific levers named (autoplay hero, two removed apps) and a downstream conversion figure (5.8%→6.9% add-to-cart) passes the specificity test; no concern about fabrication, though it is unverified. Main gap: checkout extensibility is flagged as early/one project, and there is no evidence of reading GA4 beyond basic setup — both are nice-to-haves, not blockers. At $1,150 against a $1,500–2,800 band this is strong value; advance to a live technical screen with a small paid task around a theme diff and a Liquid schema exercise.

Experience

5 years on Shopify, the last 3 at a Manila development agency building for US DTC brands — apparel, supplements and home goods, about 25 stores. Most of my work is Online Store 2.0: custom sections, metafield-driven product pages, and moving old vintage themes to JSON templates. Best result: a US apparel brand's mobile product-page LCP went from 4.6s to 2.2s after I replaced an autoplay hero video and removed two apps nobody used, and mobile add-to-cart rate went from 5.8% to 6.9% the following month.

Scenario answer

First, my reply to the client: 'Let's not revert yet. The old version is still in your themes list, unpublished, so going back is one click whenever we decide. Give me until tomorrow to find what changed — reverting blind throws away the update's fixes and teaches us nothing.' Then, in this order: 1. Is the drop real? Shopify's conversion rate breakdown for the 7 days after the update against the 7 before and the same week last month: sessions with cart additions, reached checkout, completed checkout. Then the number that can't lie — orders. If orders held and only the reported rate fell, tracking broke, not the store. A GA4 snippet pasted into theme.liquid years ago is exactly the kind of code edit that goes missing in an update. 2. Which step dropped? If add-to-cart held and checkout completion fell, the theme probably isn't the cause, because checkout doesn't run on the theme. I'd look at shipping rates, payment methods, an expired discount. 3. Split by device and traffic source. A theme problem usually shows on one device. A drop spread evenly across everything, starting the day a sale ended, isn't a theme problem. 4. Diff the two versions. shopify theme pull --theme <id> for both copies into one Git repo, then diff: templates/product.json, the main product section, the variant picker, the product JavaScript. I also check whether Shopify said 'code edits could not be included' when the update was added. If it did, anything a developer or an app had written into those files is gone. 5. Use the page like a customer, on a real phone. Is add-to-cart still above the fold? Did the picker change from buttons to a dropdown, or stop preselecting a variant? Are the review stars, size guide and payment messaging still there? 6. Speed. Shopify's web performance report for product pages on mobile — theme changes are marked on the chart — and PageSpeed Insights on both versions. What I'd recommend depends on what I find, but it's usually a fix, not a revert: put the missing snippet back as its own section, restore the picker behavior, repair the tracking. I'd only republish the old version as a stopgap if orders are really down and I can't find the cause within a day, and then port the fix into the new version rather than live on the old one. One caveat I'd say out loud: with a few hundred product-page sessions a week, 25% can be a dozen add-to-carts. A week of data is a signal, not a verdict.

Work sample

BRIEF A US swimwear brand, about 300 products, wanted a size chart on every product page — different for tops, bottoms and one-pieces — that their own team could edit. They had already picked a size-chart app. I tested it on a duplicate theme first: it added about 110KB of JavaScript to every page of the store, not just product pages, and their mobile product-page LCP was already 3.4s. So I proposed building it into the theme instead, with no monthly fee, and they agreed. APPROACH 1. Data first. A metaobject definition, 'Size chart': a name, a list of rows (each row its own small metaobject: size, bust, waist, hip, in inches and cm) and a fit note. Three entries — tops, bottoms, one-piece. Each product gets one metafield pointing at its chart. The team assigned all 300 products in an afternoon. 2. Markup in its own snippet, size-chart.liquid: a 'Size guide' link next to the size picker that opens a native <dialog> with a real HTML table. Not an image of a table, so it's readable on a phone and by a screen reader. 3. One small edit to a vendor file: a new block type in the main product section's schema that renders the snippet. It's listed in the repo README, so if a future theme update can't carry it over, putting it back is one block, not a rebuild. 4. No JavaScript library. The dialog needs about 20 lines to open and close, loaded on product pages only. WHAT I TESTED - A product of each chart type, a product with no chart (the link doesn't render) and a chart with an empty row. - A real iPhone and a mid-range Android, not just DevTools: the table scrolls sideways inside the dialog instead of widening the page. - Keyboard and VoiceOver: focus moves into the dialog, Escape closes it, focus returns to the link. - The theme editor: the block can be moved or hidden without code. - Theme Check clean, and PageSpeed Insights on mobile before and after: no change to LCP, because nothing loads until someone taps. - Then I asked the client to watch the number that mattered. Over the next two months, 'wrong size' exchanges went from about 14% of returns to 9%.

Ximena O.

SCREEN 88/100

Mexico · asking $1,300

Screening notes

The work sample is the standout: the candidate describes a /blocks file architecture that leaves no theme file edited (update-safe by design), a metaobject with three named fields plus a per-SKU override for freight products, an empty-state hide behavior, VoiceOver order verification, and a confirmed A/B result (7.1→7.9% ATC, ~48k sessions, ~33% WISMO reduction) — none of those specifics were supplied by the brief, and the combination of CRO rigor with OS2.0 implementation discipline is genuinely uncommon. The scenario answer independently demonstrates mature diagnostic sequencing: defining the metric before pulling it, reconciling Shopify vs GA4 discrepancy as a tracking signal, segmenting by variant count and reviews block, using Clarity recordings as a faster signal than weekly data, and proposing Rollouts/Shoplift split rather than a hard revert — the Rollouts reference is a real, niche tool that most junior Shopify devs don't reach for. The one real gap is JavaScript: the candidate flags it as 'not my strongest,' and for a JS/TS-primary Junior Developer role that matters; the brief lists it as a must-have for the general role even if the Shopify search doesn't stress it, so there is unresolved risk on more complex front-end work. At $1,300 against a $1,500–2,800 band, the candidate is below floor, which is a minor flag but leaves room for the hire to land the band; overall this is a confident advance-to-interview with a targeted JS probe.

Experience

4 years as a Shopify developer at a Mexico City e-commerce agency, on the CRO side: US and Mexican DTC brands in beauty, pet food and coffee subscriptions. I build the product-page changes and I also set up the measurement — GA4, Shopify's customer events, and the tests. I've run about 40 A/B tests on product pages. The one I'm proudest of moved delivery and returns information from a tab to under the add-to-cart button for a US pet-food brand: add-to-cart rate up 11% over three weeks and about 48,000 sessions.

Scenario answer

I'd tell the client I understand wanting the old version back, and that they'll have a yes or no within two working days, with the numbers behind it. First I make sure we're measuring the same thing. 'Product-page conversion' can mean three different numbers, so I define it as sessions that viewed a product and added to cart, and pull it from both Shopify and GA4 for the 14 days before and after the update. If Shopify shows the drop and GA4 doesn't, or the other way round, I look at tracking first: if the store's add_to_cart event is pushed from theme code, an update can drop it. Then I segment, because a real theme problem rarely hits everyone equally: - mobile vs desktop - paid social vs email vs organic - new vs returning visitors - the top 10 products one by one. If the drop sits on products with many variants, I look at the variant picker; if it sits on products with lots of reviews, I check the reviews block survived the update. In parallel I compare the two versions: the vendor's release notes first, then the product template and main product section side by side, in the theme editor and in code. And I watch 30 to 40 recorded mobile sessions in Microsoft Clarity on the new version, looking for dead clicks and rage clicks around the picker and the button. Recordings usually show in an hour what the numbers take a week to say. On speed, I'd run PageSpeed Insights on both versions, but in my experience a few hundred milliseconds rarely explains a 25% drop by itself. A missing or moved element usually does. Then my recommendation. If I find a specific cause, fix it in the new version and keep the update. If the drop is real and I can't find a cause, I'd split-test old against new for two weeks instead of reverting on one week of data that might be noise — Shopify's Rollouts can run an experiment between two themes if the store has access to it; otherwise Shoplift. Reverting for good also means the next update becomes a bigger jump.

Work sample

BRIEF A US pet-food brand, subscription-first. Customers kept emailing to ask when an order would arrive and whether they could return an opened bag. The answers existed — in a 'Shipping' tab under the description, which on mobile sat three screens below the add-to-cart button. The ask: put delivery and returns information where people decide, and let the team change it without a developer. APPROACH - One block, 'Delivery and returns', directly under the add-to-cart button. Their theme's product section accepts theme blocks, so it lives in its own file in /blocks. No existing theme file was edited, so there is nothing for a vendor update to clash with. - The content comes from a metaobject, 'Delivery promise', with three fields: the dispatch cut-off ('Orders placed by 2pm ET ship the same business day'), the delivery range in days, and a one-line returns promise. The team edits it once and it changes on every product. - A product metafield can override it, for the two heavy SKUs that ship by freight. - Plain text, no accordion. The whole point was that people see it without tapping anything. WHAT I TESTED - A normal product, a freight product with the override, and a product with nothing assigned: the block hides itself instead of showing empty labels. - The theme editor: the team can move, hide and restyle the block without code. - VoiceOver on iPhone reads it in order, straight after the button. - Then a real A/B test before I called it done: three weeks, about 48,000 product-page sessions split 50/50. Add-to-cart rate went from 7.1% to 7.9%, and 'where is my order' emails dropped by about a third. The client kept it.

Mylene C.

SCREEN 72/100

Philippines · asking $850

Screening notes

Strongest evidence is the work sample: candidate names a concrete deliverable (before-after.liquid), describes schema settings with specificity (image pickers, background color, preset for 'Add section'), chooses CSS grid with a responsive breakpoint, and adds a JS drag-compare slider — all detail the brief did NOT supply, suggesting real hands-on execution. Scenario judgment is methodical and honest: side-by-side theme comparison, console check, asking whether something other than the theme caused the drop, and a clear two-day rollback threshold — the rollback framing is sound even if not deeply technical. Biggest concern is the ceiling on technical depth: JavaScript is self-described as 'basic,' Online Store 2.0 section architecture is implied but never explicitly named, metafields and checkout extensibility are absent, and performance tooling (Lighthouse, image lazy-loading, LCP) is never mentioned despite the role brief flagging mobile performance as a must-have. Verdict: advances to interview as a competent Shopify theme developer with real project volume and honest communication; probe mobile performance workflow and OS2.0 app block schema depth before committing, and $850 sits well below band floor, signalling either negotiation room or a mismatch in seniority expectations.

Experience

3 years as a freelance Shopify developer, working through Upwork and with a small Cebu agency, mostly for small US and Australian stores. I set up and customize themes, edit Liquid and CSS, create custom sections, install and configure apps, and fix layout problems on mobile. I have completed more than 60 projects with a 98% Job Success Score. I am hardworking, a fast learner and I always make sure my clients are satisfied.

Scenario answer

I understand the client is worried about losing sales, so I would act quickly. But before reverting I would try to find out what changed, because the new version may have important fixes and improvements. First, I would open the old theme and the new theme side by side in the theme editor and compare the product page: the layout, the sections and the blocks. I would check if any sections or app blocks are missing, like the reviews or the size chart, because sometimes apps need to be added again after a theme update. Then I would test the product page on my phone and on desktop to see if something is broken, like the variant selector, the add to cart button or the product images. I would also check the browser console for errors. I would also ask the client if they changed anything else last week, like prices, shipping rates or apps, because the drop might not be caused by the theme. If I find the problem, I would fix it in the new theme. If I cannot find it in one or two days, I would recommend going back to the old theme to protect the sales, and keep working on the new version in the background before publishing it again.

Work sample

BRIEF: A skincare client wanted a 'Before and after' section for the homepage and product pages, where they can upload two photos and a short text and change it themselves without a developer. APPROACH: I created a new section file, before-after.liquid, in the Sections folder. In the schema I added settings for the heading, two image pickers, a text box and the background color, plus a preset so the client can find it under 'Add section' in the theme editor. For the layout I used CSS grid: two columns on desktop and one column on mobile. I also added a small JavaScript slider so customers can drag to compare the two photos. WHAT I TESTED: I tested the section in the theme editor to make sure all the settings work and it can be added to any page. I checked it on desktop, tablet and mobile in Chrome, and on my own iPhone. I also tried it with different image sizes to make sure the layout does not break. The client was happy with the result and now uses it on 5 product pages.

This is the artifact every search delivers

Post the role and the same screener runs on your real applicants — the questions arrive already written, and you read every finalist in full before any fee is due.

Post a role free Or have us run the search

The same screener, other roles

Sample shortlist: Shopify Developer | Rolemote