4 ms·

Interesting article. For a while, we had a non-typical interview strategy: A take-home project. We would give the candidate a week or so to work on a smallish

Interesting article. For a while, we had a non-typical interview strategy: A take-home project. We would give the candidate a week or so to work on a smallish project, the requirements of which we would specify. After they completed the project, we would do a group walkthrough with them. We've hired five engineers over the last three years. For the first two, we did the take-home project. But, then I started to wonder a bit about if it was reasonable to ask programmers to work a weekend on a project. There were a bunch of persuasive comments in HN threads on the subject saying it was unfair -- a job seeker would have to spend an incredible amount of time on each application. And one candidate that I really liked aborted the interview process once I told him about the take-home test. So I changed the process to something much more typical, with live, in-person coding exercises. We hired three more engineers under this system. So, how did they compare? Well, the engineers hired when we were doing take home projects have worked out INCREDIBLY well. They are independent and very resourceful. They are excellent. The engineers hired under the more typical system have not done well at all. We had to let go of two of them, after months of coaching, and the third isn't doing that well. Random chance plays a huge role here, I'm sure. Maybe we just got lucky with the take-home project engineers. But personally, I think it makes a lot more sense to have the interview process match the work. /shrug

dclowd9901 11y ago
Right there with you; we do take home tests. It's all about the expectation. We outline out front what we're looking for (logical code separation, FP-inspired, sound code), and what would be nice to see (testing etc.) Mostly, we want to see how well the developer can explain their decisions throughout the process. Maybe they made a shitty decision. If they know it, and explain why it was shitty, that's a pass. When I joined the company, the exercise took me about 3-4 hours. I don't think that's a ton to ask, especially if you make the onsite interview less intensive (which we do).
Gratsby 11y ago
I instituted take home tests within my group. We're up front that the interviewee should not spend more than 4 hours on the project and that we don't care if it works. I am more interested in whether or not I can read the person's code, follow their logic, and if they think about logging, unit testing, etc. Coding skill, while important, is a very small part of whether or not I am interested in a candidate. Soft skills are a much stronger part of the equation IMO. I could care less if a person can write a recursive function or if they don't know the performance difference between different ways of doing things.
tedmiston 11y ago
Take-home projects are just a more complete and accurate representation of the development experience someone would have on the job. You have much more data about them than a 30-60 minute live coding session. Though my current company doesn't do them, I was hired for a previous position from a take-home project and generally support them. As an engineer, I'd rather put more effort into a smaller number of take-home projects than a larger number of live coding sessions...

dclowd9901 11y ago

Right there with you; we do take home tests. It's all about the expectation. We outline out front what we're looking for (logical code separation, FP-inspired, sound code), and what would be nice to see (testing etc.) Mostly, we want to see how well the developer can explain their decisions throughout the process. Maybe they made a shitty decision. If they know it, and explain why it was shitty, that's a pass. When I joined the company, the exercise took me about 3-4 hours. I don't think that's a ton to ask, especially if you make the onsite interview less intensive (which we do).

Gratsby 11y ago

I instituted take home tests within my group. We're up front that the interviewee should not spend more than 4 hours on the project and that we don't care if it works. I am more interested in whether or not I can read the person's code, follow their logic, and if they think about logging, unit testing, etc. Coding skill, while important, is a very small part of whether or not I am interested in a candidate. Soft skills are a much stronger part of the equation IMO. I could care less if a person can write a recursive function or if they don't know the performance difference between different ways of doing things.

tedmiston 11y ago

Take-home projects are just a more complete and accurate representation of the development experience someone would have on the job. You have much more data about them than a 30-60 minute live coding session. Though my current company doesn't do them, I was hired for a previous position from a take-home project and generally support them. As an engineer, I'd rather put more effort into a smaller number of take-home projects than a larger number of live coding sessions...