Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bug squash: An underrated interview question

blog.jez.io

Post reply on HN
Print view View original

51–60 of 282 posts

Re: Bug squash: An underrated interview question

#51

Post by jez »

berikv wrote: post #4

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

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)

Re: Bug squash: An underrated interview question

#52

Post by teaearlgraycold »

nine_k wrote: post #45
JohnFen wrote: post #2

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…

This approach then selects those who are relaxed. The candidates that have five more interviews at advanced stages, and likely to receive several offers, as opposed to candidates who badly need a job. The former kind of candidate may be more desirable for the employer :-/

Even if I have no other offers I’m pretty good at maintaining a calm demeanor in an interview. I think it’s served me well over the years.

Re: Bug squash: An underrated interview question

#53

Post by doawoo »

Triplebyte (one of the best hiring experiences I ever had) gave me this during their initial interview.

They dropped an archive of a medium-ish codebase to my machine, that had failed unit tests. My task was to simply fix the code so the tests passed.

Not only did I feel engaged with the interview because I could speak aloud as I debugged, I also found it fun!

Re: Bug squash: An underrated interview question

#54

Post by __float »

zug_zug wrote: post #36

I've only had one "find the bug" interview, and it was awful: - Didn't set you up with a way to reliably run/test the code, nor a step-through-debugger which, jeez is it 1980? Like setting up a repo in a language you aren't familiar with (say getting your py-env exactly right) can take a whole hour if it's not your main language. - Didn't have standardized questions, which is hugely problematic (some bugs are 2 order…

> - Didn't set you up with a way to reliably run/test the code, nor a step-through-debugger which, jeez is it 1980? Like setting up a repo in a language you aren't familiar with (say getting your py-env exactly right) can take a whole hour if it's not your main language.

How frequently do people interview in a language other than their "main" one(s)?

> - Didn't have standardized questions, which is hugely problematic (some bugs are 2 orders of magnitude harder than others)

How do you know they're not standardized? (You say in another comment where it was, and indeed that's where the blog post author works. It's described as a pretty standardized process by my reading of it.) You can pass the interview without actually solving the bug, but I get it's easier to blame the problem than admit you struggled with it.

Re: Bug squash: An underrated interview question

#56

Post by __float »

lr4444lr wrote: post #25

How much time do you allot for this thing? Cloning the repo, dependency installs, server/DB setups, possible build steps, configuring the IDE to the project ... even if the whole thing is containerized, just going from nothing to running code in an IDE alone could be expected to take 20-30 minutes of the interview.

The bugs are chosen in projects that don't require this much setup. (There is no server/database, they use standard tools for the given language, and they are generally solvable without needing an elaborate IDE/debugger setup. Of course that may help, and it's why you bring your own computer and choose the language ahead of time.)

Re: Bug squash: An underrated interview question

#57

Post by 0x20cowboy »

marcinzm wrote: post #40
0x20cowboy wrote: post #38

If you can’t sit down with someone, have a simple tech conversation with them and be able to tell if they know what they are doing… if you need to “give someone a test”… the problem is likely not the candidate.

That biases heavily to candidates with good people skills and the skill to take over a conversation. Yes, you are not in fact immune to this even if you think you are, that’s why it’s so dangerous.

I disagree. That would indicate conversations skills equate to knowing what you are talking about.

"Yes, you are not in fact immune to this even if you think you are, that’s why it’s so dangerous."

I think that I am. I'll think about that a bit more. I don't care for popular people so, in fact, my bias might be the other direction. However, I don't think I have ever met a person who I thought was technical and proficient, but turned out not to be.

I have been forced to hire people I knew were not proficient because they passed a test, but not the other way around.

Re: Bug squash: An underrated interview question

#58

Post by halfcat »

”what we’re observing is X, but we see Y instead.”

What?

Anyway, I’ve found these kind of interview questions rarely helpful because the scenario is either overly simplistic, or it’s some obscure bug they identified (which they only caught because it caused an outage, i.e. they also didn’t “solve” this when they wrote it).

A similarly poor interview question happens in IT operations when the interviewer asks super specific details about some CVE from 5 years ago that he’s particularly proud of pulling an all nighter to patch a bunch of servers.

Re: Bug squash: An underrated interview question

#59

Post by throwaway215234 »

0x20cowboy wrote: post #38

If you can’t sit down with someone, have a simple tech conversation with them and be able to tell if they know what they are doing… if you need to “give someone a test”… the problem is likely not the candidate.

What you're describing is a low hiring bar. Low hiring bars make sense for companies that pay low to average salaries, or don't require particularly deep technical skills. But it's an awful strategy if you're trying to filter for exceptional talent and willing to pay top dollar.

Re: Bug squash: An underrated interview question

#60

Post by BurningFrog »

0x20cowboy wrote: post #38

If you can’t sit down with someone, have a simple tech conversation with them and be able to tell if they know what they are doing… if you need to “give someone a test”… the problem is likely not the candidate.

Strong disagreement!

Sure, there is some correlation between talking and doing, but I've worked with people who talk like geniuses and code like crap. And also the opposite.

For some skills, there is just no substitute for actually have people actually demonstrate using them.

Post reply on HN