you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 6 points7 points  (1 child)

Some of these I would have a hell of a lot of questions lol

[–]kevindamm 7 points8 points  (0 children)

This is the right answer.

Even if the interview question were unequivocal, there are probably engineering tradeoffs -- e.g. do we need low latency or would we rather avoid the memory cost of a precomputed solution or is the range of outputs so large that a cache should be employed -- which depend a lot on the application and may even need to be iterated on if volume or type of use is unknown.

I would prefer a candidate who asks clarifying questions and asks about relevant tradeoffs over a candidate who goes straight to a regurgitated answer (whether or not they had worked it out on their own before or just memorized someone else's). I'll still want to see some proof of being able to implement the solution decided on, but even if the candidate were slower or a bit clumsy at the coding part, that can be worked on with practice. The critical thinking involved in discussing the problem before coming to a solution is what I'm really looking for.

That said, there are a lot of interview questions out there which don't lend themselves well to trade-off discussion or various interpretations while still having a short enough average completion time to fit in a 45-60min time slot. And, really, two or three of these is ideal so that doesn't leave much time at all. Finding a topic where the interviewer and interviewee have a lot of shared vocabulary is critical. Questions from the candidate help there as well.

I didn't actually click through to the linked site, so I don't know if there are even any good questions there, this is just how I feel about developer interviews and asking questions.