Hacker News new | ask | show | jobs
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.

3 comments

>That said, I admit that I would also expect error handling to be addressed in any piece of software written for any purpose.

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.

> when I was interviewing developers I would give specifically vague requirements

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

The code had tests checking if errors threw under certain conditions... like I say it had error handling but we changed the way it worked during the interview so we needed to add some extra error conditions which we did and test coverage remained 100% so all paths in the code were tested.