[HN Gopher] Bug squash: An underrated interview question
___________________________________________________________________
Bug squash: An underrated interview question
Author : jez
Score : 20 points
Date : 2024-08-18 15:07 UTC (2 days ago)
(HTM) web link (blog.jez.io)
(TXT) w3m dump (blog.jez.io)
| JohnFen wrote:
| I like this approach far, far more than coding tests!
|
| > It's fun. It's fun in the same way an escape room is fun. It's
| fun because of the dopamine you get when the test suite blinks
| green.
|
| Keep in mind that for lots of people in a job interview setting
| (even excellent candidates) this is not fun, this is stressful.
| It may be fun on the job or at home, but the stress of a job
| interview both eliminates any "fun" aspect and makes even simple
| tasks more difficult. Just mentioning that to encourage some
| amount of empathy and understanding for the candidate.
| harimau777 wrote:
| 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.
| berikv wrote:
| Although I like this interview question, it has a big downside.
| You make the candidate spend quite a lot of effort while you as
| an interviewer don't learn much. The answer to "Can this
| candidate find and fix this bug?" is not necessarily equal to "Is
| this candidate a good expansion of the team. What do they bring
| that we need?"
| ryandrake wrote:
| It's kind of a fizzbuzz-ish weed-out question: If they _can_ do
| it, sure, you haven 't learned that much, but if they cannot,
| then you know with pretty high certainty that they're not going
| to add to the team.
| yas_hmaheshwari wrote:
| This is one of the interview questions at Stripe, and I agree
| that it was the most "fun" part of the interview (It is still
| pretty stressful giving an interview, but magnitude times much
| less so than converting a BST to doubly linked list, and
| converting it back )
| ajbt200128 wrote:
| > You'll need at least one question per language that you want to
| allow people to interview in. ... "Was this performance poor
| because they're bad at debugging, or just unfamiliar with this
| language's tools?"
|
| Not necessarily a con. Different languages/tech stacks have very
| different tools. I.e. debugging a GC issue is different than
| debugging a network issue is different than debugging an embedded
| issue. If you chose a language for a very good reason, then it's
| not a con to filter out those who aren't familiar with that
| language enough to debug an issue in it
___________________________________________________________________
(page generated 2024-08-20 23:00 UTC)