this is a good strategy. You want to understand the flow, and discover what is important to accomplish particular use cases. This should also tell you about interfaces, which helps with divide-and-conquer against the code base. You also want to be able to reproduce builds and configurations, so you need to identify the related parts for a particular component.
Tactically reading code may not seem productive, but if the source is versioned and someone has explained the history of the application, you might be able to pull diffs and see what code was the target of changes, thus telling you what is the focus of attention. Code that isn't changed very much but is used a lot tells you what are truly fundamental parts of the overall systems. Commits may help with identifying who to ask about a particular section. Perhaps the committer might have or be able to identify some relevant documentation relating to their specific work. The build can tell you about the relevant part of the code base in use as well. Often an org may have documentation, but the docs may not be well indexed. Running code is the index.
I'm "experienced" and get kinda curmudgeonly ( or worse ) when I work someplace that runs the developer shop like it's 1999 or earlier, so I'm always vigilant for anti-patterns in the interview...the situation the OP describes would be one of those - if job position is not "heroic individual contributor" I would expect some sensible on-boarding for new devs supervised by a knowledgeable guide, with some example tasks to help get up to speed. Successful orgs do this. Orgs that don't are prone to failure and devaluing your shares through repeated VC financing, heheh.