2 ms·

I'd usually say the first part isn't that interesting compared to the second. Any take home challenge to some extent just tests how willing someone is to burn

by Ntrails 12y ago

I'd usually say the first part isn't that interesting compared to the second. Any take home challenge to some extent just tests how willing someone is to burn several hours generating code to maybe pass a stage in an interview. How would you feel about, say, providing a candidate with a chunk of [source] code and 30 minutes to read through and grok it. Then they can lead a discussion/review about their thoughts on its structure, and so on. This can move in to their preferred implementation, or just focus on consequences and risks etc. Essentially switching positions from the usual stage 2 where you're reading code and leading. I know reading code is in some ways easier than writing - but to me understanding foreign source is sometimes harder than writing a fresh tool in your own style etc. Being able to distill intent, aim etc.

kasey_junk 12y ago
> how willing someone is to burn several hours generating code to maybe pass a stage in an interview. We are well into the area where it is my biases talking and not any sort of well researched finding, but I don't believe in developers who can turn on/off writing good code. Either a developer writes good code, or they don't. Further, I take getting my next job very seriously. I take hiring my next colleague equally seriously. I'd hope that this seriousness (in combination with me asking for a reasonable amount of work sample) would encourage everyone involved to put their best foot forward. > How would you feel about, say, providing a candidate with a chunk of [source] code and 30 minutes to read through and grok it. I have never tried this so don't have any experiential recommendations. My instinct is to think that this would be problematic, not because it is wrong to judge someones ability to learn foreign code, rather because the evaluation step would be very hard to filter for someone who learned foreign code quickly, from someone who is great at talking about stuff generally. If I wanted to judge someones foreign code ability, I would as part of the code project, expect them to interact with a provided set of foreign code. I'd set explicit boundaries about how much they could or could not change it and then judge the candidate on how their new code interacted with the legacy code as well as what and how they changed the legacy system. > I know reading code is in some ways easier than writing I don't think that is in the least bit true. I think evaluating a candidates ability to interact with legacy code is a hugely valuable thing to filter on in most environments, it's just very hard to design a fair and repeatable work sample problem around it.

by Ntrails 12y ago

kasey_junk 12y ago

> how willing someone is to burn several hours generating code to maybe pass a stage in an interview. We are well into the area where it is my biases talking and not any sort of well researched finding, but I don't believe in developers who can turn on/off writing good code. Either a developer writes good code, or they don't. Further, I take getting my next job very seriously. I take hiring my next colleague equally seriously. I'd hope that this seriousness (in combination with me asking for a reasonable amount of work sample) would encourage everyone involved to put their best foot forward. > How would you feel about, say, providing a candidate with a chunk of [source] code and 30 minutes to read through and grok it. I have never tried this so don't have any experiential recommendations. My instinct is to think that this would be problematic, not because it is wrong to judge someones ability to learn foreign code, rather because the evaluation step would be very hard to filter for someone who learned foreign code quickly, from someone who is great at talking about stuff generally. If I wanted to judge someones foreign code ability, I would as part of the code project, expect them to interact with a provided set of foreign code. I'd set explicit boundaries about how much they could or could not change it and then judge the candidate on how their new code interacted with the legacy code as well as what and how they changed the legacy system. > I know reading code is in some ways easier than writing I don't think that is in the least bit true. I think evaluating a candidates ability to interact with legacy code is a hugely valuable thing to filter on in most environments, it's just very hard to design a fair and repeatable work sample problem around it.