When a new node joins the network, it will look up nodes from the DNS seeds. It'll reach out to multiple nodes it hears about and ask them for more peers in turn. The new node asks each of their peers for their best chaintip and then starts sychronizing the headers of the best chaintip it hears about first. A block header is only 80 bytes (tiny in comparison to complete blocks) but already allows checking that all the blocks on that chain are connected and that the blocks are meeting the difficulty criteria.

From then on, the node verifies each block in order to validate that the consensus rules were followed. If the best chaintip they were following is found to be injuring any consensus rules, the first block to be invalid is discarded and the peers that follow this chain disconnected. The best chaintip from that point on is found instead is found by querying the remaining (rule-compliant) peers. Finally, the node will discover the valid chain with the most accumulated difficulty.

Each release of Bitcoin Core sets a default value for the assumevalid parameter to a block that recently preceded the release. When synchronizing up to that block, nodes using assumevalid will assume that the history up to that block is valid. They will still calculate all the UTXO set transitions and check difficulty everywhere, but will not check signatures on transactions up to that block.

Yes a full node downloads and verifies all blocks starting from the genesis block. Not on every startup though, the state is efficiently stored and read back into memory on startup (with some rechecking of the last X blocks as a sanity check against corruption). For finding the right chain, it starts with downloading the headers first, with which it can determine the most-work chain, so it doesn't need to download all forks along the way (unless it encounters an invalid block). Yes, this can take a while, but it's at the core of how bitcoin achieves being trustless: validate everything yourself.