I don't necessarily disagree with this - I've often felt like the criteria used to make software development decisions should be more empirical (YAGNI etc, schemas, contracts - not the whole formal specification bucket, but formal-"ish") and constraint based

However, it seems to me - as a layman with zero accounting experience beyond Wikipedia and GnuCash - you could feasibly drop an accountant into any arbitrary business and they would eventually find their way around the cash flows, balances, and - given sufficient information - build up a general profit/loss and general idea of financial health.

It doesn't seem to me, however, that you could drop any software engineer into any arbitrary company and expect the same. You should be able to, but not right now. Some software engineers can do that. Not all of them.

I suppose my point being: a degree from a chartered accountant indicates a core level of competency to me. But a software engineering degree doesn't. This is why we interview them with whiteboards / fizz buzz / how many windows can you wash / what is the ideal shape of a manhole cover.

Because you can get a top class degree in S.E. / C.S. and still not be able to handle a JVM OOM error.

It's true that the problem space of “accounting” seems, at least to me (I likewise don't have deep experience), somewhat more constrained; indeed, accounting seems very specialized. Perhaps one difficulty here is that “software engineer” isn't really one job or career---it's dozens of jobs or careers that we're pretending are one and the same. To follow the accounting example, I guarantee people are hiring software engineers to do work that is largely accounting. But they're doing that work in something other than Excel, so it's software engineering, not accounting. But is that actually true? You wrap these software engineers in teams with acceptance criteria, etc, etc, but really you're trying desperately to paper over the fact that your software engineers aren't accountants, and you're basically training accountants by trying to help the software engineers build an accounting system.

In general, I agree with your point. It's mentioned elsewhere that there's a difference between a trade school and a university, and a software engineering degree is a broad university degree. Much like an English degree won't guarantee you're a great author, it seems odd to expect a CS degree to guarantee you know how to handle an OOM error, for example. I think in many cases CS/SE degrees to themselves a disservice by trying to teach everything, instead of allowing specialization that can be clearly understood in the next phase of someone's career.