3 ms·

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, defi

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

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