How can a random salt for a hash function work in practice? I understand the theory behind the use salts in hash functions, but when I see it  implemented, the implementations always generate the salt on the fly and the salt appears to be different for every hash. 


When implementing a salt for users signing into a website, doesn't the salt need to be the same at account creation as the salt used when the user wants to log in? 
In implementation, wouldn't the salt be the same every time? 
I understand that the salt may be different from user to user (in my example), but when user A signs in on Monday, and again on Friday, wouldn't the salt need to be the same for both those times?
Usually, when the user registers, you will generate a random value to become the salt. Then, in the user database, you store the user's name, salt, and hash generated using the password and salt (and whatever else is relevant for a user table).

Note that doing it this way allows each user to have a unique salt. Each user having a unique salt greatly increases attack difficulty. An attacker is forced to do a brute-force attack per user instead of precomputing per-password-scheme rainbow tables (no salts) or a per-database rainbow table (a system-wide salt). It is still your responsibility to make sure the brute force attack is actually slow enough to be costly to an attacker in these days of massively parallel GPU hash implementations.

Ideally, an attacker would not even be able to see the salt on the database, but it does not have to be private if worse comes to worse.