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

11–20 of 282 posts

Re: Bug squash: An underrated interview question

#11

Post by ozr »

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

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.

Re: Bug squash: An underrated interview question

#13

Post by singleshot_ »

Noumenon72 wrote: post #8

I was thinking, wouldn't it be fairer to do the test in an online code sandbox where being able to build and install isn't an issue? Then I thought, isn't letting the candidate use their own machine and debugging tools about as biased as hiring a limo driver based on how fast they can drive their own car? It does tell you who's a real "car guy" or "Unix guy", it just has a slight disparate impact by screening for peo…

Decent product idea? I’ll stay tuned for your Show HN.

Re: Bug squash: An underrated interview question

#14

Post by dingnuts »

Noumenon72 wrote: post #8

I was thinking, wouldn't it be fairer to do the test in an online code sandbox where being able to build and install isn't an issue? Then I thought, isn't letting the candidate use their own machine and debugging tools about as biased as hiring a limo driver based on how fast they can drive their own car? It does tell you who's a real "car guy" or "Unix guy", it just has a slight disparate impact by screening for peo…

your job doesn't let you configure your own environment and tools?

Re: Bug squash: An underrated interview question

#15

Post by franciscop »

I had a very similar intro experience to dev. I started with some friends as a hobby, and my first paid jobs were when I was hired to do a bunch of small tasks in different projects. Add some animations in this Ember project, fix some bugs in this Wordpress project, add a very specific feature in this Angular project, etc. I probably did a terrible job at that time and I'll always be grateful, but it also taught me A LOT about jumping into a foreign codebase and start working on it almost right away, especially since I was paid hourly and I was super-aware I was paid to fix the problems and not to learn the code. IMHO what this article explains is one of the most valuable bits I retain from that time.

Re: Bug squash: An underrated interview question

#16

Post by ElectricSpoon »

Noumenon72 wrote: post #8

I was thinking, wouldn't it be fairer to do the test in an online code sandbox where being able to build and install isn't an issue? Then I thought, isn't letting the candidate use their own machine and debugging tools about as biased as hiring a limo driver based on how fast they can drive their own car? It does tell you who's a real "car guy" or "Unix guy", it just has a slight disparate impact by screening for peo…

I find editors to be deeply personal things. Throw a vim user in vscode and you might be disappointed, and vice-versa. I don't care about your tools, I care that the sum of you and your tools make you good.

I think the good middle ground is having both a canned environment and allowing candidates to use their own... Unless the job is about debugging production systems where only vi is available, in which case that interview might as well represent the actual job.

Re: Bug squash: An underrated interview question

#17

Post by kopirgan »

I could be wrong but given how fast things change in this business, this seems to test very micro level skills not the learning and adaptability skills.

What if a guy could, given the business or technical issue the code solves, write something faster than he could fix others code?

May be the job is about heads down coding so this bug fix test is appropriate..

Re: Bug squash: An underrated interview question

#18

Post by vandyswa »

I've done the equivalent of this by asking them to describe an interesting bug they've encountered in past lives; how it came up, how they hunted it, how they fixed it. By listening to them describe the work, asking questions, and following their thought processes, you can come to a fairly good hire/no from this single walk-through.

I know, it's short and humane, so not a good fit for current Sillycon Valley culture.

Re: Bug squash: An underrated interview question

#20

Post by from-nibly »

kopirgan wrote: post #17

I could be wrong but given how fast things change in this business, this seems to test very micro level skills not the learning and adaptability skills. What if a guy could, given the business or technical issue the code solves, write something faster than he could fix others code? May be the job is about heads down coding so this bug fix test is appropriate..

Then you could do that and showcase that you can write code incredibly fast.
Post reply on HN