FartyMcFarter

I like most of that TLDR, but:

> Full-stack bragging (...) is pure corporate theater.

I think Google is just about as full-stack as possible when it comes to AI. They do design their own ML hardware, they do tons of research, and do everything in between including hardware drivers, ML libraries (JAX), and the physical datacenters.

We know he's definitely stepping. That's a start.

I think Demis has been way more influential in the past decade. Jeff and Sanjay built a lot of Google's foundational software, but that was a long time ago.

What do you mean?

Even if that's the way it should be, it's not reality.

You can study for the interviews you'd like to have, or the ones you'll actually have.

If you expect Leetcode-style problems in the interview and are actually interested in doing your best there, why wouldn't you prepare for that?

We're specifically talking about people who are interviewing for jobs - I'd expect a lot of them to have done leetcode before the interviews.

Also: when we think about whether we've seen a problem or not before (in order to be honest during an interview), presumably this includes all problems we have a significant memory of, not just problems we've seen recently.

Plot twist: the interviewer despises the internal culture and did this as a way to send a signal that the interviewee shouldn't work there regardless of how well the interview went.

> As a candidate myself I always mention if I have seen similar problems, such as finding primes - real example, and I was hired on that loop at Microsoft!

Normally I'm completely in favour of being honest about this (and would almost certainly do it myself), but in the case of something as common as "finding primes" I'd think it's OK to just do it. Does any interviewer really expect that the majority of candidates haven't look at basic prime finding and primality checking algorithms?

> People would not understand assembly any more and blindly trust the output of the compiler.

This was OK as long as you understood enough Assembly to debug it. Even though I haven't written much Assembly directly, I can still debug it when there are compiler bugs, which does ocasionally happen.

If you lose the ability to both write and debug code then things get much worse. If no one at a company can do that, then you truly are at the mercy of the LLMs.

As for hardware bugs, those are only possibly to identify (by excluding any other possibility) and work-around, since most engineers don't have the luxury of being able to change the hardware.

I'm wondering if some of us will become consultants to companies that lost the ability to handle code. When I was in university the going meme was that old COBOL programmers were making a lot of money in consulting jobs, maybe this will be the new version of that.

> Problem is short of filtering out anything published after 2023

Is it even feasible to filter this? Such metadata can be easily faked too in a lot of contexts.

Great show, great reference.

Then I have to deal with whichever random person they decide to send. I can't be the only one who finds this annoying (even if I'm not in the majority).

I don't want a person I don't know very well in my space.

That aside: if I'm lucky enough to find a person who's good and reliable, they might move away, switch jobs etc.

It has all the headaches that come with hiring and managing someone, because, well, it is exactly that... If I don't want to be a manager at work (been there done that, happy to let others do it and get the raise that comes along with it), I sure as heck don't want to do it at home.

> Hell, the only ones that can afford them will be the same that would hire human household help.

But maybe they'd rather deal with a robot than a human?

Another way to look at it is that they're avoiding some of the expensive parts of making products that use AI, while leaning into their strengths. No Tesla required within the explanation.

These robots look slow and not very fluid in their motions, but LLMs like ChatGPT also looked very dumb initially. If progress is as fast as LLMs , this could have massive applications in a few years.

Yes. That's a whole other level of difficulty to accomplish safely.

> they didn't plan to just spend cash without any return.

No return? Annual earnings have kept increasing at 20-40% for the last 4 years.

Plus there's this:

https://www.theregister.com/paas-and-iaas/2026/07/22/google-...

> Google Cloud is killing it

> It's Alphabet's fastest-growing business and now makes up more than a fifth of the juggernaut's revenue and operating profit

Why does it raise alarm? Pretty sure all this spending was planned.

True on all counts. Not sure why you're getting downvoted.

> I do not feel like I have the mental space to keep track of everything I need to do, and I do not even feel like I am aware of what I'm doing anymore.

Have you tried keeping a document logging what your thoughts/steps while doing a task were? I find this helps me stay on track. You don't need to write it in a clean way, just bullet points to reconstruct the steps you've taken, progress, decisions you need to take etc.

You can start with something as simple as "I downloaded the code from 'X', 'Y' is the shell command I used to build the project, now how do I reproduce bug 'Z'? Is there an existing script I can run or do I need to ask someone for a command, blah blah"...

I find this is very useful when working on unfamiliar tasks or when I'm finding it hard to get traction on a task (due to procrastination or anything else). Just writing something has a way of making yourself get any clarity you can, and if you lose traction again, the notes you wrote are something you can use to get started again.

It's quite freeing to not have to have all the context in your head all the time.

Now they have several Turing Award winners, and several Nobel Prize winners.

Given his seniority, it could also be that he picks whatever bugs he wants to work on. Whether that is from personal interest, frequency of crashes or any other criteria.

When you're at that level in a company, it's rare that someone would be micromanaging what you work on at all times.

As someone who has debugged his fair share of tricky low-level issues, the parts that I find impressive in his blog posts are things such as "then we look at the bytes in memory and oh yeah, this looks like an exception record". I would usually not think to do that (or be able to recognise it as easily as I presume he did).

Quake 1 was worth it even if just for the multiplayer. It was so good that people were having fun online even on just the "start" map with the shareware version. Quakeworld was especially great and very playable even with a modem. Then you add the moddability (including QuakeC) and the groundbreaking renderer, it's one of the biggest technical achievements in gaming history.

The single player was weaker than the multiplayer, but still enjoyable with its strange variety of map atmospheres.

I'm glad Quake happened even if it made id Software a worse company thereafter. I would understand if the people involved feel differently though.

Is the title a reference to "will it blend"?

> They were so close to getting it right.

The philosophy of C++ is to not introduce unnecessary overhead, and to trust the programmer. This design choice is prevalent throughout the language. They were never going to make an exception, especially for something as prevalently used as references.

There are countless examples of this "no unnecessary overhead and/or trust the programmer" choice:

- primitive types and standard containers are not thread safe - it's up to the programmer to know this and use them accordingly.

- std::unique_ptr lets you grab the underlying raw pointer, in which case it's no longer a "unique_ptr". But there are cases in which it's useful to do this (e.g. interfacing with C code), so they let you do it, and trust that you do it in a safe way. They could have made unique_ptr not support this, but then it would be less useful (or force you into copying data unnecessarily to call an API that requires a raw pointer).

> But there's no enforcement.

There's no strict enforcement, but it is undefined behaviour, so compilers can randomly choose to act as if it's enforced and simply crash your program or make it act weirdly.

Programmers are notoriously nitpicky, and avoid making absolute statements in most cases (wait, I'm doing it too!).

This is because we've been trained to be humble by the machines we work with. Computers expose a lot of our mistakes, and over time they remove any illusion that we can be quickly confident about things.

I would take the qualifiers in his post as an indication of his general disinclination towards making absolute statements, not as a lack of humility.

That still doesn't make it a good comparison. The salt emitted by desalination plants is already in the sea now, it's not salt that went somewhere else.