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

221–230 of 282 posts

Re: Bug squash: An underrated interview question

#221

Post by sqeaky »

bluGill wrote: post #196
b20000 wrote: post #112

Earlier quoted context omitted.

why do young programmers need to pass? nobody gives a shit whether experienced people pass leetcode so give me one good reason why you should rate young programmers differently.

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 solve a problem instead of experience and expertise.

Re: Bug squash: An underrated interview question

#222

Post by sqeaky »

b20000 wrote: post #215
bluGill wrote: post #197

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…

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 performance doesn't also usually have unilateral authority to fire someone. And a technical manager telling someone that this person can't code or is disruptive on a team often can't communicate that to the managers with firing authority. This can be out of hesitance, budget concerns, or legitimate communication skills on either parties count.

So the hiring practices that most of the companies I have worked at tend to skip on possibly excellent candidates in preference of definitely excellent or at least definitely decent candidates. This is mostly about risk aversion then gain maximization.

Re: Bug squash: An underrated interview question

#223

Post by lapcat »

sqeaky wrote: post #222
b20000 wrote: post #215

Earlier quoted context omitted.

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…

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.

Re: Bug squash: An underrated interview question

#224

Post by bawolff »

marginalia_nu wrote: post #123
bawolff wrote: post #82

Earlier quoted context omitted.

> How frequently do people interview in a language other than their "main" one(s)? I would say most of the time. However i still think debugging is a core skill you should be able to demonstrate in languages that aren't your main one.

In Java, would you catch that these two snippets of code do different things? List l = new ArrayList (); l.add(1); l.add(2); l.add(3); l.remove(1); // invokes List.remove(int) System.out.println(l); // [1, 3] Collection l = new ArrayList (); l.add(1); l.add(2); l.add(3); l.remove(1); // autoboxes 1 and invokes Collection.remove(Object) System.out.println(l); // [2, 3] Bugs very often lurk in language specifics. Pytho…

Probably not. However i think (after copius println debugging and lots of time) i'd probably be able to narrow it down to which line the unexpected behaviour was happening. From there i would google the language construct, and hopefully get something useful.

The art of debugging isn't memorizing all the foot guns, its narrowing the problem down enough that you can deal with the foot guns you have never heard of before.

Re: Bug squash: An underrated interview question

#225

Post by fduran »

flurie wrote: post #30

I'm not too proud to admit I took the general concept from https://sadservers.com/ and turned it into something I could use for interactive debugging interviews. I had golden images with some scenarios I wrote myself, and the images automatically shared a tmux session over http so I could follow along without requiring the candidates to screen share. I did have to ask for IPs so I could ensure the machines were just…

Hello, SadServers author here. Zero shame in adapting an idea you found somewhere; I'm super happy you built something useful.

I've thought of adding programming debug scenarios (I even got sadbugs.com lol), may implement in the future.

I'd love to see what you've done, please feel free to connect :-)

Re: Bug squash: An underrated interview question

#226

Post by marginalia_nu »

bawolff wrote: post #224
marginalia_nu wrote: post #123

Earlier quoted context omitted.

In Java, would you catch that these two snippets of code do different things? List l = new ArrayList (); l.add(1); l.add(2); l.add(3); l.remove(1); // invokes List.remove(int) System.out.println(l); // [1, 3] Collection l = new ArrayList (); l.add(1); l.add(2); l.add(3); l.remove(1); // autoboxes 1 and invokes Collection.remove(Object) System.out.println(l); // [2, 3] Bugs very often lurk in language specifics. Pytho…

Probably not. However i think (after copius println debugging and lots of time) i'd probably be able to narrow it down to which line the unexpected behaviour was happening. From there i would google the language construct, and hopefully get something useful. The art of debugging isn't memorizing all the foot guns, its narrowing the problem down enough that you can deal with the foot guns you have never heard of befor…

A good chunk of the debugging skill is just having seen a lot of bugs before, and knowing what to look for based on the symptoms alone. This is an extension of your ability to mentally model the behavior of the code, which is fairly central to any programming activity.

Another part of debugging involves various methods for reducing the size of the haystack, but it's not really realistic to rawdog every bug like that, as that would mean each bug would likely take hours rather than a few minutes.

Any half-experienced Java developer should spot the stink in that code immediately.

Re: Bug squash: An underrated interview question

#227

Post by mrj »

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?

There are lots of good people who are unemployed through not fault of their own. The goal is (as always) to find good candidates. Because many companies have a weird aversion to those not already working, the pool will be stronger by including those with other job histories because it doesn't really indicate who they'll be as an employee. There are great candidates there.

It's just cargo cult hiring.

Re: Bug squash: An underrated interview question

#228

Post by normie3000 »

Izkata wrote: post #206
normie3000 wrote: post #165

Earlier quoted context omitted.

Probably boolean. If you don't see the difference, welcome to Java :D

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.

Re: Bug squash: An underrated interview question

#229

Post by saagarjha »

lapcat wrote: post #186
saagarjha wrote: post #137

Earlier quoted context omitted.

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

What do you think is a good solution?

This is Hacker News I’m on here to complain not find solutions

Re: Bug squash: An underrated interview question

#230

Post by alexvitkov »

mistercow wrote: post #202
alexvitkov wrote: post #107

Earlier quoted context omitted.

"We don't want you to know you've already failed so we can waste your time for a month in the off-chance nobody better shows up."

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 what the interviewer is looking for, that's a terrible interview.

Post reply on HN