Functional Requirements

Think of functional requirements as the "What" of your system. They are specific behaviors or functions the system must perform. In an interview, when you discuss functional requirements, you're essentially outlining the core functionalities your system should support.

Examples:

1. User Stories: If you're designing a social media app, a functional requirement could be "As a user, I want to post updates so that I can share my thoughts with my followers."
2. System Capabilities: Like processing payments in an e-commerce system, or handling search queries in a search engine.
3. Data Processing: For instance, generating monthly sales reports in a financial system.

Non-Functional Requirements

Non-functional requirements are the "How" of your system. They describe the system's operational qualities and constraints. They're crucial for ensuring the system's reliability, efficiency, and maintainability.

Examples:

1. Performance: How fast does the system respond to a user's action?
2. Scalability: Can the system handle growth? Both in terms of data volume and user load.
3. Availability: What is the system's uptime? For example, 99.9% availability.
4. Security: How does the system protect against unauthorized access or data breaches?
5. Maintainability: How easy is it to update and manage the system?
6. Compliance: Adhering to data privacy laws like GDPR or industry-specific regulations.

In System Design Interviews

When you're in a system design interview, here's how you can handle these requirements:

1. Clarify Requirements: Start by asking questions to understand both functional and non-functional requirements. Interviewers often leave these vague to see if you'll probe for more details.

2. Prioritize: Not all requirements are equally important. Identify which ones are critical for the system’s success.

3. Trade-offs: Discuss trade-offs related to different architectural decisions, especially concerning non-functional requirements. For example, a system highly optimized for read operations might have slower write operations.

4. Use Real-World Examples: If you can, relate your points to real-world systems or your past experiences. This shows practical understanding.

5. Balance: Ensure you're not focusing too much on one type of requirement over the other. A well-rounded approach is often necessary.

Remember, in system design interviews, interviewers are often interested in seeing how you think and approach problems, not just your final solution. Demonstrating a clear understanding of both functional and non-functional requirements is key to showing your comprehensive knowledge in system design.