[edcarter]

That is because it is an actual __Engineering__ exam, not a programming one. Testing for programming skills in an SE exam is like testing a mechanical engineer's CAD skills. I would argue that the majority of "SE" jobs do not actually entail engineering but software development (or construction), which is only a small subset of SE.

[monocasa]

The computer engineering exam has tons of the underpinnings covered, with a whole section on relevant math. Where as the software one pretty much only covers process. The one algorithms or discrete math question they have boils down to just 'what is big o complexity'.

[WorldMaker]

I guess the question is what is the necessary "base set" that shows proficiency enough in learning that you could throw someone at a problem and expect them to solve it. Keep in mind that to keep a PE active there are also lifelong learning requirements.

Certainly what I see in the PE today seems like a good starting base. Having some idea of Big O complexity can be a great place to start when working with algorithms, and certainly from my perspective I'd rather have an engineer with a solid idea of Big O complexity trade-off issues than a bunch of rote memorized implementations of classic algorithms.

Also, don't forget that a lot of discrete math and algorithms bubbled up into the Fundamentals of Engineering test that is the prerequisite of the PE test:

https://ncees.org/wp-content/uploads/FE-Ele-CBT-specs.pdf

Which isn't to say that the PE can't be improved for Software Engineering to better meet industry needs, but certainly the current PE still stands as a good starting point that the industry could try to hone to a better tool if they wanted.