Where is the best place to find remote developers?

Referrals from your current team and former contractors produce the best hires at the lowest cost. After that, look at developer communities around the technology you use, niche job boards, and staffing providers. General freelance marketplaces have the widest pool and the most filtering work.

How long should a paid trial for a developer be?

One to two weeks of part-time work, usually 15 to 25 hours, is enough to see how someone communicates, handles ambiguity, and writes code. Pay their normal rate. Use a task that resembles your real work, has a clear acceptance standard, and involves at least one conversation with your team.

Should I hire remote developers as contractors or employees?

It depends on the facts of the relationship and the law where the person lives. Someone who works full time for you, under your direction, on your schedule, with no other clients looks like an employee in most jurisdictions regardless of what the contract says. Misclassification can bring back taxes and penalties, so take advice before you decide.

What is an employer of record?

A company that legally employs a worker in their own country on your behalf. It runs payroll, withholds taxes, and provides the required benefits, and you pay the salary plus a monthly fee. You direct the work. It lets you employ someone abroad without setting up a legal entity there.

How to hire remote developers for an agency

Most advice on hiring remote developers is written for product companies. An agency has a different problem. Your new developer will be working on a client’s system within days, the client is paying for every hour, and a weak hire is visible to the people who pay your invoices. That changes how you source, how you vet, and how you onboard.

Before any of this, check that hiring is the right move. A hire makes sense when you can see about twelve months of revenue for the role. For a shorter or less certain need, staff augmentation is usually cheaper, and the Team hub lays out the options side by side.

Where to find them

In order of how well each source has worked for me:

Referrals from your own team. Good developers know other good developers, and they will not recommend someone who would embarrass them. Pay a referral bonus on completion of the first ninety days. A bonus of $2,000 to $3,000 is small next to a recruiter’s fee.

People who have already worked with you. Former contractors, freelancers from past projects, developers from a client’s team who have since moved on. You already know how they work. Keep a list and stay in touch.

Communities around your technology. Contributors to the open-source projects you depend on, people who answer questions well in a framework’s forum, speakers at small meetups. Their work is public and you can read it before you ever speak. Approach them directly and specifically.

Niche job boards. A board dedicated to remote work or to one language attracts a narrower, more relevant pool than a general one. Write the listing as an honest description of agency life: several clients, changing context, real deadlines. The people that description puts off are people who would have left in six months.

Staffing and augmentation providers. Faster and more expensive. Many arrangements allow you to convert a placed developer to your own employee for a fee, which works as an extended trial. If the provider is abroad, the tradeoffs in nearshore vs offshore apply.

General freelance marketplaces. The pool is enormous and the quality is uneven. They work if you are willing to run several small paid trials in parallel and keep one person in five.

Whatever the source, state the salary or rate range in the first message. It saves both sides a week.

How to vet: the paid trial

Interviews measure how well someone interviews. Take-home tests measure how much free time a candidate has, and the best candidates decline them. A paid trial measures the thing you are buying.

The structure I use:

A 30-minute call. Background, what they want, rate, availability, time zone. I am mostly checking that they explain technical things clearly.
A code conversation. They walk me through something they built. I ask why they made two or three specific decisions. This takes 45 minutes and screens out more people than any puzzle.
A paid trial of 15 to 25 hours over one to two weeks. At their quoted rate, under a short contractor agreement with confidentiality and IP assignment.
A decision within two business days of the trial ending.

Designing the trial task

A good trial task has five properties.

It resembles your real work. A bug fix and a small feature in a codebase like the ones you maintain. An internal tool or a sanitized copy of a past project works well. Avoid live client code until the person has signed your full agreements and the client contract allows it.
It is slightly underspecified. Leave one real ambiguity in the brief. You want to see whether they ask or assume.
It has a clear acceptance standard. Tests pass, the feature does what the brief says, the pull request is reviewable.
It requires contact with your team. At least one question to a lead and one code review with feedback. How someone responds to review comments tells you most of what you need to know.
It ends with a short written handover. Agency work changes hands constantly. A developer who cannot write a clear handover note will cost you later.

What it costs, and what it saves

Line	Calculation	Amount
Trial hours		20
Candidate’s rate		$70
Trial fee	20 x $70	$1,400
Your lead’s time (brief, questions, review)	4 hours x $100	$400
Cost per trial		$1,800
Three finalists	3 x $1,800	$5,400

Compare that with a hire who does not work out. Suppose the person has a loaded cost of $10,000 a month and you take six weeks to accept the problem. That is $15,000 in pay, plus the lead’s time, plus whatever the client noticed. A recruiter’s fee at 20 percent of a $110,000 salary is $22,000 for a candidate you still have not seen work. Against either figure, $5,400 for three trials is cheap.

