Bug squash: An underrated interview question • Hacker News Board

Re: Bug squash: An underrated interview question

#241

Post by nailer » Wed, Aug 21, 2024, 5:50 PM UTC

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…

> It may be fun on the job or at home, but the stress of a job interview both eliminates any "fun" aspect and makes even simple tasks more difficult.

Suggestion here: leave the room and come back in 40 minutes. Let them debug, fix the problem, and present to you when they're done.

Re: Bug squash: An underrated interview question

#242

Post by nailer » Wed, Aug 21, 2024, 5:56 PM UTC

whatever1 wrote: post #169

xgb84j wrote: post #154

Earlier quoted context omitted.

Great idea, that's exactly what I like to do as well. Because many people were interested in some actual code, here is an example that we used for Java: --- public class UserDao { private Provider sessionProvider; public UserDao() { this.sessionProvider = new DbSessionProvider(); } public boolean saveUser(User user, ApiConfig config) { try { Session session = sessionProvider.get(); session.save(user); System.out.prin…

"Don't write to stdout but to a logger." Not great advice given the fact that a logger paged pretty much every SDE on this planet.

That's the intention. So people see the messages.

That said, modern Linux OSs send stdout to journald by default. journald should forward to some centralized logging server.

Re: Bug squash: An underrated interview question

#243

Post by lapcat » Wed, Aug 21, 2024, 6:09 PM UTC

bluGill wrote: post #233

lapcat wrote: post #223

Earlier quoted context omitted.

> 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 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, so there's still no justification for the so-called "risk aversion" of the interviews.

I guess I'm not sure why you responded to me rather than to squeaky.

Re: Bug squash: An underrated interview question

#244

Post by Borg3 » Wed, Aug 21, 2024, 6:15 PM UTC

IshKebab wrote: post #235

Borg3 wrote: post #212

Earlier quoted context omitted.

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.

Hehe.. Well, most importand is, use whatever language that makes you happy using it. I ve started using Ruby around 2006 I think. I was evaluating Python too, but syntax annoyed me and portability issues as well back then. I never regreted that I choosed Ruby. Its just solid for me :)

Re: Bug squash: An underrated interview question

#245

Post by whatever1 » Wed, Aug 21, 2024, 6:19 PM UTC

nailer wrote: post #242

whatever1 wrote: post #169

Earlier quoted context omitted.

"Don't write to stdout but to a logger." Not great advice given the fact that a logger paged pretty much every SDE on this planet.

That's the intention. So people see the messages. That said, modern Linux OSs send stdout to journald by default. journald should forward to some centralized logging server.

It's an extra dependency. But I guess we will never learn. Just import log4j and pray.

Re: Bug squash: An underrated interview question

#246

Post by sqeaky » Wed, Aug 21, 2024, 7:06 PM UTC

b20000 wrote: post #239

sqeaky wrote: post #220

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. 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...

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 who don't practice? Maybe in some jobs I do maybe in some jobs I don't.

If someone really does have 20 years of experience then a single evening of practicing will do a lot more for them than it will a fresh faced kid from college even if that kid from college does it for two or three hours every day for a week.

I just simply don't accept the notion that leet code interviews favor people based on age.

Re: Bug squash: An underrated interview question

#247

Post by sqeaky » Wed, Aug 21, 2024, 7:14 PM UTC

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…

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 rules and makes an otherwise functional organization seem dysfunctional. Interviews might not be able to tell you if someone is excellent but some terrible people will absolutely reveal their cards. Most of the time there is an unlimited pool of applicants so even if an excellent one is passed up there will be another decent one somewhere. Not every job needs excellence some just need a baseline competence and an ability to be a team player.

These and other factors add subtle weight to risk aversion.

Also, difficulty in firing people doesn't automatically mean organizational dysfunction, sometimes it's an attempt at preventing abusive management. 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.

Re: Bug squash: An underrated interview question

#248

Post by sqeaky » Wed, Aug 21, 2024, 7:18 PM UTC

bluGill wrote: post #234

sqeaky wrote: post #221

Earlier quoted context omitted.

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 p…

A lot of these are good points and need to be taken into account. But not every team persists, or even intends to persist. Not every developer is suitable for training others.

I've been on Plenty of teams that formed and disbanded in 3 months, we had a goal of building a prototype and turned it over to the customer. Just isn't a great place for new devs. Alternatively, I worked at slow and steady insurance companies that had all the appropriate processes for risk aversion in place and were great places to teach new devs. They let them stretch their wings knowing that they would be protected by good CI and good unit tests and other defensive practices at an organizational level.

Not every team needs every sort of skill or skill level. It's a judgment called each team needs to make, and some teams will decide wrong.

Re: Bug squash: An underrated interview question

#249

Post by mistercow » Wed, Aug 21, 2024, 7:22 PM UTC

alexvitkov wrote: post #230

mistercow wrote: post #202

Earlier quoted context omitted.

What an incredibly bad faith reply. Candidates should always be given an answer within a few days of finishing the interview. But it’s not good for a candidate to think they’ve bombed during the interview. If someone fails my interview, it is completely possible that they’ll still get an offer. I have one data point, and my colleagues are going to collect more. I’ve changed my vote from no to yes in debriefs many tim…

Nope, this is as straight forward as it gets. There are only two ways not to know if you're failing or acing an interview: 1. You don't know what metrics you're being judged on. 2. You do know but you either can't assess your abilities in said metrics or you can't tell how well you've presented them. The second one is up to the candidate, not much you can do about that, but if during an interview you have no idea wha…

There is a vast distance between “accurate self-assessment” and “no idea what the interviewer is looking for”.

I’ve already explained why I think obscuring poor performance to preserve candidate confidence is crucial. If you think that’s a “terrible interview”, maybe you could elaborate on why, rather than just asserting it.

Re: Bug squash: An underrated interview question

#250

Post by Hamuko » Wed, Aug 21, 2024, 7:43 PM UTC

sqeaky wrote: post #219

Hamuko wrote: post #105

Earlier quoted context omitted.

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…

>Doesn't a take-home task also prevent any chance to ask questions in the middle?

Probably yeah. I don't remember my last take-home assignment having communication between the start and the end, although I would have probably been able to send them a question if there was something unclear.

>don't most day-to-day jobs have a large communication component?

I wouldn't know if mine has a "large" communication component, especially in terms of synchronous communication, since everyone's remote, choosing their own hours and so on. A lot of our work is very independent.