4 ms·

The real problem with that question isn't that it's stupid. Everyone knows it's stupid, it's testing your ability to come up with an estimate in a domain you're

The real problem with that question isn't that it's stupid. Everyone knows it's stupid, it's testing your ability to come up with an estimate in a domain you're not too familiar with using "napkin math". That's a legitimate skill and asset in software engineering. The real problem is that the ability to come up with a good napkin math estimate for a technical problem doesn't correlate with the ability to actually do the job to solve the problem. Ability to estimate doesn't imply engineering/programming skill. You still have to evaluate that part somehow (coding, take home test, github contributions, etc). It also tells you nothing about the candidate's ability to work with others, under pressure, collaborate in a team, and all sorts of other "behavioural" interview questions. Once you spent enough time to evaluate someone's behavioural skills, and also their technical skills, you don't have any time left in an hour interview to evaluate their napkin math skills.

flavius29663 5y ago
Which is why companies started moving into other questions that have no relation to your job, like designing youtube. There is such a slim chance that you'll end up designing youtube at your tenure there, in a team of 2...that it's probably more likely to fill a jet with balls. Yet somehow people are not bothered by the design youtube question the same way they are about balls in a plane. It's true that the youtube version has technologies that are somewhat related to what you'll be doing, but in practice you won't have the opportunity to choose that many technologies for a single product, you'll be a cog in the machine anyway.
- thinkharderdev 5y ago
  Yeah, I think in general people lump Fermi estimation problems in with "brain teaser" questions (which I think really are silly) because they are both technical(ish) interview questions that have nothing to do (superficially) with software engineering.
RHSeeger 5y ago
> The real problem is that the ability to come up with a good napkin math estimate for a technical problem doesn't correlate with the ability to actually do the job to solve the problem. I don't think this is true at all. There have been many times where I've estimated numbers to come up with a "scale" number ... which was important in other ways. How many servers are we likely to need? How many connections per second are we likely to see? How much memory is this likely to take up. Depending on the context in which you need to know the answer, estimating a value can be extremely useful. It can point you towards the right "group" of solutions that you should consider.
FabHK 5y ago
> the ability to come up with a good napkin math estimate for a technical problem doesn't correlate with the ability to actually do the job to solve the problem. You realise that that's a very strong (and probably wrong) statement? Those two abilities are obviously distinct, but quite probably positively correlated. So while there are be better interview questions, the answer to this question tells you something about the candidate.

flavius29663 5y ago

Which is why companies started moving into other questions that have no relation to your job, like designing youtube. There is such a slim chance that you'll end up designing youtube at your tenure there, in a team of 2...that it's probably more likely to fill a jet with balls. Yet somehow people are not bothered by the design youtube question the same way they are about balls in a plane. It's true that the youtube version has technologies that are somewhat related to what you'll be doing, but in practice you won't have the opportunity to choose that many technologies for a single product, you'll be a cog in the machine anyway.

thinkharderdev 5y ago
Yeah, I think in general people lump Fermi estimation problems in with "brain teaser" questions (which I think really are silly) because they are both technical(ish) interview questions that have nothing to do (superficially) with software engineering.

RHSeeger 5y ago

> The real problem is that the ability to come up with a good napkin math estimate for a technical problem doesn't correlate with the ability to actually do the job to solve the problem. I don't think this is true at all. There have been many times where I've estimated numbers to come up with a "scale" number ... which was important in other ways. How many servers are we likely to need? How many connections per second are we likely to see? How much memory is this likely to take up. Depending on the context in which you need to know the answer, estimating a value can be extremely useful. It can point you towards the right "group" of solutions that you should consider.

FabHK 5y ago

> the ability to come up with a good napkin math estimate for a technical problem doesn't correlate with the ability to actually do the job to solve the problem. You realise that that's a very strong (and probably wrong) statement? Those two abilities are obviously distinct, but quite probably positively correlated. So while there are be better interview questions, the answer to this question tells you something about the candidate.