I'm obviously not rhinoceraptor, but a lot of what they said seems correct to me (speaking as someone who's interviewed others a lot, but never used at-home code assignments as part of the process).
_Some form_ of error handling and validation should be demonstrated, because that's a standard part of any program.
Equally SQL injection is _always_ important. That's not a 'hidden' judgement criteria. It's a fundamental security issue that should be protected against.
Again, I'm not rhinoceraptor, but the gist of their post seems correct. If I was reviewing some code and it had no error handling, no validation, lots of god classes and methods and was susceptible to the most common form of web-based security flaw, that is probably a sign that the candidate isn't suitable for the position.
Good, constructive feedback should then be provided.
>> Note how the evaluation changes from one person to other, you could be someone who expects an exception to be printed, I could be someone who expects an exception to be the wrong way, and would rather prefer a No Op.
I agree completely. Any good interviewer/code reviewer should be fine with someone using exceptions even if they prefer no ops.
If an interviewer did complain loads about that (without specifying how bad input should be handled), they are a bad interviewer.
>> The candidate could implement your spec 100% and yet get rejected.
But adding "The application should not be simple to hack" probably isn't something a company should need to add to the spec?
>> In 24 hours? What are you hiring for really? And why that kind of tearing hurry?
24 hours? really? Yes I understand your frustration, that's no-where near enough (assuming you mean a company asks for the solution back the day after requesting it).
If it was me, I'd assume that such a company doesn't value work-life balance and pass on them :)
_Some form_ of error handling and validation should be demonstrated, because that's a standard part of any program.
Equally SQL injection is _always_ important. That's not a 'hidden' judgement criteria. It's a fundamental security issue that should be protected against.
Again, I'm not rhinoceraptor, but the gist of their post seems correct. If I was reviewing some code and it had no error handling, no validation, lots of god classes and methods and was susceptible to the most common form of web-based security flaw, that is probably a sign that the candidate isn't suitable for the position.
Good, constructive feedback should then be provided.
>> Note how the evaluation changes from one person to other, you could be someone who expects an exception to be printed, I could be someone who expects an exception to be the wrong way, and would rather prefer a No Op.
I agree completely. Any good interviewer/code reviewer should be fine with someone using exceptions even if they prefer no ops.
If an interviewer did complain loads about that (without specifying how bad input should be handled), they are a bad interviewer.
>> The candidate could implement your spec 100% and yet get rejected.
But adding "The application should not be simple to hack" probably isn't something a company should need to add to the spec?
>> In 24 hours? What are you hiring for really? And why that kind of tearing hurry?
24 hours? really? Yes I understand your frustration, that's no-where near enough (assuming you mean a company asks for the solution back the day after requesting it).
If it was me, I'd assume that such a company doesn't value work-life balance and pass on them :)