Hacker News Reader

Comment by berikv | Hacker News Reader

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?”

View on HN

The point of the interview is not to answer "Can this candidate find and fix this bug?" but rather "what is the candidate's approach to fixing unknown problems?"

A good performance looks like making a hypothesis for where the bug is, testing that hypothesis, and repeatedly narrowing in closer and closer. Finding and fixing the bug is irrelevant!

A bad performance might look like

- running out of hypotheses for what might be causing the bug

- making hypotheses, but never testing them

- failing to interpret the result of their test of the hypotheses (thinking it confirms one thing, when it doesn't actually confirm that, or it confirms the opposite)

So like trial & error? Modify, compile, run?

That could be one way to approach this, yes

Care to elaborate on other approaches? I am curious.

A candidate could, for example, debug the issue without modifying the code. Or they could alter the system it runs on.

Sorry, but do you have any data that shows 'great' candidates run tests and use your approach of finding / fixing bugs? Read the book 'Coders at Work' which describes some of the best developers of all time - most of them use print statements to find bugs / debug. Btw, I've solved bugs in 2-5 minutes which some developers spent hours or days working on (to their amazement) -- I've done this countless times in the past without using code or any debugging / testing tools -- all it took was reading the code and figuring out in my head what was going on and which data elements could introduce problems -- so I suppose I belong in your list as well? Sorry I just want to see the thought process here, to me it makes 0 sense and all the HN commenters commending the parent article are also making me absolutely scratch my head since the suggested process makes many many assumptions without having any data to back them up.

I agree with you, print statements or just simply reading the code (or modifying the code and then testing) can do wonders.

It rarely makes sense to hire for a specific need. I want people that are smart and high agency. Seeing how they approach problems like this is generally enough to tell.

I've done similar interviews in the past and they are remarkably high signal.

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.

Astonishingly, I’ve found fizzbuzz to be a shockingly good weeder question for tech screens.

To me this sounds like a relaxing break from the effortful part of the interview.

Reply on news.ycombinator.com