8 ms·

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-

by 0xfeba 8y ago

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.

deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
codezero 8y ago
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.
- 0xfeba 8y ago
  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.
fermuch 8y ago
And what is the the second test?
- 0xfeba 8y ago
  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.
judofyr 8y ago
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.
adrianhel 8y ago
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.
- adrianhel 8y ago
  hir: him/her
  - allannienhuis 8y ago
    'them' works pretty well for this case.
adrianhel 8y ago
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.
hartator 8y ago
Lol, depending on the typo in the URL, I would probably think the service is just down, and it's not part of test.
- brobinson 8y ago
  I would be scared of a service where a 404 response means it's down.
ruckusing 8y ago
Yeah I'd grab the URL and feed it to curl on the command line to start inspecting the HTTP traffic and start from there.
- 0xfeba 8y ago
  You're hired.
ghostbrainalpha 8y ago
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.
- 0xfeba 8y ago
  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.
ramblerman 8y ago
> So far, the test seems to work well. How would you know.
- 0xfeba 8y ago
  We haven't had to fire anyone hired after utilizing it.
augbog 8y ago
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
- 0xfeba 8y ago
  It sure does, they have to open the debugger to find that out though. I do give them the hint that "I would use the debugger".
  - augbog 8y ago
    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 :)
CyberDildonics 8y ago
Sounds like you are weeding out people who don't know how to use the one tool you are using. Debugging is about narrowing down the problem until you can isolate it, and ultimately understand the problem to figure out exactly what it is.
- 0xfeba 8y ago
  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.

by 0xfeba 8y ago

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

codezero 8y ago

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.

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

fermuch 8y ago

And what is the the second test?

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

judofyr 8y ago

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.

adrianhel 8y ago

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.

adrianhel 8y ago
hir: him/her
- allannienhuis 8y ago
  'them' works pretty well for this case.

adrianhel 8y ago

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.

hartator 8y ago

Lol, depending on the typo in the URL, I would probably think the service is just down, and it's not part of test.

brobinson 8y ago
I would be scared of a service where a 404 response means it's down.

ruckusing 8y ago

Yeah I'd grab the URL and feed it to curl on the command line to start inspecting the HTTP traffic and start from there.

0xfeba 8y ago
You're hired.

ghostbrainalpha 8y ago

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.

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

ramblerman 8y ago

> So far, the test seems to work well. How would you know.

0xfeba 8y ago
We haven't had to fire anyone hired after utilizing it.

augbog 8y ago

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

0xfeba 8y ago
It sure does, they have to open the debugger to find that out though. I do give them the hint that "I would use the debugger".
- augbog 8y ago
  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 :)

CyberDildonics 8y ago

Sounds like you are weeding out people who don't know how to use the one tool you are using. Debugging is about narrowing down the problem until you can isolate it, and ultimately understand the problem to figure out exactly what it is.

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