The password is normally sent in plaintext over an encrypted connection to the server. The server then calculates the hash of the password and compares it against the entry in the database.
The hash and salt are stored in the database together. The hash function is coded into the application. For applications which support multiple hash functions (usually for changing the hash function in future) there may be a flag to suggest which algorithm was used for that particular password. The hash storage format may also offer clues as to which algorithm was used (hash length can be an indicator. Formats like bcrypt store the details of what is used directly). Alternatively someone with a copy of the authentication database tables can attempt common passwords with an assortment of algorithms until they find a hash that exists.
when a hacker tries to brute force their way into a system they need to find the hashed password, the salt and the hash function
This isn't true. A hacker that has obtained a copy of the authentication database tables may try to reverse the hashes. This is useful because many users re-use credentials. There are many ways to obtain a copy of the tables - including but not limited to finding an exploitable channel to gain a shell (command prompt / terminal where you can execute commands directly) on the server, SQL injection, the database being open to the internet with default credentials or a tired developer accidentally checking in access tokens to a public git repository.
To do so you would normally try large lists of common passwords, common dictionary words and for ~9 characters a full brute force. This usually results in reversing a large percentage of the available hashes.