[hashmap]

Pointing to the interview process works against that argument rather than for it, and for the same reasons. Have you never been stuck on a problem at night and woken up with the answer? A good number of the really interesting problems I've solved got solved that way. Many of them felt like they either didn't have an answer or there's no way I was going to get it. Good thing there isn't a 2.5 hour timer following me around!

[chongli]

I have been stuck on problems that I figured out the next day. Many times. But that was when I was new to the topic, at the beginning of the course. By the time I reached the exam, I knew the tricks and how things fit together, and I could quickly solve lots of different proofs based on that same material.

That’s what the exam is testing for. If you need unlimited time to write the proof, then you haven’t studied the material yet, and should be expected to perform poorly on the exam.

It’s like the difference between someone who has never touched React before the interview, and someone who has been programming with React for several months. You expect the person with several months of experience to know how to solve problems with React several times faster than the person who doesn’t know it at all. If you’re hiring and looking for someone with a minimum of 1 year of React experience then you shouldn’t expect the person to take a full day to do basic tasks with React (especially if you the interviewer or anyone else on your team can do those tasks in just a few minutes).

[hashmap]

> I have been stuck on problems that I figured out the next day. Many times. But that was when I was new to the topic, at the beginning of the course.

Maybe it has been a while since you have worked on something difficult, then? Difficult for you, I mean. Maybe the difficult things are now easy.

> If you need unlimited time to write the proof, then you haven’t studied the material yet, and should be expected to perform poorly on the exam.

I mean, maybe. I remember some classes and exams where I had simply never seen the topic before, and the problem relied on having picked up on metapatterns that weren't explicitly taught during the class and applying them in novel ways on the spot. Though my guess was that at least some of those problems were markers for "if you can one-shot this, we want to know".

> If you’re hiring and looking for someone with a minimum of 1 year of React experience then you shouldn’t expect the person to take a full day to do basic tasks with React.

If you're talking about the basics, then yeah I would agree. I guess I don't really know what counts as a synthesis problem in this context, and if we were looking at specific examples it would be more obvious why one might be fair and another might not be. I've heard that line about TAs being touted as being able to solve the tests in just a few minutes, yet somehow unsolvable problems fell through the cracks to the students in the same class more than once in mine.

[chongli]

If you're talking about the basics, then yeah I would agree.

That's the crux of it, really. For a lot of students, the kind of proofs we do in undergrad pure math courses are very difficult. For a math professor? They're extremely basic.

There are levels to this. If a typical high school math student is at level 2 or level 3 (of math ability), a 3rd year pure math course may be at level 10, but the professor teaching the course is at level 100. Okay, so these are made up numbers, but I hope they help to illustrate.

For someone who has never tried to write a computer program in their life, writing Fizzbuzz may be quite difficult. For a working lead developer with 10 years of experience? Quite basic.