What is Helm and what problem does it solve that raw kubectl apply of YAML manifests doesn't?
Quick Answer
Helm is Kubernetes's package manager: it templates manifests with variables (via Charts), tracks each install/upgrade as a versioned Release with its own history, and can compute a diff-like upgrade or roll back to any prior release version. Raw kubectl apply has no templating, no built-in versioning of what was deployed, and no first-class rollback to a specific prior state.
Detailed Answer
A Helm Chart is a directory of templated YAML (using Go templates) plus a values.yaml that supplies the variables — this lets one chart be reused across environments (dev/staging/prod) by swapping values files instead of maintaining near-duplicate YAML per environment. When you helm install or helm upgrade, Helm records a Release object (stored as a Secret or ConfigMap in the cluster by default) capturing exactly which manifest was applied and with which values, and increments a revision number each time.
This gives you helm history <release> to see every past revision, and helm rollback <release> <revision> to revert to any of them — something plain kubectl has no equivalent for, since kubectl apply just applies whatever YAML you point it at with no memory of prior states beyond what's in your own version control. Helm also supports lifecycle hooks (pre-install, pre-upgrade, post-upgrade, etc.) for things like running a database migration Job before the main upgrade proceeds, and dependency management so a chart can declare and vendor other charts it needs (e.g. an app chart depending on a Redis subchart).
Interview Tip
Anchor your answer on 'templating + release history + rollback' as the three concrete things kubectl apply doesn't give you — that's more convincing than saying 'it's a package manager.'