There is a recurring theme in this post about "putting candidates to the test" - sometimes simple testing in the hiring form (to select the ones with the highest intent) and them to "test with a project" to find out the best ones. I wonder if this is very practical for a company that isn't a popular/based-in-vally startup. I have a two part question: (a) How successful have you been in getting this level of engagement with candidates before you hired them? I would love to learn more about this. And (b) How well does this work for "non-programming" roles - that is, can you really devise practical projects/problems for people to solve. I know the business development example mentioned in the OP, but that is a small test in the form of a question - but I can't imagine what a real "project" for this type of role would be? -- sorry, thats 3 questions :) .. but I am curious to dive deeper into this aspect of the post.
I did a bit of testing at my previous employer, where I was the hiring manager, but it was in the interview (so candidates had no choice). I think that is a nice compromise--the candidate is fairly far along in the process, and you can still learn a lot about a developer with a small project. Granted, these were junior positions.
As far as (b), I have no experience in this, but I can think of problems for a non technical person to fulfill. If confronted with doing this, I'd just ask the hiring manager to list 2-3 pressing problems and have the candidate outline a solution to one of them. Maybe I'm missing the thrust of your question?
Comments
There is a recurring theme in this post about "putting candidates to the test" - sometimes simple testing in the hiring form (to select the ones with the highest intent) and them to "test with a project" to find out the best ones. I wonder if this is very practical for a company that isn't a popular/based-in-vally startup. I have a two part question: (a) How successful have you been in getting this level of engagement with candidates before you hired them? I would love to learn more about this. And (b) How well does this work for "non-programming" roles - that is, can you really devise practical projects/problems for people to solve. I know the business development example mentioned in the OP, but that is a small test in the form of a question - but I can't imagine what a real "project" for this type of role would be? -- sorry, thats 3 questions :) .. but I am curious to dive deeper into this aspect of the post.
I did a bit of testing at my previous employer, where I was the hiring manager, but it was in the interview (so candidates had no choice). I think that is a nice compromise--the candidate is fairly far along in the process, and you can still learn a lot about a developer with a small project. Granted, these were junior positions.
As far as (b), I have no experience in this, but I can think of problems for a non technical person to fulfill. If confronted with doing this, I'd just ask the hiring manager to list 2-3 pressing problems and have the candidate outline a solution to one of them. Maybe I'm missing the thrust of your question?