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

71–80 of 282 posts

Re: Bug squash: An underrated interview question

#71

Post by kenschu »

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.

Agree! This is one of the core pains we set out to fix. Using a CDE to package everything nicely for the candidate goes a surprisingly long way for their experience.

I think there's a valid point that any IDE != a candidate's local setup. But I think there's a compromise there - we try to offer a variety of common IDE's + a few mins of prep to download extensions, etc before you're thrown in the thick of it.

Re: Bug squash: An underrated interview question

#72

Post by danielheath »

AlexCoventry wrote: post #70
shermantanktop wrote: post #50

Earlier quoted context omitted.

Depends very much on the company. Fishing in the unemployed-and-desperate end of the pool is a real tactic. The odds are good but the goods are odd, as they say.

What's the goal? Increase headcount at any cost?

Find the occasional spark of brilliance someplace where others aren't looking?

Re: Bug squash: An underrated interview question

#73

Post by ericjmorey »

AlexCoventry wrote: post #70
shermantanktop wrote: post #50

Earlier quoted context omitted.

Depends very much on the company. Fishing in the unemployed-and-desperate end of the pool is a real tactic. The odds are good but the goods are odd, as they say.

What's the goal? Increase headcount at any cost?

Finding talent

Re: Bug squash: An underrated interview question

#74

Post by ryoshu »

One of my favorite interviews was like this, but it was a long time ago and they printed out the code and told me there was a problem. Here's a pencil. What's wrong? Most were a function call or two. In one case I remember someone was doing a loop that incremented the index of a SQL query in code and using each result, instead of querying the set and looping through it in the code.

The fun part was it was a discussion. Two people, paper and pencil, talking about the code. And the examples were from bugs they'd already squashed in a code base they inherited. It was a project that I ended up working on that had... quite a few interesting bugs like that.

Re: Bug squash: An underrated interview question

#75

Post by mistercow »

> It’s easy for the candidate to self-assess their own progress.⊕ When the candidate isn’t doing well on it, they probably already knew it without needing to be told as much by the recruiter. This is a much better candidate experience than the whiplash of thinking you solved a question perfectly only to realize that the interviewer was looking for something else entirely.

Not to say that I think this is a bad type of question overall, but IMO, this is an anti-feature. The candidate does not need to accurately self-assess their performance on the day. They need to have their confidence preserved so they don’t tilt and tank the signal for the entire interview round.

Re: Bug squash: An underrated interview question

#76

Post by simonw »

harimau777 wrote: post #3

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 sco…

"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.

Re: Bug squash: An underrated interview question

#77

Post by jez »

halfcat wrote: post #58

”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 sp…

Sorry about that! edited to

> What we're observing is X, but we want to see Y instead.

Re: Bug squash: An underrated interview question

#78

Post by Exoristos »

AlexCoventry wrote: post #70
shermantanktop wrote: post #50

Earlier quoted context omitted.

Depends very much on the company. Fishing in the unemployed-and-desperate end of the pool is a real tactic. The odds are good but the goods are odd, as they say.

What's the goal? Increase headcount at any cost?

Improve the ratio of compensation to workload in the hiring employer's favor.

Re: Bug squash: An underrated interview question

#79

Post by shermantanktop »

danielheath wrote: post #72
AlexCoventry wrote: post #70

Earlier quoted context omitted.

What's the goal? Increase headcount at any cost?

Find the occasional spark of brilliance someplace where others aren't looking?

That’s it. Not everyone lives a life that leads to a perfect resume.
Post reply on HN