3 ms·

Sorry but no way. You send me a programming task you expect me to do in my personal time, and you’ve just revealed you practice extreme ageism, discriminate aga

by mlthoughts2018 6y ago

Sorry but no way. You send me a programming task you expect me to do in my personal time, and you’ve just revealed you practice extreme ageism, discriminate against parents or people with elder care responsibilities, and many more negative and disrespectful signs. It shows excessive entitlement on your side, indicating a poor working environment. Out of consideration for finding a healthy, reasonable employer, I would reject you immediately, and so should everyone. It’s not a matter of some candidates liking your process and not others - the process you describe solely perpetuates destructive and exploitative interview behaviors for everyone, even people free of outside responsibilities who can have the luxury to make room for a multi-hour take home exam within a month or two of being assigned.

11thEarlOfMar 6y ago
The median age of my team is 60. We give candidates all the time they need, as in a week or more. We explain the process when we ask them to interview, and if they prefer a white board interview instead of a take home, we can do that. So far, no one has taken that option. You're right that some people object to being asked to do programming (though none that we've asked to come in have objected) and some people think they should be compensated, which we don't do. I point out that the code review, for example, takes my team of 4-5 engineers 1-2 hours of their time, so we are matching the candidate's time spent with my team's time. In any case, it's certainly not for everyone, and we're flexible.
- mlthoughts2018 6y ago
  None of this makes it better. “We give candidates all the time they need” (which you suggest is something insanely short notice, like 1-2 weeks) is not an answer. What about people who cannot give you time outside of 1-2 hour blocks within business hours of a weekday, as in they can never work on your assignment apart from that. You’re just openly admitting that you won’t assess that whole cohort of humans. I urge you to reconsider. You are determining a process that you happen to fancy, maybe because it makes you feel like you’re a visionary of interview process or you’re going against the trend, but you’ve got blinders on about your commitment to this and what it means for people who just happen to have obligations. The standard whiteboard hazing trivia is bad enough, and 4+ hour long marathon on-sites that require weeks of study and taking vacation days just to interview are ridiculous. But your method is not much better. You’re still perpetuating this myth that somehow, unlike virtually every other profession on the planet, software engineering requires intense examination of on-the-spot demonstrated skill, rather than simple conversation probing past experience and domain knowledge. We just do interviewing completely ass backwards in software. Part to assert gatekeeper superiority, part to judge fealty. It’s just bananas.
  - 11thEarlOfMar 6y ago
    To be honest, if a candidate told me they didn't have time for a take home, I'd arrange to complete the interview process in times-of-day that works for them. The purpose was to avoid 'coding in front of a firing squad', and we could achieve a similar outcome by leaving the room while they work. BTW, I will consider the approach of simple conversation probing past experience and domain knowledge. I infer that would be in lieu of a coding demonstration. If that has worked for you, any detail that you can fill in would be appreciated.

11thEarlOfMar 6y ago

The median age of my team is 60. We give candidates all the time they need, as in a week or more. We explain the process when we ask them to interview, and if they prefer a white board interview instead of a take home, we can do that. So far, no one has taken that option. You're right that some people object to being asked to do programming (though none that we've asked to come in have objected) and some people think they should be compensated, which we don't do. I point out that the code review, for example, takes my team of 4-5 engineers 1-2 hours of their time, so we are matching the candidate's time spent with my team's time. In any case, it's certainly not for everyone, and we're flexible.

mlthoughts2018 6y ago
None of this makes it better. “We give candidates all the time they need” (which you suggest is something insanely short notice, like 1-2 weeks) is not an answer. What about people who cannot give you time outside of 1-2 hour blocks within business hours of a weekday, as in they can never work on your assignment apart from that. You’re just openly admitting that you won’t assess that whole cohort of humans. I urge you to reconsider. You are determining a process that you happen to fancy, maybe because it makes you feel like you’re a visionary of interview process or you’re going against the trend, but you’ve got blinders on about your commitment to this and what it means for people who just happen to have obligations. The standard whiteboard hazing trivia is bad enough, and 4+ hour long marathon on-sites that require weeks of study and taking vacation days just to interview are ridiculous. But your method is not much better. You’re still perpetuating this myth that somehow, unlike virtually every other profession on the planet, software engineering requires intense examination of on-the-spot demonstrated skill, rather than simple conversation probing past experience and domain knowledge. We just do interviewing completely ass backwards in software. Part to assert gatekeeper superiority, part to judge fealty. It’s just bananas.
- 11thEarlOfMar 6y ago
  To be honest, if a candidate told me they didn't have time for a take home, I'd arrange to complete the interview process in times-of-day that works for them. The purpose was to avoid 'coding in front of a firing squad', and we could achieve a similar outcome by leaving the room while they work. BTW, I will consider the approach of simple conversation probing past experience and domain knowledge. I infer that would be in lieu of a coding demonstration. If that has worked for you, any detail that you can fill in would be appreciated.