That just sounds like a bad interview. Lately I've been conducting a few interviews at my company and the primary focus isn't what you know but how you employ that knowledge. We have a somewhat tricky technical part but we're just looking for your process. We honestly don't care if you finish or not, rather were you able to communicate the issue, do you know how to debug your errors, can you think through a problem.
Trick question interviews are just lazy interviewers honestly. Being really good at finding any answer is more valuable than just knowing a handful of trick questions.
That sounds like much better interview experience. I only hope you'll make that expectation clear to the candidate. Otherwise, they will still feel obligated to finish and will be hesitant to ask questions. The candidate must know that you're testing communication skills and not the ability to finish.
That just sounds like a bad interview. Lately I've been conducting a few interviews at my company and the primary focus isn't what you know but how you employ that knowledge. We have a somewhat tricky technical part but we're just looking for your process. We honestly don't care if you finish or not, rather were you able to communicate the issue, do you know how to debug your errors, can you think through a problem.
Trick question interviews are just lazy interviewers honestly. Being really good at finding any answer is more valuable than just knowing a handful of trick questions.
That sounds like much better interview experience. I only hope you'll make that expectation clear to the candidate. Otherwise, they will still feel obligated to finish and will be hesitant to ask questions. The candidate must know that you're testing communication skills and not the ability to finish.
It was a very bad interview indeed. Luckily, there are also good ones. I've blogged about that as well: dev.to/smeijer/how-i-got-a-job-off....