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

251–260 of 282 posts

Re: Bug squash: An underrated interview question

#251

Post by lapcat »

sqeaky wrote: post #247
lapcat wrote: post #243

Earlier quoted context omitted.

How does your comment relate to the topic here, job interviews? squeaky said that companies are risk averse in their hiring process because it's hard to fire people. I said that companies are not risk averse if they can't fire incompetent people. You responded that it takes time to determine whether someone is incompetent. Ok, but that just shows job interviews are ineffective at weeding out incompetent candidates, s…

No u ;) Just Sqeaky. I think the relationship between hiring and firing and interviewing is a little more subtle than a strict if/then statement. It can be impossible to know up front if it will be easy to fire someone. Some people can hide incompetence of certain kinds for months or even years. Maybe the person that needs to be fired is competent but just toxic. Maybe the person rides right up to the line of the rul…

> 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 leetcode doesn't make you a team player.

> Also, difficulty in firing people doesn't automatically mean organizational dysfunction, sometimes it's an attempt at preventing abusive management.

Organizational dysfunction and abuse management are one and the same.

> With how swiftly you are advocating for firing I would love to be at such an organization that made firing difficult if you were my supervisor.

I advocated firing "someone obviously incompetent". Why would you fear that?

Re: Bug squash: An underrated interview question

#252

Post by bluGill »

lapcat wrote: post #243
bluGill wrote: post #233

Earlier quoted context omitted.

I've seen very few people obviously incompetent. As such it takes a while to prove they are incompetent. They do write working code and get it through review. Often the only clear sign is nobody likes working with them - only after you get rid of them do you have concrete evidence that they weren't contributing (that is the team got as much done now since they no longer were stopping their own work to help the incomp…

How does your comment relate to the topic here, job interviews? squeaky said that companies are risk averse in their hiring process because it's hard to fire people. I said that companies are not risk averse if they can't fire incompetent people. You responded that it takes time to determine whether someone is incompetent. Ok, but that just shows job interviews are ineffective at weeding out incompetent candidates, s…

If someone is not helping you, but you pay them for a year that is very costly.

Re: Bug squash: An underrated interview question

#253

Post by lapcat »

bluGill wrote: post #252
lapcat wrote: post #243

Earlier quoted context omitted.

How does your comment relate to the topic here, job interviews? squeaky said that companies are risk averse in their hiring process because it's hard to fire people. I said that companies are not risk averse if they can't fire incompetent people. You responded that it takes time to determine whether someone is incompetent. Ok, but that just shows job interviews are ineffective at weeding out incompetent candidates, s…

If someone is not helping you, but you pay them for a year that is very costly.

I agree, of course, but once again I'm confused about how this relates to what I said or to the overarching topic.

Re: Bug squash: An underrated interview question

#254

Post by b20000 »

sqeaky wrote: post #246
b20000 wrote: post #239

Earlier quoted context omitted.

you can't call 20 years of experience a lack of dedication to craft...

I have more than 20 years of experience and I manage to find time to do leet code exercises before I interview. I'm saying that testing people for their skill, in any way, will have imperfections and will wind up excluding people. If it excludes people based on something they can control that's probably not the worst thing. Not everybody can get time to practice, but do I really want to be working alongside people wh…

i want to work with people who already know how to solve problems and don’t need to practice every night to be able to do that

Re: Bug squash: An underrated interview question

#255

Post by awkii »

doawoo wrote: post #53

Triplebyte (one of the best hiring experiences I ever had) gave me this during their initial interview. They dropped an archive of a medium-ish codebase to my machine, that had failed unit tests. My task was to simply fix the code so the tests passed. Not only did I feel engaged with the interview because I could speak aloud as I debugged, I also found it fun!

You're describing the parallelized web-scraper that they pointed to their own internal site? Yeah that was fun. Too bad everyone got the same question.

Re: Bug squash: An underrated interview question

#256

Post by maxvt »

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…

> It also just seems like there's a huge random element, like am I debugging code written by somebody who thinks at the same level of abstraction as me? Did they write comments I understand?

Isn't that part of what professional software engineering is about? Unless you worked with the same group of people for a decade and have had the time to mind meld together professionally, _any_ random developer at a new company is nearly guaranteed to think in a different way and have their own philosophy of code comments.

Checking for mental flexibility and adaptation to varying approaches for others is a great subject for an interview as a software engineer.

Re: Bug squash: An underrated interview question

#257

Post by burnished »

AlexCoventry wrote: post #70
shermantanktop wrote: post #50

Earlier quoted context omitted.

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?

Hiring talent at a steep discount.

Re: Bug squash: An underrated interview question

#258

Post by burnished »

nine_k wrote: post #45
JohnFen wrote: 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 :-/

Relaxation during an interview can also be a function of practice. Obviously when you're squeezed its more difficult to get that practice in, but if you can it can help tremendously.

Re: Bug squash: An underrated interview question

#259

Post by mark-r »

I ended up doing this for an entire week, once.

I was hired and presented with a system that didn't work. I knew nothing whatsoever about their proprietary system and wasn't even given access to their codebase. I wondered why they were being so spectacularly unhelpful with onboarding tasks. At the end of the week, I found out - the whole thing had been a test to see how well I would do, and needless to say I failed miserably.

They told me I was a bad fit, and I had to agree, but probably not for the same reasons they were thinking. I really dodged a bullet with that one.

Re: Bug squash: An underrated interview question

#260

Post by burnished »

StefanBatory wrote: post #179
JohnFen wrote: 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.

>> They want people who can work under stress.

Not exactly. Interviews are a different kind of stress that is usually a direct result of being observed in an unfamiliar and somewhat high pressure situation. You might have to deal with an outage at work, but typically your employment isn't on the line (less pressure) and you have a great deal more familiarity.

Some hiring practices intentionally try to create a more welcome, less stressful experience because they don't want to bias for interviewing skill (as opposed to fitness for the job).

Post reply on HN