How does hashing differ from encryption, and when would you use one over the other?

These two get conflated constantly, but they solve different problems and behave in opposite ways.

Encryption is reversible

Encryption transforms plaintext into ciphertext using a key, and crucially that transformation is reversible: anyone with the right key can recover the original data. Its job is confidentiality — keeping data secret from people who lack the key. If you ever need the original value back, you want encryption.

Hashing is one-way

A cryptographic hash function takes input of any size and produces a fixed-size digest. It is deliberately one-way: there is no key, and you cannot feasibly reverse the digest to recover the input. Good hash functions are also collision-resistant (hard to find two inputs with the same digest) and exhibit the avalanche effect (a one-bit change scrambles the whole output).

Hashing answers questions like "is this file unchanged?" or "does this password match?" without ever storing or revealing the original data.

Why passwords are hashed, not encrypted

If you encrypted passwords, anyone who stole the key could decrypt every password at once. Hashing means even the database operator cannot recover them. But you must do it right:

• Salt each password with a unique random value so identical passwords produce different digests and precomputed rainbow tables are useless.
• Use a slow, work-factored algorithm — bcrypt, scrypt, or Argon2 — not a fast general-purpose hash like SHA-256. Slowness is a feature: it throttles brute-force attempts.

What interviewers look for

The core test is "reversible vs one-way" and matching each to confidentiality vs integrity. The senior-sounding answer adds that passwords need salting and a deliberately slow algorithm, not plain SHA-256.