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