No argument on perseverance, but I don't think it measures conscientiousness. At least, not how I understand the term, which has connotations of intrinsic motivation rather than extrinsic.

Now, if measuring how a person responds to extrinsic motivation is your goal, then this type of interview does just fine. It measures a person's ability to delay gratification for a later reward (because you can have perseverance without that, which you can also call being stubborn or determination, eg. "I'm going to figure this out even if it kills me" ).

I'd bet my net worth that the ability to perform well on these interviews positively correlates with IQ.

For example, you will likely find the applicants rejected numerous times from FAANG have higher age-adjusted bodyfat levels and more dental cavities compared to successful candidates. And of course these measures negatively correlate with IQ too.

So what? Correlation doesn't necessarily make for reasonable selection criteria. Variance is too high.

In my experience, algorithm design is primarily pattern matching. You have a toolkit with a set of abstractions for modeling the problem and a set of algorithmic techniques for solving it. If you have the right tools in the toolkit, potential solutions will jump out. You then pick a promising solution and figure out the details. If you don't have the right tools, you have to go back to reading or start building new tools from basic principles. That can take hours, days, weeks, months, or years, if you succeed at all.

I guess this is similar to proving mathematical theorems, but I haven't done much of that after grad school.

But you're claiming this is somehow not "intelligence"?

But that's the whole point of LC grinding: to claw your way through enough of these problems until, lo and behold... there ends up being an 80 percent chance that any given "medium" problem thrown at you -- is one that you have in fact seen and worked on, already.

I'm just guessing at the 80 percent figure. But it seems pretty clear from the cult of LC grinding that one of the goals of this strategy is not just to learn general techniques for solving these problems -- but to get a significantly high percentage of these problems under your belt already, or nearly so.

While also learning to deploy the just the right grunts and moans and pauses to make your interviewer think you're seeing the problem for the first time, of course.

Why don't they just conduct a proctored test? Doesn't make any sense.

A lot of it is about gauging the candidates aptitude, and of course their willingness to put in the work.

It's like those kids in math class that say, "I'm never going to use this in real life."

I was a college math major, but believe that the math curriculum is ripe for reform.

Because of the usual lack of rigorousness -- e.g. most companies will not require you to prove that the system is going to be up for 99.9999% of the time, the load balancing is optimal, the abstract queue in our system is not going to diverge (when it does inevitably we will just reboot and keep doing it until we get more funding) -- the expectation and targets is also to avoid it.

Most developer positions are doing essentially the equivalent of designing over and over the equivalent in civil engineering terms of one or two story buildings.

There are positions that will exercise one's engineering skills (including math). However, the culture and expectation of "math person" does not promote them. Graphics, cryptography, distributed/byzantine systems (I don't mean using AWS here), optimization, ML (new algorithms/improvements), maps, are some areas that one's cs/math/engineering skills can be used at.

But note that when any X of those areas become trendy there is the gut reaction of an "intro to X for programmers" coming out that is a couple of hand-wavy sketches, some sketchy intuition -- most often wrong in the details -- and an API guide.

Having done my undergraduate in Europe, every year was math heavy -- math was the core not the attrition machine. And I do see this mentality in the U.S. startup industry where a lot of times the Edison approach is taken of trying every single filament width choice on a mock-up instead of doing a quick calculation.

Having taught math to undegrads in the U.S. and from discussions with people that TA'd, I would agree with you that the math curriculum needs to be revised from the ground up as being extremely inadequate. On the other hand, most software "engineer" positions, do not require any engineering to be done.

From an (software even!) engineering perspective, nobody needs to solve the same Math problem twice. All "Math problems" are either solved or are open problems (this is almost by definition). The ones which are already solved do not require re-solving again, which means that in the vast majority of cases a competent (software) engineer only needs to learn how to apply them. I don't know about traditional engineering, but in software, often it's just a matter of importing a library and calling an API. The software development ecosystem has developed to a point where you don't need to know how to implement things, you just need to know what you need. Unless you're an expert specialist in a particular field, you often can't do better than that, because whatever idea you have, most likely somebody more competent than you has already written an open source library for that.

I don't think it's useful to contrast general incompetence with a lack of mathematical ability -- though it sometimes correlate somewhat if only because general intelligence often manifests in mathematical ability. There are simply too many unproven assumptions from "math education" => "writing better software". If anything, good software engineers need to be ready to learn, and learning maths outside of formal schooling is just one of the many things they need to do. The general lack of quality in software is a supply and demand problem -- as long as FAANG can afford to pay 200k+ USD to fresh grads with no experience, companies with a smaller budget must make a trade off between lowering quality and not delivering at all.

Ironically(?) the market is actually responding. People doing interview prep are learning the minimum subset of mathematics and engineering required for a high paying software job. Then you get people complain about grinding leetcode. Imagine what happens if FAANG companies add abstract set theory to their standard interview questions! (I'm willing to bet this would lower software quality...)

Well, someone, has to write that software.

When people used to say, "I'm never going to need to know this", my teacher would reply "You're right you won't, but the smart kids will"

I'd like to see school math place roughly equal emphasis on:

1. Arithmetic, i.e., expression manipulation 2. Computation, both numeric and symbolic 3. Learning from data 4. Theory, i.e., things like sets and proofs

Items 2 and 3 are things that people can use throughout their lives, even outside of STEM careers, and could be blended with the science curriculum. Items 1 and 4 would serve the needs of "math people" and academic mathematics.

This is only true if you’re working in a mature business with stable usage patterns. Even then, using lower level APIs can be easier and more flexible.

The idea that this is a meaningful proxy for "ability to get things done" -- about that I'm not so sure.