Hacker News Reader

Comment by __float | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com