The uncomfortable position most clients are in is this: they are hiring someone precisely because they cannot do the work themselves, which means they also cannot evaluate it. The usual response is to fall back on proxies — years of experience, a polished profile, a confident interview — and those proxies are weak. Confident and competent look identical for about the first three weeks.
There are, however, several checks that do not require expertise. They work because they test process and honesty rather than skill, and process and honesty are visible to anyone.
Check that the work exists and is theirs
Ask for links to live work, not screenshots. Then open them. This sounds too obvious to state and it eliminates a surprising share of applicants, because portfolio images are trivial to borrow and live URLs are not.
For anything on the public web, verify independently. A designer who claims a site can be checked against the site's own credits or the Wayback Machine; a developer who claims an app can be checked in the store listing. You are not looking to catch someone out — you are confirming the basic premise before you spend money on the rest of the evaluation.
- Live URLs, App Store or Play Store links, published articles with their byline
- A public code repository, if the work is the kind that produces one
- Which parts of a team project were specifically theirs
- A reference from a client with a real, checkable identity
Ask what went wrong
This is the single most informative question available to a non-expert: "Tell me about a project that went badly and what you did about it."
Everyone with real experience has one. The answers separate cleanly. Weak candidates either have no such project — which means either no experience or no reflection — or blame the client entirely. Strong candidates describe a specific situation, name their own contribution to it, and explain what they changed afterwards. You do not need domain knowledge to tell those apart.
The follow-up matters as much: "What would you do differently now?" A person who has genuinely thought about their failures answers immediately and concretely.
Test how they handle not knowing
Ask something slightly outside their stated area, or ask them to estimate something they do not have enough information about. What you are watching for is whether they say so.
A freelancer who answers every question with certainty is either extraordinary or is going to make expensive guesses on your project without telling you. "I would need to look at the database before I could answer that" is one of the most reassuring sentences in a hiring interview. Bluffing in an interview is a preview of bluffing in a status update.
Buy a small piece first
The most reliable vetting method is a paid trial: a small, self-contained, genuinely useful piece of work, paid at their normal rate. Not a free test — free tests select for people with nothing better to do, and good freelancers decline them, so you filter out exactly the candidates you wanted.
What the trial reveals has almost nothing to do with the deliverable:
- Did they ask questions before starting, or assume?
- Did they communicate when something took longer than expected, or go silent?
- Did they deliver in the format agreed, or in whatever was convenient?
- Did they flag a problem they noticed that was outside the task?
- Was the estimate roughly right, and did they say so when it was not?
Worth noting: A trial that costs a few hundred dollars regularly prevents a five-figure mistake. It is the cheapest insurance in freelance hiring and the most commonly skipped.
Read the proposal for evidence of reading
Templated proposals are easy to spot once you look for it: they describe the freelancer's process rather than your project, and they could be sent to anyone. A proposal that references a specific detail of your brief, or asks a question that proves the brief was read closely, is a meaningful signal — it is the first sample of how they will treat your requirements.
Be more suspicious of proposals that agree with everything. A freelancer who reads a brief carefully usually finds at least one thing to question. Total agreement often means total skim.
Interpret reviews properly
Ratings on marketplaces cluster near the top and carry little information. The text does not. Read the middling reviews specifically, and read what the positive ones actually praise — "responsive and easy to work with" and "solved a problem we had failed to solve for months" describe different freelancers.
A profile with a small number of detailed reviews is generally more informative than one with a hundred identical five-star lines. Volume is easy to accumulate on trivial work.
What not to weight heavily
- Years of experience: ten years of repeating one year is common in freelancing
- Certifications, outside regulated fields where they are legally required
- Response speed alone, which mostly measures availability
- Rate as a proxy for quality in either direction — expensive and bad exists, cheap and excellent exists
- A beautiful profile, which is evidence of profile-writing skill and nothing else
Decide before you are attached
Write down what would make you end the engagement before you start it: missed deadline without warning, a week of silence, a deliverable that ignores the brief. It is far easier to define that standard when you have no money invested and no relationship to protect.
The expensive version of this mistake is not hiring the wrong person. It is noticing in week two and continuing until week nine because ending it felt awkward.