By taking advantage of prior work we can accelerate our learning and our impact. Know that while joining a new team is non-trivial, it doesn't have to be hard! Use the scientific method. You'll gain confidence in your abilities and make a good first impression while you're at it.
Pay attention to just what it is that you're setting up. Noting the order in which you run internal projects helps you understand dependencies. A good way to start experimenting with and understanding the code is to get that test suite successfully running, then make changes to the codebase completely at random and see what breaks.
Some teams will have a document describing this, and if that document is an accurate depiction of reality then you should certainly work to understand it. In any case, asking a more senior person on the team to give you an overview is a good idea.
An important question to ask is: How does a feature get from my machine to live production? This would cover things like repositories used, deployment pipelines, testing, and external dependencies.
Figure out the mission, product offering, and goals.
Balance understanding each intricate detail against making impact quickly. Understand something just enough to express what it does without necessarily knowing exactly how it does that.
Search for artifacts that were created as part of the software development cycle. Particularly useful are issue trackers like JIRA/Asana/Pivotal Tracker, pull requests and issues in tools like GitHub and GitLab, and the git history itself. Sometimes you'll find a pull request that implements something very similar to what you want to do, and you can use that as a guide. Trying to divine something from scratch, while sometimes necessary, requires significantly more effort than adapting from an example.