You tap "Forgot password", and a minute later the site emails you your old password. Helpful? An interviewer might ask exactly this: "Is that good service or a red flag? And how would you store passwords?" It is a red flag, and the reason leads straight to how passwords should be stored.
If it can send it back, it kept it readable
A site that can email you your old password has stored it in a form it can read: plain text, or encryption it can undo. Then a single database leak exposes every user's password, and because people reuse passwords, the damage spreads to their other accounts too.
Encryption sounds safer, but it is two-way: whoever has the key can decrypt, and the key often sits where an attacker can reach it. Adobe learned this in 2013. Its breach exposed 153 million accounts whose passwords were encrypted with Triple DES, not hashed, using one key for every password, with the password hints in plain text. Identical passwords gave identical encrypted values; nearly 1.9 million accounts used "123456".
Hashing: the chutney
The right tool is a hash, which works like grinding chutney. You can't turn chutney back into tomatoes and chillies, but the same recipe in the same grinder gives the identical chutney every time. The site keeps the chutney in a jar. At login it grinds what you typed and compares the result with the jar. So it never needs to store your password at all; it only ever sees it for the moment you log in.
Two problems, two fixes
Same password, same hash. Because the same input always gives the same hash, an attacker can grind common passwords in advance and simply look up leaked hashes in that table. Everyone who used "123456" shares one hash. The fix is a salt: a random value, different for each user, mixed in before hashing. Think of a different pinch in each person's chutney, with the pinch's name written on the jar's label. The salt isn't secret, but now the same password gives different hashes, the precomputed table stops working, and every account has to be attacked separately.
Fast hashes are too fast. General-purpose hashes like SHA-256 are built for speed, like an electric mixer. In hashcat's published benchmark, one RTX 4090 computes about 22 billion SHA-256 hashes per second, so a leaked database can be checked against huge word lists quickly. Passwords need a sil-batta instead: a password hash that is slow on purpose, such as bcrypt, scrypt or Argon2id, which OWASP recommends. One login barely notices the cost; billions of guesses become expensive. It buys time, not magic: a very weak password still falls.
Back to "Forgot password"
A well-built site can't email your old password, because it never kept it. Instead it sends a random reset link that works once and expires. OWASP's Forgot Password guidance puts it bluntly: "do not send the password in the email!"
The answer to give
A site should never be able to tell you your password.
In the interview: "It's a red flag. I'd never store the password, encrypted or not, and no password hints. Every user gets a random salt, I hash with a slow password hash like Argon2id or bcrypt, compare hashes at login, and Forgot password sends a single-use reset link that expires."
Sources: OWASP Password Storage Cheat Sheet; OWASP Forgot Password Cheat Sheet; NIST SP 800-63B-4; Have I Been Pwned, Adobe; CSO Online on Adobe; hashcat RTX 4090 benchmark.