What validation checks would you implement for an email field?

WHAT THIS TESTS: This question tests your practical engineering judgment, not your ability to write a perfect RFC-compliant regex. The interviewer wants to see if you understand the trade-off between data purity and user experience. A senior engineer knows that being too strict rejects valid users, while being too lenient pollutes the database. The key is to show you think in layers of validation, from simple and fast to complex and definitive.

A GOOD ANSWER COVERS: A strong answer outlines a multi-stage validation strategy. First, state the goal is to confirm a user-controlled, deliverable email address, not to achieve perfect RFC 5322 compliance. Second, describe simple, synchronous checks on the backend: check for a single '@' symbol, ensure the local part (before @) and domain part (after @) are not empty, and check for obviously invalid characters. Third, mention optional, asynchronous checks like a DNS lookup for the domain's MX records to see if it's configured to receive mail. Fourth, and most importantly, state that the only truly reliable validation is verification: sending an email with a time-sensitive, unique link that the user must click to confirm ownership and deliverability. Finally, mention that all input must be sanitized to prevent injection attacks (XSS, SQLi).

COMMON WRONG ANSWERS: The biggest red flag is immediately jumping to a complex regex. Many famous "RFC-compliant" regexes are thousands of characters long, computationally expensive, and still fail to capture all edge cases or reject addresses that are technically valid but practically undeliverable. This approach signals a lack of real-world experience. Another common mistake is forgetting the verification step (sending a confirmation email), which is the industry standard for a reason. Failing to mention the security implications of user input (sanitization) is also a miss.

LIKELY FOLLOW-UPS: Be ready for questions like: "How would you handle disposable email address services?" (Answer: Use a third-party service or internal blocklist, but weigh the business impact). "Should validation be on the frontend or backend?" (Answer: Both. Frontend for immediate UX feedback, backend as the authoritative source of truth and security). "Would your MX record check be synchronous?" (Answer: No, it's a network call and should be asynchronous to avoid blocking the user request).

ONE CONCRETE EXAMPLE: Consider the email user+alias@gmail.com. This is a valid email address that Gmail delivers to the user@gmail.com inbox. A naive, overly-strict regex might reject it because of the '+' symbol. This would block a legitimate user. A better approach is to perform a simple syntax check (it has an '@', etc.), accept it, and send a verification email. If the user clicks the link, the email is confirmed as valid for your system's purposes, regardless of its specific syntax. This prioritizes successful user onboarding over pedantic rule-following.