Live data from Hacker News

Bug squash: An underrated interview question

blog.jez.io

121–130 of 282 posts

Re: Bug squash: An underrated interview question

#121
post #108

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…

This has failed me because code get pretty gnarly fast, many things I thought was obvious was missed by people smarter than me. I think as long as it is a tool for discussions rather than grades it is good though.

Re: Bug squash: An underrated interview question

#123
post #82
post #54

Earlier quoted context omitted.

> - Didn't set you up with a way to reliably run/test the code, nor a step-through-debugger which, jeez is it 1980? Like setting up a repo in a language you aren't familiar with (say getting your py-env exactly right) can take a whole hour if it's not your main language. How frequently do people interview in a language other than their "main" one(s)? > - Didn't have standardized questions, which is hugely problematic…

> 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. Python has its infamously static default arguments as an analogous quirk.

Re: Bug squash: An underrated interview question

#124
post #51
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?”

The point of the interview is not to answer "Can this candidate find and fix this bug?" but rather "what is the candidate's approach to fixing unknown problems?" A good performance looks like making a hypothesis for where the bug is, testing that hypothesis, and repeatedly narrowing in closer and closer. Finding and fixing the bug is irrelevant! A bad performance might look like - running out of hypotheses for what m…

So like trial & error? Modify, compile, run?

Re: Bug squash: An underrated interview question

#125
post #109
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?

NOTHING BUT THERE'S ALSO NOTHING WRONG WITH LOWERCASE

Re: Bug squash: An underrated interview question

#126
post #120

Earlier quoted context omitted.

not wrong per se, but they take longer to type than lowercase

Wait, what?

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.

Re: Bug squash: An underrated interview question

#128
post #112
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.

Just because people in group A are treated badly, that's favoring group B, doesn't mean it's reasonable to do the reverse.

Re: Bug squash: An underrated interview question

#129
post #119
post #118

Earlier quoted context omitted.

A) I, and a lot of other people, do give a shit whether experienced candidates pass leetcode, and try not to give leetcode interviews unless forced to by HR fiat B) As an industry and as a society, it's not a good thing to refuse to hire new grads, since that leads to the kind of labour shortages we see in e.g. medicine and pulls up one of the best ladders for wealth mobility. Tech therefore needs some kind of funnel…

it’s not a good thing to refuse to hire older people and most older people do not pass leetcode without significant grinding

Yeah my first response to 99% of these kind of interview questions is why? I look at ROI and how working code impacts budget and investment. It pains me to say it but the biggest companies out there have horrible code in COBOL that frankly doesn’t make sense to change it over. Similarly bug squashing usually is how did it pass QA/static analysis/dev ops.

Re: Bug squash: An underrated interview question

#130
I am quite skeptical of item 6 in this list, but otherwise it looks pretty good:

> Cheating effectively is indistinguishable from debugging skill.

If you know the code or problem ahead of time and how to fix it, you can certainly be convincing in your walk-through of how to do it.

Post reply on HN