Sample shortlist · candidates written by us, real screener output
Data Entry Specialist
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: Data Entry Specialist · Band: $650–1,000/mo
Must-haves: high accuracy sustained under volume, a repeatable method rather than ad-hoc care, flags anomalous records instead of copying them, comfortable in spreadsheets
Nice to have: CRM migrations, basic formulas or scripting, document processing
Scored by the same rubric the production screener runs on real applicants (data-entry, claude-sonnet-4-6), on 2026-09-20. Nothing below was edited afterwards — including where it went against a candidate. The rubric and weights are published.
Marilou B.
SCREEN 88/100Screening notes
The strongest concrete evidence is the 41,000-record HubSpot migration with a client-selected 400-record audit sample yielding 0.3% error rate — that is a verifiable, specific claim with the anti-gaming detail that the client chose the sample, not the candidate. The scenario answer demonstrates exactly the differentiating judgment this role requires: correctly separates a formatting problem (phones, fixable by transform) from a data integrity problem (dates, not the candidate's call), refuses to invent values, and adds the unprompted correlation check between bad phones and bad dates as a diagnostic signal rather than a row-level problem — that last move is the kind of systemic thinking a script does not have. The work sample is operationally rigorous: the row-count reconciliation gate, the ISO date locale-ambiguity trap, the distinction between safe exact-duplicate merges and unsafe fuzzy merges, and the principle 'flag anything where being wrong is invisible' are all non-generic and reflect real migration scar tissue. The one concern is that everything is written at a level of polish and structural coherence that slightly exceeds what most candidates produce unassisted, which warrants a live scenario question in interview to confirm the reasoning is genuinely internalized; salary at $900 sits at the top of band but is defensible given the migration scope. Verdict: advance to interview, open with a live ambiguous-data scenario.
Experience
5 years of data work for US clients, starting in straight entry and moving into migrations. Last two years I ran CRM migrations at a Manila outsourcing firm — the largest was 41,000 contact records out of a legacy Access database into HubSpot, done over six weeks with a 0.3% error rate measured on a 400-record audit sample the client pulled themselves, not one I chose. Before that, three years of invoice and purchase-order entry at 300–400 documents a day.
Scenario answer
I would stop and send a message before touching another record, and I would not finish today. Here is why and what I would actually do. The 200 phone numbers and the impossible dates are two different problems and conflating them is the mistake. The phone formats are a formatting problem. That I can solve without asking: they are almost certainly a mix of local and international notation, or numbers that lost a leading zero because a spreadsheet read them as numbers. I would write one transform that normalises everything to a single format, run it, and spot-check thirty of the two hundred by eye. I would not hand-edit two hundred cells — hand-editing is where new errors come from, and it cannot be re-run if the client sends a corrected export. The impossible dates of birth are a data problem and they are not mine to decide. A date of birth of 1900-01-01 or 2087-03-14 usually means one of three things: a required field somebody typed junk into, a system default, or a genuine transposition. Which one it is changes what should happen, and only the client knows. Guessing at a person's date of birth in a customer database is the kind of quiet error nobody finds for two years. So: I pull those records into a separate tab, with the row number, the original value and what I think the cause is. Then one message to the client, today, early enough that they can answer today: here is what I found, here is what I have already fixed, here are the N records I need a decision on, and here is the one I would recommend. Short, and with the sheet attached. Then I would say plainly that I will not finish today. I would finish the 3,800 clean records, hold the flagged ones, and give a realistic time for the rest once I have the answer. A migration delivered on time with 200 invented dates of birth in it is worse than one delivered a day late, and it is worse in a way that only shows up after everyone has stopped paying attention. One more thing I would do unasked: check whether the 200 bad phone numbers and the handful of bad dates are the same records. If they are, that is a batch — an import from one source, or one period — and the client will want to know that far more than they want the individual rows.
Work sample
CLEANING A MESSY CONTACT LIST — the exact steps Assumption: a CSV export, a few thousand rows, going into a CRM. Deliverable is a clean import file plus a flagged-exceptions sheet. BEFORE ANYTHING 0. Copy the raw file and never touch the original again. Every step below runs on the copy. If step 6 goes wrong I want to restart from truth, not from my last save. 1. Row-count the raw file and write the number down. The final import count plus the flagged count must equal it. This is the check that catches silently dropped rows, which is the failure nobody notices. STANDARDISE, IN THIS ORDER 2. Trim whitespace on every text column first. Half of what looks like a duplicate is "Maria " versus "Maria". 3. Names: split into first and last only if the source is consistently "First Last". If it contains titles, suffixes or two-word surnames, do not auto-split — flag the ambiguous ones instead. Auto-splitting names is how "Van Der Berg" becomes a first name. 4. Dates: convert everything to ISO (YYYY-MM-DD). The trap here is the ambiguous ones — 03/04/2024 is two different dates depending on the source's locale. I check the source's locale once, apply it, then verify by finding any date where the day component exceeds 12 and confirming those parse the way I expect. If a file contains both formats mixed, the file cannot be converted safely and that goes to the client. 5. Phones: normalise to E.164. Restore leading zeros lost to numeric formatting, add country codes where the source's country is known. 6. Emails: lowercase, trim, and validate the shape. An invalid email is flagged, not deleted — the client may have the correct one elsewhere. DUPLICATES 7. Exact duplicates on email first — those are safe to merge. 8. Then fuzzy duplicates: same last name plus same phone, or same email domain plus same first name. These are NOT auto-merged. They go to the exceptions sheet with both rows side by side, because merging two real people who share a surname and a company phone number is unrecoverable once the source is gone. FLAG, DO NOT FIX 9. Anything in this list goes to the exceptions sheet rather than getting a value I made up: - impossible dates (future births, pre-1900, obvious defaults like 1900-01-01) - values in the wrong column (an email in the phone field — usually one shifted row, and if so the rows around it are shifted too, which is worth saying) - records missing a field the CRM requires - fuzzy duplicate pairs Each row gets: row number, field, original value, why it was flagged, and my suggestion. FINISH 10. Reconcile the count from step 1. Clean + flagged = raw. If it does not balance, find the difference before delivering. 11. Spot-check 30 random rows against the raw file by eye. Not the first 30 — random, because errors cluster. 12. Deliver both files together and lead the message with the exceptions, not with the clean count. WHAT I WOULD FLAG RATHER THAN FIX, IN ONE LINE Anything where being wrong is invisible. A mangled phone number gets discovered the first time someone calls it. An invented date of birth never does.
Andrés P.
SCREEN 87/100Screening notes
The weight-unit mismatch discovery — unsolicited, seven months running, with a measurable downstream effect on freight cost analysis — is exactly the kind of anomaly-flagging-over-faithful-copying evidence this role demands, and it comes with enough specifics (250 records/day, monthly reconciliation, TMS context) to be credible rather than generic. The scenario answer and work sample both demonstrate a genuine mental model: the distinction between mechanical fixes (phone normalization with formula + sample check) and judgment calls (impossible DOBs require a decision-owner, not a guess), the 'cluster check' instinct that turns 200 individual problems into one root-cause problem, and the Row-count reconciliation discipline that catches silent row loss. The DD/MM vs MM/DD ambiguity handling in the work sample is a real practitioner's detail that most applicants miss entirely. The main concern is modest: SQL is claimed as 'basics' with no concrete example of how it was used in the reconciliation workflow, and Apps Script is mentioned but not evidenced — neither is a disqualifier but both would be worth probing in interview. At $980 against a $600–1,000 band, the candidate is at the top of range but the specificity and unsolicited-discovery story justify the ask; would present to client without hesitation.
Experience
4 years of data operations, two of them supporting a US logistics company from Bogotá on US Central hours. Daily work was entering and validating shipment records — around 250 a day — plus a monthly reconciliation between the client's spreadsheet and their TMS. I found and reported a recurring mismatch where a weight field was being entered in kilograms by one warehouse and pounds by another; it had been running for about seven months and was skewing their freight cost analysis. Nobody asked me to look, it just did not add up.
Scenario answer
I would not finish today, and I would say so before the end of the morning rather than at 5pm. The two issues are not equivalent. The phone formats are mechanical — I can normalise them with a formula and verify a sample. That does not need anyone's permission and it does not need to stop the work. The impossible dates of birth do need permission, because fixing them requires deciding what the correct value is, and I do not have that information. A date that reads 01/01/1900 is almost always a system default rather than a real entry, but "almost always" is not a basis for writing something into a person's record. So my actual sequence: 1. Continue the migration for the clean records so momentum is not lost. 2. Build a normalisation for the phone numbers and run it, then check a sample of around 30 by eye against the source. 3. Pull every anomalous record into a separate sheet with the row reference, the original value, and my reading of what caused it. 4. Message the client before lunch — not at the end of the day — with the exceptions sheet, what I have already handled, what I need a decision on, and my recommendation for each. Sending it early is the difference between an answer today and an answer tomorrow. 5. Say clearly that the deadline will slip on the flagged subset, and give a new one. The reason I would not just fill in the dates and move on is that this kind of error is invisible after delivery. A wrong phone number gets found the first time someone dials it. A wrong date of birth sits in the database looking exactly like a right one, and three years later somebody runs an age-based report on it. I would also check whether the bad records cluster — same import batch, same date range, same source system. If they do, the client has one problem rather than two hundred, and that is the more useful thing to tell them.
Work sample
CLEANING A MESSY LIST — my procedure SETUP 1. Work on a copy. The original file stays untouched so I can always go back and compare. 2. Record the starting row count. At the end, clean rows plus flagged rows must add back up to it. STEP BY STEP 3. Trim leading and trailing spaces across all text fields. This has to happen before duplicate detection or half the duplicates will not match. 4. Standardise capitalisation on names and cities (proper case), but leave anything that looks like an acronym or a company name alone. 5. Dates: pick one target format, YYYY-MM-DD, and convert. Where the source mixes DD/MM and MM/DD I look for rows where the first component is above 12 to work out which convention the file follows. If both conventions appear in the same file I stop and ask, because a wrong guess silently corrupts about half the dates. 6. Phone numbers: strip formatting characters, restore any leading zeros the spreadsheet removed, and apply the country code. Verify the resulting lengths are consistent. 7. Emails: lowercase and check for a valid structure. Invalid ones get flagged. DUPLICATES 8. Sort by email and remove exact duplicates where every field matches. 9. Where two rows share an email but differ in other fields, do not merge automatically — they go to the exceptions list, because deciding which version is current is the client's call. WHAT I FLAG RATHER THAN FIX 10. Impossible values — dates in the future, ages over 120, placeholder entries like 000-000-0000 or test@test.com. 11. Data in the wrong field, which usually means a row shifted during export and the neighbouring rows need checking too. 12. Records missing a required field. DELIVERY 13. Reconcile against the starting count. 14. Spot-check a random sample of rows against the original. 15. Send both the clean file and the exceptions list, and lead with the exceptions so they are not missed.
Grace T.
SCREEN 62/100Screening notes
Strongest concrete evidence: real volume figure (150 POs/day), named tools (Adobe Acrobat, internal order system), and a work sample that shows genuine Excel literacy (TRIM, PROPER, Conditional Formatting, Find & Replace) rather than just naming the application. Biggest concern: the scenario answer reveals the critical weakness for this role — she would silently 'correct' impossible birth dates using her own judgment and only notify the client in a post-hoc summary, rather than stopping, flagging before altering, and asking for a decision rule; this is exactly the anomaly-handling failure the brief is testing for. The work sample step 8 ('correct them or leave them blank') mirrors the same gap: no escalation trigger, no client checkpoint, no quarantine column. English is clear and professional but the framing is mostly adjective-based ('very careful,' 'accuracy very seriously') without procedural evidence of a repeatable system. Verdict: competent mid-tier BPO candidate with real volume experience and solid spreadsheet basics, but does not yet demonstrate the judgment-over-faithfulness differentiator; borderline for interview, only if paired with a targeted scenario probe on anomaly escalation protocol.
Experience
3 years of data entry work. I started as an encoder at a Cebu BPO doing medical records, then moved to a US client where I entered orders into their system from PDF purchase orders, around 150 a day. I have a typing speed of 72 words per minute with 99% accuracy and I am known for being very careful and detail-oriented. I always double-check my work before submitting it.
Scenario answer
I would first finish normalising the phone numbers so they are all in the same format, because consistency in the data is very important and the client will want them to look uniform. For the records with the impossible dates of birth, I would correct them as best I can. If the date is clearly a typing error I would fix it, and if it is not clear I would leave the field blank rather than putting in something wrong. I would then continue with the rest of the migration so that I can meet the deadline, as I was asked to finish today. I would work through the remaining records carefully and double-check my entries as I go. At the end I would send the client a summary noting how many records had formatting issues and how many had date problems, so they are aware of what I found during the migration. I take accuracy very seriously and I would make sure the final file is as clean and correct as possible before handing it over.
Work sample
STEPS FOR CLEANING A MESSY LIST 1. Open the file in Excel and save a copy as a backup. 2. Use the TRIM function to remove extra spaces from all the text columns. 3. Use PROPER to fix the capitalisation of the names so they are consistent. 4. Sort the data by the email column so that duplicates appear next to each other. 5. Use Conditional Formatting to highlight duplicate values, then review them and delete the ones that are exact duplicates. 6. For the dates, select the date column and use Format Cells to change them all to the same date format. 7. For the phone numbers, use Find and Replace to remove any dashes, brackets and spaces so they are all just digits. 8. Look through the data for any values that are obviously wrong, such as a date of birth in the future, and correct them or leave them blank. 9. Check the whole file one more time from top to bottom to make sure nothing was missed. 10. Save the cleaned file with a new name and send it to the client. WHAT I WOULD FLAG TO THE CLIENT I would tell the client about any records where information was missing or looked incorrect, and about how many duplicates I removed, so they know what was changed.
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.