I second this. I freelance as a part time CTO and this has been my favorite appproach to hiring devs. A paid project goes a long way to establishing a good work relationship and gives both sides most of what they need to decide if it’s a good fit longer term. I also always offer my clients to start with a small contained project to see if we’re a fit. This ends up saving a lot of time: the risk is low for the employer, and the developer gets paid their market rate and has a chance to show that they are worth it. It’s then really easy to decide if we should continue working together or not.

>freelance as parttime CTO

job title inflation bingo !!! ;)

I agree; when I interview I tend to talk to them for a bit to get a feel for how they view the world and how they code. I ask about personal projects, how they learn new things, sources of information for keeping current, what they've worked with, personal interests. I ask what they've worked with and why and why they would choose a particular solution. You can get some really interesting answers (programmers tend to be polymath-y types). I think the best hires we've made were people who had personal side projects, naturally curious with learning hobbies (not just programming), and were open and honest about questions, willing to have a good discussion, and weren't just trying to give the expected answers. There are two sides to that coin, since the interviewer also has to value that, and maybe it just depends on who you are and what you are looking for, but it has worked well for us.

I love the idea about doing the paid project on the real project; I'd love to implement that too.