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

191–200 of 282 posts

Re: Bug squash: An underrated interview question

#191

Post by sethammons »

0x20cowboy wrote: post #38

If you can’t sit down with someone, have a simple tech conversation with them and be able to tell if they know what they are doing… if you need to “give someone a test”… the problem is likely not the candidate.

We tried this approach. It did not work. Source: SendGrid while ramping up to become a public company. The interviewing experience involved was fairly extensive; I had probably given a couple hundred interviews in my career by then and I was not the most experienced by a long shot.

We tried to have a zero coding interview. All behavioral and experiences questions followed up by "how would you design a system to do blah." Got a candidate that did well. Hired. Turned out they could talk the talk but not walk the walk. It was wildly unexpected. They simply couldn't code well. Too long to deliver, too poorly written, usually didn't work right. We insisted on _some_ coding in interviews going forward

Re: Bug squash: An underrated interview question

#192

Post by janaagaard »

I agree. The best interview experience that I had was to be sat in front of a small app that had lots issues, both big and small, and also a lot an not-really-issues-but-still like inconsistent code styles and names, and code comments and code that weren't aligned. This was a great starting point for both me and the interviewer. The interviewer had a list of things to ask into about the code, so that we didn't get stuck.

Re: Bug squash: An underrated interview question

#193

Post by playingalong »

StefanBatory wrote: post #179
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…

Isn't that what companies would look for, though? They want people who can work under stress. If you had two equal programmers, and one who was stressed and the second who was not, any company would pick the second one without thinking.

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.

Re: Bug squash: An underrated interview question

#194

Post by hkon »

xgb84j wrote: post #154
Twirrim wrote: post #91

My favourite thing to do for "coding" interviews is to give the candidate a piece of absolutely awful python code that a friend of mine came up with for use for interviews. There are code smells, side effects, errors, confusing syntax, a whole slew of things in it. I give them the code, tell them I'll help with every bit of python syntax (and really emphasise that I don't mark people down _at all_ for any lack of fam…

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…

Ever get the answer: this code should not exist?

Re: Bug squash: An underrated interview question

#195

Post by StefanBatory »

playingalong wrote: post #193
StefanBatory wrote: post #179

Earlier quoted context omitted.

Isn't that what companies would look for, though? They want people who can work under stress. If you had two equal programmers, and one who was stressed and the second who was not, any company would pick the second one without thinking.

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.

Re: Bug squash: An underrated interview question

#196

Post by bluGill »

b20000 wrote: post #112
ta_1138 wrote: post #96

Earlier quoted context omitted.

I administered bug squash questions a few dozen times. Experience definitely trumped the smartest, most prepared young programmers, because no matter how much they studied, they hadn't really faced a real test suite in a large codebase. We had to rate them on a different scale, because otherwise very few of them passed.

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 programming as well, and they start off as junior.

Re: Bug squash: An underrated interview question

#197

Post by bluGill »

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?

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 different questions for different levels. You should know if you are hiring a junior, mid, or senior engineer. (you may have different levels), and ask them different questions.

Re: Bug squash: An underrated interview question

#198

Post by bluGill »

johnisgood wrote: post #133
saghm wrote: post #126

Earlier quoted context omitted.

Per letter, capitalization doesn't take much longer, but over the course of an entire sentence or paragraph, having to reach for shift can potentially add up. Sure, it's still small overall, but I think it's reasonable to give the benefit of the doubt to a stranger about whether the extra effort for them to type them is more than the amount of extra effort for you to read it.

It doesn't take longer for me as I have both of my hands on my keyboard and I can hold the Shift without any delay (or noticeable delay), simultaneously. You could even use "caps lock" in which case you wouldn't have to use shift at all.

The shift key is an uncomfortable stretch for my fingers. I can do it, but it isn't comfortable.

Re: Bug squash: An underrated interview question

#199

Post by bluGill »

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…

I've interviewed a few people who have a great resume and came off well in the interview, but I was left wondering if they could write code. (HR only allows me to ask specific research based questions in an interview and so it is easy to answer well without giving any indication you can write code). We now have some filter exercises that are about if you can write code at all.

Re: Bug squash: An underrated interview question

#200

Post by lapcat »

bluGill wrote: post #197
lapcat wrote: 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…

> If the above doesn't answer your question

You misinterpreted my question, because I was asking what saagarjha thinks, not what anyone else thinks.

Post reply on HN