I generally go through something like the following steps:
* I look at the readme if it exists
* I pull down the project and run any setup steps (install dependencies, start up database, etc).
* If there are tests, I try to get the tests to run (this may lead to additional setup)
* Once I get the tests to run, I make sure they are all passing
* If it's an application (as opposed to a library) I will get it up and running on my computer and play around with it as a user.
* Finally I will start scanning the source code - Starting with the main app, and digging down where it seems relevant.
* If I am looking for some specific functionality, I let that guide my perusal of the source, otherwise it's just looking at the major pieces - routes, views, models, etc. to get a feel for what the relevant parts of the app are.
I'm using Clap[0] for a command line project I'm doing in Rust. The API for it is fantastic, and the examples are very well commented. Overall it's the best library I've run across in a while.
The biggest thing I see is not considering edge cases.
They'll have a certain way they are checking a few cases (and maybe a couple tests), but they don't have the foresight to really try to break things. They will also make assumptions about how the code will be called, what entities will exist at that point, etc. that just don't hold in reality.
This typically manifests in code that works fine when they use it, and all the tests pass, but it breaks as soon as it gets up on the staging server, or as soon as somebody else tries to use it.
Also:
Not listening to feedback from senior devs.
Drastically underestimating the complexity of what they are working on.
If the puzzle questions seem like high school math, I second the idea of building something. Try to get a website set up if that interests you. If not, try building a command line tool to help you with something you do regularly.
The act of trying to build something that works is an incredible learning experience, and will teach you a lot about whether or not programming is something you should pursue.
Udacity's intro to CS course is really good. Not sure if it covers all your bases but it definitely hits most of them. Note I'm not talking about the programming foundations in Python course.
I have been listening to Partially Derivative and Talking Machines, both data science related. Talking Machines is more industry focused whereas Partially Derivative is more fun. Also Reply All, a show about the Internet. Non tech I listen to the History of Philosophy podcast.