One thing that wasn't touched here is that you can actually map the developer tools to your local files. My old co-worker used Dev tools as his text editor. Pretty nifty!
I implemented two simple interview tests in order to weed out people who can't do simple debugging.
In one, I hand them my laptop and give them a basic create-react-app sample that uses fetch on a remote URL, but there's a typo in the URL. I tell them it's supposed to fetch a remote REST API and parse the JSON but it doesn't work--how would you fix it?
So far, two ways to pass: Just look at the source code, or use the network debugging tools to find the error.
Spraying console.log statements everywhere is a red flag to me. So far, the test seems to work well.
I have a similar interview question, but I have a few layers on top of it, not all of which are required to progress through the interview:
1. Send CSP headers that prevent some of the JS from executing. This is really obscure to most people, but if you look at the console and search the internet for the error, it gives you a good idea. This gets you thinking about the script.
2. Include a simple JS syntax error in the AJAX call. It helps prime them to figure out why the call, once the error is fixed, still doesn't work, rather than having them try to think about the entire front-end as a source for potential problems.
I like to make sure that people are generally guided to the problem to solve, but also to test them along that path. A lot of debugging involves things a few steps/layers removed from the actual problem before you get to the point of solving it, so it's fun to test those steps too, as each can lead you down a wrong/different path.
Those are all good ideas, thanks! I made it super easy, it's an invalid URL. Everything else is setup, but having a few more non-required steps would allow me to be more granular between two otherwise good candidates.
Not so much debugging. Same create-react-app setup, but increment a counter on a button press. The solution is to add an event handler (which requires binding or an arrow function for the right context), and increment a state variable.
That and the debugging example are surprisingly effective at weeding out people who have "React" sprayed all over their resume but can't do one of the most common things.
We had one person who apparently had no fear of "3-1 pair programming with strangers" and instantly came up with the solution. She ended up taking a better offer though. Can't blame her. I wouldn't do as well as she did, and I wrote the damned thing.
Can’t you just ask them if they have experience with the Chrome debugger? And if that’s such a deal breaker for you, you can teach them in the first week? I mean, it’s not like the Chrome debugger is such a complicated beast. Even if you have no experience with it, you can probably learn 90% of the useful tricks in a few hours.
But if they don't know how to use the Chrome debugger then that probably correlates to not being able to do many other tasks. That few hours just teaching them how to use Chrome debugger turns into weeks of teaching them how to do lots of tasks.
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.
I see that knowledge about Chrome debugger probably correlates with knowledge about other tasks, but there has to be some false negatives, no?
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.
They didn't make a simple "if you can't use developer tools X way then I'm not hiring you" statement.
>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.
> What is being looked for is familiarity with the tools you are expected to know.
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?
I don't know Chrome debugger because one of the first things I did was to get VS Code to control Chrome debugger so I can set breakpoints while looking at code with the font and highlighting I'm familiar with.
Weeding out applicants is dangerous if you're not trying hard to disprove first impressions or wrong answers.
If you could explain or show how you connected VS code to act as the debugger for Chrome I would let you and you could use VS code instead. I would also be impressed.
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.
How would I do that when I was handed your laptop? I would assume that's part of the constraints and revert to console.log, like I usually do when it's not my laptop.
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.
I’m one of the contributors to VScode chrome debug.
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
I don't read them as looking for experience with one specific tool so much as a systematic approach vs shotgun just-print-out-everything-everywhere aimlessness.
That's the web developer equivalent of being able to use a hammer as a carpenter, though. That's a bit of an exaggeration but only a bit. Would you hire a carpenter if he couldn't use a hammer effectively? Sure, you could spend a few hours teaching him and probably get him to be good enough to be useful. But would you really rather hire him over someone who knows how to use a hammer if that's the only differentiating factor between the two people?
If you already know that the hammer is the best way to solve it, why wouldn't you ask them to solve it with a hammer? Using the right tool is tricky and there are cases where console.log is more efficient than a debugger:
- 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.
None of those apply to their fizzbuzz-level question.
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.
> I’m guessing you don’t have much experience with front-end code
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.
I prefer console logs to the debugger for the following reason -
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.
You can make a conditional break point, put in arbitray js statements, such as console.log, and return false if you dont want to pause there. Best of both worlds and you dont have to clean up the code after.
I can type `console.log(blah)` into a text file and hit save much faster than I can search for the same file within Chrome right-click and then come up with a working conditional breakpoint dependent on the context around it and type this into a tiny input field.
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.
Edit: I just checked and the latest version of VSCode has LogPoints. Perhaps that means others see room for improvement, too.
I do. I just verify. They can also use Firefox or any other browser's tools if they are more comfortable.
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.
Ah, that's good to hear. Sorry for the rant, and for interpreting you in the most negative way. As I've mentioned downthread, I've just annoyed with silly, definite, interviewing questions that's more like a trap and less like a discussion.
Yep. This sounds like a trap to me. But OP sounds like he's not using it that way. Phew.
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.
I've been through (and hell, am going through) interviews that were stupid trick questions. I distinctly remember one startup in NYC that gave me a simple JS whiteboard question, then some super difficult Google question that required backtracking, memoization, etc.
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...
Right but 'so far' for such a hazing interview setup doesn't say much. You handed the candidate your laptop and a bug they don't know from Adam (is it some tricky shadowed var thing? Weird truthiness thing? It's a dumb typo! But only you know that) and are hovering over their shoulder and harumphing when they start typing 'console.'. Or you tell them they're doing it wrong if they start checking something only you already know is not the problem. This all measures something but it's probably not 'problem solving ability' of the sort that's useful for a web front end programmer.
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.
And significantly faster in many cases if you already know what you're looking for. The Chrome debugger can be painfully slow debugging some of the ember applications in work - I have a video of it taking nearly a minute to respond to keyboard input in a deep stack (The firefox devtools perform a little better on the same codebase).
Ok -- I suppose it's the only bad example I have encountered.
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.
Appreciate the simplicity of the test. With CRA-type debugging, my colleague thought that was how debugging was done with web dev in general (which would have been awesome!) He was fresh out of uni.
A lot of console logging gives you a indicator that the person either doesn't know what is happening or that the person does not trust the CRA debugger.
If (s)he doesn't trust such quality tools by default it is a sign of paranoia. They are too good to doubt as an initial user. It may have flaws, but ir's like doubting your compiler.
It is probably you.
If the person has a lot of logging you should ask hir why.
Lacking experience in a given language is not a real objection to a quality developer. Lacking general programming ability would definitely be.
I would be alarmed if the person was an > medium level dev and did nor know what was up
within 30s. For entry level, it's not as easy. If a person did not find out within 45m, I probably wouldn't hire them.
I really appreciate when people who actually conduct the interviews give honest information about how their decision making process works.
Especially because everyone will hammer the shit out of you and critique your thought process.
Even if you think this paticular criteria is random/inefficient, people are missing a major opportunity to get inside the head of a person who could hire them.
Well, I'm not and (do not want to be) a manager, but I've turned into lead dev of this project after the former lead left (we're friends though so I had a heads up way ahead of time).
But we started this procedure together after just miserable results from "just talking" to candidates. Keep in mind most of the candidates were (and all are now) contractors. We did whiteboarding at first. It didn't seem effective and I hated it anyway. We could only ask very simple things, write a for loop, write any kind of recursive function that counts to 10, etc.
So I setup a project with create-react-app and IntelliJ IDEA. I give a brief intro to the IDE, showing that saved changes are built automatically, and usually reloads in the browser automatically and they just have to worry about the particular fetch call in one case, or adding the code (I don't say event handler) to handle a button press.
The code is 30 lines in one, and 40 lines in the other problem, including braces, imports, etc. I understand how intense interviewing can be but these, to me and our team, are super easy problems.
I've gotten a fair bit of heat for that post, but no real suggestions on how to improve the process.
doesn't the console tell you an error happens when trying to make that request? unless the typo URL is actually a valid URL that returns a 200 response
Ah nice -- yeah we have a similar interview that tests debugging as well so glad to hear other people do it. We have found it really effective as it is a skill that is often overlooked in technical interviews but is something you do on a day-to-day basis. We have it so some tests fail despite the fact they LOOK like they should pass. Props to you for having a practical technical interview :)
The Chrome dev tools are more well-known than that. But I would let them use Firefox, or whatever they want. Even connect VS code or some other IDE to the browser if they wish (as someone else mentioned).
It's really more open ended than everyone here is making it out to be. I was just saying that so far, people open the dev tools or they just notice the URL is malformed in the source code. Or, they just freeze up and can't write a console.log in the right place to begin with.
This is great, besides the Sources tab, I use DOM and Event breakpoints a ton to debug a lot of problems.
Something, I'm not sure if most people know, if you break somewhere (whether event or DOM), you can access the currently in scope variables directly in the console. It's extremely useful for finding out what's going on with something in the middle of hairy code at a specific point in time.
As well as setting breakpoints, one can trigger the debugger by including the statement
debugger;
in a script. Then, having the Dev Tools console open when that statement executes will automatically hop you into the debugger with access to variables in scope, etc. Easier IMO than manually setting breakpoints, especially when working with some transpiled languages.
For transpiled languages: if you set up source maps correctly, you can access the non-transpiled language and the devtools will set up rules on the correct places (in this case, breakpoints, which also jump automatically to the original source instead of the transpiled version)
There's no end to amazement at how great Chrome tools are. When you think "they can't get anything more into them", they throw in additional things. Anything from full-page screen captures to animation profilers. I've yet to scratch the surface of what they have to offer.
And they add new stuff continuously. Once every few months you open DevTools to be greeted with a new What's new in DevTools".
And then there's Safari (I'm on a Mac). I still prefer Safari to Chrome and Firefox. But their DevTools... &-10 years ago their DevTools where best-in-class, putting even Chrome's DevTools to shame. And then they not only stagnated, they regressed. Good luck using any part of whatever the Safari DevTools are anymore.
Give the developer a simple task that is work relevant and 24h.
If the person does it in 5m using some fancy trick, then you know they're a problem solver of high calibre. 1h-5h: They are probably adequate. 24h: junior or bad.
Ask them about the trad offs they made. The 24h guy may not have made any, and may be the perfect maintainer. The 5m guy must have made some. Ask for their reasoning.
It may be the reason to hire them. It may be the reason not to.
How do you know how long it took? Even with the fancy coding screen sharing software? I could have had an important phone call and walked away from the laptop.
Can someone explain why the chrome browser simulator is so bad. I recently had to do some web work, normally don't deal with HTML . Anyways I tried to use the emulate view to test against iOS devices. Had QA test on a real device and it was all wrong. Ended up just getting a virtualbox of osx up to run the stimulator.
Normally it isn't a problem using it but trying to line up slanted designs with pixel perfect placement wasnt working out at all.
My understanding is that Chrome emulates viewports and little more, it doesn't support different rendering engines and such.
You should use it to understand what various mobile devices might look like, great for prototyping, but it doesn't replace physical or truly virtualised devices ( as a service / VMs ) for testing.
Chrome developer tools is just a godsend. Its so much better than any other debugger I've worked with, and miles better than firefox debugging tool
I personally use a chromium based browser called slimjet to do all of my development. It runs off v55 I think which is like 5 versions behind chrome. But its nice to have a dedicated app for debugging.
When I first started developing I would always just go on stackoverflow and ask a dumb question. Now I consult my debugger and it answers everything I ever wanted to know.
Knowing how to use a debugger means I can reverse engineer html/css on any site too, so thats a big bonus.
How is Chrome DevTools "miles better" than Firefox Developer Tools included with Firefox Developer Edition?
I checked your blog to see if you've written a detailed comparison. I saw that your latest blog post is about writing your first user script in 2018, and you didn't use the term "user script"[1][2]; instead, you used the term "Tampermonkey Scripting" as if Tampermonkey originated user scripts. Do you have enough experience with web development to adequately compare Chrome DevTools and Firefox Developer Tools?
This might just be from my own limited experience, but firefox developer tools provides way too much information when inspecting elements on a page. It gets to the point that its distracting. I don't need to know where an element is positioned on the page, I can see it on the page itself. There might be perhaps settings to change this, but the native settings are not to my liking. I also have noticed on the on/off many occassions I have used it in the last 2 years, there is sometimes noticable lag delays when inspecting items. I find the interface much less intuitive as well.
I will argue that firefox does have significantly better support for CSS grid layouts (as it came out with support first), but I don't use that often, and recently chrome unleased these tools in the last year to my knowledge.
I use chrome inspection tools tab for the following purposes now mostly: elements, console, sources, and network. I don't use any of the other tools very often, partially because I don't need too. This is what I mostly compared firefox developer edition tools too.
I've found when I wrote my first stylish extension and just debugging in javascript chrome is just a much more pleasant experience. I have never really run into any problems asides some issues regarding its native RWD tools for handling body margins. Firefox did not have this issue, but this is why I use the linked tool in the above comment
I was aware when I wrote that post that its not called tampermonkey scripting and it was called something else but I didn't remember at the time. Now I know its userscripts :)
I got a bunch of those errors in chrome a year or so ago - turned out I was on a really old version of Chrome (I didn't realise auto-update wasn't working on their Beta stream at the time), and some ssl cert chain configs became stale (or something like that). Updating my browser fixed it.
99 comments
[ 2.4 ms ] story [ 178 ms ] threadIn one, I hand them my laptop and give them a basic create-react-app sample that uses fetch on a remote URL, but there's a typo in the URL. I tell them it's supposed to fetch a remote REST API and parse the JSON but it doesn't work--how would you fix it?
So far, two ways to pass: Just look at the source code, or use the network debugging tools to find the error.
Spraying console.log statements everywhere is a red flag to me. So far, the test seems to work well.
1. Send CSP headers that prevent some of the JS from executing. This is really obscure to most people, but if you look at the console and search the internet for the error, it gives you a good idea. This gets you thinking about the script.
2. Include a simple JS syntax error in the AJAX call. It helps prime them to figure out why the call, once the error is fixed, still doesn't work, rather than having them try to think about the entire front-end as a source for potential problems.
I like to make sure that people are generally guided to the problem to solve, but also to test them along that path. A lot of debugging involves things a few steps/layers removed from the actual problem before you get to the point of solving it, so it's fun to test those steps too, as each can lead you down a wrong/different path.
That and the debugging example are surprisingly effective at weeding out people who have "React" sprayed all over their resume but can't do one of the most common things.
We had one person who apparently had no fear of "3-1 pair programming with strangers" and instantly came up with the solution. She ended up taking a better offer though. Can't blame her. I wouldn't do as well as she did, and I wrote the damned thing.
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
I hear ya. But it feels like one wrong move and they're out. That doesn't make them bad or untrainanle. Does it?
- 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.
Edit: I just checked and the latest version of VSCode has LogPoints. Perhaps that means others see room for improvement, too.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.
A lot of console logging gives you a indicator that the person either doesn't know what is happening or that the person does not trust the CRA debugger.
If (s)he doesn't trust such quality tools by default it is a sign of paranoia. They are too good to doubt as an initial user. It may have flaws, but ir's like doubting your compiler.
It is probably you.
If the person has a lot of logging you should ask hir why.
Lacking experience in a given language is not a real objection to a quality developer. Lacking general programming ability would definitely be.
Especially because everyone will hammer the shit out of you and critique your thought process.
Even if you think this paticular criteria is random/inefficient, people are missing a major opportunity to get inside the head of a person who could hire them.
But we started this procedure together after just miserable results from "just talking" to candidates. Keep in mind most of the candidates were (and all are now) contractors. We did whiteboarding at first. It didn't seem effective and I hated it anyway. We could only ask very simple things, write a for loop, write any kind of recursive function that counts to 10, etc.
So I setup a project with create-react-app and IntelliJ IDEA. I give a brief intro to the IDE, showing that saved changes are built automatically, and usually reloads in the browser automatically and they just have to worry about the particular fetch call in one case, or adding the code (I don't say event handler) to handle a button press.
The code is 30 lines in one, and 40 lines in the other problem, including braces, imports, etc. I understand how intense interviewing can be but these, to me and our team, are super easy problems.
I've gotten a fair bit of heat for that post, but no real suggestions on how to improve the process.
How would you know.
Debugging is about narrowing down the problem until you can isolate it, and ultimately understand the problem to figure out exactly what it is.
It's really more open ended than everyone here is making it out to be. I was just saying that so far, people open the dev tools or they just notice the URL is malformed in the source code. Or, they just freeze up and can't write a console.log in the right place to begin with.
Something, I'm not sure if most people know, if you break somewhere (whether event or DOM), you can access the currently in scope variables directly in the console. It's extremely useful for finding out what's going on with something in the middle of hairy code at a specific point in time.
As well as setting breakpoints, one can trigger the debugger by including the statement
in a script. Then, having the Dev Tools console open when that statement executes will automatically hop you into the debugger with access to variables in scope, etc. Easier IMO than manually setting breakpoints, especially when working with some transpiled languages.And they add new stuff continuously. Once every few months you open DevTools to be greeted with a new What's new in DevTools".
And then there's Safari (I'm on a Mac). I still prefer Safari to Chrome and Firefox. But their DevTools... &-10 years ago their DevTools where best-in-class, putting even Chrome's DevTools to shame. And then they not only stagnated, they regressed. Good luck using any part of whatever the Safari DevTools are anymore.
And specific HTML nodes: https://developers.google.com/web/updates/2017/08/devtools-r...
If the person does it in 5m using some fancy trick, then you know they're a problem solver of high calibre. 1h-5h: They are probably adequate. 24h: junior or bad.
Ask them about the trad offs they made. The 24h guy may not have made any, and may be the perfect maintainer. The 5m guy must have made some. Ask for their reasoning.
It may be the reason to hire them. It may be the reason not to.
Feel free to pay people for being tested.
Normally it isn't a problem using it but trying to line up slanted designs with pixel perfect placement wasnt working out at all.
You should use it to understand what various mobile devices might look like, great for prototyping, but it doesn't replace physical or truly virtualised devices ( as a service / VMs ) for testing.
I personally use a chromium based browser called slimjet to do all of my development. It runs off v55 I think which is like 5 versions behind chrome. But its nice to have a dedicated app for debugging.
One tool that I find I use everyday is this: http://lab.maltewassermann.com/viewport-resizer/. It is WAY better than chromes native responsive webdesign tool.
When I first started developing I would always just go on stackoverflow and ask a dumb question. Now I consult my debugger and it answers everything I ever wanted to know.
Knowing how to use a debugger means I can reverse engineer html/css on any site too, so thats a big bonus.
I checked your blog to see if you've written a detailed comparison. I saw that your latest blog post is about writing your first user script in 2018, and you didn't use the term "user script"[1][2]; instead, you used the term "Tampermonkey Scripting" as if Tampermonkey originated user scripts. Do you have enough experience with web development to adequately compare Chrome DevTools and Firefox Developer Tools?
[1] https://wiki.greasespot.net/User_script
[2] https://en.wikipedia.org/wiki/Userscript
I will argue that firefox does have significantly better support for CSS grid layouts (as it came out with support first), but I don't use that often, and recently chrome unleased these tools in the last year to my knowledge.
I use chrome inspection tools tab for the following purposes now mostly: elements, console, sources, and network. I don't use any of the other tools very often, partially because I don't need too. This is what I mostly compared firefox developer edition tools too.
I've found when I wrote my first stylish extension and just debugging in javascript chrome is just a much more pleasant experience. I have never really run into any problems asides some issues regarding its native RWD tools for handling body margins. Firefox did not have this issue, but this is why I use the linked tool in the above comment
I was aware when I wrote that post that its not called tampermonkey scripting and it was called something else but I didn't remember at the time. Now I know its userscripts :)
CSS basics: https://developers.google.com/web/tools/chrome-devtools/css/
JS debugging basics: https://developers.google.com/web/tools/chrome-devtools/java...
Console basics: https://developers.google.com/web/tools/chrome-devtools/cons...
Finding ways to improve site speed: https://developers.google.com/web/tools/chrome-devtools/spee...