TL;DR: It proxies public registries so an upstream outage or a deleted package does not stop your builds, hosts your own artifacts, and gives you one place to scan and control what enters the organisation. The proxy cache alone usually pays for it within a quarter.
How to approach it
Answer with failures you have seen rather than features. The three that carry this argument are an upstream outage stopping every build, a version disappearing, and being unable to answer "are we affected" when a widely-used package turns out to be compromised. Then cover the repository types, because that is the part with practical detail.
A strong answer
A repository manager sits between your builds and the outside world, and serves three kinds of repository.
Remote (proxy) repositories mirror an upstream: Maven Central, npm, PyPI, Docker Hub. The first request fetches and caches; every later request is served locally. That gives you three things. Builds keep working when the upstream is down or rate-limiting you, which for Docker Hub's anonymous pull limits is a routine occurrence rather than a hypothetical. Builds keep working when a package is unpublished or a tag is deleted upstream, which has broken large parts of ecosystems more than once. And you get one egress point, so the build network does not need to reach the whole internet.
Local (hosted) repositories hold what you produce: your images, your libraries, your Helm charts. This is where promotion happens, moving a build from a snapshot repository to a release repository rather than rebuilding it for each environment.
Virtual (group) repositories present several of the above behind one URL, so a developer configures one registry and the manager resolves across the local and proxied ones in a defined order. That resolution order matters for security: if a virtual repository checks the public proxy before your local one, an attacker who publishes a public package with the same name as your internal one can have it resolved instead. That is dependency confusion, and configuring the order so internal always wins, plus excluding your own namespaces from the public proxy, is the mitigation.
The supply-chain argument is what usually gets this funded. One place every dependency passes through means you can scan on entry, block by licence or severity, and answer the question that arrives on a bad morning: which of our builds used this package, and when. Without a repository manager that question takes days of archaeology across build logs.
The practical pieces to mention. Retention matters, because these grow without bound: snapshot builds expire on a schedule, releases are kept, and image tags need a policy or the storage bill becomes the story. High availability matters more than people expect, since once every build depends on it, the repository manager is a single point of failure for all delivery, and it needs the same treatment as any other production system. And checksum-based storage means the same artifact stored once regardless of how many repositories reference it.
On choosing: Artifactory covers the most package types and has the most mature promotion and replication features, at a real licence cost. Nexus covers the common formats well and is cheaper, with a capable free tier. Cloud-native options like Azure Artifacts, GitHub Packages and AWS CodeArtifact are simpler and sufficient when you are within one ecosystem and do not need cross-format promotion.
What interviewers probe next
"What is the difference between this and a container registry?" A container registry handles one format. A repository manager handles many, which is what you want when one team ships jars, another npm packages and another Helm charts, and you want one policy and one scan across all of them.
"How do you handle an artifact that must never be deleted?" A release repository with deletion disabled and immutable tags, plus a retention policy that only ever touches snapshots. Anything a deployed release references has to outlive the release.
"Does this slow developers down?" Only if it is a gate with no cache. Done properly it is faster than the public internet, because the cache is on your network.
Common mistakes
Pulling directly from public registries in production builds, so an upstream outage or a rate limit stops delivery.
A virtual repository that resolves the public proxy before the local one, which opens the door to dependency confusion.
No retention policy, so storage grows until somebody deletes things in a hurry and breaks a rollback.
Treating the repository manager as developer tooling rather than as production infrastructure, and running it without redundancy.