How to Hire a Software Developer

Why this role matters

Software developers turn product decisions into working code. Each hire shapes the codebase other people will maintain for years, so judgement about readability, testing and trade-offs matters as much as raw speed. A good developer reduces the load on the rest of the team; a poor fit adds review work, bugs and rework.

Where to find candidates

• LinkedIn, searching by stack, past employers and the kinds of products candidates have shipped
• Hacker News monthly "Who is hiring?" threads for startup and remote roles
• Wellfound and We Work Remotely for startup and remote developers
• GitHub, looking at contributors to open-source projects in your stack
• Local meetups, language conferences and user groups for your languages and frameworks
• Referrals from your current engineers, who know who they would like to work with again

Skills to look for

Red flags

• Cannot explain trade-offs in their own past projects, only what the team decided
• Skips tests, or treats them as something QA does later
• Reacts defensively to review comments in a pairing or review exercise
• Reaches for a rewrite or a new framework before understanding the existing code
• Take-home code with no README, no tests and no explanation of decisions
• Describes past work only in buzzwords with no concrete detail

The interview process

1. 1

   Define the role

   Write down the stack, the level, the product area and what success looks like after the first few months. This keeps every interviewer judging against the same bar.

2. 2

   Recruiter or hiring manager screen

   Confirm experience with your stack, the scale of systems they have worked on and why the role interests them. Ask them to walk through one change they shipped end to end.

3. 3

   Code review exercise

   Give a short pull request from a realistic codebase with a few planted issues: a missing test, an unhandled error, a naming problem. Ask them to review it as they would a colleague's. This shows judgement and how they give feedback.

4. 4

   Feature work sample

   Ask them to add a small feature to a sample repository, such as a new API endpoint with validation and tests, and to explain their choices. A job simulation of the real work is one option if you want every candidate to face the same realistic task.

5. 5

   System and team conversation

   Discuss how they would extend the feature at larger scale, how they handle production incidents and how they work with product and design. Finish with a conversation about how they like to receive feedback.

How to evaluate

• Correctness and readability of the work sample
• Quality and relevance of tests
• Quality of feedback in the code review exercise
• Reasoning about trade-offs, and willingness to change their mind
• Ability to work within existing conventions
• Clarity when explaining technical decisions to non-engineers

Onboarding

• 1Have their laptop, accounts and repository access ready before day one
• 2Give them a small, real ticket they can merge in their first week
• 3Pair them with a named buddy for code review and questions
• 4Walk through the architecture, deployment pipeline and on-call process early
• 5Ask them to fix any gaps they hit in the setup docs as their first contribution

Common questions