A twelve-person product company needs a backend developer. The founder interviews five people over two weeks, likes the one who spoke best, and makes an offer. Three months later the new hire is slow on code review and the team lead says what everyone is thinking: we never checked how this person actually works.
A small company cannot copy a large firm's hiring machine. It can run a scorecard and a short skills test that anyone on the team can follow. This post sets out both.
Start with what the role needs
Before posting the role, write down what this developer will do in the first six months. Name the product areas, the languages and tools, who they will work with and what a good outcome looks like. Most hiring mistakes begin here, with a vague role that every interviewer reads differently.
From that description, pick four or five things you will assess. Typical choices are problem solving, code quality, reading and changing existing code, communication, and fit with how your team ships. Fewer is better. Each interviewer takes one or two.
Build a simple scorecard
A scorecard turns opinions into notes that can be compared. Each interviewer scores only their own areas, writes two or three lines of evidence, and does it before talking to the others. This stops the loudest voice deciding for the group.
Candidate, role and date.
Interviewer and area assessed.
Score for each area on a scale you define, such as one to four.
Evidence: what the candidate did or said.
Concerns to probe in the next round.
Recommendation: proceed, hold or decline.
Written before discussing with other interviewers.Run a skills test that respects the candidate
A long unpaid assignment drives good candidates away, especially those with a job and a notice period. Keep the test short and close to real work. Two formats suit small teams.
- A paired session of about an hour where the candidate and one of your developers fix a small bug in a sample repository.
- A short take-home task, with a time limit you state clearly, on a problem that mirrors your product.
- A code review exercise where the candidate reads a short pull request and says what they would change.
Whichever you choose, use the same task for every candidate in that role. Write down in advance what a good answer looks like, so reviewers do not mark by taste. Remove any task that you would not be willing to do yourself in the stated time.
The process, step by step
- 1
Write the role and the scorecard
Agree the first six months of work and the four or five areas to assess. Share both with every interviewer.
- 2
Screen with a short call
Check the basics: experience that matches the role, expectations on pay range, notice period and reason for looking. Take notes.
- 3
Run the skills test
Use the same task for everyone. Ask the candidate to explain their choices aloud, since reasoning matters as much as the result.
- 4
Hold a structured interview
Each interviewer covers their own areas with the same questions for each candidate. Score alone, then compare.
- 5
Check references
Speak to a former manager or lead. Ask about how the person works with others and handles feedback.
- 6
Decide and respond quickly
Meet once, compare scorecards, decide and reply to the candidate within a few working days. Delay loses good people.
Questions that reveal how someone works
Ask candidates to describe a bug they found in their own code and how they fixed it. Ask what they would change about a past project if they had another month. Ask how they handled a disagreement in a review. Listen for specifics: the file, the failure, the fix, the learning. General answers usually mean the person watched rather than did.
Fairness and consistency
Ask every candidate for the same role the same core questions. Keep notes on the work, not on personal matters such as family plans or background. If an interviewer has a strong gut feeling, ask them to name the evidence behind it. If they cannot, treat it as a question to probe, not a verdict.
Questions about pay, contracts, notice terms and background checks have legal angles that depend on the facts. Check your process and documents with your own qualified legal adviser. GullyHR can help you design the process, scorecards and interview guides, but it does not give legal advice.
Keep the process moving
Candidates compare your speed with the speed of other companies. Fix a turnaround for each stage and publish it to your own team: screen within two working days, test review within three, final decision within a week of the last interview. These are your choices, not standards. Keep a tracker with the stage date for every candidate and review it each Monday, so nobody waits in silence.
After the offer
A good hire can still be lost between offer and joining. Plan for that from the start. Our post on reducing drop-off between offer and joining covers it. Once the person joins, plan the first week so they ship something small early.
If your team is hiring several developers in a short period, IT specialised recruitment support can help with sourcing and screening, while your own developers stay in charge of the technical decision. For how engineering teams are usually set up, see the software development companies page.
