5 ms·

Do recruiters have up-to-date information on the number of piano tuners in NYC? How do they verify the answer?

by rzzzt 4y ago

xyzelement 4y ago
Not at all. It's about you coming up with a framework for how you'd estimate it, and working through it.
necovek 4y ago
It's never about guessing a correct answer. Eg. if I guess NYC population is 10M, with every 100th household having a piano, I can guess there are 100k pianos in NYC. If each of them needs tuning once every two years, that's 50k tunes each year. That's roughly 1k tunes each week, which, if a tuner can do 2 a day (5 work days per week), is 100 tuners. And then it'd be worth comparing to tuning of venue pianos which are tuned more frequently: let's say 10k venues with pianos requiring tuning every month, or 2k tunes a week. So another 200 tuners. You can also talk about pattern of work instead of market demands (eg most tuners only get 1 tune a week, so we can multiply the number of tuners by 10), just to show off you are ignoring other variables knowingly. Obviously, each of the guesses has a large error margin, and errors multiply, so you can be off by way more than a single order of magnitude. But just coming up with things to include in your calculation, and not being scared of exploring such random situations with little data you know, signals some generic problem solving ability. Eg for a better answer, I now know I need exact number of people and venues in NYC, I need to ask tuners how often are pianos tuned, get some data on how frequent are pianos in homes, how long does a tune take, etc. While I think I am decent at these questions, and I do believe they signal a very generic problem solving ability, I agree they are terrible interview questions for most software engineering roles, since you rarely hire for such generic ability, and might even get more out of a more specific question/test..
- Falkon1313 4y ago
  But that still presupposes a whole lot of knowledge about pianos that most people just wouldn't be expected to have. From what percentage of households have them to how often they need tuning to how long it takes to tune one. Unless you're a serious piano nut, you're at best throwing out random numbers, and likely not only don't know the answers, but don't even know what questions to ask. What about peak demand? Do lots of parents also sign their kids up for piano lessons at the start of each school year? Do pianos get played more often during the winter months? It's like the Drake equation - it doesn't matter what factors you choose (you can always come up with more) or what values you assign them (you can't know what most of them would be anyway). It's meaningless as a whole. And also irrelevant to software development or most anything else; at best it would be only very loosely relevant to managing a piano tuning company.
  - necovek 4y ago
    That's exactly what this tests for. I have no idea what those values are! I am still able to make guesses to show that I can figure out a bunch of variables that affect the final value. And since I am multiplying data that's off maybe even by few orders of magnitude, errors multiply as well: I am aware of how erroneous input data affects the results too. Is it relevant to software development as a whole? It definitely is. You've got to provision web workers for new service being developed: you can only (guess)timate number of expected users, you can guess how much CPU time each request will take, figure out cost per unit, look at bandwidth requirements, and make your pick. To improve on your guess, you actually go and measure request times (p50, p99), decide on the number of users you can sustain with your team cost effectively, measure network usage, etc. Or you need to decide on what type of DB to use? Depending on access patterns (read heavy, write heavy, time series...), data size and scalability demands, team familiarity with different tech, you make a guess at what should work: you can only measure after you've got the system exposed to real, live load. Now, I still think it's a bad interview question: people can be perfectly comfortable answering above questions, yet not see that they are in abstract exactly the same as the number of piano tuners in NYC. It tests for that generic and general ability to estimate anything, and to break down any problem. Yet some people get flabbergasted (like you seem to do?), since they think too much about specifics of each of the numbers they use and how wrong they might be. Basically, they have a hard time of letting go of the inaccurracies :) As such, it's a mixture of tests: supposedly only tests you problem breakdown skills, but in reality tests your confidence in using inaccurrate numbers or lack of problem domain knowledge to solve a problem. Which makes it a bad interview question unless both of those is what you want to learn about someone.
    - rzzzt 4y ago
      I have no problem with the question being abstract; my main gripe lies in the first part of your explanation, compounded noise is still noise. Why go through all the mental gymnastics if you yourself are aware that it can be way off? Your next-in-chain-of-command will treat it as hard fact and make a decision or commit to something based on it- then you have all these piano tuners loitering around and nothing to do. It's similar to estimating novel work.

