Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I wonder if this is an improvement over a conventional white boarding question.

It seems to me that debugging in particular is often dependent on the developer realizing some edge case or scenario where things circumstances line up to produce a bug. In that case, wouldn't a "bug squash" end up being similar to a "gotcha style" white boarding question.

The author, quite correctly, says that the interview should be scored not on whether the candidate can immediately vomit up a solution but on whether they can demonstrate their an organized thought process. However, isn't that true of white board questions as well?

Overall, it seems to me that the real problem with conventional white board questions is when the interviewer focuses on whether the candidate gets the right answer rather than on whether they demonstrate the ability to problem solve. While it sounds like the author is a good interviewer who focuses on assessing the candidate's thought process, it's not clear to me that giving debugging questions is actually what causes that.



"It seems to me that debugging in particular is often dependent on the developer realizing some edge case or scenario where things circumstances line up to produce a bug."

I don't think that's the case if there's a test failing. If a well-written test fails, that means there's a completely scoped out requirement for how the feature should work. The candidate should know how to use a debugger, so they should be able to start diving in and figuring out how the code works and what might be going wrong. I don't think that's likely to produce gotchas.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: