If WA did things like silently degrading/removing E2EE, wouldn't it be discoverable by an independent security researcher?

WA seems large enough that the security community would put in that effort periodically.

Well, yes. Obviously. One would hope.

But if they were to do so, it could be done so that there likely wouldn't be anything in the visible application or its behaviour to highlight the change to a regular user. Unless you somehow see that the key ratcheting is in use and can confirm the two-sided key state out of band with your peer, you can't tell without disassembling the client.

However, this feels like derailing quite far from the original topic. The contract and assumption of E2E protection unavoidably relies on trusting the client(s) and the devices they run on.

That seems like something you could build. There's a handful of YC companies working on that.

I don't think FANG companies are likely early adopters of that. They are all relatively conservative with hiring. Navigating the organization to find an internal champion who's incentives are aligned seems really tough. Internal established recruiting teams seem disincentivized to use a 3rd party certification. Using that might reduce the number/importance of the internal recruiting team.

The advantage is that it would reduce total recruitment cost and burden. I mean filtering on a CS degree and school should be enough but apparently it isn't. There are also non-traditional programmers. There's a finite set of reasonable problems so there will be some difficulty in hiding the answers when you have access to Google vs in person.

Outside of that, the most important skill is gathering requirements, gathering requirements and gathering requirements. In the startup world this is called finding product market fit.

System architecture design and computational thinking are also necessary but I don't think any software engineer can do those well without gathering requirements which is basically about identifying product market fit within your corporation.

Deletion is very much a technical/organizational challenge.

Imagine some engineer writing some feature you've never heard of and they decide they need data in a different format. They write a job to do this.

Now imagine that job somehow has a bug which prevents the deletion system from understanding that copy exists. That bug could be non-obvious to find.

Knowing more or specific technologies isn't what makes someone a good engineer.

Practice identifying problems, taking full ownership of them and fully thinking through and delivering solutions.

This is way easier if you find a problem that you're interested in.

If you're not able to sink your teeth into any good problems, at least pay attention to people around you who do this well so you can copy them in the future.