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

261–270 of 282 posts

Re: Bug squash: An underrated interview question

#261

Post by burnished »

StefanBatory wrote: post #195
playingalong wrote: post #193

Earlier quoted context omitted.

Some organizations (although admittedly not all) put a lot of effort to offer a creative environment for their creative staff. So they optimize for something else. A bit like 100m race vs. marathon.

I'm still at university, so despite my previous post having a bit of accusatory tone, I was genuinely curious. At least my profs told us many times that we should be prepare that stress at work is absolutely normal and that if we can't handle it, just drop out.

Working minimum wage jobs of most stripes or in the service industry (retail, restaurants, that sort of thing) is far more stressful in my experience. Working conditions tend to be worse and people treat you worse. Not that tech isn't stressful at times, just that I've never felt like I needed to go to the walk-in to cry about it.

Re: Bug squash: An underrated interview question

#262

Post by burnished »

serpix wrote: post #163
sk11001 wrote: post #100

Earlier quoted context omitted.

There’s no chance that I can come up with a good bug story on demand without any preparation.

compare this with the technical interview bomb of demanding you write a full blown program right fuking now, complete with tests. Which one do you prefer?

Writing the program. Recalling a bug for the purpose of impressing a stranger does not sound fun.

Re: Bug squash: An underrated interview question

#263

Post by xgb84j »

normie3000 wrote: post #228
Izkata wrote: post #206

Earlier quoted context omitted.

Ah, but the code already uses boolean instead of Boolean.

Whoops, so it does. In which case I have no idea what the solution is referring to.

No serious Java code uses booleans to indicate failure or success. It's on the same level as not using a language's standard variable naming scheme. It's not wrong, but something experienced Java developers working on good code will immediately notice.

In good Java code you would return either void to indicate side effects or the newly saved user. Exception handling should be done outside the function, because depending on the context you might retry etc.

The main idea is to check if people who say they are very experienced understand conventions and have experience with common Java libraries.

Re: Bug squash: An underrated interview question

#264

Post by tharibo »

rtpg wrote: post #28

At one place there was a bug squash interview like this. Rough idea was we wrote a very small version of a system we had in our app (some data-syncing-then-displaying service), with a handful of bugs and a very simple feature request. It was very helpful for sanity checking if a person was able to be in front of a computer. There's a bit of a challenge because I think there's a pretty low ceiling of performance (stra…

This.

Keep in mind people that a job interview is to check wether you want to work with the person, not to judge if they "pass" the test.

Or to say it differently, they don't have to find and fix the bug, they have to demonstrate ability with the tools, a good attitude, a match with your work culture.

Re: Bug squash: An underrated interview question

#265

Post by sqeaky »

lapcat wrote: post #251
sqeaky wrote: post #247

Earlier quoted context omitted.

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…

> 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 that a system that does is magic.

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

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". That last one is super important, somehow the places I have worked that fired very quickly, fired people that looked different very fast. 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.

Re: Bug squash: An underrated interview question

#266

Post by sqeaky »

lapcat wrote: post #253
bluGill wrote: post #252

Earlier quoted context omitted.

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.

Because many people who hire think more vetting reduces the chance of bad hiring.

Re: Bug squash: An underrated interview question

#267

Post by sqeaky »

b20000 wrote: post #254
sqeaky wrote: post #246

Earlier quoted context omitted.

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

I have played magic the gathering for 30 years. You better believe that if I am going to a tournament I am practicing in advance. Even if I don't learn a new specific skill it might hasten decisions I already know or show me subtle nuances that mught be clutch.

Why would I take my career less seriously than a game?

Re: Bug squash: An underrated interview question

#268

Post by Piskvorrr »

chii wrote: post #183
Exoristos wrote: post #78

Earlier quoted context omitted.

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.

Might correlate with ability. Which - let's be honest - gets rounded down to "is caused by inability", just in the next step, in the name of Efficient Hiring Process.

Re: Bug squash: An underrated interview question

#269

Post by rudnevr »

it's kind of strange to me that ad-hoc debugging is considered such a valuable skill. I thought it's mostly a juniors' perspective. I typically set up extended loggers and logger methods, write everything to the some formatted file, and have a diffable, persistent, provable, multithread-friendly and versioned bug demonstration, which scales well to bugs of any complexity.

(I once found some 10 bugs in a pretty old and tested bond calculation engine while migrating it to the cloud, which nobody could initially believe.)

Re: Bug squash: An underrated interview question

#270

Post by lapcat »

sqeaky wrote: post #266
lapcat wrote: post #253

Earlier quoted context omitted.

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

Because many people who hire think more vetting reduces the chance of bad hiring.

> Because many people who hire think more vetting reduces the chance of bad hiring.

I don't know why you are answering for bluGill, and bluGill is answering for you. This is frustrating to me, because you don't appear to be of one mind. Unless you are secretly of one mind, one person behind two HN accounts.

In any case, bluGill's previous comment suggests that job interview vetting is rarely enough: "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 incompetent person on things that it is never clear if should have been figured out alone)"

Post reply on HN