Item — HN Reader

I've only had one "find the bug" interview, and it was awful:

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

- Didn't have standardized questions, which is hugely problematic (some bugs are 2 orders of magnitude harder than others)

- It also just seems like there's a huge random element, like am I debugging code written by somebody who thinks at the same level of abstraction as me? Did they write comments I understand?

3 comments

> - 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 (some bugs are 2 orders of magnitude harder than others)

How do you know they're not standardized? (You say in another comment where it was, and indeed that's where the blog post author works. It's described as a pretty standardized process by my reading of it.) You can pass the interview without actually solving the bug, but I get it's easier to blame the problem than admit you struggled with it.

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

I once interviewed (and got the job) for a java dev position with a mostly C/C++ background.

One of the issues to solve during the tech interview was fixing a bug in a fairly involved web app with a java backend. Long story short, it boiled down to "==" being used to compare two strings instead of ".equals" somewhere deep in their class hierarchy.

I found it and fixed it, even though I was not familiar with the reference vs value equality difference in java. General debugging skills acquired over years should allow you to track down exactly where things go more wrong than expected, and then help you reason about why it goes wrong.

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.

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.

I seem to interview in a different language every time I switch jobs.

> How frequently do people interview in a language other than their "main" one(s)?

A lot of companies have a set of "standard" interview languages like Java or C++ that may not be used by the role that is being hired for.

> setting up a repo in a language [...] can take a whole hour if it's not your main language.

Even if it is your main language.

Yea there's a huge element of randomness to these kinds of interviews. I wasn't a big fan of them at Stripe. You can get some signal like:

- do they methodically approach the problem? - do they understand the bug? - do they know how to use debugging tools? - do they know advanced debugging tools? - do they work well in an unfamiliar codebase?

But in practice I'd say most candidates check those boxes, at which point it becomes an arbitrary evaluation unless you pass/fail them based on whether they solved the bug.

I gave this interview 100+ times and my criteria boiled down to: did they propose a hypothesis and then follow it to a conclusion? Doesn’t matter if it was wrong, just mattered that they were able to falsify it or find the solution.

At the end, I would have them walk me through the bug, its cause, and the fix in very high level terms to make sure they could articulate the path we took.

As it happens the place I had a really bad experience with it was stripe. I had pretty much aced every other question, but basically was setup with a problem where I didn't have a way to reliably get it running (and I wasn't even clear what the app was supposed to do, it was just some random project off of github).

Fortunately I already had an offer onhand from facebook.

> It also just seems like there's a huge random element, like am I debugging code written by somebody who thinks at the same level of abstraction as me? Did they write comments I understand?

Isn't that part of what professional software engineering is about? Unless you worked with the same group of people for a decade and have had the time to mind meld together professionally, _any_ random developer at a new company is nearly guaranteed to think in a different way and have their own philosophy of code comments.

Checking for mental flexibility and adaptation to varying approaches for others is a great subject for an interview as a software engineer.