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

101–110 of 282 posts

Re: Bug squash: An underrated interview question

#101

Post by RomanPushkin »

The only downside I see is that I need to share my screen with a person I don't know. Don't get me wrong, but I normally have access to some crypto on my laptop, banking notifications turned on for my 2FAs, private messages I'm getting from my spouse, maybe some borderline NSFW chatgpt dialogs, screenshots of my ideas, emails, private notes, personal projects, whole bunch of tabs I am not willing to close or share, etc.

I don't have issues to show the screen to a friend of mine. Or showing the screen of a work computer to a colleague. However, demoing the whole screen is violation of privacy. Please don't do that, unless you grant VNC access to a machine with a set of popular tools, code editors, etc.

How about reverse bug squash? Interviewer shares the screen with all his/her private info, notes, tabs, development environment settings, shell command history (with maybe autosuggestions turned on), and the interviewee needs to guide the interviewer towards finding the bug?

Re: Bug squash: An underrated interview question

#102

Post by jpmoral »

__float wrote: post #65
jpmoral wrote: post #23

Had an interview question like this where the interviewers were very impressed. Said it was the fastest and cleanest they'd seen anyone do it, and in an unfamiliar framework no less. Unfortunately it wasn't enough for me to get the job. I had a couple of answers in the next section they didn't quite like.

> I had a couple of answers in the next section they didn't quite like. Could you say more about this? Were they technical or behavioral interviews?

Technical. IIRC:

- I did the system design at the wrong level of abstraction (too low)

- Got asked about lowish-level database details. I took the question at face value and said I didn't know. What I should have done was explain what I did know (which was at a level slightly higher than the question), make an educated guess, and say how I would find the information. I still don't understand why Id didn't do that as I've always done it in interviews before or since.

This is my own assessment, they didn't give detailed feedback. Just that I wasn't strong enough in some areas (paraphrasing).

Re: Bug squash: An underrated interview question

#103

Post by [deleted] »

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…

[deleted]

Re: Bug squash: An underrated interview question

#105

Post by Hamuko »

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…

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

Re: Bug squash: An underrated interview question

#106

Post by aaronbrethorst »

ryandrake wrote: post #5
berikv wrote: post #4

Although I like this interview question, it has a big downside. You make the candidate spend quite a lot of effort while you as an interviewer don’t learn much. The answer to “Can this candidate find and fix this bug?” is not necessarily equal to “Is this candidate a good expansion of the team. What do they bring that we need?”

It's kind of a fizzbuzz-ish weed-out question: If they can do it, sure, you haven't learned that much, but if they cannot, then you know with pretty high certainty that they're not going to add to the team.

Astonishingly, I’ve found fizzbuzz to be a shockingly good weeder question for tech screens.

Re: Bug squash: An underrated interview question

#107

Post by alexvitkov »

mistercow wrote: post #75

> It’s easy for the candidate to self-assess their own progress.⊕ When the candidate isn’t doing well on it, they probably already knew it without needing to be told as much by the recruiter. This is a much better candidate experience than the whiplash of thinking you solved a question perfectly only to realize that the interviewer was looking for something else entirely. Not to say that I think this is a bad type of…

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

Re: Bug squash: An underrated interview question

#108

Post by gecko6 »

I have an interview question:

step 1: the candidate is shown the specification for a method and the results of running the test suite on an obfuscated version of the method. All tests pass. The test suite is minimal, and test coverage is abysmal.

step 2: the candidate is asked to come up with more test cases, based on the specification. The code is run against the updated test suite - most new tests will fail because the method's implementation has several known bugs.

step 3: The un-obfuscated source is provided and the candidate is asked to correct any bugs they discover.

step 4: the changed source is run against a full test suite.

I like this because the candidate's ability to think of test cases, debug, and fix existing code are all tested for.

Re: Bug squash: An underrated interview question

#109

Post by yonrg »

b20000 wrote: post #83
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…

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…

What is wrong with capitals?

Re: Bug squash: An underrated interview question

#110

Post by b20000 »

yonrg wrote: post #109
b20000 wrote: post #83

Earlier quoted context omitted.

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…

What is wrong with capitals?

i don’t need them here, i am not writing a book
Post reply on HN