Live data from Hacker News

Bug squash: An underrated interview question

blog.jez.io

271–280 of 282 posts

Re: Bug squash: An underrated interview question

#271
post #265
post #251

Earlier quoted context omitted.

> Interviews might not be able to tell you if someone is excellent but some terrible people will absolutely reveal their cards. You appear to be equivocating on the definition of "terrible". The type of programming interviews that people dread, and are the subject of the linked article, are technical coding quizzes. These audition-style interviews do little or nothing to identify people who are "toxic". And grinding…

> You appear to be equivocating on the definition of "terrible" Such a thing defies singular definition. Every company, person, and project will use different metrics. We might agree that someone truly awful is terrible, but more people exist on the margins. So how could I cleanly define it when clearly there isn't a single definition that matters? I agree they don't find some kinds of toxic people, but I would argue…

> Such a thing defies singular definition. Every company, person, and project will use different metrics.

The submitted article is about bug squash interviews vs. leetcode interviews, in other words, technical audition-style coding tests. That's what I've been discussing all along too, and the relevant definition of "competence" is technical programming ability. You appear to be want to go off on a tangent about "toxicity", but it's unclear what bearing that has on the topic of the overarching conversation. Certainly no technical coding test is going to weed out toxicity.

> I would argue that a system that does is magic.

I agree.

Also, magic does not exist.

> Because I don't know you and do not YET trust that "obviously incompetent" isn't a synonym for "politely disagreed one time", "didn't suck up enough", or "black".

Well, you don't have to worry, because I've never hired anyone and won't be hiring anyone in the foreseeable future.

> And having a longer harder vetting process during might let a company see a red flag and avoid someone who might make such decisions and allow some time and process to review firing because the rate of terrible hires is likely lessened so firing rapidly is perceived to be less important.

It's weird that you've seemingly shifted suddenly from the topic of hiring engineers to hiring managers. Again, this is completely irrelevant to the topic of the submitted article, which is bug squash interviews. You want to argue that more "vetting" will help, but you haven't actually explained your method of vetting, other than "magic". In any case, if you're worried about racial discrimination in the firing process, which of course is a legitimate worry, then why wouldn't you worry about racial discimination in the hiring process too? After all, you don't have to fire someone who you never hire in the first place, right? Why do you think that black people wouldn't simply be "vetted" out before they get hired (especially since you yourself appear to want to increase the amount of vetting, and thus the opportunities to weed out whomever the hiring manager doesn't like)? It's truly bizarre to believe that you could institute a magical hiring process that could somehow nullify a racist hiring manager. On the other hand, if your magical hiring process could weed out racist managers before they get hired, then you wouldn't have to worry about the firing process.

Re: Bug squash: An underrated interview question

#272
post #184

Earlier quoted context omitted.

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…

Interview stress is nigh indistinguishable in my experience from a bad customer call. Indeed, if I replaced the bug fix part with writing an effective ticket or test for the issue, this becomes an even better method for tech support, technical account managers, or sales engineers than for developers, unless it's a company where devs regularly interact directly with customers.

Re: Bug squash: An underrated interview question

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

Even if I have no other offers I’m pretty good at maintaining a calm demeanor in an interview. I think it’s served me well over the years.

I've completely flubbed questions but thinking out loud in a personable way nets a lot of bonus points

Re: Bug squash: An underrated interview question

#276

Earlier quoted context omitted.

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.

This! One of the best developers I've worked with used to be a carpenter who had a kid with Down syndrome. He taught himself programming in his spare time. Smart, extremely driven and knew how good we all had it.

Re: Bug squash: An underrated interview question

#277
post #45
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…

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

[deleted]

Re: Bug squash: An underrated interview question

#278
post #51
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?”

The point of the interview is not to answer "Can this candidate find and fix this bug?" but rather "what is the candidate's approach to fixing unknown problems?" A good performance looks like making a hypothesis for where the bug is, testing that hypothesis, and repeatedly narrowing in closer and closer. Finding and fixing the bug is irrelevant! A bad performance might look like - running out of hypotheses for what m…

Sorry, but do you have any data that shows 'great' candidates run tests and use your approach of finding / fixing bugs? Read the book 'Coders at Work' which describes some of the best developers of all time - most of them use print statements to find bugs / debug. Btw, I've solved bugs in 2-5 minutes which some developers spent hours or days working on (to their amazement) -- I've done this countless times in the past without using code or any debugging / testing tools -- all it took was reading the code and figuring out in my head what was going on and which data elements could introduce problems -- so I suppose I belong in your list as well? Sorry I just want to see the thought process here, to me it makes 0 sense and all the HN commenters commending the parent article are also making me absolutely scratch my head since the suggested process makes many many assumptions without having any data to back them up.

Re: Bug squash: An underrated interview question

#279
post #33

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.

You just need to rewrite the dev tools in rust! Joking aside, modern fast tools like bun can make this type of interview way more viable. I once conducted this type of interview where the candidate had to install node on their windows laptop and... we spent most of the time debugging their install :/

FYI just small tip on the Windows / Node front, you should just install & use NVM instead of Node directly - will make many headaches go away.
Post reply on HN