Sample shortlist · candidates written by us, real screener output
Junior 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: Junior Developer · Band: $1,500–2,800/mo
Must-haves: ships features in JS/TS or Python under review, sound debugging order, writes tests, honest rollback judgment
Nice to have: Next.js or React experience, PostgreSQL, API integration work, basic CI/CD awareness
Scored by the same rubric the production screener runs on real applicants (junior-developer, claude-sonnet-4-6), on 2026-09-21. Nothing below was edited afterwards — including where it went against a candidate. The rubric and weights are published.
Carlos D.
SCREEN 84/100Screening notes
Strongest concrete evidence: named real deliverables with specifics (multi-step onboarding wizard, CSV/background-job pipeline, Stripe integration at 94% coverage), stack matches the brief exactly (TS, Next.js 14, PostgreSQL, Prisma, GitHub Actions, Vitest), and the work sample is clean, correct, and paired with a genuinely complete test plan including edge cases (ties, refunds, ISO datetime slicing) that goes beyond what most juniors would enumerate. Debugging scenario is methodical and honest — the 20-minute rollback threshold with a stated rationale rather than a vague 'it depends' is the kind of judgment this role needs. Biggest concern: all claims are self-reported with no external verifiability (no repo link, no employer name, coverage stat unconfirmed), and the scenario answer, while good, reads slightly polished — the rollback logic is sound but doesn't mention communicating with stakeholders or an incident channel, which would have pushed it higher. Verdict: advances to technical interview; strongest candidate at this band for the brief, salary ask of $2,200 sits comfortably mid-range.
Experience
2.5 years as a full-stack developer, first at a Bogotá web agency (React + Node, Postgres), then 18 months at a US-based SaaS startup (TypeScript, Next.js 14, PostgreSQL, AWS). At the startup I shipped features end to end under senior review: a multi-step onboarding wizard, a CSV import and background-job pipeline, and a payment integration with Stripe. I write tests first on anything touching money or user data — the Stripe integration has 94% coverage. I work on US Eastern hours, which means I am in standup, in Slack, and reachable during review cycles without a lag.
Scenario answer
My debugging order for a production 500 after a deploy: 1. Look at the logs immediately. Not git history yet — I want the actual error message and stack trace. A generic 500 with no context is a different problem than a TypeError on a specific line. 2. Reproduce on staging. If it reproduces there, I am not racing time with production risk. If it does not, that is critical information: environment-specific config, a database state difference, a caching layer. 3. Check git log for the deploy. diff the specific files that could have touched the failing path. I am looking for the last change before the 500 started. Most of the time it is obvious when you see it. 4. If the error is in a specific route or function, I add temporary debug logging to staging and trigger the same request, then read the output. I do not guess when I can look. 5. If staging does not reproduce: check environment variables first. The most common cause of 'works on staging, fails in prod' in my experience is a missing or wrong env var — a database URL, a feature flag, an API key. Then check database state: does production have a migration staging does not, or vice versa? Rollback vs fix forward: I roll back if I have not found the root cause within 20 minutes and the error is affecting a significant percentage of users. An unknown bug in production for 30 minutes while I keep digging is worse than a rollback followed by a clean fix. I would rather ship the fix with tests and a clear explanation of what failed than push a patch under pressure. If I found the cause and it is a one-line fix with obvious scope, I fix forward — but only after testing the fix on staging and having the rollback ready.
Work sample
// Top 3 months by revenue from a list of orders // TypeScript, but the logic is identical in JavaScript or Python interface Order { id: string; amount: number; date: string; // ISO-8601, e.g. "2024-03-15" } function top3MonthsByRevenue(orders: Order[]): { month: string; revenue: number }[] { // Reduce to a map of month-key -> total revenue const byMonth = orders.reduce<Record<string, number>>((acc, order) => { const month = order.date.slice(0, 7); // "YYYY-MM" acc[month] = (acc[month] ?? 0) + order.amount; return acc; }, {}); // Sort descending by revenue, take top 3 return Object.entries(byMonth) .sort(([, a], [, b]) => b - a) .slice(0, 3) .map(([month, revenue]) => ({ month, revenue })); } // HOW I'D TEST IT // 1. Happy path: 5 months of data, verify the correct 3 come back in the right order. // 2. Fewer than 3 months of data: returns all months, no error. // 3. Empty array: returns empty array. // 4. All orders in the same month: returns one entry. // 5. Tie for 3rd place: both tied months appear (behaviour to confirm with spec). // 6. Negative amounts (refunds): check they reduce the total correctly. // 7. Date parsing edge: an order with date "2024-01-01T00:00:00Z" — slice(0,7) must still give "2024-01" not an unexpected string. import { describe, it, expect } from 'vitest'; describe('top3MonthsByRevenue', () => { it('returns top 3 months sorted by revenue', () => { const orders = [ { id: '1', amount: 500, date: '2024-01-10' }, { id: '2', amount: 300, date: '2024-01-15' }, { id: '3', amount: 1200, date: '2024-02-01' }, { id: '4', amount: 800, date: '2024-03-05' }, { id: '5', amount: 200, date: '2024-03-20' }, { id: '6', amount: 100, date: '2024-04-01' }, ]; const result = top3MonthsByRevenue(orders); expect(result).toEqual([ { month: '2024-02', revenue: 1200 }, { month: '2024-03', revenue: 1000 }, { month: '2024-01', revenue: 800 }, ]); }); it('handles fewer than 3 months', () => { const orders = [{ id: '1', amount: 100, date: '2024-01-01' }]; expect(top3MonthsByRevenue(orders)).toHaveLength(1); }); it('returns empty array for no orders', () => { expect(top3MonthsByRevenue([])).toEqual([]); }); });
Kenji W.
SCREEN 74/100Screening notes
Work sample is clean and correct — aggregation logic is sound, the console.log doubles as a lightweight integration check, and the enumerated Jest cases cover the meaningful edge cases (empty, fewer than 3 months, same-month summation) without being prompted, which is above-average test thinking for a junior. The scenario answer shows a disciplined debugging order: logs → diff → staging reproduction → targeted investigation → rollback threshold at ~15 minutes of no progress, which is honest and operationally sensible rather than boilerplate. Experience is specific enough to be credible — React/Node.js at a Manila software house, named project types (B2B tool, real-estate scraper, Discord bot), PostgreSQL and Jest in actual use — though no numbers (team size, user counts, LOC, PR volume) prevent a higher score. Biggest concern is the self-admitted absence of E2E tests and the freelance-only last 8 months, which means no recent exposure to code review culture or a structured CI pipeline; salary at $1,900 sits comfortably mid-band and is fair for what is shown. Advance to technical interview; probe E2E testing maturity and whether the freelance projects had any review process.
Experience
2 years as a web developer, starting at a Manila software house doing client projects in React and Node.js, then going freelance 8 months ago. Most of my work is US-based clients — a small B2B tool, a real-estate listing scraper, a Discord bot. I write mostly JavaScript but have done Python for two data-pipeline projects. My weakest area is testing — I have been improving: I now write unit tests for utility functions and API handlers but I do not yet have a systematic E2E test suite. I am self-taught, CS graduate, and I am fast at reading documentation and picking up new libraries.
Scenario answer
When a production endpoint returns 500s after a deploy, my first step is to check the server logs for the actual error. The stack trace usually points to the specific file and line. While that loads I would also check the git log to see exactly what changed in the deploy — sometimes you can spot the problem in the diff before you even see the error. Once I have the error, I try to reproduce it on staging. I use the same request that triggers it in production. If staging reproduces it, I can debug without touching production. For actual debugging: if the error points to a database query I check whether the schema migration ran correctly. If it is an import or require error I check package versions. If it is a runtime error I add logging around the suspect code on staging and trace through the execution. For rollback vs fix forward: if I cannot reproduce the issue within about 15 minutes and real users are hitting errors, I would roll back to the previous working version and investigate calmly. Rolling back is always the safer choice if the fix is not obvious quickly. If I found the bug and it is a small targeted change, I fix forward but only after testing on staging.
Work sample
// Top 3 months by revenue — JavaScript function top3MonthsByRevenue(orders) { // Build a revenue map keyed by 'YYYY-MM' const monthMap = {}; for (const order of orders) { const month = order.date.substring(0, 7); monthMap[month] = (monthMap[month] || 0) + order.amount; } // Sort and take top 3 return Object.entries(monthMap) .sort((a, b) => b[1] - a[1]) .slice(0, 3) .map(([month, revenue]) => ({ month, revenue })); } // Testing approach: // I would write unit tests using Jest with these cases: // - Normal case: spread across 4+ months, verify correct top 3 and order // - Empty input: should return [] // - Only 1 or 2 months of data: should return all months (not crash) // - All orders in one month: should return that month only // - Multiple orders in same month: amounts should be summed correctly // - I would also manually test with real-looking data before shipping // Example test: const orders = [ { id: 'a', amount: 400, date: '2024-01-05' }, { id: 'b', amount: 200, date: '2024-01-20' }, { id: 'c', amount: 900, date: '2024-02-10' }, { id: 'd', amount: 350, date: '2024-03-01' }, ]; console.log(top3MonthsByRevenue(orders)); // Expected: [{month:'2024-02',revenue:900},{month:'2024-01',revenue:600},{month:'2024-03',revenue:350}]
Priya S.
SCREEN 74/100Screening notes
The work sample is clean, correct, and production-ready: the defaultdict aggregation is idiomatic, the slice handles the under-3 edge case naturally, and the commented tests cover basic, empty, and boundary cases with real assertions — not just placeholders. The scenario answer shows a sound debugging sequence (logs → diff → staging repro → rollback gate) and the rollback judgment is honest and well-reasoned rather than performative. Experience specifics are moderate — React frontend, Python/Django backend, PostgreSQL, Git review workflow are all named and real, but there are no numbers (team size, ticket volume, lines of code, PR count) and no project-level detail that would let a client picture the actual scope. The main gap is testing confidence: self-reported weakness on integration tests is honest but leaves a must-have partially unmet, and the tests in the sample are commented out rather than runnable, which slightly undersells execution. At $1,600 against a $1,500–2,800 band, this is a fair-priced junior who covers JS/TS and Python, has Django+PostgreSQL+React, and shows honest judgment — advances to interview with a focus on testing depth and any concrete project metrics.
Experience
1.5 years as a junior developer at a Bangalore startup working on a React frontend and a Python/Django backend. I have worked on building UI components, writing API endpoints, and fixing bugs. I have used Git throughout and submit code for review regularly. My main languages are Python and JavaScript. I am still building my testing skills — I can write unit tests but I am not confident with integration tests yet. I have a computer science degree and I learn quickly.
Scenario answer
If a production endpoint starts returning 500 errors after a deploy, the first thing I would do is check the application logs to see the error message. This usually tells you what went wrong. Next I would look at what was changed in the deploy using git log and git diff to see which files were modified. This often points to where the bug was introduced. Then I would try to reproduce the error in the staging environment with the same request or data. If it reproduces there, I can debug safely. For debugging I would add print statements or logging to the relevant code to trace the execution. I would also check the database to make sure any schema migrations ran without problems. If I cannot find the problem quickly and a lot of users are affected, I think the right call is to roll back to the previous version. It is better to have the old working version running while you investigate carefully than to leave users seeing errors. I would fix forward only if I already understood what the problem was and had a simple, tested fix ready.
Work sample
# Top 3 months by revenue — Python def top3_months_by_revenue(orders): """Returns the top 3 months by total revenue. Args: orders: list of dicts with 'id', 'amount', and 'date' (YYYY-MM-DD string) Returns: list of dicts {'month': 'YYYY-MM', 'revenue': float}, sorted descending """ from collections import defaultdict month_totals = defaultdict(float) for order in orders: month = order['date'][:7] # 'YYYY-MM' month_totals[month] += order['amount'] sorted_months = sorted(month_totals.items(), key=lambda x: x[1], reverse=True) return [{'month': m, 'revenue': r} for m, r in sorted_months[:3]] # How I would test it: # import unittest # class TestTop3Months(unittest.TestCase): # def test_basic(self): # orders = [ # {'id': '1', 'amount': 100, 'date': '2024-01-01'}, # {'id': '2', 'amount': 200, 'date': '2024-01-15'}, # {'id': '3', 'amount': 500, 'date': '2024-02-10'}, # {'id': '4', 'amount': 300, 'date': '2024-03-05'}, # {'id': '5', 'amount': 50, 'date': '2024-04-01'}, # ] # result = top3_months_by_revenue(orders) # self.assertEqual(result[0]['month'], '2024-02') # self.assertEqual(result[0]['revenue'], 500) # self.assertEqual(len(result), 3) # # def test_empty(self): # self.assertEqual(top3_months_by_revenue([]), []) # # def test_fewer_than_3_months(self): # orders = [{'id': '1', 'amount': 100, 'date': '2024-01-01'}] # result = top3_months_by_revenue(orders) # self.assertEqual(len(result), 1)
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.