Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome developer tools to master

apsdehal.in

Post reply on HN
Print view View original

21–30 of 100 posts

Re: Chrome developer tools to master

#21

Post by wild_preference »

judofyr wrote: post #19
savanaly wrote: post #18

Earlier quoted context omitted.

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…

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 a…

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.

Re: Chrome developer tools to master

#22

Post by degenerate »

dmitriid wrote: post #12

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 Saf…

I didn't know about the screenshot! Found this article showing where it is: https://www.utilitylog.com/full-page-screenshot-chrome/

Re: Chrome developer tools to master

#24

Post by judofyr »

figgis wrote: post #20
judofyr wrote: post #17

Earlier quoted context omitted.

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 solv…

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 co…

> 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?

Re: Chrome developer tools to master

#25

Post by judofyr »

wild_preference wrote: post #21
judofyr wrote: post #19

Earlier quoted context omitted.

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 a…

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 som…

> 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.

Re: Chrome developer tools to master

#26

Post by 0xfeba »

codezero wrote: post #6
0xfeba wrote: post #3

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 th…

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 t…

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.

Re: Chrome developer tools to master

#27

Post by adrianhel »

0xfeba wrote: post #3

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 th…

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.

Re: Chrome developer tools to master

#28

Post by adrianhel »

adrianhel wrote: post #27
0xfeba wrote: post #3

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 th…

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…

hir: him/her

Re: Chrome developer tools to master

#29

Post by bryanrasmussen »

judofyr wrote: post #19
savanaly wrote: post #18

Earlier quoted context omitted.

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…

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 a…

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.

Re: Chrome developer tools to master

#30

Post by 0xfeba »

judofyr wrote: post #14
0xfeba wrote: post #3

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 th…

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.

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.

Post reply on HN