TL;DR: A pod is one or more containers that share a network namespace, an IP address and optionally storage, scheduled together onto one node and living and dying as a unit. Kubernetes needs that unit because some containers only make sense running beside another one on the same machine.
How to approach it
Answer the "why" before the "what". Anyone can recite that a pod is the smallest deployable unit; the interesting part is what the containers inside one share, because that is the reason the abstraction exists at all. Then give one real case where you would put two containers in a pod, and one where you would not.
A strong answer
Containers inside a pod share three things.
A network namespace, so they share an IP address and a port range. Two containers in the same pod reach each other on localhost, and they cannot both bind port 8080. From outside, the pod has one address.
Storage, when you mount the same volume into both. An emptyDir volume is the usual way one container writes a file and another reads it.
A lifetime and a node. They are scheduled together, they are never split across machines, and deleting the pod deletes all of them.
The reason this abstraction exists is that certain things are genuinely one unit. A service and its log shipper. An application and a proxy handling its TLS. A container that fetches configuration from a remote store and writes it to a volume before the main process starts, which is what an init container is: it runs to completion first, and the main containers do not start until it exits successfully.
The rule for when to add a second container: only when it must be on the same machine as the first, and only when it makes no sense to scale the two separately. A proxy handling every request for one application qualifies. A background job that happens to be written by the same team does not, because scaling the application would scale the job with it, and you almost never want that.
Worth saying out loud: you rarely create a pod directly. You create a Deployment, and it creates a ReplicaSet, which creates pods. A bare pod has nothing watching it, so when the node it is on dies, it is simply gone. That fact catches people out, because kubectl run produces exactly that.
One more thing beginners find surprising: common Linux runtimes use a pod sandbox, often implemented with a pause container, to hold shared namespaces. The implementation varies by runtime; it is not an extra application container that you configure in the pod spec.
Choose the pod boundary by failure and scaling behavior
Imagine an API container and a local proxy sharing one pod. They communicate over localhost and scale together: increasing the Deployment from four to eight replicas also creates four more proxies. That is useful when every API instance needs its own proxy. A report-generation worker with a different queue and memory profile should usually have its own workload controller so it can scale independently.
Sharing a pod also shares placement constraints. A large sidecar request can make the entire pod unschedulable even when the application container alone would fit. Sum the relevant resource requests using Kubernetes scheduling rules and inspect init-container requirements before blaming the application's request.
To investigate identity after a failure, record the pod UID as well as its name, assigned node and container restart count. A container restart within the same pod differs from controller-created replacement. Design clients around Service discovery and application retries rather than relying on an old pod IP remaining valid.
What interviewers probe next
"What happens to a pod's IP when it restarts?" A container restarting inside the pod keeps the IP. The pod being replaced gets a new one, which is why nothing should ever address a pod by IP and why Services exist.
"Can containers in different pods share a volume?" Not an emptyDir. Sharing depends on the volume and access mode. ReadWriteOnce permits use from one node and can include multiple pods there; ReadWriteOncePod restricts a supported CSI volume to one pod. Neither makes concurrent application writes safe. Volume access modes.
"When does a pod restart versus get replaced?" A container crashing is restarted in place by the kubelet, and the restart count goes up. Eviction or node loss can lead its controller to create a replacement with a new UID. Names may be reused by controllers such as StatefulSet, and a bare pod has no controller to replace it.
Common mistakes
Saying a pod is "a wrapper around a container" and stopping, which explains nothing about why it exists.
Putting several unrelated containers in one pod because they belong to the same feature, then being unable to scale or update either independently.
Creating bare pods for anything real, so nothing recreates them after a node failure.
Assuming two containers in a pod can both listen on the same port. They share the network namespace, so the second one fails to bind.