Hacker News Reader

Comment by jfengel | Hacker News Reader

It's an estimation problem, and programming is full of estimation problems. How many servers will I need? Will I be able to fit this in RAM or do I need an on-disk solution? How long will it take to go from 10 users to 10 million users, and will I be able to scale the design?

You don't need the exact value, just a rough order of magnitude. That's the whole point of the big-O notation. A problem like that is lighthearted, which has the advantage of removing all of the computery specifics that could bog you down in a realistic question. The ability to pull numbers out of your ass quickly, and still have them be within a factor-of-2 of an answer that would take weeks or months to gather, is critical for a developer.

The ability to guess that is also a good indicator of whether you're likely to be a good culture fit.

View on HN

If you want to know how many servers I'd need for a task or to discuss memory/space tradeoffs, then ask those questions outright instead of doing this indirect dance. I don't see how the question gives you an advantage when you're being asked to take skills you use and apply them to domains you don't work in that are irrelevant for the job.

The skillset I have that allows me to accurately estimate software projects is based on my knowledge and experience in that domain, and just because I can estimate there doesn't mean I can estimate tennis balls in a building, nor does being able to estimate tennis balls in a building give any indication of ability to estimate software projects.

Anyone that thinks there's some overlap between estimating software problems and estimating how many tennis balls would fit in the Empire State Building is not someone I'd want to work for.

Sounds like we have an excellent accord, then. I want employees who can think creatively about problems that they haven't seen before. So with any luck, you'll find places who want employees like you, and I'll find employees who match my criteria.

I agree with you, and as such, I suggest simply asking such an estimation problem set in the computing world. It also has the advantage that you can get into discussions of things relevant to computing, like finding out how much they understand about orders of magnitude time like socket communication times to various distances, speeds of disks, etc.

One of the reasons I don't like "how many ping pong balls" etc. is that you're wasting valuable interview time. Interview time should be treated as very valuable to all concerned. Asking about ping pong balls just to find out estimation skills is a waste of time because it doesn't raise any other interesting questions, vs asking an estimation question that raises all kinds of other things you can pick up that are actually relevant in addition to testing estimation skills.

I think there's advantages and disadvantages to either approach. In this case, the thing I like about it is having them talk through their reasoning, regardless of the domain. If it's a domain they're familiar with I get the benefit of their knowledge, but it also takes longer because the specificity raises a lot more questions. If it's an unfamiliar domain, I get a glimpse of their creativity with a problem they haven't previously considered.

If anything, it sounds like "ping pong ball" problems have become cliche. That makes them less useful: it doesn't represent my creativity, and it potentially leads to them reciting rote answers from "cracking the interview" books.

Fortunately, I can come up with a thousand problems off the top of my head. How many letter "e" in the New York Times every day? How many sodium atoms in the ocean? How many people at the Nobel Prize Ceremony?

The more off the wall the question, the more I'm testing how they handle the unfamiliar -- as well as conveying who I am. Which is part of the point. They should be interviewing me as much as I'm interviewing them.

I find it pointless to convince someone who doesn't see the value of thinking about solutions to problems they've never seen before. They will never be pioneers and that's okay, an organization needs both.

If you're implying I don't see value in solving problems I've never seen before, part of my objection is precisely that these "problems" aren't it. They're all the same. You pull 3-5 numbers out of your moderately informed ass and multiply them together. This is not "a problem I've never seen before", it's a problem I've heard a hundred times before. There's no creativity here, it's a dreadfully dull and well-established process.

They are completely 'it', you just don't understand how, and don't even bother to ask why.

These are so cliche that they mean nothing. They're all the same question. Superficially different, but fundamentally three same. There nothing to sink your teeth into, because they're all made up. Asking something with some grounding in reality gives us something to actually chew on.

But hey, ask your silly question about sodium atoms. As for "interviewing you" as well, if you're ever interviewing me and pull one of those out, you better be looking pretty good in the rest of the interview because you just lost a lot of points.

Reply on news.ycombinator.com