Makes sense. It's like we were prohibited from using calculators in school when I was growing up. If you're testing for on-the-job performance then you should have on-the-job tools.
Similar to graphing calculators vs basic scientific calculators... if you're trying to demonstrate you understand an equation, having the calculator do that for you doesn't show you understand what it is doing.
Where in a job, you're probably not going to need to rebalance a B-Tree in any practical sense. For that matter, in my own experience, most actual development rarely has people optimizing their RDBMS usage in any meaningful way, for better or worse.
It's the difference between learning and comprehension and delivering value. Someone has to understand how the machine works to fix it when it breaks. And there are jobs at every level. Most of them aren't that constrained in practice though.
That isn't entirely true and brings up an important nuance. I understood algebra and calculus extremely well but I routinely got half-score for fudging a calculation or somesuch because multiplication has a foundation of rote knowledge: you need to memorize you ten-times table. To this day (at 37) I continue to use algebra to do basic multiplication in my head (7*6 = 7*5+7 = 7/2*10+7 = 35+7 = 42).
Sure, using a graphing calculators solve the problem isn't demonstrating understanding, but 90s kids were simply asking for the basic calculator with 2 registers (display and M) and basic math and "sci" (sin, cos, sqrt, etc.) operators.
Preventing use of basic calculators does nothing to demonstrate knowledge of math at all, it actually hinders it.
I'm not sure why you're still talking about this. A basic "non-graphing" (90s "scientific calculator") is not capable of doing all the work for you. All it did was the basic things like add, mul, sub, sin, cos, etc. I am referring to one of these[1].
> It's not far from how common core, aka new math actually tries to teach it. It actually shows you understand the mechanics
I understand the mechanics of mathematics but still fared more poorly than I should have because I messed up a simple op like multiplication more often than I should have. My point is that had I had access to a basic calculator I would have scored significantly better in school. I went from Bs to As (80%, not sure what that is in GPA) in university by mere virtue of being able to use a simple calculator.
Again, not being able to use a [basic] calculator tests a signal that isn't actually important. Not being able to use Google/AI/whatever in your interview similarly tests an unimportant signal. The most important hire signal for a SDE is actually how they operate in a team and how they communicate with stakeholders, which these coding tests don't do.
[1]: https://upload.wikimedia.org/wikipedia/commons/4/4f/FX-77.JP...
I prefer a paired interview scenario with actual questions about approach to working through problems. As an interviewee I do horribly with the leetcode questions, there's no opportunity for clarifying questions, and some systems penalize you for looking away from the screen even. It's unnerving and I refuse to do them any more.
I also don't mind the "here's a task/challenge that should take a half hour or so." where you simply create a solution, commit to github, etc.
As an interviewer I prefer the walkthrough interviews as well... I usually don't get into pedantic exercises, or language/platform nuances unless the applicant uses "expert" on more than one or two subjects.
I'm not sure when an employer should really care about whether their cashier can add/subtract correctly vs just use the output from the machine. But in the education setting where you're making a claim that students will learn X you should be testing X.
And yet here we are . . .