Занимались ли хранением файлов и подобным

Что проверяют

Работали ли вы с файлами в продакшене, а не только открывали их через open(). Интервьюер хочет услышать, где лежали файлы, как они туда попадали и что вы делали с безопасностью. Следом обычно спрашивают про большие файлы или про то, как вы отдавали их пользователю.

Как отвечать

Рассказывайте о своём проекте, со своими объёмами и цифрами. Опорные точки, которые стоит покрыть:

• где хранили: объектное хранилище, совместимое с S3 (AWS S3, Yandex Object Storage, MinIO), локальный диск или сетевой том. Сами файлы в хранилище, метаданные (ключ, размер, тип, владелец) в PostgreSQL;
• как загружали: через boto3 или aioboto3, в Django через FileField и django-storages, в FastAPI через UploadFile. Большие файлы шли потоком или multipart-загрузкой (upload_fileobj включает её сам), а не читались в память целиком;
• прямая загрузка: presigned URL из generate_presigned_url или generate_presigned_post, клиент грузит файл прямо в хранилище, и бэкенд не тратит на это воркеры;
• безопасность: закрытый бакет, ссылки на скачивание с ограниченным сроком, ключи вида UUID вместо имени от пользователя, проверка размера и типа по содержимому, а не по расширению;
• согласованность: что будет, если строка в базе удалилась, а объект остался. Хороший ответ: фоновая очистка сирот и lifecycle-правила бакета.

Если такого опыта не было, не придумывайте историю. Скажите, с чем работали (pathlib, временные файлы, выгрузка отчётов в CSV), и опишите, как спроектировали бы хранение сейчас. Продуманный подход звучит убедительнее, чем сочинённые «10 000 файлов в день».

Где спотыкаются

Читают загруженный файл в память целиком через await file.read(). На файле в пару гигабайт процесс падает или отнимает память у соседей.

Доверяют Content-Type из запроса и имени файла. Имя вроде ../../etc/passwd при записи на диск без нормализации превращается в path traversal.

Кладут файлы в базу в bytea без причины. Бэкапы разрастаются, реплики отстают, а раздавать такие файлы через CDN неудобно.