Python-разработчик.
Профессия, зарплаты
и карьерный путь.

Сначала назовите задачу. Список удобен для изменяемой последовательности, кортеж — для фиксированного набора элементов, словарь — для поиска значения по ключу, множество — для проверки уникальности и принадлежности.

Например, задачи пользователя можно хранить в списке, данные задачи — в словаре, а уникальные теги — во множестве. Объясните, важны ли порядок, повторы и изменение данных. Кортеж неизменяем, но может содержать изменяемый объект.

Оператор == сравнивает равенство значений по правилам типа, а is проверяет, один ли это объект. Два разных списка с одинаковыми элементами равны через ==, но не обязаны быть одним объектом.

Для проверки отсутствующего значения пишут value is None. Для строк и чисел обычно нужно сравнение значений. Не опирайтесь на случайное совпадение идентичности небольших чисел или строк — оно не выражает смысл задачи.

Значение аргумента по умолчанию создаётся при определении функции. Если функция добавляет элементы в такой список, последующие вызовы без этого аргумента могут увидеть уже изменённый объект.

Обычный подход: указать None по умолчанию, а новый список создать внутри функции при проверке is None. На собеседовании покажите два последовательных вызова и объясните, почему их результаты влияли друг на друга.

Начните с последней строки traceback: она показывает тип ошибки и сообщение. Затем найдите место в своём коде и воспроизведите проблему на минимальном примере. Перехватывайте конкретное ожидаемое исключение там, где можете осмысленно его обработать.

Не скрывайте все ошибки пустым except. Для внешнего сервиса можно вернуть понятный ответ и записать диагностику; для некорректных входных данных — сообщить о проблеме клиенту. Очистку ресурсов удобно организовать через with или finally.

Опишите путь: клиент отправляет запрос, сервер проверяет формат и права, выполняет бизнес-логику, обращается к хранилищу и возвращает ответ. Разделяйте ошибки входных данных, отсутствие ресурса и внутренний сбой.

На своём проекте покажите один успешный запрос и один ошибочный. Объясните статус ответа и структуру ошибки. Проверку доступа выполняйте на сервере: скрытая кнопка в интерфейсе не защищает чужие данные.

INNER JOIN возвращает совпавшие строки по условию соединения. LEFT JOIN сохраняет все строки левой таблицы; если пары справа нет, соответствующие поля результата будут NULL.

Пример: нужно показать всех пользователей, включая тех, кто ещё не создал задач. LEFT JOIN подходит, но фильтр по правой таблице в WHERE может убрать строки без пары. Объясните, должен ли фильтр стоять в ON или WHERE, исходя из нужного результата.

Транзакция объединяет изменения в одну операцию: они фиксируются вместе либо откатываются. Например, запись заказа и резервирование остатка должны согласованно завершиться; промежуточное состояние не должно стать итоговым.

Объясните границы транзакции, commit и rollback. Транзакция базы сама по себе не откатывает письмо или запрос к внешнему API. Для внешних действий нужен отдельный подход, например очередь событий с повторной обработкой.

Начните с поведения: успешная операция, неверные данные, отсутствующий объект, запрет доступа и отказ зависимости. Unit-тест проверяет небольшую часть логики, интеграционный — взаимодействие компонентов, например API и базы.

Внешний API в изолированном тесте можно заменить управляемым ответом. Проверьте как успех, так и таймаут. Отдельно нужны проверки реальной интеграции: один mock не подтверждает, что контракт внешнего сервиса соблюдён.

Сначала выясните, какие изменения столкнулись и какое поведение нужно сохранить. Прочитайте обе версии, обсудите неясный замысел с автором и соберите итоговый вариант.

Удалить маркеры конфликта недостаточно. Проверьте diff, запустите относящиеся к изменению проверки и убедитесь, что не потеряли чужую логику. На интервью полезно рассказать о реальном конфликте и способе проверки результата.

Используйте последовательность: задача, ограничения, ваш вклад, решение, проверенный результат. Возьмите одну конкретную сложность вместо перечисления всего стека.

Скажите, что сделали самостоятельно, где получили помощь и что бы изменили сейчас. Для учебного проекта результатом может быть работающий сценарий и проверка тестами. Для рабочего — измеримое изменение, если вы можете объяснить, как его измеряли.

Асинхронность помогает обслуживать несколько операций, пока они ждут ввод-вывод: сеть или хранилище. Во время await управление может перейти другой задаче. Это не означает, что тяжёлые вычисления автоматически начнут выполняться параллельно.

Блокирующий вызов внутри корутины может остановить обслуживание остальных задач. Выбирайте подходящую асинхронную библиотеку или выносите блокирующую работу. Обсудите таймауты, отмену, ограничение параллелизма и поведение при отказе зависимости.

Сначала воспроизведите проблему на похожих данных и проверьте, где тратится время. Изучите план выполнения через EXPLAIN: способ чтения таблиц, соединения, оценки количества строк. Проверьте, не делает ли приложение множество запросов вместо одного.

Индекс выбирают под запрос и распределение данных. Он занимает место и увеличивает стоимость записи. EXPLAIN ANALYZE действительно выполняет запрос, поэтому применяйте его с учётом побочных эффектов и нагрузки. Сравните результат до и после изменения.

Сначала определите, какие действия опасно выполнить дважды: списание, создание заказа, отправка уведомления. Используйте ключ операции и сохранение результата так, чтобы повтор можно было распознать.

Учитывайте гонку между одновременными запросами: одной проверки «записи ещё нет» недостаточно. Помогают ограничения уникальности и атомарная запись в базе. Для очереди уточните момент подтверждения сообщения и сценарий падения после выполнения действия, но до подтверждения.

Начните с измерения: какую дорогую операцию нужно ускорить и какая задержка обновления допустима. Определите ключ, срок жизни, размер и поведение при недоступности кеша.

Разберите изменение исходных данных, массовое истечение ключей и одновременное заполнение кеша. Не храните персональные ответы под общим ключом. Хороший ответ связывает решение с требуемой свежестью данных, а не сводится к «добавим Redis».

Уточните нагрузку, требования к задержке и доступности, характер данных и ограничения команды. Затем предложите самое простое решение, которое удовлетворяет этим условиям, и объясните границы компонентов.

Рассмотрите отказы, наблюдаемость и план изменений без остановки продукта. Сравните альтернативы по стоимости поддержки и риску. Сильный ответ показывает, почему выбранное решение подходит именно этой задаче и при каких условиях его придётся пересмотреть.