TL;DR: Kustomize patches a base with overlays and stays declarative YAML throughout, so what is in Git is close to what is applied. Helm templates strings into YAML and adds a release lifecycle with versioning and rollback. Use Kustomize for your own applications across environments; use Helm to consume and distribute third-party software.
How to approach it
Describe the mechanism of each in one line, because they are genuinely different mechanisms rather than competing syntaxes. Then split by use case, which is where the real answer is.
A strong answer
Kustomize is a patching engine. You write a base of ordinary manifests, and each environment is an overlay that patches it: change the replica count, add a resource limit, set an image tag. There is no templating language, the base is valid YAML you can apply directly, and kustomize build shows the result before anything reaches the cluster. It is built into kubectl.
Helm is a templating engine plus a package manager. Charts are Go templates rendered with values files, producing manifests. It also tracks a release: what was installed, at what version, with what values, which is what makes helm rollback possible and why the chart ecosystem exists.
The mechanical difference matters. Helm templates strings before the YAML is parsed, so an indentation error inside a conditional produces invalid YAML at render time and the error message points at a line in generated output. Complex charts become logic-heavy and hard to reason about. Kustomize cannot produce invalid YAML that way because it operates on parsed structures, but it also cannot express conditional logic, so anything dynamic gets awkward or impossible.
So my split:
Your own applications across environments: Kustomize. The differences between dev, staging and production are almost always small and structural (replicas, resources, ingress host, config values), which is exactly what patching expresses well. What sits in Git reads like Kubernetes rather than like a template, which matters when someone is debugging at 3am.
Third-party software: Helm. You are not going to write a Prometheus or a cert-manager deployment by hand, and the chart is how those projects distribute. Consuming a chart is the normal path and there is no reason to fight it.
Distributing software to others: Helm, because values files are a real configuration interface and versioned charts are a real distribution mechanism.
The wrinkle worth naming: Argo CD normally renders charts and manages the resulting resources without a Helm release. Flux helm-controller instead performs Helm installs/upgrades and tracks real releases through HelmRelease objects. Reverting Git can change either desired state, but their lifecycle and hook behavior differ. Rendering charts into committed manifests is a third workflow with its own update ownership. Flux HelmRelease. That also makes the diff in a pull request show what will actually change, which templated charts do not.
They also compose: Kustomize can patch the output of a Helm chart, which is the common pattern for taking a community chart and adjusting something its values do not expose.
What interviewers probe next
"Where does Helm store release state?" Secrets in the release namespace by default. Which means it is cluster state, and losing it loses your release history, and it is a second source of truth alongside Git.
"How do you handle secrets in either?" Neither solves it. External Secrets can reference a remote secret. SOPS and Sealed Secrets store encrypted values in Git and decrypt through separately managed keys and controllers; encrypted content is not merely a reference.
"What is a post-renderer?" A hook that lets you modify chart output before apply, typically to run Kustomize over it. The escape hatch for a chart that does not expose what you need.
Common mistakes
Arguing syntax preference rather than mechanism. Templating strings and patching structures fail differently.
Writing an in-house chart with heavy conditional logic for one application, which is the hardest way to express three small environment differences.
Ignoring the overlap with GitOps, which changes the value of Helm's release tracking considerably.