Pay for the trial even when the answer is no. People talk, and an agency that pays promptly for trial work gets better candidates the next time.

Contractor, employee, or employer of record

There are three common ways to engage a remote developer. The right one depends on where the person lives, how they will work, and how long you expect the relationship to last.

	Independent contractor	Direct employee	Employer of record
Who is the legal employer	Nobody. They run their own business	You	A third-party company in the worker’s country
Who handles tax and benefits	The contractor	You	The employer of record
Works where	Anywhere, subject to local law	Where you have a legal entity or registration	Countries the provider covers
Cost on top of pay	Low	Payroll taxes and benefits, often 20 to 30 percent	Local employer costs plus a monthly fee per person
Setup time	Days	Days at home, months in a new country	One to three weeks
Main risk	Misclassification	Fixed cost and local employment obligations	Fee, and less direct control over employment terms
Fits	Short, defined, part-time, or multi-client work	Long-term core team in a place you already operate	Long-term, full-time people in a country where you have no entity

The contractor question

Whether someone is a contractor follows from the facts of the relationship, whatever label the contract uses. Regulators and courts look at who controls how and when the work is done, whether the person has other clients, who supplies the tools, whether the person carries any financial risk, and how permanent the relationship is. In the US, the tests differ between federal agencies and between states, and some states apply a much stricter standard than others.

A developer who works forty hours a week for you alone, attends your standups, uses your equipment, and has done so for two years looks like an employee almost everywhere. If an authority reaches that conclusion, the consequences can include back taxes, penalties, and benefits owed. This applies abroad as well: many countries protect workers who are contractors on paper and employees in practice. The UK and several EU countries have their own tests and their own penalties, and some shift liability onto the business receiving the work.

Use contractors for work that is truly independent: a defined project, part-time hours, a person with other clients. For a full-time, long-term role, employ the person, directly or through an employer of record. Ask an employment lawyer or accountant before you settle the structure, because the cost of asking is small and the rules change.

Employer of record

An employer of record is a company with a legal entity in the worker’s country. It hires the person on your behalf under a locally compliant contract, runs payroll, withholds tax, and provides the benefits the law requires. You direct the work day to day and pay the salary, the local employer costs, and a fee, usually a flat monthly amount per employee.

The arrangement costs more than a contractor and less than opening your own entity abroad. It also puts a third party between you and your employee on matters like contract terms, notice, and termination, which follow local law. Read what the local notice and severance rules are before you hire, since they are often more generous to the employee than US norms.

Whichever structure you use, get a written IP assignment that is valid under the law of the person’s country. Your clients expect to own what they pay for, and that ownership has to pass through you. The reasoning is laid out in who owns the code.

Onboarding into client work

A product company can give a new developer a month to settle in. Your new hire will be measured in billable hours almost immediately. Plan the first two weeks in writing before the person starts.

Before day one. Signed agreement, confidentiality, and IP assignment. Accounts created. Equipment or a security baseline for their own machine. Check the client’s contract for any requirement to approve new team members, background checks, or limits on where work can be done from.

Days one and two. Your working practices: how you track time, how you write tickets, how you review code, when people are expected to be reachable. A one-page brief on the client: what they do, what the project is for, who the contacts are, what has gone wrong before.

Days three to five. Shadow the project lead. Read the codebase with a guide. Ship one small, low-risk change through the full process, from ticket to review to deployment. The goal of the first week is one merged pull request and a working environment.

Week two. Normal tickets with close review. A proper introduction to the client, by name and role, on a call. Clients accept new people readily when they are introduced and resent discovering them in a commit log.

First thirty days. A weekly check-in with the lead, and a frank review at the end of the month. If the fit is wrong, this is the time to say so.

Two rules save a lot of trouble. First, decide how the first week is billed and tell the client. I usually bill ramp-up time at a reduced rate or absorb it, and say so in advance, because a client who pays full rate for a newcomer reading documentation will bring it up at renewal. Second, write down your communication norms: expected response times, core overlap hours, and where decisions get recorded. Remote teams run on writing, and a new person cannot absorb unwritten habits from across a room.

After the hire

A remote developer who goes quiet is the usual early sign of trouble. Keep a short daily written update for the first month and a weekly conversation that is about the person as well as the tickets.

Then watch the numbers. A new hire adds about 150 hours of capacity a month, and capacity nobody has sold becomes bench. The article on bench management shows how to forecast that before you make the offer, which is the right order to do it in.