How I hired the best software developer for my project with 2 hours spent
Hiring people is hard. It’s time-consuming, often expensive, and nerve-wracking for both the interviewer and the interviewee. It becomes even more challenging when several candidates appear equally promising after an initial conversation.
As an employer, I naturally want to hire the best person for the job. But how do you identify the best candidate for your project, especially when time and resources for interviews are limited?
There are many ways to approach this, but one of the most effective methods I’ve found is to give candidates a coding test. This allows you to evaluate their coding style, problem-solving abilities, and thought processes. However, many companies make a critical mistake: they assign artificial problems that don’t relate to the actual job. That approach can fall short of truly assessing how someone will perform in the role. Many strong candidates are reluctant to waste their time on artificial problems, and I completely understand and support their perspective. Instead, I believe the test should directly reflect the real-world challenges they’ll face in the job.
My Hiring Experience
Recently, I needed to hire a software developer for an open-source project. As much as I would’ve liked to handle it myself, my commercial projects already demanded all of my attention. After narrowing the field through introductory interviews, I found myself in a tricky spot: several candidates seemed equally qualified.
So, I turned to the coding test. This wasn’t just any coding test—it was a real problem from the very project I was hiring for. Since it was an open-source project, sharing the task with candidates was straightforward. I gave them one week to solve the problem and outlined clear evaluation criteria so they’d know exactly what I’d be looking for. I also promised to pay a reasonable reward for their working solution. Transparency was key here; I wanted them to understand the expectations.
This is the message I sent to the candidates:
Hi <Name>,
Thank you again for interviewing for the Creative Ruby Developer position. I was impressed by your skills and enthusiasm, and I genuinely believe you could be a great fit for this role. However, choosing the best candidate is a challenging task, as we’ve had strong applicants like yourself.
To ensure a fair, transparent, and unbiased selection process, I’m inviting you to participate in a paid challenge that mirrors the type of work involved in the role.
Challenge Details:
- Take this ticket: https://github.com/widefix/actual_db_schema/issues/45
- Solve the issue within a week by following these steps:
- Clone the repository locally (do not fork it initially).
- Make changes locally to solve the issue.
After 9 December 9:00 UTC, create a fork on GitHub, push your commits, and submit a pull request to the original repository. Do not make any new commits after this time.
Deadline to submit your pull request: 9 December at 13:00 UTC.
Compensation:
- Every participant who submits a working solution that meets the ticket’s requirements will receive $100.
- The winning solution will secure the position with a monthly contract.
Evaluation Criteria:
- Following the rules above.
- User-friendliness and attractiveness of the solution.
- Simplicity of the technical implementation.
- Low risk of introducing regressions.
- Clear and accurate commit messages and pull request description.
Please confirm your participation within 24 hours of receiving this message. If you have any questions about the task or process, feel free to reach out.
I’m excited to see your creative solutions and wish you the best of luck!
Warm regards,
Andrei
The Results
One candidate out of four declined to participate in the competition right away, while the other three proceeded.
The task wasn’t overly complicated, so I expected all the candidates to complete it—and they did. But while they all solved the problem, the approaches they took were different. That's exactly what I wanted. Since the issue description was not too strict, I expected the solutions to be different.
Recommended by LinkedIn
This particular role required working on a user interface without input from a designer, so it had a creative component. I needed someone who could think outside the box and create a visually appealing interface on their own. That meant I evaluated their solutions not just for functionality but also for creativity, code quality, and problem-solving efficiency. I wanted someone who could tackle challenges both quickly and thoughtfully.
The pull requests told me everything I needed to know. Each candidate’s submission was like a window into how they thought and worked. After reviewing the pull requests, it became clear who the best fit for the role was. It wasn’t a difficult decision because I knew exactly what I was looking for—a candidate whose skills and abilities aligned perfectly with the project’s needs.
These are the solutions created by the candidates:
The Outcome
The entire hiring process, from start to finish, took me about two hours. In that short time, I found the best candidate for the job. The process was efficient, and both the candidate and I were happy with the outcome. Their willingness to tackle a real problem from the project also demonstrated genuine interest and commitment—a good sign for any hire.
Why This Approach Works
This method is a win-win for both the employer and the candidate. The employer gets a clear, hands-on view of how the candidate thinks and works, while the candidate gains insight into the kind of problems they’ll be solving on the job. It’s a practical, fair, and efficient way to make hiring decisions.
If you’re hiring or applying for a job, I highly recommend this approach. It eliminates guesswork, builds confidence on both sides, and ultimately leads to better matches between employers and employees. For me, it turned a typically stressful process into one that was straightforward and even rewarding.