I had an eerily similar experience interviewing at a similar public SaaS co recently.

Ten years ago, maybe

I haven't job hunted in five years or so, but leetcode was omnipresent in my local market. I got some offers without leetcode but those jobs paid about half as much as the ones that required leetcoding.

What does prep look like now?

The market now is more about getting the interview rather than passing the interview.

Wow, this might seal the deal for "SaaS-pocalypse". I imagine the upside is high for Spoons considering the wealth of data and a well-oiled product enshittification playbook.

Everyone posting here is now on a list somewhere. Hopefully you're deanonymized sufficiently. Better hope we don't get caught up in something!

>Hopefully you're deanonymized sufficiently

What?

*you are sufficiently anonymous here

Choosing what to remember is my biggest challenge!

This is absurd and I love it.

Rendered text cannot be assumed to equal the underlying text, unfortunately

How so? As i understand your point, this would mean we cannot trust GitHub enough to return the same content in git clone vs curl?

As an example, webfonts can make rendered text differ from the underlying text that ends up on your clipboard.

Sure, but doesn't this assume that you cannot the publisher anyway? So why would you not trust their homepage but trust their source-code

This, and some results smartly ignoring the selected sort order because gmail suggests you "follow up", both work together to paint a vivid picture of a disassociated product team who no longer understands their customer.

I'm enjoying learning about these hard problems, but this line about credit made me chuckle:

> We helped prepare the manuscripts and formalize the proofs in Lean, and we take responsibility for their correctness

Offering to take responsibility for the correctness of a proof written in Lean feels like volunteering to be the fall guy in case someone finds a flaw in basic arithmetic, no?

well, a bug in the Lean kernel was discovered last week by way of an LLM tricking itself and its handler into believing it had found a non-constructive proof of the existence of a nontrivial Collatz cycle, see https://infosec.exchange/@0xabad1dea/117002106099986943 and https://lipn.info/@mevenlennonbertrand/116997917683191056

That seems to have been more of a sensationalized joke. Even your link has a disclaimer in it now. Read this chat from the researcher who did this:

https://leanprover.zulipchat.com/#narrow/channel/270676-lean...

It's not at all a joke ... that's a severe misunderstanding of the context.

There is no evidence that I can find for the claim "a bug in the Lean kernel was discovered last week by way of an LLM tricking itself and its handler into believing it had found a non-constructive proof of the existence of a nontrivial Collatz cycle."

As I currently understand it, all we know is that:

- a mathematician produced a Lean-verified counterexample to the Collatz conjecture, demonstrating a bug in the kernel

- he claims that LLMs were involved somehow but pointedly refuses to specify how

- he admits that he knew about the bug before publishing the counterexample to his repository.

Perhaps not a joke (although it sure seems to me like they discovered a bug and thought falsely disproving the Collatz conjecture would be a flashy way to announce it), but at best extremely sensationalized by the above description. If you have additional context I would be happy to hear it!

Indeed. It seems to me much more likely that the AI was directed to look for bugs in Lean, found one, and then it was directed to write a proof specifically targeting the bug.

Fascinating, and arguably an illustration of why the bifurcation of responsibility is interesting in the first place.

It seems that a lot of folks misunderstand the guarantees that lean provides.

I just want to state that having "lean proofs" that build (checks) does not mean the actual real theorems we care about hold. Ignoring lean kernel bugs, ultimately a human (not an agent) has to verify the lean encoded theorem statements (specs/specifications), that the lean proofs are checked against, indeed correctly encode the real theorems. For non-trivial theorems such as these, this is an arduous and tricky task where even a little mistake could be fatal. AI generated lean encoded theorems can be huge and difficult to understand. I wonder if anyone reputable has audited these specifications.

I'm not an expert at it myself, but my understanding is there are numerous ways to "cheat" in a Lean proof (via `sorry` and similar). They're taking responsibility for fully verifying that none of these cheats were used (and that the theorem statements themselves were all correctly formalized.)

Even beyond cheating with sorries or kernel bugs, the lean encoded theorems (or specifications) must be checked by humans to see if they truly mirror the real theorem authentically.

No, the correctness isn't for the "inside the Lean proofs", but for the translation of "human language math" and its formal Lean variant.

I see. It still feels like a bit of an oddly solemn way of saying "this is the part we admit responsibility for"

Traditionally, a mathematician would be implicitly responsible for all that (if they were to publish Lean code) and also the intellectual work that led to the artifact of the mathematical paper (and code, if part of the contribution). This statement should rather be read as an acknowledgement of limitation of authorship from the implicit, traditional understanding.

Well, to be fair, with Lean proofs, that's the only thing there is (unless I'm missing something).

It’s more than you get from free software - you get no proofs, no warranties and any responsibility of its authors are their pure good will. Reminder lean proofs are software!