TL;DR: A namespace is a scope for object names, RBAC rules, resource quotas and network policy. Use one per team or per environment-within-a-cluster, not one per service. It is not a security boundary against a container escape, and network traffic crosses it freely unless you write a policy.
How to approach it
Give what it scopes and what it does not, in that order. The second half is the part that matters and the part most answers miss, and an interviewer who asks this on a platform team is usually checking whether you would treat a namespace as isolation for something it cannot isolate.
A strong answer
What a namespace scopes:
Names. Two teams can both have a Deployment called api without colliding. Within one namespace, names must be unique per resource type.
RBAC. A Role and RoleBinding apply inside a namespace, so you can grant a team full control over their own space and nothing outside it. This is the most common reason to create one.
ResourceQuota and LimitRange. A quota caps the total CPU, memory and object counts a namespace may consume, and a LimitRange sets defaults so a pod submitted with no requests is either given some or rejected. Without quotas, one team's mistake consumes the cluster.
Network policy, if you write one. Policies are namespaced and select pods by label.
What it does not scope, which is the more useful list:
The kernel. Every pod on a node shares it. A container escape is not contained by a namespace, which is why untrusted workloads need a sandboxed runtime or a separate cluster.
Networking, by default. Kubernetes networking is flat: any pod can reach any other pod in any namespace by IP. The isolation people assume they are getting only exists once a NetworkPolicy with a default deny is in place.
Nodes. Pods from different namespaces land on the same machines and share page cache, disk and network bandwidth.
Cluster-scoped objects. Nodes, PersistentVolumes, StorageClasses, CustomResourceDefinitions and ClusterRoles are not in any namespace, so a team that needs its own CRD needs more than a namespace.
For the practical question of how to divide them: one per team, or one per team per environment if you run multiple environments in a cluster. Not one per microservice, which gives you four hundred namespaces, four hundred sets of quotas and RBAC to maintain, and no benefit, since a Deployment already groups its own pods.
Production and non-production belong in different clusters rather than different namespaces. They share a control plane otherwise, and a mistake in one can exhaust the API server for the other.
Two things that bite beginners. kubectl get pods only shows the current namespace, so a missing pod is usually in another one; -A shows all. And deleting a namespace deletes everything in it, including PersistentVolumeClaims, and the deletion blocks until every object's finalizers complete, which is why a namespace can sit Terminating for a long time.
What interviewers probe next
"Can a Service in one namespace be reached from another?" Yes, by its fully qualified name, payments.prod.svc.cluster.local. Short names only resolve within the same namespace, which is what the search domains in the pod's resolver configuration do.
"How would you stop that?" A NetworkPolicy with a default deny on ingress in the destination namespace, allowing only the namespaces or pod labels you name. It needs a CNI that enforces policy, which not all do.
"What is in the default namespace?" Whatever somebody created without specifying one. Nothing should live there in a real cluster, and a default full of objects is a reliable sign nobody is looking after it.
Common mistakes
Treating a namespace as a security boundary and running untrusted code in one.
Assuming pods in different namespaces cannot reach each other, when the default is that they can.
One namespace per service, which multiplies administration without isolating anything a Deployment did not already separate.
Applying quotas with no LimitRange, so pods with no requests are admitted and the quota accounting becomes meaningless.