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

61–70 of 282 posts

Re: Bug squash: An underrated interview question

#61

Post by kenschu »

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…

This is exactly what we've built!

We take in these bug-squash/Github based repos, serve them in VScode Web/Jetbrains/etc, and give you instant results

Email is in profile if anyone's curious to see it live

Re: Bug squash: An underrated interview question

#63

Post by kenschu »

caseyy wrote: post #41
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.

So true. A test will only measure its set of criteria. What is a test for drive — desire to understand and learn? What is a test for how a person will respond to challenging and overwhelming prod scenarios? What is a test for if they will burn out in a month because they want to prove how rockstar of a programmer they are? My most successful hiring has always been based on a conversation with 3-4 practical questions.…

There's both culture and technical elements to consider in a potential hire. I don't think anyone would contest that vetting for the culture/drive of a candidate is important. But I do think the demonstration of skills is a necessary part of technical hiring, at least for non-senior positions.

Re: Bug squash: An underrated interview question

#64

Post by marcinzm »

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

Earlier quoted context omitted.

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

> I don't care for popular people so, in fact, my bias might be the other direction

It's not about someone being popular and you saying it just makes me more certain you don't realize the trap. People can have well honed social skills and not act like your standard popularity contest wining politician.

Re: Bug squash: An underrated interview question

#65

Post by __float »

jpmoral wrote: post #23

Had an interview question like this where the interviewers were very impressed. Said it was the fastest and cleanest they'd seen anyone do it, and in an unfamiliar framework no less. Unfortunately it wasn't enough for me to get the job. I had a couple of answers in the next section they didn't quite like.

> I had a couple of answers in the next section they didn't quite like.

Could you say more about this? Were they technical or behavioral interviews?

Re: Bug squash: An underrated interview question

#66

Post by __float »

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

How is debugging a "micro level skill"? Jumping into an unknown project/system/whatever is something you will likely have to do at some point. (Sometimes it might be code you wrote yourself years ago, but revisiting without any context makes it feel unknown.)

Is this hypothetical guy always writing 100% correct code?

Re: Bug squash: An underrated interview question

#67

Post by __float »

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…

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

I think this might be a typo - we're observing X but want Y, or some similar variation. In any case, there's a bug.

Re: Bug squash: An underrated interview question

#68

Post by tedunangst »

__float wrote: post #54
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…

I seem to interview in a different language every time I switch jobs.

Re: Bug squash: An underrated interview question

#69

Post by leoqa »

trevor-e wrote: post #43
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…

Yea there's a huge element of randomness to these kinds of interviews. I wasn't a big fan of them at Stripe. You can get some signal like: - do they methodically approach the problem? - do they understand the bug? - do they know how to use debugging tools? - do they know advanced debugging tools? - do they work well in an unfamiliar codebase? But in practice I'd say most candidates check those boxes, at which point i…

I gave this interview 100+ times and my criteria boiled down to: did they propose a hypothesis and then follow it to a conclusion? Doesn’t matter if it was wrong, just mattered that they were able to falsify it or find the solution.

At the end, I would have them walk me through the bug, its cause, and the fix in very high level terms to make sure they could articulate the path we took.

Re: Bug squash: An underrated interview question

#70

Post by AlexCoventry »

shermantanktop wrote: post #50
nine_k wrote: post #45

Earlier quoted context omitted.

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 :-/

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?
Post reply on HN