Network Architecture and Design Methodology
Start with requirements, not boxes
Architect-level questions reward candidates who can show a repeatable methodology: capture business and technical requirements, derive a logical design, validate it against constraints, then produce a physical implementation and migration plan. Know the vocabulary of structured design (hierarchical core/distribution/access, modularity, redundancy, scalability, manageability) and the difference between a logical topology (VLANs, subnets, routing domains, trust boundaries) and a physical topology (devices, links, media, power).
Capacity and availability math
Be comfortable with simple quantitative reasoning. Redundancy questions often hinge on whether a design tolerates a single failure (N+1), maintains service during maintenance (N+N), or survives a site loss. Availability is a product of serial dependencies, so adding components in series reduces end-to-end availability unless each is highly reliable; parallel paths improve it. Traps include confusing MTBF with availability, treating a redundant power supply as protection against a switch failure, and assuming a redundant link helps if both links share one conduit or one upstream device.
Design artifacts and validation
Know what belongs in a design document (requirements traceability, bill of materials, IP/VLAN plan, routing and QoS policy, physical and logical diagrams, test and acceptance criteria). Questions frequently test whether you validate the design against the requirements before implementation rather than after.
Worked rule of thumb
For any proposed topology, ask three questions in order: (1) What fails if this single element fails? (2) What shared dependency do the "redundant" paths have? (3) Does the design still meet the stated requirement at that failure point? If the answer to (3) is no, the requirement was never met.