TL;DR: A VM runs a full guest kernel on virtualised hardware. A container is an ordinary Linux process whose view is narrowed by namespaces and whose resources are capped by cgroups, sharing the host kernel. That sharing is why containers start in milliseconds and why they are a weaker isolation boundary.
How to approach it
Answer with the mechanism rather than the diagram. Most people draw the two stacks and say containers are lighter, which is the observation rather than the reason. Naming namespaces and cgroups specifically, and then drawing the security conclusion from the shared kernel, is what makes this sound like knowledge rather than a slide.
A strong answer
A virtual machine is created by a hypervisor that presents virtual hardware: a CPU, disks, network cards. On top of that you install a full operating system with its own kernel. Booting means booting an OS, which takes tens of seconds, and the image is measured in gigabytes because it contains one.
A container is not a machine at all. It is a process running directly on the host kernel, with two Linux features applied to it.
Namespaces restrict what the process can see. A PID namespace means it sees its own process tree starting at PID 1 and cannot see the host's processes. A mount namespace gives it its own filesystem view, which is how the container image becomes its root directory. A network namespace gives it its own interfaces and routing table, so it has its own IP. There are others for hostname, users and inter-process communication. Each one narrows a dimension of what the process perceives.
cgroups restrict what it can consume: a CPU quota, a memory limit, IO bandwidth. Exceed the memory limit and the kernel's OOM killer terminates the process, which is what an OOMKilled pod actually is.
That is the whole mechanism. ps on the host shows the container's processes as ordinary processes, because they are. There is no guest kernel, no virtual hardware, no boot.
The consequences worth stating:
Start time is process start time, milliseconds rather than a boot. Image size is your application plus its dependencies, tens or hundreds of megabytes, because the kernel is not in there. Density is much higher, since there is no per-VM operating system overhead.
And the security consequence, which is the one interviewers are usually driving at. All containers on a host share one kernel. A kernel vulnerability exploited from inside a container reaches the host and every other container on it. A VM escape has to get through the hypervisor, which is a much smaller and more heavily defended surface. So containers are an excellent isolation boundary between your own cooperating workloads and a weak one for anything untrusted. If you run code a customer supplied, you want a sandboxed runtime like gVisor or Kata (which puts a lightweight VM back underneath) or a separate machine.
The practical point about portability: a container image carries your dependencies but not a kernel, so it depends on the host kernel's ABI and on the architecture. An arm64 image does not run on an amd64 host without emulation, which is why multi-architecture images exist.
What interviewers probe next
"Why does a container image need a base like Debian or Alpine then?" For userland: libc, shell, certificates, package tooling. Not for a kernel. A statically linked binary needs none of it, which is what scratch and distroless images exploit.
"Can a container run a different OS from the host?" A different distribution, yes, because that is userland. A different kernel, no. Docker on macOS or Windows runs a Linux VM and the containers run inside that.
"What does --privileged do?" Removes most of the restrictions: all capabilities, access to host devices. It reduces the container to roughly a process with root on the host, and it is worth being able to say that plainly because it is requested far more often than it is needed.
Common mistakes
Saying containers are "lightweight VMs", which gets the mechanism backwards and leads to wrong conclusions about isolation.
Claiming containers are more secure than VMs. They isolate differently and the shared kernel is a larger attack surface.
Forgetting that the host kernel is shared, then running untrusted code in a plain container.
Believing an image is portable everywhere, when it is tied to a kernel ABI and a CPU architecture.