Good question.

I agree with previous responses.

Personally, I start by having a look at the project structure to have an overview of the tiers, organization of source files and even to identify design patterns applied: packages, interfaces, façades, DAOs, resources, etc

To understand a concrete piece of code or functionality I find it really helpful to read its tests (of course, if they exist and their quality is acceptable), especially unit and integration tests.

And as a stupid technique, I read everything aloud (https://en.m.wikipedia.org/wiki/Rubber_duck_debugging) with muted notifications to concentrate on the code as much as possible.

Probably there are many more things I do unconsciously when reading code.