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