Live data from Hacker News

Bug squash: An underrated interview question

blog.jez.io

181–190 of 282 posts

Re: Bug squash: An underrated interview question

#181
post #83

Earlier quoted context omitted.

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

I can't speak to anxiety or other disorders but I have a hard time swallowing that leetcode discriminates against the older crowd. I'm not older, but I was in the industry prior to the leetcode style interview. I've never sat down and "grinded" leetcode but I've also never had a problem with those styles of interview once they became common. Neither have my former co-workers. I have a few friends that are still worki…

One reason they can discriminate against the older crowd is that they are hard for people with established jobs and familial responsibilities to study for. Working for a longer period of time leads to more experience bug squashing. Younger developers are much more likely to not have kids and more likely to have time to dedicate to grinding questions while having less experience with "real work" i.e day to day LOB software development that the bug hunt interviews optimize for.

Re: Bug squash: An underrated interview question

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

Isn't that what companies would look for, though? They want people who can work under stress. If you had two equal programmers, and one who was stressed and the second who was not, any company would pick the second one without thinking.

That assumes that during regular work, you'd be under stress. If it were the military, then yes, i would agree - working while you're being shot at means you need to be able to work under stress.

However, a lot of people don't do well under stress, and in many corporate settings, there's usually no real source of stress (except perhaps artificial stress induced by management). Someone might work much better in a stress free environment than someone else under a stressful environment, but you'd then easily miss these candidates by structuring the interview to be stressful.

Re: Bug squash: An underrated interview question

#183

Earlier quoted context omitted.

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

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

The reason someone is unemployed or is desperate might correlate (inversely) with their ability to produce high workload.

Re: Bug squash: An underrated interview question

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

Isn't that what companies would look for, though? They want people who can work under stress. If you had two equal programmers, and one who was stressed and the second who was not, any company would pick the second one without thinking.

All stress is not the same. Interview stress is actually very different from working stress.

Ask a firefighter who rushes into burning buildings for a living to give a public speech in front of a large crowd of people in a non-burning building. Which is more stressful? For the firefighter, it may be the latter. Fighting fires is what they train for, what they're experienced with, whereas giving speeches is not.

A lot of people, no matter the profession—firefighter, programmer, etc.—have a great fear of public speaking. Likewise, a lot of people, no matter the profession, also have a great fear of job interviews, especially the crazy audition-style interviews of programmers. It's simply human nature, with little bearing on job performance in general. We shouldn't be giving auditions to people who aren't stage performers. Personally, I never work with someone watching me—definitely not a judgmental stranger who will fire me for any perceived peccadillo—nor do I ever have some specific narrow time limit on my work in the range of 15 minutes or so.

Re: Bug squash: An underrated interview question

#185

Earlier quoted context omitted.

I can't speak to anxiety or other disorders but I have a hard time swallowing that leetcode discriminates against the older crowd. I'm not older, but I was in the industry prior to the leetcode style interview. I've never sat down and "grinded" leetcode but I've also never had a problem with those styles of interview once they became common. Neither have my former co-workers. I have a few friends that are still worki…

One reason they can discriminate against the older crowd is that they are hard for people with established jobs and familial responsibilities to study for. Working for a longer period of time leads to more experience bug squashing. Younger developers are much more likely to not have kids and more likely to have time to dedicate to grinding questions while having less experience with "real work" i.e day to day LOB sof…

I think the point is that competent developers can solve the problem on the go. You don't have to study for it.

I don't know, maybe some places do have ridiculously hard problems that you just have to memorize the algorithm for, but personally I haven't seen that. It's more like advent of code style stuff that you kind of just figure out by yourself.

Re: Bug squash: An underrated interview question

#186
post #119

Earlier quoted context omitted.

it’s not a good thing to refuse to hire older people and most older people do not pass leetcode without significant grinding

I don't think replacing an interview that fails older people that instead fails younger people is a good solution.

What do you think is a good solution?

Re: Bug squash: An underrated interview question

#187
I agree. Great question. Academic LeetCode exercises are really not what I consider useful in evaluating candidates.

However, I'm biased. I'm really, really good at finding and fixing bugs, and pretty much stink at LeetCode, so take my support with a grain of salt.

One problem is that, if the exercise gets known, expect an underground economy of solution cheats. Same with LeetCode, but that's sort of expected. Bug fix solutions hit harder.

Re: Bug squash: An underrated interview question

#188
post #185

Earlier quoted context omitted.

One reason they can discriminate against the older crowd is that they are hard for people with established jobs and familial responsibilities to study for. Working for a longer period of time leads to more experience bug squashing. Younger developers are much more likely to not have kids and more likely to have time to dedicate to grinding questions while having less experience with "real work" i.e day to day LOB sof…

I think the point is that competent developers can solve the problem on the go. You don't have to study for it. I don't know, maybe some places do have ridiculously hard problems that you just have to memorize the algorithm for, but personally I haven't seen that. It's more like advent of code style stuff that you kind of just figure out by yourself.

You don't need to memorize the algorithm for, but if you haven't been exposed to those types of problems you will solve them much more slowly. Younger developers are more likely to have experience with more CS style problems than an older LOB developer who focuses more on writing clean testable code. I don't have an axe to grind in this as I am the younger developer in this situation.

Re: Bug squash: An underrated interview question

#189
post #185

Earlier quoted context omitted.

One reason they can discriminate against the older crowd is that they are hard for people with established jobs and familial responsibilities to study for. Working for a longer period of time leads to more experience bug squashing. Younger developers are much more likely to not have kids and more likely to have time to dedicate to grinding questions while having less experience with "real work" i.e day to day LOB sof…

I think the point is that competent developers can solve the problem on the go. You don't have to study for it. I don't know, maybe some places do have ridiculously hard problems that you just have to memorize the algorithm for, but personally I haven't seen that. It's more like advent of code style stuff that you kind of just figure out by yourself.

Last time I did the gauntlet at Google I was able to solve all the problems.

However I wasn't as fast as others as I didn't recognize any of the questions and had to work through them. Interviewers expect you to be fast, or at least compare you to people who seem faster. Doesn't matter who studied or not, or who will actually perform better on non-leetcode tasks.

Also having kids is a real issue, it absolutely crushes the amount of time you have to anything besides working.

Re: Bug squash: An underrated interview question

#190

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.

I agree — this is very much the type of interview I like to give. However it took me a while to get good at steering the conversation and digging for details.

It’s really easy to let the interviewee talk through talk through all of the great things they built from a product and business perspective — and assume they understand the technical perspective. There are candidates who are really good at talking in an impressive way, but manage to talk around any true implementation details or deep technical understanding.

It’s also really easy to come away with a bad impression of someone who has a tendency to give short answers and not elaborate on things, even when it turns out that person is really skilled when you dig in.

I imagine a big part of the reason for the test-style interviews we have today is that it’s easier to train an interviewer on how to give them.

Post reply on HN