Chrome developer tools to master
apsdehal.in
apsdehal.in
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.
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.
[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.
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.
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...
As well as setting breakpoints, one can trigger the debugger by including the statement
debugger;
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?
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 :)
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...
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.
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.
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.