If you're reading this thinking "wow, a recall! tesla must suck at building cars!" then you probably don't know anything about how the automotive industry works and you should refrain from commenting
Even people who know about building cars think Tesla sucks at building cars. Which is why in an interview about speeding up the production line, the head of Volkswagen's production lines thought that a duration that was still almost twice as long as a Tesla spent on the line was about their lower floor and that anything less would be problematic.
Maybe that's why their cars ship with their windshields glued on, all the time, or all of their brake pads, all of the time, or secured body panels, all the time.
Or maybe he should have refrained from commenting?
If you’ve spent a significant amount of time widening the scope as far as possible to include everything interesting about your original question, and there is nothing in that whole widened scope that the audience will give a shit about, your topic is unsaveable and your advisor is a failure.
If there is something interesting enough to qualify, then reduce the scope as much as possible. It should go without saying that you shouldn’t throw out the interesting bit.
The problem that occurs in practice is “focus on finishing” leads people to finish without actually doing anything meaningful. Advisors may or may not encourage this depending on where they are in their career.
When you get on the industry job market nobody cares if it took you 3 years or 7 years to do the work, they only care if it’s meaningful.
If you can somehow get your hands on a dozen NVL72 racks and duct tape them together in such a way to rent them out as a service, you can make your money back in less than 2 years at current demand pricing. $50M is more than enough to get this going.
It’s hard to argue against hiring contributors, but a bounty system that pays pennies vs. market value for skilled developers shouldn’t be the only interview path, it’s borderline exploitative.
It’s not exploitive if you like working on it. I can see an additional upside here (for tinygrad) that they better screen out people who are just trying to optimize for job prospects or money, who would do better elsewhere, and get people who actually like contributing.
Few people with no innate interest in the project are likely to ramp up and start contributing just for a shot at a job. Whereas if you’re Facebook or whoever you are much more likely to get people who don’t care about the product and just have decided they can make a lot of money by jumping through the right hoops.
This idea that you're supposed to accept worse pay because you believe in the idea doesn't apply to George. If his companies succeed, he'll be rich. Of course, there's nothing wrong with even working for free if that's what you like, just don't make a moral principle out of it.
I don’t mean to imply it’s to get employees to accept lower pay. I mean that there is some implicit screening against people who are solely optimizing for high pay.
Lots of reasons why you would want to simultaneously pay well and not attract people who are optimizing for pay.
I don’t fully understand why you wouldn’t want to attract people who optimize pay. You always should aim for getting paid what you’re worth which is understandably hard to define. I think that’s the whole point of OPs argument how this is exploitive. You’re trying to sell a “vision” for lower pay.
All other interview processes (that I've witnessed or heard of) waste anyone's time with barely anything to show for though, regardless if it ever comes to a offer.
As opposed to months of interview prep, followed by half a dozen interview stages, possibly including an unpaid take-home mini project, all of which could be for naught because you fluffed some obscure algorithm question that bears no relation to your day job?
What's even sadder is that because of AI coding agents it's possible the bounty system will go away. The value today is much less in writing the code and much more in defining the tasks and validating the code. We don't have the bandwidth to read tons of AI slop, which at first glance looks okay, but upon spending time to read it you realize it isn't good. The fix for this is probably a reputation or staking system.
I'm shocked that interviewing still works how it does in large companies; the Sybil attacks and DDOS are just getting started.
What's the problem? Someone submitted it for people to read but it didn't catch on, now it's resubmitted and people can read it after all. Everyone happy. Don't be so attached to imaginary internet points.
The leap is not really there yet and it's cheap because you are the product. The robot will be a massive headache, will work poorly for most tasks, frequently break and require maintenance. In exchange for $500/mo and providing those test hours in a novel environment and the data that goes with it, you get to have a robot in your house that occasionally does something right. The bet being made here is that they can turn that data hose into a useful robot before this poor customer experience tanks their brand.
I’d suggest Octave over Matlab, because current Matlab has tons of distracting AI and autocomplete front and center. Probably really helpful for getting a plot just right or implementing an algorithm from a paper, but not so good for learning the basics.
I think his main point is about strict typing in Fortran. You can add type annotations in Julia but it's almost an anti-pattern if you don't need them e.g. for dispatch. In any case the type annotations in these examples would be quite unnecessary, unlike in Fortran (where as I understand you can at best enable implicit typing but then must use variable names with specific patterns).
I would argue that the strict typing in Fortran is actually a significant hindrance. there's nothing about any of these algorithms that requires double precision (or even contiguous storage), so why should the algorithm randomly restrict it? Annotations of rank (e.g. AbstractMatrix in julia) help document what the code does, but the strict annotations of Fortran are restrictions without value.
Step 1) Write the function using high level abstractions
Step 2) Glance over the generated assembly and make sure that it vectorized the way you wanted.
> Glance over the generated assembly and make sure that it vectorized the way you wanted.
Isn't that sth you would also need to do in Fortran? IMO Julia makes this so easy with its `@code_*` macros and is one of the main reasons why I use it.
If you write Julia similar to Fortran, with explicit argument types and for loops and avoiding allocations it shouldn’t be too far off. Fortran IIRC has a few semantics which might make it more optimal in a few cases like aliasing
But indeed there are almost certainly less performance surprises in Fortran
This is the default workflow in every high-level language. Even if I’m writing explicit SIMD intrinsics in C targeting a specific processor, I still have to benchmark and maybe look at the assembly to make sure it did what I intended (or something better).
people like to complain about matlab as a programming language but if you're using it that way you're doing it wrong.
matlab (the core language) is awesome for expressing matrices and vectors and their operations as well as visualizing the results. matrix expressions in matlab look almost identical to how they look in mathematical notation (or how one might write them in an email). you shouldn't be using programming language flow control (or any of the other programming language features), you should be learning how to write for loops as vector and matrix operations and learning from the excellent toolboxes.
