Live data from Hacker News

Bug squash: An underrated interview question

blog.jez.io

231–240 of 282 posts

Re: Bug squash: An underrated interview question

#231
post #215

Earlier quoted context omitted.

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…

> I would prefer the best

How do you define best, and once you do, how much better than second best are they? What if the best person asks for several million dollars per year (an unreasonably high number as I write this), but the second will accept for $200k (a reasonable number though low if they really are second best). My guess is you cannot tell the difference between the top 20% of programmers in actual day to day work, and probably couldn't tell the difference in an interview.

Re: Bug squash: An underrated interview question

#232
>Cheating is indistinguishable from debugging skill. Even with knowledge of the exact bug ahead of time, if you just open the file with the bug, barf out the code to fix it, and run the tests, you’re going to fail the interview.

Umm hopefully you don't fail for this. I've definitely known and hired devs that can do this with surprising frequency. Just because the interviewer may have taken hours to find the bug doesn't mean someone else must.

Re: Bug squash: An underrated interview question

#233
post #223
post #222

Earlier quoted context omitted.

It is my experience that caution during the hiring process means skipping on possibly excellent people to accidentally prevent hiring a dud. There are plenty of both on the job market most of the time. In practice firing people is hard at most companies, even if there are no laws protecting people in an individual situation. In principle it can be easy but generally a manager who is in a position to evaluate performa…

> This is mostly about risk aversion then gain maximization. I think you meant to say organizational dysfunction. The inability to fire someone obviously incompetent is not risk aversion, it's risk accumulation.

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)

Re: Bug squash: An underrated interview question

#234
post #221

Earlier quoted context omitted.

You should have a mix of developers on any project, some senior, some mid level, some fresh out of school. The senior engineers should devote a significant amount of time to improving the junior. Your mix should skew to junior developers just because some developers will decide to switch to management, selling insurance, or some such. Note that I did not say younger - you will get a few "old" people switching to prog…

Do I really want a mix of programmers on my project? That's a very sweeping blanket statement and you're putting a lot of your beliefs on to other people. The smoothest projects I've worked on were always full of nothing but senior developers. But even though that is just my personal experience I know full well many projects benefit from Junior developers. Sometimes fresh perspective and energy are what you want to s…

For a short time only senior is better. However eventually someone will leave and it takes time to get the new person up to speed. Your seniors will retire and you need juniors trained up and ready to take over. If you are only a short term next quarter thinker you are right, but if you think long term some juniors that you bring up to senior are the better value. (note that this also requires retention of existing people, if your culture is change the team every project there is no value in this - I'm against such cultures, but it is very common in the real world to not value experience on your project)

Of course there is value in bringing in external experts for a short time as well. You don't want to be isolated and not learn from the rest of the world, and of course sometimes you have money for a large project and sometimes you don't and want to fall back the the minimum staff needed to keep institutional knowledge alive.

Last, ignoring everything else, you have a moral obligation to society to build a better world. That includes training the next generation. (and this helps you - when you are retired they will be the senior engineers building the tools to keep you alive)

Re: Bug squash: An underrated interview question

#235
post #212

Earlier quoted context omitted.

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.

Ruby is even worse in my experience, but I guess some people have strange priorities.

Re: Bug squash: An underrated interview question

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

> 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 don't doubt that at all. But I've also had that on a whiteboard.

Also, it sounds like your interviewer was a jerk. Which seems orthogonal to the style of interview.

Re: Bug squash: An underrated interview question

#237
post #149

Earlier quoted context omitted.

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

I thought the point of affirmative action was that being unfair is ok if it is to compensate for a prior unfairness.

We don’t typically do affirmative action by picking interview questions that make things harder for some candidates as opposed to others, though. We consider some questions to be easier for, say, men to answer (“tell me about a time you were asked to demonstrate leadership”) but we seek to remove that bias rather than asking questions that solely focus on things that can only be answered by those who experienced bias (e.g. “tell me about a time you experienced racism that affected your work” is not likely to be an interview question).

Re: Bug squash: An underrated interview question

#238
post #213

Earlier quoted context omitted.

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…

> 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 don't doubt that at all. But I've also had that on a whiteboard. Also, it sounds like your interviewer was a jerk. Which seems orthogonal to the style of interview.

one of his colleagues was similar, so all I can conclude is that this particular FAANG has a higher than average number of jerks

Re: Bug squash: An underrated interview question

#239
post #220
post #213

Earlier quoted context omitted.

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

you can't call 20 years of experience a lack of dedication to craft...
Post reply on HN