3 ms·
For people with side/brochure projects, my "take home" tests are always "add these simple features to your git hub project xxx". Often it gets done the same
by Ensorceled 4y ago
For people with side/brochure projects, my "take home" tests are always "add these simple features to your git hub project xxx". Often it gets done the same day.
Otherwise, I'll do something simple, on a shared screen in the language of their choice.
It shouldn't be hours and hours and, ideally, it's a win/win.
- coupdejarnac 4y agoIs this commonly done? I haven't seen this before. If I had an interviewer do this for me, I would be very impressed.
- bpicolo 4y agoNot being facetious here - if they have notable github projects, why do you want a new feature versus viewing or talking through something they've already developed in one of them? Why is the novelty important? The shared coding screen is definitely the most common method. And the one I've found most folk prefer. There won't ever be a one size fits all solution, but ideally your interview methods are equitable across all candidates, and ones that the majority of candidates are comfortable going through. Disparate processes hurts the former.
- Ensorceled 4y ago> if they have notable github projects, why do you want a new feature It might not actually be their project. > but ideally your interview methods are equitable across all candidates My candidates are not competing with each other, the tests do not need to be "equitable" between candidates, just fair for that candidate. One problem, for instance, with github projects is that it's a fairly privileged position to be able to have significant side projects. So it's not fair to expect a candidate to have a github presence and you would be eliminating people without a lot spare time (single parents is the go to example).