I don't disagree with much of what you said. Let me first get a couple of things out of the way, just to clarify:
DealerOn doesn't "ghost" candidates. We always review the code tests as soon as is reasonably possible (usually within 24-48 hours) and always get right back with them letting them know the result. While I frequently provide some detailed feedback to our recruiter to pass along, in one recent case the candidate send an email asking what they could have done better, as they were looking to improve. I gave a long response, as I really liked that attitude and felt an obligation to be as clear and transparent with the candidate, given their stated desire to learn from their mistakes on the test.
We have removed the time limitation from our code test for a couple of reasons. #1, it's not enforceable without having the person in our office while they're taking it. #2, things come up in your personal life and we didn't want people to feel that they needed to sacrifice just to get us a code test on time. The fact that we're almost always hiring makes this easier for us.
I actually have a special needs child, and am fully aware of the time commitments associated with that. That being said, I took DealerOn's code test prior to being hired here. It wasn't too bad, and can be done in a few hours if you're efficient.
Our code test is very basic, and the requirements are clear, except in areas where we specifically want to see how you can fill in the gaps. What we're usually looking for are basic attention to detail. For example, we provide a set of sample inputs and the expected outputs. When we receive a submission that doesn't work with the given sample inputs, it's a pretty bad sign. Also, not only do we not require installing webpack for our code test, we specifically state that we only want you to use what comes by default with .Net or Java, depending on what you use for your test. We don't want to have to spend hours setting up and environment just to evaluate your code test either. :-)
Bottom line: Do we miss out on candidates from time to time due to our code test? Almost certainly. But we've also been extremely successful in hiring great candidates and our turnover rate has been very low. The purpose of this article wasn't to defend DealerOn's use of a code test, but to recognize that code tests are a reality in the software industry at this time and there are a few things you can do to improve your chances of doing well on them. It isn't targeted at very senior engineers, as they likely know most of this anyway.
Thanks for the comments.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't disagree with much of what you said. Let me first get a couple of things out of the way, just to clarify:
DealerOn doesn't "ghost" candidates. We always review the code tests as soon as is reasonably possible (usually within 24-48 hours) and always get right back with them letting them know the result. While I frequently provide some detailed feedback to our recruiter to pass along, in one recent case the candidate send an email asking what they could have done better, as they were looking to improve. I gave a long response, as I really liked that attitude and felt an obligation to be as clear and transparent with the candidate, given their stated desire to learn from their mistakes on the test.
We have removed the time limitation from our code test for a couple of reasons. #1, it's not enforceable without having the person in our office while they're taking it. #2, things come up in your personal life and we didn't want people to feel that they needed to sacrifice just to get us a code test on time. The fact that we're almost always hiring makes this easier for us.
I actually have a special needs child, and am fully aware of the time commitments associated with that. That being said, I took DealerOn's code test prior to being hired here. It wasn't too bad, and can be done in a few hours if you're efficient.
Our code test is very basic, and the requirements are clear, except in areas where we specifically want to see how you can fill in the gaps. What we're usually looking for are basic attention to detail. For example, we provide a set of sample inputs and the expected outputs. When we receive a submission that doesn't work with the given sample inputs, it's a pretty bad sign. Also, not only do we not require installing webpack for our code test, we specifically state that we only want you to use what comes by default with .Net or Java, depending on what you use for your test. We don't want to have to spend hours setting up and environment just to evaluate your code test either. :-)
Bottom line: Do we miss out on candidates from time to time due to our code test? Almost certainly. But we've also been extremely successful in hiring great candidates and our turnover rate has been very low. The purpose of this article wasn't to defend DealerOn's use of a code test, but to recognize that code tests are a reality in the software industry at this time and there are a few things you can do to improve your chances of doing well on them. It isn't targeted at very senior engineers, as they likely know most of this anyway.
Thanks for the comments.