TL;DR: The number after the slash is how many leading bits are the network, so the remaining bits are hosts: a /24 has 8 host bits, 256 addresses, 254 usable in a traditional network and 251 in an AWS subnet. Size subnets generously, because a VPC CIDR cannot be shrunk and an undersized subnet is a rebuild.
How to approach it
Do the arithmetic out loud, then move to the practical half quickly. The calculation is the easy part and the interviewer usually wants to reach the design question: how you would carve a VPC, and what happens when you get it wrong. Mention the cloud-specific reservations, because that detail only comes from having done it.
A strong answer
CIDR notation is an address plus a prefix length. 10.0.1.0/24 means the first 24 bits identify the network and the remaining 8 identify hosts within it. So:
/24 -> 32 - 24 = 8 host bits -> 2^8 = 256 addresses
/26 -> 32 - 26 = 6 host bits -> 2^6 = 64 addresses
/16 -> 32 - 16 = 16 host bits -> 2^16 = 65,536 addresses
Two addresses in any subnet are never assignable: the network address (all host bits zero) and the broadcast address (all host bits one). So a /24 gives 254 usable in a traditional network.
In AWS, and similarly in other clouds, five are reserved per subnet, not two: network, broadcast, and three more for the VPC router, DNS, and future use. A /24 subnet in AWS gives you 251 usable addresses. Getting that number right in an interview is a small signal that you have actually deployed into one.
Smaller prefix means bigger network. /16 is larger than /24, which trips people up because the number is bigger.
On design, the part that matters. A VPC gets a CIDR block, typically a /16 from RFC 1918 space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and you divide it into subnets per availability zone and per tier. A common layout for a 10.0.0.0/16:
10.0.0.0/20 public AZ a (4091 usable)
10.0.16.0/20 public AZ b
10.0.32.0/20 private AZ a
10.0.48.0/20 private AZ b
Three rules that come from experience rather than the documentation:
Do not overlap with anything you might ever peer with. Two VPCs with the same CIDR cannot be peered, and neither can a VPC that collides with the on-premises range coming over a VPN. Pick ranges from a registry your organisation keeps, not from whatever the console defaults to.
Size for the workload you will run, not the one you have. Kubernetes is the usual reason this hurts: on the AWS VPC CNI every pod takes a real VPC address, so a cluster of fifty nodes running thirty pods each needs fifteen hundred addresses in that subnet, and a /24 runs out. Pods stay Pending with an address allocation error, and the fix is not a resize.
You can extend, not shrink. Additional CIDR blocks can be added to a VPC, and a subnet's range is fixed for its lifetime. An undersized subnet means creating a new one and migrating, which for anything with a stable address is a rebuild.
What interviewers probe next
"What is the difference between a public and a private subnet?" Only the route table. A public subnet routes 0.0.0.0/0 to an internet gateway; a private one routes it to a NAT gateway or nowhere. Nothing about the addresses differs.
"How many /24s fit in a /16?" 256. Each step of 8 bits in the prefix multiplies the count by 256, and being able to do this without hesitating is half of why the question gets asked.
"What is /32 used for?" A single address. It appears constantly in security group rules and route tables to mean exactly one host.
Common mistakes
Using 254 for an AWS subnet when five addresses are reserved, not two.
Reading a smaller prefix number as a smaller network.
Choosing a VPC range that overlaps the corporate network, which surfaces the first time someone needs a VPN and cannot be fixed without renumbering.
Sizing subnets for node count when the CNI assigns an address per pod.