I used ST hardware from STR750 to F1, F2, F4, L0, L1 and L4. I did use the SPL library because it was a reliable way to extract register functions when reusing code across families. I never used HAL, LL, or the code generator IDEs.
The problem is lack of internal documentation. I've seen mention of hidden spinlocks and other nasty surprises in the forum. The sheer volume of issues is enough to deter any use of these libraries on a commercial product. If I have to spend the time to reverse engineer all that code I'd just as soon use my own.
For the families without ST issued SPL libraries I converted the closest match from another family. On average it would take about 4 weeks with an assistant writing tests. The time paid off in years of code reuse afterwards.
Embedded programmer qualifications? I looked for ability to read schematics and IC specsheets, solid experience in C, and most of all an understanding of why it was so important to build maintainable code for the next guy over a 20 year product lifespan.
When hiring I never bothered with code tests or whiteboarding a sample project. No one can remember every nuance of C; that's what the internet is for. What I looked for is knowledge of the "gotchas" in realtime programming, things like priority inversion, race conditions, when a mutex is needed.
Of all the programmers I replaced, not one ever instrumented or profiled their code. Many didn't even check for errors. Documentation was a dirty word. If someone told me "the code is self-documenting" then I knew they were too lazy to worry about passing on design knowledge to their successor.
I hope everyone has the experience of being handed 50K lines of "cowboy code" once in their career and told to keep it working. Come to think of it, go ahead and use the CubeMX for a project that ships 50K units a year.
