Hacker News Reader

Comment by 0xfeba | Hacker News Reader

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.

View on HN

I've written debuggers, and I still use console.log quite often. I would be pretty annoyed if I were silently judged on my choice of debugging tool.

This right here, I use both. Sometimes I like to just "debug by writing code to get more information"

Ok -- I suppose it's the only bad example I have encountered.

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.

if they resort to console.logs, they are just randomly trying things.

How does that follow? It's just another way to check the state of a program at a given point.

so far

That is, the people who start entering in console.logs, are entering them in in random places, not really troubleshooting.

Right but 'so far' for such a hazing interview setup doesn't say much. You handed the candidate your laptop and a bug they don't know from Adam (is it some tricky shadowed var thing? Weird truthiness thing? It's a dumb typo! But only you know that) and are hovering over their shoulder and harumphing when they start typing 'console.'. Or you tell them they're doing it wrong if they start checking something only you already know is not the problem. This all measures something but it's probably not 'problem solving ability' of the sort that's useful for a web front end programmer.

Yeah, a 25 line debugging question and a 25 line react .setState() question are far from hazing. See my other comment for a good example of hazing:

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.

And significantly faster in many cases if you already know what you're looking for. The Chrome debugger can be painfully slow debugging some of the ember applications in work - I have a video of it taking nearly a minute to respond to keyboard input in a deep stack (The firefox devtools perform a little better on the same codebase).

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.

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.

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

What's up with Console.log?

Reply on news.ycombinator.com