Hacker News Reader

Comment by pvg | Hacker News Reader

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.

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

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.

Reply on news.ycombinator.com