After thinking about it, and getting berated every 2 minutes with "Do you have a solution or not" I gave them a generic overview of what I would do (eg. Brute force would be to do this, a recursive call to obtain these subparts, then memoize those, etc.) but said I could not do it on a whiteboard.
I then met their asshole CTO and got berated for working for the defense industry ("What good have they ever accomplished with technology?" was I think a rhetorical question, not a trick one...) and asked to see myself out. Good god that was the worst interview I ever had.
Anyway, the interviews I have had recently are mostly just talking about specific language details, or HackerRank challenges. Which while sometimes has annoying "gotcha" problems, are mostly FizzBuzz type deals that I can live with.
So I try to imagine myself as the nervous interviewer and stick with basics. Do you know what debugging is? Can you eliminate possibilities? And I try to get a sense for how they approach coding. Keep in mind I have to make a decision after a 30-60 minute phone call, and then a 30-45 minute interview.
Yeah it's super unscientific but my boss would rather we just "talk" to them and hire them just off that. Which explains many of the problems our company has...
If I were asked to do it on my own laptop, it might be way more obvious for me to set up some watches or debug certain lines right from VSCode which I already have set up to integrate with Chrome debugging. That's how I most often debug. I've never learned to use those tools on Chrome directly because it's way more convenient to set a break point from my editor. On someone else's laptop, I'm going to reach for console.log because it's a tool I know is there no matter what the browser and what the dev env is on a stranger's laptop.
I've worked really hard to never use anything that could be a trap when I am interviewing a candidate. I'd rather do a sort of pair coding for 30 minutes and collaborate on solving a problem together.