TL;DR: ClusterIP gives a stable internal address, NodePort adds a port on every node, and LoadBalancer adds a cloud load balancer in front of that. They stack, so a LoadBalancer Service is still a ClusterIP underneath. In production almost everything is ClusterIP with one Ingress at the edge.
How to approach it
Lead with the stacking relationship, because most candidates present the three as alternatives and then cannot explain why a LoadBalancer Service still has an internal IP. Then say what you would actually run, which is the part an interviewer is listening for: one load balancer for the cluster, not one per service.
A strong answer
Start with the problem all of them solve. Pods are replaced constantly and each replacement gets a new IP, so nothing can depend on a pod address. A Service is a stable name and a stable virtual IP that keeps pointing at whichever pods currently match its selector.
ClusterIP is the default. The Service gets a virtual IP that only works inside the cluster, plus a DNS name (payments.prod.svc.cluster.local). Traffic to that IP is rewritten by the node's dataplane to one of the healthy pod IPs. This is what service-to-service calls use, and it is the right answer for the overwhelming majority of Services.
NodePort is a ClusterIP plus a port opened on every node in the cluster, by default somewhere in 30000-32767. Hit any node on that port and you reach the Service, even if no pod of that Service runs on that node. It is useful for a bare-metal cluster with something else in front, and for local development. In a cloud environment it is mostly a building block rather than something you expose directly, because the port number is ugly, the range is restricted, and you have to know node addresses that change.
LoadBalancer is a NodePort plus a request to the cloud provider for a real load balancer pointing at those node ports. You get a public IP or DNS name. The catch is the one worth naming in an interview: each LoadBalancer Service provisions its own cloud load balancer, and each of those is a monthly bill. Forty microservices exposed this way is forty load balancers.
ExternalName is the odd one out and does no proxying at all. It maps a Service name to an external DNS name via a CNAME, which is handy when you want in-cluster code to call database and have that resolve to a managed database hostname you can change later.
What I would run: every internal Service as ClusterIP, and one Ingress controller or Gateway at the edge, exposed with a single LoadBalancer, routing by hostname and path to those ClusterIP Services. One cloud load balancer, TLS terminated in one place, and routing rules that live in Kubernetes objects rather than in the cloud console.
One more detail that comes up: a Service with clusterIP: None is a headless Service. DNS returns the pod IPs directly instead of a virtual IP, which is what StatefulSets use so each replica is individually addressable.
What interviewers probe next
"How does the Service know which pods to send to?" A label selector, matched continuously. Pods that match and pass their readiness probe are in the endpoint list; anything failing readiness is removed, which is how a rolling update avoids sending traffic to a pod that is still starting.
"Is a Service a proxy?" Not a process in the path. The node programs rules (iptables, IPVS, or eBPF) so the packet is rewritten in the kernel. That is why Service traffic adds almost no latency and why there is nothing to scale.
"How does it balance?" Roughly randomly per connection, in the kernel, with no awareness of load. If you need real load balancing policy, retries or circuit breaking, that is what a mesh or an Ingress controller gives you.
Common mistakes
Presenting the three types as unrelated options rather than layers, then being unable to say what a LoadBalancer Service's ClusterIP is for.
Giving every microservice its own LoadBalancer, which works and produces a cloud bill nobody can explain.
Confusing a Service with an Ingress. A Service does not understand HTTP, hostnames or paths; it works at the connection level.
Forgetting readiness. Pods that match the selector but are not ready get no traffic, and that is a feature rather than a bug.