I have nothing against teaching new hires but for some businesses it is a significant cost so it makes sense to weed out applicants that won't be able to get stuck in straight away without a holding hand.
Weeding out applicants is dangerous if you're not trying hard to disprove first impressions or wrong answers.
I didn't mean to imply they had to use Chrome.
There's nothing to it, most people just apparently don't know that it's possible. Chrome, Firefox, and I assume all the major browsers support remote debugging, your IDE just need to know how to send them commands. All you need to do is install the Chrome/FF debugging plugin and click 'Start Debugging'. A settings file should open for you to configure the url to launch.
Good interviews are hard to design. You have to be super careful that you are testing for what you really think you are. I've let people use their own laptop, search for answers, use StackOverflow, and ask me questions. Just like we all do in real life.
If someone used vscode to debug chrome in an interview and explained how the debugger itself is a dumb extension that translates JSON RPC based vscode debug protocol to JSON rpc based chrome remote protocol under the hood, I would be super duper impressed.
Although console.log isn’t a terrible debugging strategy.
My first thing to learn in any language is how to do a printf
And mostly I find it a bit dishonest. If you have a preferred way to solve a problem in a company you should state it up-front: "Find this bug by using the debugger, not console.log, because that's the way we do it here". If the method does not matter, you should let they solve it their own way and see how efficient they are.
> I have nothing against teaching new hires but for some businesses it is a significant cost so it makes sense to weed out applicants that won't be able to get stuck in straight away without a holding hand.
Right, and that will show when they use so much time adding console.log everywhere without finding the bug. Measure the time and understanding of the problem/code/solution, not the tool.
>So far, two ways to pass:
Would mean that they understand there are a hundred different paths to solve a simple problem. What is being looked for is familiarity with the tools you are expected to know. And littering a shit ton (not just a simple "Started-HH:MM:SS.mmm" or "Stopped-HH:MM:SS.mmm" with timestamps) of console.log statements when you first start debugging is a pretty fair red flag.
Right. So just tell them straight out that "hey, can you show us how you would use the Chrome debugger to solve this?" instead of making a trap out of it?