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.
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.
I did this for a while and realized that it typically panicked the people we were interviewing, especially if they were on the junior/mid side of things and as a result, gave lower-quality answers.
> I would also expect error handling to be addressed in any piece of software written for any purpose
I guess it depends on what people are hiring for but in the long list of things I need out of that person, this ends up lower on the list