When the hell would you ever need to know that? Do you ask carpenters how many times their screwdrivers spin per minute? It just seems like useless trivia.
> When the hell would you ever need to know that?
I find this such a strange perspective. You're writing code for a computer. Sometimes you need to estimate how quickly it should run, or else estimate how quickly it could run with optimal code. Surely it's obvious that knowing how fast your computer does stuff, at least within 3 orders of magnitude, is a necessary ingredient to make that estimate.
And yet in your mind that fundamental fact is "useless trivia." Very odd.
The reason is that things today are "fast enough." These days most slowdowns aren't the result of the CPU not executing instructions fast enough. Other factors dominate, such as memory access patterns, network delays, and interfacing with other complex software such as databases.
Unless you are doing compute-heavy code, the speed of the CPU isn't much of a factor in estimating how fast the program will run.
I'm having trouble believing that people who think a CPU can do thousands of instructions per second will do well at this (or reasoning about the memory hierarchy).
You may as well ask any other sort of technical trivia question and figure the people that happen to carry around more random facts about tech are more likely to understand the bigger things that do matter. It isn't necessarily wrong it's a pretty obtuse way to make a judgment. Why not just ask them about the memory hierarchy or network delays or whatever directly?
Anyway, my answer to the question would be, "a lot". You need to know the specifics of workload and cpu to be more precise.
I personally have no idea and it's the one computer I use most frequently.
That said, when I started using computers, my first machine ran at 897 Khz on an 8-bit CPU, and had 16k of RAM. I was 11 years old, and this was a pretty standard machine for the time, unless you had real money (and even there, on the top end - not counting minicomputers or mainframes - you'd be lucky to break 8 MHz and a meg of RAM).
But I know I am of a different era. And honestly, I've stopped caring about CPU speeds too, because lately they don't change much (top end is about 4-5 GHz per core; servers can have around 32 cores - though that is increasing too).
What should be cared about is memory usage per process, and how the software you are using (or which multiple people are using) delegates that out. For instance, with PHP (not sure with PHP 7) you have one process per user, and depending on how much memory those processes take, will ultimately lead to an upper limit on the number of users that can be served at one time. In that case, knowing your memory usage and constraints of the server could be very important (there are a ton of other factors to consider as well, I know).
Which really just demonstrates the point, I think. At some point things are "fast enough" that it just doesn't matter. We've reached that point with computers. Unless you are working in a niche field that needs serious compute, the sources of performance problems are almost never going to arise from issues like trying to execute too many add instructions in a given period. The delays will come from things that are significantly harder to see - network, database, or program architecture + runtime.
...and 640K will be enough for everyone!
He's more focused on the design and craftsmanship of the bookshelf, because he's built many excellent bookshelves to industry standard effectiveness in the past and measuring the number of screws he can turn in a second hasn't been relevant to the work.
> How many nails does it take to build a house? a) hundreds b) thousands c) millions d) billions
> How many rooms are in a house? a) tens b) hundreds c) thousands
> How thick is a house wall? a) inches b) feet c) miles
What I mean is that -- thanks to all the programmers of yesteryear -- most programmers operate at a much higher level of abstraction when building anything that big.
Apparently some people take whatever warm body shows up.
It would only be valid not to hire them if they have already taken measurements and noted them down. If they can't do the calculation to convert their measurements to square footage and then to linear feet of board (with margins to allow for different board widths) - that'd be something different.
Even there I would argue one could still say "I don't know", simply because you haven't specified how you want the flooring oriented per room/area (and if it goes on the bias, it gets tricky quick), or if there is any kind of special patterns or inlays you want, etc.
Until you have the full specification at hand, you can't really give more than a ballpark answer, which in the case of flooring calcs could be wildly off (agile doesn't really work for real-world engineering like it can for software).
Likewise, for the original question, I'd expect some sort of discussion or nuanced answer. Something like, "Well, most modern CPUs are rated at the GHz, so on the basic level, we can say on the order of billions of operations - but we're getting a lot more cores, and given SIMD and such, you could actually go an order of magnitude or two over that, in theory. But if you are doing something that takes lots of clock cycles, it could drop down into 100s of millions, I suppose."
What you don't want to hear is a deranged ranting, like some people are doing in this very thread, or "I dunno" and a blank stare.
And again, none of that knowledge is relevant or required to be very competent at web development.
The equivalent question to a web developer would be how many lines of code would it take to make a bare bones site with a calculator in it? 1,000? 10,000?, 100,000? Options A and possibly B (with explanation would be acceptable).
Your question (although you don't seem to feel this way) is the equivalent of asking a carpenter: How many Watts of power will you consume while finishing this room? A carpenter who knows that may show lots of curiosity about their tools, but there are also plenty of skilled carpenters who don't know the answer to that.
Your interview question is more asking "How similar is this person to how I approach things?" than "How skilled is this person at doing their job?"
(1) because "it is faster" and "my dad always did this" and "you don't pay for my saw, so shut up"
They do make such blades for angle grinders; they tend to be "universal" blades to cut wood, metal, and ceramic/brick. There are also "chain" blades, which are meant for high-speed carving of wood (they look like a chainsaw chain wrapped around a circular blade).
Likely, if you really wanted to do it and had nothing else handy, a cutoff blade would probably cut wood just fine (take care to watch for too much friction, though). Alternatively, a circle of file folder paper chucked in would work as well.
Usually I can guide them to understand where the bottleneck is, but every so often I have to rewite it so performance is acceptable.
I would absolutely ask a carpenter how quickly he can complete a project, and I would hope he has a realistic first order approximation of how fast he can complete (process) screw driving tasks.
That said, I disagree with the question being discussed here, because I'd rather just ask him about his speed and performance; I wouldn't ask him how fast he can screw things in :) (that's a minute detail compared to the actual work).
This is the sort of question that reveals the ignorance of the person asking it. The correct answer is "yes". What is 'modern'? There are very modern embedded CPUs that operate in the low MHz range. How much power is being provided? A 'modern' CPU can be underclocked to ridiculous levels for power savings. What's an operation? Are we talking MOV AX, 1 or are we talking hashing a string?
It's the kind of question a dumb person asks thinking they're being quite clever.
And thanks for calling me dumb!
You're the type of interviewer I would weed out, so by all means keep asking the question.