Whether this is a good interview question I don't know, but:

> 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.

I see your point, but hardly anyone counts "operations" anymore. Besides, what even is an "operation" on a modern CPU? You could say, an operation is an entire CPU instruction, but the truth is that the instructions you see in assembly files are not really that atomic. So then do you count each microcode instruction as an "operation"? But even then the question is impossible to answer, because depending on the type of workload your execution time will vary significantly. For example, straight up doing math with some registers will always be faster than reading/writing memory, and reading memory in a cache-friendly way will be faster than jumping all over the place, etc.

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 agree that it is "useless trivia."

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 not infrequently surprised how people don't spot that something is orders of magnitude slower than it should be or pick the wrong architecture because they can't or won't do simple mental math to work out very roughly how long it should take to move some data around in memory, ssd or over the network or perform some simple computation on it.

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).

I don't think there's much predictive power there. The people who are answering thousands clearly just haven't though about it before and are on the spot. Humans are just terrible with big numbers, and thousands sounds like a lot already.

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?

Unless you are writing assembler, speed of your code is very distant of instructions. You don't count instructions when estimating speed. Not in higher level languages, not when working with database and definitely not in something like javascript that runs in browser.

What is the clock speed of your iPhone or android phone?

I personally have no idea and it's the one computer I use most frequently.

My phone, and your phone too (possibly) is something like 1.2 GHz per core, with 4 cores; most phones have a similar spec (and those numbers are going up, too); basically figure 1-2 GHz per core, with 2-4 cores generally.

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).

Well does it take about a second or about an hour to make one turn of the screw? If a carpenter doesn't know the answer to that in his bones, he won't be fastening many things together.

It takes significantly less than a second to turn a screw once. A couple orders of magnitude less actually, to give it some relation to the computer question.

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.

> At some point things are "fast enough" that it just doesn't matter.

...and 640K will be enough for everyone!

The carpenter may simply know that turning the screw is imperceptibly instant in his experience, and that if the bookshelf isn't getting built quickly, the bottleneck is virtually never because he's waiting on screws to be turned. He's going to have to make a trip to the store anyway so he isn't concerned with whether turning the screw requires a tenth or a thousandth of a second.

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.

If he is good, he can reason about it on the spot. If he can't, I very much doubt that he can design anything excellent. That requires critical thinking to understand what it is being used for, what is good, and importantly what solutions are unsuitable for the problem he is trying to solve.

Sure, although I was addressing the parent comment, and more specifically, "knows it in his bones."

No. Here are possible carpenter equivalents, all of which I'd absolutely consider a minimum low bar...

> 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

Number of nails as analogy for CPU operations? That's not hiring a programmer, that's hiring a computer.

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.

Carpentry is far different than programming. But even so, and equivalent question I would ask a carpenter I wanted to hire would be, "How much hardwood flooring would I need to cover the rooms in my house?" If they answer, "I dunno" and then stare at me blankly, I'm certainly not going to hire them.

Apparently some people take whatever warm body shows up.

> Carpentry is far different than programming. But even so, and equivalent question I would ask a carpenter I wanted to hire would be, "How much hardwood flooring would I need to cover the rooms in my house?" If they answer, "I dunno" and then stare at me blankly, I'm certainly not going to hire them.

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).

And because of that the kinds of answer we would expect from such a carpenter in that situation is, "Hmm ... how big is the room and what size of board are you using? 2 inch, 3 inch, 5 inch, or so mix? That's pretty popular these days. How much extra do you want - I usually recommend 15% so you have some in case you need to repair."

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.

> 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."

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?"

When carpenter will try to use toothed disc from circular saw on the handheld angle grinder(1) instead of abrasive disc and it will disintegrate at overspeed he'll know. Maybe it will be too late but he will, for sure.

(1) because "it is faster" and "my dad always did this" and "you don't pay for my saw, so shut up"

> When carpenter will try to use toothed disc from circular saw on the handheld angle grinder(1) instead of abrasive disc and it will disintegrate at overspeed he'll know. Maybe it will be too late but he will, for sure.

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.

It's absolutely relevant. On more than one occations I've had performance issues land on my table with the developer that wrote the code saying "it's not that bad, it's going through 100.000 elements". They simply don't have a relation to how much a modern computer can do in a given timeframe.

Usually I can guide them to understand where the bottleneck is, but every so often I have to rewite it so performance is acceptable.

That's not the correct analogy, because the carpenter uses the screw driver as a tool, not as a platform. The screwdriver is analogous to code, not the CPU.

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).

You don't, but if you found that a candidate carpenter couldn't tell you whether they could fasten 10 or 10,000 or 10,000,000 screws in a one-hour period, you'd start to doubt their ability in general.

The question may be to asses tech-savvy-ness of the candidate (i.e. if he/she knows the SI prefixes, what the range of the modern CPU frequencies is and how do those values reflect on computing performance). There is one kind of programmers that learned their trade just to make a buck and don't care much about their working tools, and there is another kind that finds interest in computers in general. Interviewers may prefer the second kind.

No, it's more like asking a roofer how about the area he can cover with shingles per hour. Information of vital importance.

Let's be real, if a roofer was asked anything comparable to a programming question it would be to provide an accurate approximation of the total number of roofing contracts completed globally within the last half-minute on the back of a coffee-stained napkin.

But that's not what's being asked by OP. Their question is rather simple, and software engineer should be able to answer it on autopilot, without even engaging her brain. As a hiring manager I would end the interview right there and then after the failure to answer something like this.

As an interviewee, I would roll my eyes at the ignorance of the interviewer.

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 you are one of the types of person the question is meant to weed out - people so threatened by a simple question they get defensive and hostile.

And thanks for calling me dumb!

Thanks for projecting 'threatened' onto me!

You're the type of interviewer I would weed out, so by all means keep asking the question.

And low Mhz range is in the millions, which they said they would accept as an answer with that explanation.

Clock rate != operations. It's like you didn't bother to read what I wrote.

Closely enough related to number of basic operations though I'd say. I'll agree with you if it really just is a multiple choice question without context, but the initial poster did not present it that way, but said that explanation/discussion matters. And then your objections are a good starting point for that.

The worst thing you realistically can do to stall your CPU is miss cache every time you read data from RAM. If you do this for every instruction (which would be quite a feat in itself), you divide your instruction throughput by about 200. But even then, and even on the shittiest modern CPU you'll be retiring millions of instructions per second.

The MSP430, released in 2010, can be clocked down to 32kHz. That's pretty much the state of the art in modern, low-power devices.

And if you know that, I'm pretty sure you'd pass that interview.