4 ms·

> We use skills tests that are as close to real world as possible, given time limitations. If you are timing limiting candidates, your process is not evidence

> We use skills tests that are as close to real world as possible, given time limitations. If you are timing limiting candidates, your process is not evidence based and I question how serious you are about making efforts to mitigate or limit the effects of anxiety on applicants.

rsyring 5y ago
Why do you believe time constraints and evidence based processes are antithetical? You can't give someone an unlimited amount of time to take an assessment and still expect to meaningfully be able to compare results. One person does a good job in 1 hour another person does a good job but it takes them 10 hours. Time limitations are a fact of life. Interviewees are only willing to give so much time to the application/hiring process and we have similar constraints. The time constraints are reasonable for the tasks given. We are working to mitigate anxiety in our process, I don't think we can ever completely eliminate it.
- 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?

rsyring 5y ago

Why do you believe time constraints and evidence based processes are antithetical? You can't give someone an unlimited amount of time to take an assessment and still expect to meaningfully be able to compare results. One person does a good job in 1 hour another person does a good job but it takes them 10 hours. Time limitations are a fact of life. Interviewees are only willing to give so much time to the application/hiring process and we have similar constraints. The time constraints are reasonable for the tasks given. We are working to mitigate anxiety in our process, I don't think we can ever completely eliminate it.

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?