Do recruiters have up-to-date information on the number of piano tuners in NYC? How do they verify the answer?

by rzzzt 4y ago

Do recruiters have up-to-date information on the number of piano tuners in NYC? How do they verify the answer?

xyzelement 4y ago

Not at all. It's about you coming up with a framework for how you'd estimate it, and working through it.

necovek 4y ago

It's never about guessing a correct answer. Eg. if I guess NYC population is 10M, with every 100th household having a piano, I can guess there are 100k pianos in NYC. If each of them needs tuning once every two years, that's 50k tunes each year. That's roughly 1k tunes each week, which, if a tuner can do 2 a day (5 work days per week), is 100 tuners. And then it'd be worth comparing to tuning of venue pianos which are tuned more frequently: let's say 10k venues with pianos requiring tuning every month, or 2k tunes a week. So another 200 tuners. You can also talk about pattern of work instead of market demands (eg most tuners only get 1 tune a week, so we can multiply the number of tuners by 10), just to show off you are ignoring other variables knowingly. Obviously, each of the guesses has a large error margin, and errors multiply, so you can be off by way more than a single order of magnitude. But just coming up with things to include in your calculation, and not being scared of exploring such random situations with little data you know, signals some generic problem solving ability. Eg for a better answer, I now know I need exact number of people and venues in NYC, I need to ask tuners how often are pianos tuned, get some data on how frequent are pianos in homes, how long does a tune take, etc. While I think I am decent at these questions, and I do believe they signal a very generic problem solving ability, I agree they are terrible interview questions for most software engineering roles, since you rarely hire for such generic ability, and might even get more out of a more specific question/test..

Falkon1313 4y ago
But that still presupposes a whole lot of knowledge about pianos that most people just wouldn't be expected to have. From what percentage of households have them to how often they need tuning to how long it takes to tune one. Unless you're a serious piano nut, you're at best throwing out random numbers, and likely not only don't know the answers, but don't even know what questions to ask. What about peak demand? Do lots of parents also sign their kids up for piano lessons at the start of each school year? Do pianos get played more often during the winter months? It's like the Drake equation - it doesn't matter what factors you choose (you can always come up with more) or what values you assign them (you can't know what most of them would be anyway). It's meaningless as a whole. And also irrelevant to software development or most anything else; at best it would be only very loosely relevant to managing a piano tuning company.
- necovek 4y ago
  That's exactly what this tests for. I have no idea what those values are! I am still able to make guesses to show that I can figure out a bunch of variables that affect the final value. And since I am multiplying data that's off maybe even by few orders of magnitude, errors multiply as well: I am aware of how erroneous input data affects the results too. Is it relevant to software development as a whole? It definitely is. You've got to provision web workers for new service being developed: you can only (guess)timate number of expected users, you can guess how much CPU time each request will take, figure out cost per unit, look at bandwidth requirements, and make your pick. To improve on your guess, you actually go and measure request times (p50, p99), decide on the number of users you can sustain with your team cost effectively, measure network usage, etc. Or you need to decide on what type of DB to use? Depending on access patterns (read heavy, write heavy, time series...), data size and scalability demands, team familiarity with different tech, you make a guess at what should work: you can only measure after you've got the system exposed to real, live load. Now, I still think it's a bad interview question: people can be perfectly comfortable answering above questions, yet not see that they are in abstract exactly the same as the number of piano tuners in NYC. It tests for that generic and general ability to estimate anything, and to break down any problem. Yet some people get flabbergasted (like you seem to do?), since they think too much about specifics of each of the numbers they use and how wrong they might be. Basically, they have a hard time of letting go of the inaccurracies :) As such, it's a mixture of tests: supposedly only tests you problem breakdown skills, but in reality tests your confidence in using inaccurrate numbers or lack of problem domain knowledge to solve a problem. Which makes it a bad interview question unless both of those is what you want to learn about someone.
  - rzzzt 4y ago
    I have no problem with the question being abstract; my main gripe lies in the first part of your explanation, compounded noise is still noise. Why go through all the mental gymnastics if you yourself are aware that it can be way off? Your next-in-chain-of-command will treat it as hard fact and make a decision or commit to something based on it- then you have all these piano tuners loitering around and nothing to do. It's similar to estimating novel work.