|
|
|
|
|
by yurodivuie
1320 days ago
|
|
For better or worse, when I was interviewing developers I would give specifically vague requirements, since requirement gathering is a skill that I think (senior) developers must have. I don't think that's a useful thing to do in a take-home assignment, though, since you can't clarify requirements with your client in that situation. That said, I admit that I would also expect error handling to be addressed in any piece of software written for any purpose. Interviewing is a nightmare on both sides of the fence, though. There's a reason why it's a good idea to build up and leverage your network of coworkers. |
|
I always view assignments and live coding in interviews as a startup that has runway of an hour or two. Would error handling help this startup survive another day? No. But properly covering the main use case - may in fact be.
It's fair to want the candidate to mention the edge cases and tests for it in the end verbally, there I agree. But expecting 120% performance giving out vaguely formulated problems with extreme time constraints and the pressure of an interview to me seems almost delusional.