How to Vet a Remote Developer Before They Join Your Team

Vet a remote developer the way you would vet an employee. Interview them yourself, check which parts of their past projects they built, and watch them work on your own code. Settle access and ownership before day one. Here is the checklist we suggest to clients, and how each step works when the developer comes from us.

1. 01What we check before you meet anyone

   Every engineer passes four checks before they reach a client’s shortlist.

   1. A technical interview with one of our senior engineers, on the stack they will work in.

   2. A coding test, either live or as a take-home task.

   3. A review of code and projects they built before, so we know which parts were theirs.

   4. A communication check in spoken and written English, including how clearly they explain their own work.

   Your interview comes after all four, so your time goes on fit, not on basics.

2. 02Interview the person, not the agency

   Ask to interview the developer who will actually do the work. Talk through something they built: what they chose, what went wrong and what they would change. Someone who did the work can answer follow-up questions without notes.

   With us, you get a shortlist within 2 days, and you interview the engineers yourself before anyone starts.

3. 03Check which part they built

   A team page can list a dozen apps, but one developer usually owned one piece of each. Ask which part was theirs: the API, the mobile app, the payments or the deployment.

   On our hire pages, the stack listed beside each project shows the part we built. Where a product is public, such as Orchyd or Houzi, open it and try it. Our case studies also record the team size and hours behind each build.

4. 04Watch them work in your setup

   A coding test shows how someone solves a puzzle. A small, real ticket in your own repository shows how they read unfamiliar code, ask questions and open a pull request. Give them one in the first week.

   Our engineers work inside your repo, sprint and tools from the start. Full Blown Media, whose review is on Clutch, ran its project with us through Slack and Trello.

5. 05Agree the working hours

   Write down which hours overlap with your team, and who answers if something breaks outside them. A few shared hours a day cover standups, reviews and quick questions.

   Our engineers work full time on your project and overlap with US hours when your schedule needs it.

6. 06Settle access and ownership before day one

   Give the developer their own accounts in your GitHub, cloud and project tools, not shared logins. Removing access later then takes minutes, not a password reset across every system.

   Put ownership in the contract. With us, you own everything our engineers write for you, including the source code and the intellectual property in it.

7. 07Decide how long you need them

   Be clear whether you need someone for a few months or for years, because it changes who fits. We place engineers for short engagements under six months, for six to twelve months, and in long-term roles. There is no long-term contract to start. If someone turns out not to be the right fit, we replace them and handle the handover.