Unfortunately writing high quality OR code is beyond the reach of most academic settings. This is mainly because:
- Writing high quality code is very time consuming.
- The scope of OR code is much better suited to teams of people rather than a lone wolf trying to do everything alone.
- Because it's time consuming, there's never enough time in academia to do this properly, as priorities are different (publish or perish).
- Academia is a place to learn by doing things wrong. Industry is the place we go to after we've learned stuff.
- Production code is the domain of professional developers. I thought I was pretty good at coding after my PhD, and all my developers put me to shame. Most of them are 10 years younger than me.
- In most academic groups, even if a person who does things properly shows up from time to time their know-how leaves the group when they do.
Academia really needs to move away from the notion that a talented student can just "do things" alone. This is simply not true in software in any production setting. People need teams, support, infrastructure, and senior leads to guide development.
The remedy would be for academic groups to start employing professional developers full-time to support the researchers. This would have the nice side effect of training them to do things properly while they do research.
All this means that requirements are not really high from a coding point of view. This is dangerous because supervisors tend to accept candidates who simply don't have the background to do the work necessary. My advice for entry-level applicants is to really look into who is in the group, and how long the people who know what they're doing are going to be there after you join. If they don't have a computer science background they should be prepared to do a lot of work to catch up if you want to write good code.
A red flag is if the group doesn't have a repository to inherit code between students. If they have code, people should read that code before they join. Does the group have continuous integration? Does the code have unit tests? Are there 15 forks or does everything eventually get merged into the master branch? Is there a person responsible for maintaining the codebase? Who is that person? If they leave, are there plans to replace them?
My experience is that unless new applicants can get good answers to such questions the group is unlikely to have the culture to provide the support people need to write high-quality code.
For industrial entry-level positions it depends on the company - for instance at Octeract we have very high standards for C++, but we also don't have entry-level positions. We still do a lot of training, but mostly on advanced things.
Commercial solvers are of course not the only applications of OR, in other settings standards are lower and entry-level jobs are available.
The best open source OR code I've seen is MINOTAUR, but even that is a far cry from production-level OR code.
Good resources for students are predominantly to start using the tooling we use in the industry. They should learn how to use Git, Jenkins, and the Clang tools. They should read the Google style guide on how to format code properly. The should learn how to use static analysis tools, profilers, and Valgrind to diagnose the state of their code. They should get into the habit of writing unit tests for their code (Catch! is a good testing framework for C++). They should use Doxygen to automatically map and document the codebase.