Live data from Hacker News

Bug squash: An underrated interview question

blog.jez.io

211–220 of 282 posts

Re: Bug squash: An underrated interview question

#211

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?

In my experience, it's just to hire the people that got passed over by other companies but still have some skill. You dont have to pay as much and they might also be more likely to stick around longer if they have trouble interviewing at other places.

I'm stuck in my job and I get paid less than people with lower tenure and credentials. Due to a disability, I don't have the social/political skills to get promoted in my org nor feel comfortable job hopping. It's funny though because every team I've been on has had managers or TLs telling me things that equate to 'you should be at the next level' such as "if you were preforming at this same level on another team you would probably be promoted". I had an interview internally recently and was told that I "found more errors than was expected" for my level.

So yeah, get disabled people like me so we are less mobile, work above our level for the technical work, cost less, and can't get promoted easily.

Re: Bug squash: An underrated interview question

#212
post #132

Earlier quoted context omitted.

Right... Python.. Its syntax is so ugly. So I guess you can have really awful gems there with hidden bugs :) I myself, shoot myself in a foot once doing Python code. I declared variable called 'len' and boom! What an interesting failure mode the script had. Took me a while to figure it out.

When I write Python it's an absolute hard line requirement to run it through Pylint and Pyright. They catch sooooo many issues you'd have to be a complete idiot not to do this (many people are unfortunately). In this case Pylint will tell you about this mistake: https://pylint.pycqa.org/en/latest/user_guide/messages/warni...

Hmm, nice stuff.. Luicky, I avoid python, so case closed. Ruby is so much nicer for me.

Re: Bug squash: An underrated interview question

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

leetcode style interviews discriminate against older workers: older workers don't have time to grind leetcode. they have other obligations outside work. job descriptions require "x years of experience" but then the interviewer dismisses your experience and you get purely evaluated on whether you pass the interview, just like younger people who don't have the experience.

I don't know where you've been doing coding interviews. I'm pretty confident there are leetcode type problems you will have a hard time with and won't be able to complete in the allotted time. I'll share one of my experiences with a FAANG.

My interviewer first spent a lot of time "getting to know me" and asking trick questions, and stressing he also previously founded a startup, then handed me a problem and demanded I find the optimal solution in ~10 minutes and also wanted me to talk while working on the problem. I could not remember the arguments to a function and couldn't concentrate. It bombed.

A few days later I was sent prep material for an interview at a different FAANG. One of the videos was the author of cracking the coding interview solving this exact problem on a whiteboard. It took her more than an hour to arrive at the optimal solution.

So in short: 1) interviewer had unrealistic expectations

2) interviewer wasted time with introductions given his expectations

3) interviewer asked trick questions to determine whether I am a liar even though it was pretty clear from the introductory conversations that was highly unlikely

4) interviewer created an awkward interviewing environment and triggered my anxiety

5) interviewer thought I should be able to code while talking

6) interviewer probably forgot how long it took him to solve the problem originally and probably never timed that

Re: Bug squash: An underrated interview question

#214
I was given a similar interview problem and thought it was one of the better interviews I've had. In my case the interviewer pulled up a web app and said this particular page is loading too slow, how would you approach the problem? We went from opening dev tools to look at the requests driving the page all the way through database optimizations and every layer in between.

This kind of interview didn't feel like a gotcha and was much much closer to real world work than the toy and/or algorithm problems that I have encountered. More companies should adopt these types of interview approaches.

Re: Bug squash: An underrated interview question

#215
post #186

Earlier quoted context omitted.

What do you think is a good solution?

Number one: there is research on how to interview find it and read it. All comments I've seen here give no indication that the commenter is even aware of it. I'm aware the research exists, but I have not read it (my company trained me in interviewing, and the class mentioned research but I haven't checked to see if it is the latest research that I'm trained in) If the above doesn't answer your question, then differen…

one thing I found interesting is the observer or hawthorne effect. in short, people perform differently when observed doing a task. this means that simply by observing people while they are coding, you might make them perform differently, and come to a conclusion they are not able to code, while if you did not observe them, they might have done well.

the reasoning is that it's ok to pass on excellent candidates. as a business owner I find that a real problem. I would prefer the best, not just people who had time to grind leetcode and rapidly crank out solutions to standard problems you can find online. i think it would be better if interviews erred on the side of caution and preferred to let people through especially if they have experience. you can always fire them if they don't perform. there is no job security in the US anyway.

Re: Bug squash: An underrated interview question

#216

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.

In my experience, being a workplace or even academia, there's as many types of work environments as types of teachers.

In the end, management (or founders if it's a startup) set the tone and who they end up hiring (thus, who will manage your work). And management is just normal people in the end.

Re: Bug squash: An underrated interview question

#217
post #173

Earlier quoted context omitted.

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

Ok, but why do you think you should be hired in that place though? :)

Agreed. It's a great interview question. For a story-telling position.

Re: Bug squash: An underrated interview question

#218
post #183

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.

Or it might just be a totally unrelated layoff that axed a whole team / org / whatever.

Re: Bug squash: An underrated interview question

#219
post #105
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…

Yeah, I've had a live bug squash interview (SSH into a server where a script is not functioning) and I didn't find it particularly fun. I did manage to get through it and the interviewer seemed impressed, but it's still stressful to do it with someone silently judging you. I'd much prefer take-home assignment and do it at my own pace, but I guess that might be susceptible to "cheating" (whatever you consider it being…

Doesn't a take-home task also prevent any chance to ask questions in the middle? And I mean questions both ways. An interviewee can ask questions about the code base that might be common knowledge to people on the team and an interviewer can ask questions about why a thing happened and gain insight into the interviewees thought processes.

I get that interviewing is a skill on its own, and not everyone has skills that work in an interview that transfer to the day-to-day job but don't most day-to-day jobs have a large communication component?

Re: Bug squash: An underrated interview question

#220
post #213

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…

leetcode style interviews discriminate against older workers: older workers don't have time to grind leetcode. they have other obligations outside work. job descriptions require "x years of experience" but then the interviewer dismisses your experience and you get purely evaluated on whether you pass the interview, just like younger people who don't have the experience. I don't know where you've been doing coding int…

> leetcode style interviews discriminate against older workers: older workers don't have time to grind leetcode. they have other obligations outside work.

This isn't discrimination on age this is discrimination on dedication to craft. Young people can have obligations outside of work just as easily as older people.

-- signed an old man

Post reply on HN