3 ms·
We've been trying to hire a part-time contract dev recently and we hate the process so we've been a little half-assed about it. As a result I think we've stumb
by andybak 6y ago
We've been trying to hire a part-time contract dev recently and we hate the process so we've been a little half-assed about it.
As a result I think we've stumbled across a fairly effective approach.
We ask them to do a half day to day coding task based on a real requirement. We pay them for this as we have few enough applicants that we want to test that we can afford to.
We give them the requirement as if it came directly from the client. It's incomplete and there's a few assumptions they might make that would be incorrect.
It's fascinating to watch how people have approached this. We've only done two so far but the degree to which they ask the right questions vs leap in and try and code their way through it is revealing a lot.
Our initial setup instructions had a couple of errors in and this too has been really useful. Watching how they respond and how they resolve the problem.
It's remarkably close to real world tasks - poorly worded requirements, problems with documentation, missed assumptions that it feels like we're testing the things we really want to test.
The difficulty is that we can't come right out and tell them this is what we're doing and the artificial nature of the test might make them less likely to ask questions that they would ask in a live task. We've tried to drop hints to guide them into doing so however.
- mdpopescu 6y agoHuh. On three separate jobs (small tasks, few hours to couple of days) I was told, after asking some questions, "stop bugging me and just write the damn thing". I would probably not ask any questions on any new task of that sort and just randomly pick something. To be honest, that might not even be intrinsically bad - the client can always change their mind even if I write exactly what they wanted, so "write something and show it to me" is probably a good idea.
- andybak 6y agoYeah. We would have accepted that. We did explicity say several times "ask questions. we're here". Our desired outcomes were (in order of preference: 1. Ask and figure out the task was easier than it might have seemed 2. Don't ask but make the right judgement call 3. Don't ask and overcomplicate things because you've assumed the worst. (For example - the task could have been done with no UI and just a CLI interface. We never said it needed any user facing elements. We wanted to see if they jumped to conclusions. So far everyone has assumed it needed a web UI)
- chillacy 6y agoI once had an interview like this from a very large e-commerce company in Seattle (though I did not get paid, at least they paid for my flight and hotel and food. A good deal for a college kid). Though the coding problem was less "poorly worded requirements and bad docs" and more "this is actually an NP hard optimization problem".