Live data from Hacker News

Bug squash: An underrated interview question

blog.jez.io

81–90 of 282 posts

Re: Bug squash: An underrated interview question

#81

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

I don't know, i think the best questions are the ones where candidates fully understand what is being asked about them. If they aren't able to self-assess did they really understand the question?

Re: Bug squash: An underrated interview question

#82
post #54
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…

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

I would say most of the time.

However i still think debugging is a core skill you should be able to demonstrate in languages that aren't your main one.

Re: Bug squash: An underrated interview question

#83
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…

for me cracking the coding interview is stressful

i prefer the bug squash question. i have 20 years of experience. i will probably do well.

a fresh grad might fail. do i care? no. leetcode has benefited fresh grads and is being used to discriminate against those with anxiety and other disorders and those who are older.

i think it is refreshing to try a different interview method, one that benefits those with experience.

Re: Bug squash: An underrated interview question

#84
post #81

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

I don't know, i think the best questions are the ones where candidates fully understand what is being asked about them. If they aren't able to self-assess did they really understand the question?

Candidates walking away pissed is itself also a problem. A significant percentage of candidates avoid buying from companies they're rejected from [1]. They also love sharing their poor interview experience with future potential applicants.

[1] https://www.wayup.com/employers/blog/how-a-positive-candidat...

Re: Bug squash: An underrated interview question

#85
post #81

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

I don't know, i think the best questions are the ones where candidates fully understand what is being asked about them. If they aren't able to self-assess did they really understand the question?

What you want is to prevent floundering death spirals. They need to understand the criteria, but if you need to hint and nudge them, they need to not feel like that means they’re bombing. Of course, you can absolutely do that in a bug squash interview, but my point is that it defeats this claimed advantage.

Re: Bug squash: An underrated interview question

#88
I had a bug squash interview today. I found it nice, but also frustrating.

It was nice because I didn't need to practice and I knew exactly how to debug the thing.

It was frustrating because my personal laptop is from 7 years ago (from college), is slow, and the dependencies and editor don't work out of the box for an a new repo. Additionally, I'd prefer to use IntelliJ like I do at work but again, that's too heavy for my computer to handle so I resort to vscode and have to figure out how to use it. So then the interview becomes debugging my environment instead of debugging the problem. Maybe that's a useful signal, but it's not really bug squashing anymore then.

So overall, it was still requiring learning but there was not a very good way to test in advance (how do you test all possible repo structures?)

Re: Bug squash: An underrated interview question

#89
This sounds like a lot of fun to me. A lot of people dislike debugging, but I always enjoyed it. It's a bit of a murder mystery. You not only need to understand what's happening several layers beyond the initial problem, but why the code may have been written the way it is even when you find the issue.

Re: Bug squash: An underrated interview question

#90

Earlier quoted context omitted.

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.

The most carefully honed social skills in the world won't help somebody plausibly answer a question like "What is the data type of this variable?" or "Show me the line where the null pointer dereference is happening."

They can add all the smiles and chuckles and other social niceties they want, but at the end of the day, whether they come up with the right answer or not, their logic will tell you pretty clearly whether they know what they're talking about.

That's the point of a technical interview: to distinguish those who think (or pretend) they can code sufficiently well to do the job, from those who can't.

Post reply on HN