Work versus facts
A queue distributes work. Ten workers read from it, and each message goes to exactly one of them, whichever grabs it first. That is what you want for jobs: one email per order, not ten.
A topic broadcasts facts. Every subscriber gets every message. Publish that an order was placed once, and your notification service, your analytics pipeline and your fraud detector each get their own copy to handle independently.
Keep ten instances inside each of those services if you like, sharing the load between them. The service as a whole still sees the whole stream.
Look past the mechanics to the real difference: who knows about whom. With direct calls, your producer encodes its consumers: checkout calls email, then loyalty, then analytics, and adding a fourth step means editing checkout.
With pub-sub, checkout publishes what happened and stops. Teams subscribe without checkout's involvement or even its knowledge, and six months later there are seven subscribers and checkout has not changed a line.
The decoupling is the actual product. The broadcasting is only how you get it.
Facts, not commands
Rename your messages accordingly, because this changes what they should say. A queue message is an instruction, send this email, aimed at its one consumer. An event on a topic is a fact in the past tense, order 4412 was placed, carrying enough context for subscribers the publisher has never heard of.
Getting that right, facts instead of commands, is most of the difference between pub-sub that scales across an organisation and pub-sub that quietly rebuilds the coupling you removed.
Carry one warning into interviews and production alike. Pub-sub is not automatically durable. Whether a subscriber that was down for an hour ever sees what it missed depends entirely on your broker. That is where the next two lessons go.
Worked example
At a subscription box company, checkout originally calls three services in sequence after each order: email, inventory, referral credits. Each new feature adds a call, each call adds latency and a failure mode, and by the time the analytics team asks for order data, checkout takes 900 ms and its owner Dario is the approval bottleneck for four other teams. He replaces the chain with an order.placed event on a topic. Checkout publishes in 5 ms and returns; email, inventory, and referrals subscribe and process in parallel. When the analytics team and later a new fraud vendor need orders, they subscribe themselves, and Dario finds out from the broker's subscriber dashboard, not from a meeting invite. Checkout's post-order code has not been edited in the year since, which he counts as the pattern working.