3 ms·

Interestingly in the last 6 months I’ve been on both sides of this: being hired and hiring others. It was really cool because it allowed me to understand what i

Interestingly in the last 6 months I’ve been on both sides of this: being hired and hiring others. It was really cool because it allowed me to understand what is actually good and useful in the hiring process from both ends. While hiring (only 2 people, one junior and one senior, both fully remote) I just had a ~45-60min chat about technical and non-technical things (e.g. what do you think about functional programming/rails/deployment/ops/whatever, what does <something> mean to you, how do you feel about <some workplace practice>) and then gave them a small paid project to work on our actual codebase - something like implementing a small, self contained feature or writing some tests for a particular piece of code. I found this to be a really good way to find out if I’ll like working with someone and if they are a good fit on a technical level.

mgreenleaf 8y ago
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.
lucbocahut 8y ago
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.
- jahrule 8y ago
  >freelance as parttime CTO job title inflation bingo !!! ;)

mgreenleaf 8y ago

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.

lucbocahut 8y ago

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.

jahrule 8y ago
>freelance as parttime CTO job title inflation bingo !!! ;)