Junior 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, запустите относящиеся к изменению проверки и убедитесь, что не потеряли чужую логику. На интервью полезно рассказать о реальном конфликте и способе проверки результата.

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

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

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

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

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