sandywaffles
Joined 2 years ago
Joined 2 years ago
I don't think I share that opinion. The best jobs I've had were after 7+ rounds of actual interviews: code challenge, several peer panels, systems design, hiring manager, Senior manager, Cutler fit, etc.
That of course doesn't mean there aren't companies out there abusing the system or who have less than genuine tactics. But my point is mere number of rounds isn't a good indicator of anything in isolation. I've also worked at places with less than 3 rounds that were absolutely terrible.
it sounds the opposite of optimized to me. Unless we're optimizing for something other than developer experience and efficiency?
And it's not a cut and dry issue to add. Function effects would add a lot of cognitive load to the developer along with more implicit bounds which increases accidental API break changes. You talk about the compiler implicitly adding the bounds to functions, but what happens when I now add a line in my function that allocates when before it didn't? I just broke my API unless I was also defensively testing all implicit bounds. And if I was testing all implicit bounds, can the language no longer add new bounds? Reversing that and requiring the callee to defensively declare all bounds is a borderline non-starter because it'd such a huge burden to write any function or refactor anything.
If your stance is assuming we have an existing implementation of something in the training set, and we have a robust test harness already, and we have thousands of dollars to throw at tokens, and we're not at all concerned with "works" THEN this is viable then sure? But that doesn't seem to be what most boosters are saying.