Live data from Hacker News

Bug squash: An underrated interview question

blog.jez.io

91–100 of 282 posts

Re: Bug squash: An underrated interview question

#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 familiarity with python / python syntax), and ask them to work through the code and do a code review.

There's some python specific quirks that I largely consider bonus points at best, but anyone with any appreciable familiarity with at least one language should be able to spot a number of things. As they call stuff out, I'll dig in (or not) as seems appropriate.

So far it seems to be working out great for me as an interviewer. Candidates seem to be way less stressed than they are with a "whiteboard coding" exercise. Good discussions are showing me their development skills, etc.

Re: Bug squash: An underrated interview question

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

Would you mind sharing it?

Re: Bug squash: An underrated interview question

#93
post #84
post #81

Earlier quoted context omitted.

I don't know, i think the best questions are the ones where candidates fully understand what is being asked about them. If they aren't able to self-assess did they really understand the question?

Candidates walking away pissed is itself also a problem. A significant percentage of candidates avoid buying from companies they're rejected from [1]. They also love sharing their poor interview experience with future potential applicants. [1] https://www.wayup.com/employers/blog/how-a-positive-candidat...

> A significant percentage of candidates avoid buying from companies they're rejected from [1].

When rejected, or from an otherwise negative experience.

It's not necessarily negative emotional associations. Usually it's that I picked up on signal that the company has serious problems -- either overall, or with a key person -- which suggests I shouldn't depend on the company as a vendor.

Re: Bug squash: An underrated interview question

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

It does seem a bit unfair - ok sure, anyone familiar with C-family syntax should be able to work through it and spot errors. But anyone already familiar with Python would be able to do so a lot faster.

I think the idea is good, but to be equitable it should be given in a language the person claims to be already familiar with. Or alternatively, only give it to people in a language they are not familiar with.

Re: Bug squash: An underrated interview question

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

I'm dying to see this code

Re: Bug squash: An underrated interview question

#96
post #83
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…

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

Re: Bug squash: An underrated interview question

#97
post #53

Triplebyte (one of the best hiring experiences I ever had) gave me this during their initial interview. They dropped an archive of a medium-ish codebase to my machine, that had failed unit tests. My task was to simply fix the code so the tests passed. Not only did I feel engaged with the interview because I could speak aloud as I debugged, I also found it fun!

Too bad that Triplebyte then turned around and decided to sell everyone's data after it turned out their business was not scalable after all.

Re: Bug squash: An underrated interview question

#98
I like this approach. We did something similar, but for a position as support engineer, where coding ability was one of the requirements, though not the only one.

They were given a piece of code on a toy, easy to read, english-like pseudo-language, and were asked to examine it and explain what the output to a specific input would be.

They were told that we would answer any question, except what the answer was or what the code was doing, and encouraged them to explain their reasoning as they went ahead.

We wanted to asses the candidates ability to problem solve, communicate, how would they react under preassure, and how they approached the issue.

We were not necessarily looking for perfect answers, we rather rated the candidates willingness to ask for help when stuck, how well they communicated while doing the task, whether they tried different approaches, their ability to grasp what an unknown piece of code was doing and so on... all important properties for a role supporting mission critical solutions with near to zero down-time requirements.

Our reasoning was that technical knowledge is easy to acquire over time, but problem solving skills, how candidates tackle difficult and unknown challanges were more important for the role.

In my current role I try to design interview questions like that, looking both for the candidates current skills as well as their future potential.

Not easy, but IMHO more rewarding for us and them in the long run.

Re: Bug squash: An underrated interview question

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

As was also pointed out in the TFA, while you may not be "marking people down" because of unfamiliarity with syntax, an interviewee who has more experience with the language (and it's debugging tools) used in the interview will have an inherent advantage over someone who isn't as familiar.

Re: Bug squash: An underrated interview question

#100

I've done the equivalent of this by asking them to describe an interesting bug they've encountered in past lives; how it came up, how they hunted it, how they fixed it. By listening to them describe the work, asking questions, and following their thought processes, you can come to a fairly good hire/no from this single walk-through. I know, it's short and humane, so not a good fit for current Sillycon Valley culture.

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