Developer Offshore: Questions to ask before hiring

Key takeaways

• Ask how code is reviewed before you ask about hourly rate.
• Keep production access limited until the first 14-day pilot is clean.
• Use one scorecard for code quality, response time, security habits, and manager ownership.
• A good provider can explain replacement, escalation, and tool access rules in plain English.

Start with the work, not the resume

A senior resume can still fail if the work is vague. Before a sales call, write down the first 5 to 10 tickets you want handled. Include one bug, one small feature, one test fix, and one pull request cleanup. That gives the provider something real to staff against.

Ask who turns that list into a role. If the answer is only "send us the job description," the risk stays with you. A useful provider should help narrow the role, set review points, and flag work that should stay with your in-house tech lead.

• Which tickets should this person own in week one?
• Which tickets are off limits until trust is earned?
• Who signs off on architecture, security, and production changes?

Ask how code review works

Do not accept "our developers are vetted" as the whole answer. Ask what happens after the developer writes code. GitHub's protected branch docs are a useful baseline because they show common controls like required reviews and required status checks before a merge.

For a small pilot, ask for two review layers: your tech lead owns final approval, and the offshore manager checks ticket notes, test evidence, and handoff quality before the pull request reaches your queue.

• Will every change go through a pull request?
• What tests or screenshots must be attached before review?
• Who checks for copied code, missed edge cases, and unclear comments?

Treat access like a hiring test

Access control is where many offshore plans get sloppy. NIST's least privilege control says users should only get the access needed for assigned duties. For a developer pilot, that usually means repo access by project, ticket access by board, and no direct production secrets at the start.

Personal access tokens need the same care. GitHub's token guidance pushes short-lived and fine-scoped access where possible. Ask the provider how tokens are created, stored, rotated, and removed when a developer rolls off.

• Can we start with staging only?
• Who removes access on the same day if the pilot ends?
• Where are passwords, tokens, and recovery codes stored?

Make the first 14 days measurable

Two weeks is long enough to see patterns without locking yourself into a bad fit. Give the developer a narrow queue, then review cycle time, rework, communication, and security habits twice a week.

The scorecard should be boring. That is the point. A simple 1 to 5 rating for pull request quality, test evidence, update clarity, and manager follow-up will tell you more than a polished sales deck.

• Day 1: access, repo tour, sample ticket, and review rules.
• Day 3: first pull request and manager check-in.
• Day 7: scorecard review and scope adjustment.
• Day 14: keep, replace, or redesign the role.

Provider question scorecard

FAQ