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.
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?
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
- It's a debugger you're not used to
- The stack/application is complicated and works weirdly with the debugger (e.g. exceptions are captured and stack traces are lost)
- Many things are happening at the same time so it's quicker to scan through 100 lines of output than stepping through 100 breakpoints.
I know how to use a debugger, but I also know how to console.log in such a way that I can quickly scan the output, or output a DOT file so I can visualise the flow and data as a graph.
I’m guessing you don’t have much experience with front-end code if you think this is Chrome tooling specific.
It’s really the equivalent of reading a stack trace to get an idea of where to look instead of wolf-fencing off the bat with println. “I would’ve read the stack trace if I knew you wanted me to!” wouldn’t be a good defense, likewise.
Yes, you can teach someone to read stack traces on the job. If-statements, too. And how to write their first function. But that’s not the skill level you’re always looking for.
Okay. You're guessing wrong.
I'm just asking for a bit honesty here. If they start adding console.log everywhere, how about you ask them why they're doing it that way? In a codebase I know nothing about it's not uncommon for me to add some console.log around to see how the code flows. Adding breakpoints isn't efficient when it's being hit 100 of times; reading console.log output can be done quite quickly.
Maybe I'm misunderstanding the original test, but I'm just tired of playing these games where a person asks me a question and they're holding off important information that they will use to judge me.
And your console.log example is valid, but this isn't the same situation. It's a button press, the fetch call is made.
I tell them what it should do, I say I would use the debugger but ask them what they would do.
I tend to know about where the problem is. I've been working on this code, I know it's a couple things that could be breaking it in the way it's breaking. I prefer to console.log those things because I find stepping through code tedious, though I understand some people would prefer to use the debugger.
If on the other hand it is code I don't know anything about I guess I would probably say well I guess I should set a breakpoint.
That said, because I find stepping through code tedious I will often use console log statements when I should use the debugger because I am apt to think oh I will know the answer with just another try. Thus I can end up wasting my time by using too many console log statements.
Finally this situation is also affected by the problem of specialized debugging tools for particular frameworks. I hate learning tools. I have to click on things etc. I like learning languages.
If there was a debugging environment that was a specialized console with a particular api to interact with the code I would learn it.
I don't mean a debugger statement before anyone suggests it.
If you understand the code and are currently writing it, it's almost always faster to debug with a `console.log`[0]. This seem to be the case whether you are coding in a browser or running unit tests: reaching for the debugger is slowwww.
To me, the debugging experience everywhere seems broken. Why is the only tool we have a breakpoint? What if I don't want to 'block' and just want to mark a point in the code which I want to capture a selection of information about? Why not let me visualise or filter these points, and then click through to see the callstacks and the state that was collected?
The whole DX seems to be built around the premise that I want to laboriously step through when I debug. While in 99% of cases as soon as I see some values I instantly know what I have done wrong.
The only times I normally use a debugger are when debugging problems on production sites, or when debugging complex problems in other people's code.
[0] This might not be the case, if your IDE is extremely
well-integrated with your text editor to the extent that you
can add breakpoints as easily as you can add log statements.
let b = new BreakPoint();
let start = codebase.find('let creditrating');
let end = codebase.find(functionExit('chanceToPurchaseSet'));
let report = new Reporter();
report.preamble = 'line ' + start.lineNumber + ' in file ' + start.codeFile;
report.ending = '-------------------';
report.bindTo(b.reports);
b.reportOn(['undefined','null',b.error]);
start.setBreakpoint(b);
start.runUntil(end);
with of course requisite functionality to do stuff like save scripts, run a saved script, history of reports etc.
on edit: improved formatting
We are not hiring junior devs, and even if so I would still probably ask. But experienced front end devs should know how to use a browser's debugger.
Like others said, it's a flag that they potentially don't have problem solving skills. I mean, if they put a single console.log near what they think is going wrong and find the issue, I wouldn't dismiss them so easily.
It's just that so far if they resort to console.logs, they are just randomly trying things.
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.
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...
How does that follow? It's just another way to check the state of a program at a given point.
That is, the people who start entering in console.logs, are entering them in in random places, not really troubleshooting.
https://news.ycombinator.com/item?id=17495049
In any case, unfortunately it's something I have to do. And these are the 10% of people that pass a phone screen. We have too many unqualified candidates coming in. As I mentioned in another question -- I have no control over the pool of candidates we get. I'm sure it does screen out people who don't do well under pressure, but oh well, as long as the people who make it through can work on the team I'd say it works.
If you have a better way I can implement within a 30-45 minute in person interview, I'm all ears.
To put it another way, if the candidate just starts changing completely unrelated stuff, and continues to after I say "that's not the issue, think about XYZ." That's a red flag.
I hear ya. But it feels like one wrong move and they're out. That doesn't make them bad or untrainanle. Does it?