TL;DR: TCP is a connection with ordering, retransmission and flow control; UDP is a datagram with none of that. You choose UDP when a late packet is worth less than a lost one, or when you want to build your own recovery, which is exactly what QUIC does.
How to approach it
Give the mechanics briefly, then spend the time on the choice, because the definition is memorised and the reasoning is not. Have two concrete examples ready: something that must use TCP and something that is better off without it. DNS is useful because it does both.
A strong answer
TCP establishes a connection with a three-way handshake (SYN, SYN-ACK, ACK) before any data moves. That is one round trip of latency before the first byte, and with TLS on top it has historically been two or three. In exchange you get: bytes delivered in the order they were sent, retransmission of anything lost, flow control so a fast sender does not overwhelm a slow receiver, and congestion control so it backs off when the network is saturated.
UDP sends a datagram and stops. No handshake, no ordering, no retransmission, no congestion control. A packet may arrive, arrive twice, or arrive after one sent later. The header is 8 bytes against TCP's 20, and there is no per-connection state on either end.
When UDP is the right choice:
Real-time media. In a voice call, a packet that arrives 400ms late is useless, because that moment of audio has already passed. TCP would retransmit it and hold everything behind it while it did, which is worse than the small gap you would have had. Losing it and continuing is the better outcome.
High-frequency small messages where loss is tolerable. Metrics via statsd is the standard case: dropping a fraction of samples changes nothing about the aggregate, and you do not want your application blocking on a monitoring system.
When you want your own recovery. This is the interesting one. QUIC runs over UDP and reimplements ordering, retransmission and congestion control in userspace, because doing it there allows things TCP cannot: independent streams that do not head-of-line block each other, a combined transport and TLS handshake, and connection migration when a phone switches from wifi to cellular. HTTP/3 is HTTP over QUIC over UDP, which means "UDP is unreliable" is a statement about the protocol rather than about what you can build on it.
Where the pattern is request-response and small. DNS is the classic: one small query, one small answer, and a retry is cheaper than a handshake. It falls back to TCP when the response is too large or when the transaction needs reliability, such as a zone transfer.
The head-of-line blocking point is worth making explicitly, because it is the crispest illustration of the cost of ordering. TCP guarantees order, so if packet 3 is lost, packets 4 through 20 sit in the receiver's buffer and the application sees nothing until 3 is retransmitted. One lost packet becomes tail latency for everything queued behind it. The data arrived; the ordering guarantee is what withholds it.
What interviewers probe next
"How would you debug a UDP problem?" Harder, and worth saying why: there is no connection state, so no equivalent of a connection count. tcpdump on both ends to see whether the datagram left and arrived, and counters in netstat -su for receive buffer errors, which is the usual cause of silent loss under load.
"Does UDP guarantee anything?" A checksum on the payload, so corruption is detected and the datagram is dropped. Corrupt delivery is prevented; nothing else is.
"What is a connection in UDP then?" Nothing at the protocol level. Any notion of a session lives in the application or in a stateful middlebox, which is why NAT traversal and firewall timeouts behave so differently for UDP.
Common mistakes
Saying UDP is "faster" without saying what it gives up. It removes latency from handshakes and retransmission, and it moves no data more quickly.
Describing UDP as unsuitable for anything serious, in a world where HTTP/3 runs on it.
Forgetting congestion control, which is the part that makes a naive UDP flood antisocial as well as unreliable.
Treating packet loss in a voice call as a defect, when accepting it is the design.