4 ms·
This confirms that you are part of the problem, and not serious about mitigating anxiety. Software development cycles are generally weeks in length for a reaso
by WalterSear 5y ago
This confirms that you are part of the problem, and not serious about mitigating anxiety.
Software development cycles are generally weeks in length for a reason: real software does not involve problems that can be done quickly in an hour.
You are using time limits to minimize your own work, not improve your hiring process. A short, time-limited technical problem is easy to evaluate. The candidate will have correctly solved the problem in the time allowed, and their code will be short and easy to examine for code style and pattern. However, while the signals that this process provides you will be clear and easy to compare between candidates, ultimately you are searching under the street lamp: the signals you receive are poorly correlated with candidates' actual acumen and value.
IME, this is generally done in order to push as many candidates through the pipeline as possible, in the intention of failing many decent candidates in order to avoid a 'bad hire'. However we have reams of evidence that this cynical and destructive approach does not have the outcome that people expect. It selects for people who are good at technical interviews, and against people for reasons other than their technical ability. It disproportionately selects for people coming from places of adversity.
- rsyring 5y ago> This confirms that you are part of the problem, and not serious about mitigating anxiety. You should really stop making personal insinuations. Have you actually done a significant amount of hiring? Can you suggest a better process that works in our current hiring context? I don't disagree that the process we have developed is not ideal. Feel free to post a few of the best articles/resources you have from the "reams of evidence" you mention. But, just demonstrating that the process has problems isn't enough. Is anyone showing a better way that a small company with limited resources can actually execute on? Really, can you show us how to do it differently in a way that fits the practical realities of our current context? The truth is, I'd absolutely love to work with someone for a month or two before making a hiring decision. But most good software developers already have a job. They aren't going to spend a couple months working with you to give it a shot. They also want a level of certainty that there is a good fit in the organization before they leave their current post. And, on top of that, I already get flack b/c of how involved our process is. Lots of candidates don't want to put in that much time/effort. And with 10-20 places willing to hire them, I would assume a lot don't even take the time to apply. But I can't afford to have people on our team who can't perform at the level we need. And I hate firing people. So some kind of evaluation that fits all these parameters is necessary. Otherwise, no one gets hired and we eventually go out of business. Who does that serve?