It's not the size of the code base so much as the scope and complexity of the problem that was addressed and solved. Compare:
- A website with one product for sale and paid for through PayPal.
- A commercial site that displays thousands of products in hundreds of categories, indicating realtime quantity-in-stock, expected shipping time and taxes for international customers, connected to the main production systems so that the warehouse pick-pack-ship process is triggered automatically, invoices (with appropriate discounts) are generate as product is shipped, etc., etc.
Yes, the second system will be larger, but it's the complexity of getting all of these systems humming the same tune that makes this an architectural challenge. (Especially when half the systems are legacy and if you touch them/screw them up you die.)
So I would say this: give the person interviewing you the Big Picture® (either verbally or in an Executive Summary type document), and then offer to go into any level of detail they desire of any of the workflows or subsystems.