Walk me through how you'd test a file upload feature end-to-end.

File upload is a classic interview question because it touches functional, non-functional, security, and integration testing.

Functional positive: each accepted file type uploads (PDF, JPG, PNG, DOCX), single and multiple files, drag-and-drop and click-to-browse, files appear in the destination, metadata is correct.

Boundaries:

• File size: 1 byte, exactly at the limit, 1 byte over.
• File count: 0 (should fail), 1, max-allowed, max+1.
• File name: very long names, names with spaces, unicode, names with path separators (../), reserved names (CON, NUL on Windows).
• Mime types: declared type matches actual; declared type lies (renamed .exe to .jpg).

Negative: zero-byte files, corrupted files, password-protected zip, files with embedded malicious payloads (test with the EICAR test string for AV).

Security:

• Path traversal (../../etc/passwd as filename).
• MIME spoofing — server should detect the real type.
• Executable uploads served as HTML (XSS).
• Files large enough to fill disk (resource exhaustion).
• Unauthenticated upload attempts.
• Cross-tenant access (user A uploads, user B reads via URL guessing).

UX: progress indicator accurate, network drop mid-upload behaves sensibly (retry / clear error), cancellation works, drag-and-drop visual feedback.

Integration: uploaded file triggers downstream processing (virus scan, thumbnail generation, indexing), file is stored where expected (S3, local disk), cleanup of failed uploads, retention policies.

In an interview I'd flag: I'd ask the PM whether resumable uploads are required (large files), what the AV pipeline is, and how multi-region storage is handled. That signals seniority.