5 ms·

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 mea

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.

barbegal 8y ago
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.
- judofyr 8y ago
  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.
  - figgis 8y ago
    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.
    - judofyr 8y ago
      > 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?
      - 0xfeba 8y ago
        I do. I say, I would use the debugger to find the problem, but how would you approach it?
  - deleted 8y ago
    [deleted]
- tchaffee 8y ago
  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.
  - 0xfeba 8y ago
    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. I didn't mean to imply they had to use Chrome.
    - Merad 8y ago
      > 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.
      - tchaffee 8y ago
        There are some details though. If you are using webpack you need to use the right 'devtool' settings to get the source line numbers to match up.
      - 0xfeba 8y ago
        That's a lot more effort than lots of people bother with. At least, from the pool of people we interview. But I have no say in that.
    - tchaffee 8y ago
      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.
- deleted 8y ago
  [deleted]
majormajor 8y ago
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.
- chiefalchemist 8y ago
  Well. If you don't know the code and someone is putting a gun to your head, is the shotgun approach a legit surprise? I hear ya. But it feels like one wrong move and they're out. That doesn't make them bad or untrainanle. Does it?
savanaly 8y ago
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?
- judofyr 8y ago
  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.
  - wild_preference 8y ago
    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.
    - judofyr 8y ago
      > 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.
0xfeba 8y ago
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.
- judofyr 8y ago
  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.
  - tchaffee 8y ago
    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.
  - 0xfeba 8y ago
    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...

barbegal 8y ago

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.

judofyr 8y ago
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.
- figgis 8y ago
  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.
  - judofyr 8y ago
    > 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?
    - 0xfeba 8y ago
      I do. I say, I would use the debugger to find the problem, but how would you approach it?
- deleted 8y ago
  [deleted]
tchaffee 8y ago
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.
- 0xfeba 8y ago
  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. I didn't mean to imply they had to use Chrome.
  - Merad 8y ago
    > 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.
    - tchaffee 8y ago
      There are some details though. If you are using webpack you need to use the right 'devtool' settings to get the source line numbers to match up.
    - 0xfeba 8y ago
      That's a lot more effort than lots of people bother with. At least, from the pool of people we interview. But I have no say in that.
  - tchaffee 8y ago
    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.
deleted 8y ago
[deleted]

majormajor 8y ago

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.

chiefalchemist 8y ago
Well. If you don't know the code and someone is putting a gun to your head, is the shotgun approach a legit surprise? I hear ya. But it feels like one wrong move and they're out. That doesn't make them bad or untrainanle. Does it?

savanaly 8y ago

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?

judofyr 8y ago
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.
- wild_preference 8y ago
  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.
  - judofyr 8y ago
    > 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.

0xfeba 8y ago

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.

judofyr 8y ago
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.
- tchaffee 8y ago
  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.
- 0xfeba 8y ago
  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...