When you pick a password, they know what you typed in and can validate that it fits the rules (> 8 chars, mix of letters and numbers etc).
But as mentioned they don't store your password, they store a hashed version of it. Like frying an egg, it's an irreversible change. If you have the original password you can make the hash, but if you have the hash you can't figure out the original.
When it comes to 32 byte hash functions, it's almost impossible for two input passwords to give you the same hash value output.
When you try to login down the road, you type your password, they then hash it using the same function. Then they read the value stored in the database and if the two hashes match, they know you typed your password correctly because again you can only get the same hash if you use the same input.
Why do this? One reason is because if the database is compromised, they won't know your password and can't try to login to other services using your name/email and password.
This is the most simple version, if you're smart when you design your system you also salt your hashes. What salting does, is take a random bit of data (maybe the exact time in milliseconds past 1970) and append that to your original password. Then both those values; your original password and the salt, are used as the input for the hash and the result of hashing that is stored in the database, along with the salt (random bit of data) stored separately. Then when you type your password, they lookup the salt for your name/email, append the salt again to your input password, and test if the hashed value matches the value stored in the database.
Using salt means that your hashed password will never be found in somebody elses database.
If you use your email + same password on my site and on google, and then my site is hacked and they can read my database; they then know what the hashed password is. Though they still can't read what you put in originally, they can run millions of words/phrases into a hash function and build a table. The hash of "test" = "alskdjflkjlkjsdf", the hash of "oil" = "llkjsdflkjslkdfj" etc etc (not real hash values). Then if they see "alskdjflkjlkjsdf" in my database, they look for that value in their table of millions of pre-calculated hashes, and when they get a match they know that your password must have been "test".
However, if you salt your hashes as described above, then they can't lookup "alskdjflkjlkjsdf" in their table and attempt to login to google with your email/password, because every site uses different salts and so your hashed password is different on every database even though you used the same input password.
Edit: for the 6 previous passwords: again, they don't store your unencrypted version of the password, they store the hashed version of the password. When you are forced to type in a new password for the 7th time, they hash your password and get "lkjsldkfjl" (say). Then they look if "lkjsldkfjl" is one of the previous 6 values and if it is, they say "sorry, pick something different".
Edit2: Bottom line: if a site claims to be able to email you your password back, run from it. A secure system will never be able to tell you your password.
Password managers are the only tool that is the exception. They build an encrypted database using a single password. Like a lock box, if you have the one key you can get into the box and read everything stored inside it. The lock box is not storing your hashed password, they are storing your original unhashed passwords. Those values are encrypted using a single password so once you know the master password, you can unencrypt the database and read all your password values.