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

Project Manager

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: Project Manager · Band: $1,150–2,000/mo

Must-haves: runs delivery for a small software or agency team, surfaces slips early and unprompted, status updates that say what changed and what it costs, board hygiene in Jira, Linear, Asana or ClickUp

Nice to have: client-facing agency experience, basic budget tracking, Scrum or Kanban in practice

Scored by the same rubric the production screener runs on real applicants (operations, 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.

Katrina L.

SCREEN 84/100

Philippines · asking $1,600

Screening notes

Strongest evidence: the 11/12 on-time delivery stat with a named corrective action (weekly buffer check added post-2023 miss), salary range fit, and a work sample that is genuinely publication-ready — it names a specific API constraint (90-day limit vs. 2-year requirement), quantifies the cost ($1,440, contingency drawdown to $2,560), offers two costed options with a reasoned recommendation, and sets a hard reply deadline; this is not boilerplate. Scenario answer adds independent value beyond what the question supplied: the insight that hand-off wait time inflates the gap beyond the three stated slips, and the practice of checking Jira status-change timestamps rather than estimates — neither was prompted. Biggest concern: this is a PM-to-Operations-Manager pivot; the candidate shows zero evidence of vendor coordination, SOP authorship, fulfilment oversight, or running AI tooling, which are the core of the actual open role — the fit is strong against the search brief but materially weaker against the role description, and that gap is unaddressed. Verdict: advances to interview for a PM or delivery-lead seat without hesitation; hiring manager should probe whether operations scope (process documentation, vendor management, AI-tool ownership) is genuinely in the candidate's background before treating this as a match for the Operations Manager role as written.

Experience

6 years in delivery, the last 4 as a project manager at a Manila digital agency building web apps and e-commerce sites for US clients — usually three or four projects at once, teams of 4–8, budgets of $40K–180K. I own the plan, the board and the client status call. After we missed a launch in 2023 I added a weekly buffer check to our Jira boards; since then 11 of my last 12 projects landed within a week of the committed date, and the one that didn't was flagged to the client five weeks ahead. I'm not a developer, so I lean on tech leads for estimates.

Scenario answer

Today, in this order. 1. Reconcile the number. Three slips of one to two days is six days at most, so if about eight days of buffer are gone, something else is eating it — usually the waiting between tasks: QA couldn't start, a client review slot was missed, a developer had moved to another project by the time the work arrived. I check in Jira when each ticket actually changed status, not what the estimates say. That gap matters more than the slips, because the rest of the plan assumes hand-offs are instant too. 2. Re-forecast what's left. Thirty minutes with the tech lead, critical path only; I don't estimate code myself. I want two dates: the one we hit if nothing else goes wrong, and the one I would commit to. 3. Make the board tell the truth. I flag the three slipped tickets, add the waiting as its own line, and change the status in the client's report from on track to at risk. Nobody lied here, but a green board with the buffer gone is how a project 'suddenly' slips in its last week. 4. Call the main stakeholder this afternoon. Ten minutes. Nobody should hear 'we've used our buffer' for the first time in front of their own boss. 5. Prepare one decision with its cost. For example: move the admin reporting screens to a second release and keep the date, or keep the scope and move the date a week — about 160 extra hours of team time, four people for a week. On the call I lead with it rather than save it for the end: 'We're at risk. In two weeks we've used about eight days of buffer through three small delays and the waiting between them. On today's forecast we still make [date], with [n] days of buffer left, which won't absorb another two weeks like these. Here's what I'm changing, and here's the one decision I need from you.' What I'm changing: hand-offs get their own tickets with dates, so waiting shows up on the board, and every status report gets one line — buffer used, buffer left. What I would not do is say 'on track' tomorrow and plan to win the days back quietly. A team that slipped three times in two weeks doesn't speed up in week three.

Work sample

Subject: Customer portal — 5 working days behind; new launch date Friday 9 October STATUS: At risk (last update: on track). One decision needed from you by Thursday 17 September. WHERE WE ARE - 31 of 44 tickets done. Sign-up, billing and the account pages are built and have passed QA. - Left: the order-history screens, final QA and launch prep. WHAT CHANGED On Tuesday, while connecting order history, we found that the warehouse system's API only returns the last 90 days of orders. Your customers need two years. The vendor can switch on a date-range option, but their earliest release slot is Tuesday 29 September. We missed this because the option is in the API documentation; it just isn't enabled on your account. We should have tested a live call in week one instead of trusting the documentation, and we now test every outside system with a real call during planning. WHAT IT COSTS - Time: launch moves from Friday 2 October to Friday 9 October, 5 working days. - Money: about 24 extra hours for a second QA pass once the vendor's change lands — $1,440 at the $60/hour contract rate. It comes out of the contingency, which goes from $4,000 to $2,560. - Nothing else moves. Sign-up and billing are unaffected. THE ONE DECISION A. Wait for the vendor. Launch Friday 9 October with two years of order history on day one. Cost as above. B. Keep Friday 2 October with the last 90 days of history, and release the full history once the vendor's change is in, by Tuesday 13 October. The same QA cost, plus about 8 hours ($480) for the extra release. Customers see partial history for about a week, and support should expect a few questions. I recommend B: nothing about older orders is urgent, and 2 October is the date your team has already given customers. Please reply A or B by Thursday 17 September so we can plan next week's sprint. Next update: Friday 18 September, or sooner if the vendor's date moves.

Ramon V.

SCREEN 84/100

Mexico · asking $1,950

Screening notes

The work sample is the standout: it names the exact root cause (sandbox webhooks vs. production credentials), quantifies what's left (17 of 58 stories, broken by workstream), gives a crisp revised date with a stated confidence rationale, and frames the client's decision as a binary with downstream consequences — this is genuinely client-ready writing that most candidates cannot produce. The scenario answer is equally strong: the throughput-over-estimates re-forecast methodology, the '8 buffer days used' framing, the explicit 'at risk' status change before the call, and the candid personal failure anecdote ('I did that once, early on') are specific and earned, not generic; the shared-cause pattern-matching shows real diagnostic instinct. Experience specifics hold up: 5-year delivery manager tenure, two or three squads simultaneously, Scrum/Kanban split by work type, throughput forecasting with a verifiable claim (±4 days on 8 projects), and named tools used with genuine depth (control chart, cumulative flow, Jira Plans). The one material gap is budget ownership — he explicitly flags it was held by account managers, which misses a must-have for the Operations Manager role brief, though it aligns fine with the Project Manager search brief this scoring is actually against; salary at $1,950 sits 8% above the posted ceiling, which is a real friction point but not disqualifying at this quality level.

Experience

9 years in software: 4 as a backend developer, then 5 as delivery manager at a Guadalajara software consultancy building products for US startups. I run two or three squads of 5–7 engineers at a time — Scrum on product work, Kanban on support — and own planning, the Jira boards and the weekly stakeholder update. I moved our forecasting from estimates to the team's actual throughput; on my last 8 projects, the forecast made at the halfway point landed within 4 working days of the real finish. Budgets were owned by our account managers, not by me.

Scenario answer

The board says on track because it counts tickets, not days. So today is about getting a date I believe, and tomorrow is about saying it before anyone asks. Today: 1. Put the three slips side by side: what slipped, by how much, and why. If they share a cause — the same reviewer, the same third-party API, estimates that run short on one kind of work — this is a trend, not bad luck, and the rest of the plan has the same problem in it. 2. Re-forecast from throughput, not estimates. I take what the team has actually finished per week over the last six weeks and run it against what's left. Say 34 tickets remain and the team closes 5 to 7 a week: that's five to seven weeks. If the plan says five, then five is now the best case, not the expected one. 3. Decide whether the date is slipping or gone. With about eight buffer days used, it isn't gone, but it has little or no room for a fourth slip. That's 'at risk', and I change the status today, on the board and in the written update, so the call isn't the first place it appears. 4. This afternoon, with the tech lead and the product owner together, I prepare two options: what we'd move out to protect the date, and the date we'd hit with the full scope. On the call, first item, not last: 'We're at risk on the launch date. We've used about eight buffer days in two weeks through three small slips, and they share a cause: [cause]. At the rate the team is really finishing work, the full scope lands between [date] and two weeks after it. We can protect the date by moving [feature] to the next release, or keep everything and move the date. I need you to pick one by Friday.' Then what I'm changing so it doesn't repeat: fix the shared cause — a second reviewer, a mock for the slow API — and the weekly update gets a line for buffer used against buffer planned. What I would not do is present the old date with a promise to catch up. I did that once, early on. The team worked three weekends and we still missed.

Work sample

PROJECT UPDATE — Inventory sync, Thursday 15 October Status: AT RISK. Launch moves from Friday 23 October to Friday 30 October — 5 working days. WHERE WE ARE Product import, the admin screens and the stock rules are built and tested: 41 of 58 stories closed. The remaining 17 are order routing (9), reconciliation reports (5) and launch tasks (3). WHAT CAUSED THE SLIP On Tuesday we connected to your production ERP for the first time and found that stock updates arrive as one file overnight, not in real time. Our design assumed real time because the ERP's API documentation describes change webhooks. On your account they are a paid add-on that isn't switched on; we had built against the ERP's sandbox, where they were on. I should have had us confirm this on the production account in week one. We now check every integration against production credentials during planning. To launch, we need a scheduled job that reads the nightly file, reconciles it against live stock and alerts when the two disagree. Two engineers, 5 working days. It sits on the critical path, because order routing can't be tested until stock is reliable. REVISED DATE Friday 30 October. I'm confident in it: the new work is small and well understood, and order routing, the riskiest part left, has 2 days of slack after it. THE ONE DECISION WE NEED FROM YOU Do you want to switch on the ERP's webhook add-on? It doesn't change the 30 October date — the nightly job is needed for launch either way. It changes how fresh stock is afterwards. - Yes: we move to real-time updates about two weeks after launch and keep the nightly job as a backup. The add-on's price is set by your ERP vendor, so your account contact there would need to quote it. - No: stock on the site can be up to 24 hours old, permanently. To avoid overselling, we'd stop selling an item when stock falls to 3 units instead of 0. Please reply by Monday 19 October so we can plan the sprint that starts that day. Next update: Thursday 22 October.

Martín G.

SCREEN 72/100

Argentina · asking $1,350

Screening notes

Strongest evidence is the work sample: it names a specific external blocker (payment provider approval), gives concrete old/new dates (13 Nov → 20 Nov), flags a decision needed, and outlines a mitigation — this is genuinely client-ready writing, not boilerplate. The scenario answer shows sound instincts (board hygiene, parallel-tasking, honest stakeholder framing) but stays conceptual throughout — no numbers cited, no example of a real slip he caught early in a past project, no mention of how much buffer was used or what the recovery plan cost. Experience section lists credible tools (Jira, Confluence, Scrum ceremonies) and a real context (cross-border clients, 2-3 concurrent projects) but is heavy on adjectives ('very organised, good communicator, positive attitude') and thin on specifics — no team sizes, no sprint cadences, no budget figures, no example of a prevented escalation. At $1,350 he sits comfortably in band and his ART overlap with US Eastern is genuine; advances to a structured interview with probing questions on early-warning signals and quantified delivery outcomes, but is not a lock.

Experience

5 years in IT project management at a Buenos Aires software company that builds custom software for clients in Argentina, Spain and the US. I manage 2 or 3 projects at the same time, coordinating developers, designers and QA, and I am the main contact with the client. I work with Scrum: I run the dailies, sprint planning and retrospectives, and I keep the Jira board updated. I am very organised, a good communicator and I always keep a positive attitude with the team.

Scenario answer

This is a common situation in software projects, where small delays add up and are not visible on the board. Today I would meet with the team to understand the reason for each delay and see if there is a common problem behind them. I would also update the board so it shows the real status of the tasks, and review the remaining work with the developers to see if we can recover part of the time, for example by doing some tasks in parallel or reprioritising the backlog. I would also prepare a short presentation for the call with the progress of the project, the completed tasks and the delays. On the call with the stakeholders I would be transparent. I would explain that we had some small delays in the last two weeks, the reasons for them, and that we have used part of the buffer. I would explain the actions we are taking to recover the time, and that for now we are still aiming for the original date, but the risk is higher and I will inform them immediately if anything changes. I think it is very important to have a relationship with the stakeholders based on trust and honest communication, so they are never surprised by bad news.

Work sample

Subject: Project status update — Mobile app Hello everyone, Here is the status update for this week. Current status: The project is 5 days behind the original schedule. The team has completed the login, user profile and notifications features, and we are now working on the payments module. Cause of the delay: This week we discovered that the integration with the payment provider needs an additional approval from their side before we can use the production environment. This was not included in the original plan, and the approval process is taking longer than expected. Revised date: Based on the current situation, the new estimated delivery date is 20 November instead of 13 November. Decision needed: We need your approval of the new delivery date so we can update the plan and inform the team. Next steps: We will continue working on the parts of the payments module that do not depend on the approval, and we will follow up with the payment provider every day. Please let me know if you have any questions. Best regards

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: Project Manager | Rolemote