Comment by kafkaesq | Hacker News Reader

Comment by kafkaesq | Hacker News Reader

Parent Full thread

The point isn't to answer the question correctly. It's to show how you think through the problem.

That's what people always say. Like, as if they actually tell from 1 or 2 of these goofy whiteboarding sessions.

It seems the most they can actually glean from these sessions is, "Huh, looks like their problem-solving approach is different from mine. Plus, they come in not having the advantage of having the solution already ready-baked and laid-out for them, in whatever interviewing guide it was I found this problem. Doesn't that suck for them? Not to mention being under pressure from doing way too many, generally carelessly orchestrated interview tracks (in their non-existent spare time) while being stuck in some job they're anxious to quit. And getting distracted by me diddling with my cell phone while they're doing headstands for me. Gosh, why is it so hard to find decent candidates, these days?"

There is a lot of cynicism about these types of questions in this thread, but I suspect a lot of it is coming from programmers and not data scientists. As a DS candidate I always find these kinds of interview questions a valuable learning experience and a positive challenge. It also provides me some insight into the kinds of problems they're interested in, and the kinds of approaches they use.

When I mean "right approach", I mean that there are several possible approaches, but only one of them is doable in a few hours in the afternoons, where as the others might take a research team and several weeks. Being able to recognize the right approach, and to ask the right clarifying questions, is important for data scientists, in the same way that being able to choose the correct algorithm or data structure is important for (certain types of) software engineers.

Agreed - these questions are definitely more appropriate for research oriented positions. And actually, way more interesting in their own right than most programmer interview questions.

What rubs me the wrong way is when, applying for more or less "standard dev" jobs, one gets asked research-grade questions (i.e. "Solve this cute problem I was fed the solution to recently, either in grad school or in some handout my manager gave me just now. But which was actually an open problem in the literature for 5-10 years before a reasonable solution came down the pipe.")

For a job that ends up being, "Congratulations on making it through our interview process! Now would you mind debugging this {{horribly written X}} that no on here wants to touch with a 10-foot pole? Everyone here has to do 9-12 months of shitwork before moving on to anything interesting here, you see."

Reply on news.ycombinator.com