Artyom_Novikov
New member
За последние годы я прошёл, наверное, два десятка собеседований на позиции Senior Python-разработчика — от небольших продуктовых команд до крупных компаний с многоступенчатым наймом. И каждый раз перед встречей я ловил себя на одной и той же мысли: сейчас начнут гонять по алгоритмам и заставят писать красно-чёрное дерево на доске. На деле всё оказалось иначе. Чем выше уровень, тем меньше спрашивают про синтаксис и тем больше — про то, как ты думаешь, как принимаешь решения и что происходит вокруг твоего кода.
Python-специфика, конечно, никуда не девается, но подаётся она через задачи, а не через экзамен. Меня спрашивали, почему GIL мешает одному сценарию и совершенно не мешает другому, когда asyncio даёт выигрыш, а когда превращается в карго-культ, как ведут себя генераторы и корутины под нагрузкой, что происходит с памятью при обработке большого файла и почему чтение целиком в список — не лучшая идея. Ключевое слово здесь — почему. Правильный ответ без объяснения причин ценится куда ниже, чем спорный ответ с честной аргументацией. Интервьюер хочет услышать ход мысли, а не заученную формулировку из документации.
Самая весомая часть любого senior-интервью — это системный дизайн и компромиссы. Мне давали расплывчатое описание продукта и просили набросать архитектуру: сервисы, очереди, база, кэш, ретраи, идемпотентность, наблюдаемость. И вот тут начинается настоящая беседа. Почему PostgreSQL, а не что-то другое? Что будет, если брокер очередей ляжет на десять минут? Где вы разместите транзакционную границу? Что произойдёт при повторной доставке сообщения? Хороший кандидат не выдаёт единственно верный вариант, а озвучивает развилку, называет плюсы, минусы и критерии выбора. Именно на этих развилках, на мой взгляд, и отсеиваются те, кто выучил инструменты, но не научился ими торговать.
Дальше идут истории из продакшена, и здесь я советую готовиться особенно тщательно. Меня почти всегда просили рассказать про самый неприятный инцидент, который я разгребал, и про то, что я сделал, чтобы он не повторился. Не про героизм в три часа ночи, а про системное исправление: алерты, тесты, ревью, изменение процессов. Спрашивают и про цифры — сколько запросов в секунду, какая была задержка, насколько упало потребление ресурсов, сколько стоила ошибка в деньгах. Если вы не помните точных чисел, честно скажите оценочные и объясните, откуда они взялись. Врать тут бессмысленно: опытный интервьюер почти всегда различает реальный проект от пересказа статьи из блога.
Отдельный большой блок — это то, что я бы назвал инженерией вокруг кода. Как вы проводите код-ревью и что считаете поводом вернуть задачу на доработку? Как вы менторствуете джунов и как понимаете, что человек вырос? Как оцениваете задачу, если требования меняются каждую неделю? Как объясняете продакту, что фича займёт три недели, а не три дня? Мне задавали вопрос про конфликт с коллегой, который настаивал на своём решении, и про то, как я переубеждал человека старше себя по должности. На senior-уровне технические навыки считаются уже данностью, а вот умение договариваться, не ломая людей, проверяют целенаправленно.
А что почти не спрашивают? Жёстких алгоритмических задач на два часа с динамическим программированием. Тривиальных вопросов про разницу между списком и кортежем. Перечисления методов стандартной библиотеки. Мне ни разу не пригодилось писать сортировку с нуля на собеседовании, зато регулярно пригождалось умение прочитать чужой кусок кода и вслух объяснить, что в нём сломано и как это починить. Лайв-кодинг на senior-позиции — это чаще разговор о качестве, тестах и краевых случаях, чем гонка за оптимальной сложностью. Так что если вы готовитесь, не зарывайтесь в тренировочные платформы до потери пульса.
По итогам своих походов я собрал для себя несколько правил, которыми охотно поделюсь. Первое: выучите собственное резюме досконально, потому что любой пункт в нём — законный повод копать на три уровня вглубь. Второе: заведите пять-семь историй из практики по схеме ситуация, задача, действия, результат, и пусть в каждой будут конкретные цифры и выводы. Третье: на любой технический вопрос проговаривайте компромиссы, даже если уверены в ответе — это ровно то поведение, которое ищут. Четвёртое: обязательно задавайте свои вопросы про процессы, дежурства, техдолг и то, как принимаются решения. Пятое: не блефуйте. Фраза «я с этим не работал, но рассуждал бы так» звучит в разы сильнее, чем попытка изобразить экспертизу, которая рассыпается на первом уточняющем вопросе.
В целом, мой главный вывод простой: собеседование на senior-разработчика — это не проверка эрудиции, а разговор двух инженеров о том, как делать сложные вещи надёжно и не сойти с ума. Если вы честно работали над реальными системами, у вас уже есть почти все нужные ответы — их просто нужно привести в порядок и научиться рассказывать. А теперь вопрос к вам, форумчане: какой вопрос на собеседовании оказался для вас самым неожиданным — и что вы поняли про себя уже после того, как вышли из переговорки?
Python-специфика, конечно, никуда не девается, но подаётся она через задачи, а не через экзамен. Меня спрашивали, почему GIL мешает одному сценарию и совершенно не мешает другому, когда asyncio даёт выигрыш, а когда превращается в карго-культ, как ведут себя генераторы и корутины под нагрузкой, что происходит с памятью при обработке большого файла и почему чтение целиком в список — не лучшая идея. Ключевое слово здесь — почему. Правильный ответ без объяснения причин ценится куда ниже, чем спорный ответ с честной аргументацией. Интервьюер хочет услышать ход мысли, а не заученную формулировку из документации.
Самая весомая часть любого senior-интервью — это системный дизайн и компромиссы. Мне давали расплывчатое описание продукта и просили набросать архитектуру: сервисы, очереди, база, кэш, ретраи, идемпотентность, наблюдаемость. И вот тут начинается настоящая беседа. Почему PostgreSQL, а не что-то другое? Что будет, если брокер очередей ляжет на десять минут? Где вы разместите транзакционную границу? Что произойдёт при повторной доставке сообщения? Хороший кандидат не выдаёт единственно верный вариант, а озвучивает развилку, называет плюсы, минусы и критерии выбора. Именно на этих развилках, на мой взгляд, и отсеиваются те, кто выучил инструменты, но не научился ими торговать.
Дальше идут истории из продакшена, и здесь я советую готовиться особенно тщательно. Меня почти всегда просили рассказать про самый неприятный инцидент, который я разгребал, и про то, что я сделал, чтобы он не повторился. Не про героизм в три часа ночи, а про системное исправление: алерты, тесты, ревью, изменение процессов. Спрашивают и про цифры — сколько запросов в секунду, какая была задержка, насколько упало потребление ресурсов, сколько стоила ошибка в деньгах. Если вы не помните точных чисел, честно скажите оценочные и объясните, откуда они взялись. Врать тут бессмысленно: опытный интервьюер почти всегда различает реальный проект от пересказа статьи из блога.
Отдельный большой блок — это то, что я бы назвал инженерией вокруг кода. Как вы проводите код-ревью и что считаете поводом вернуть задачу на доработку? Как вы менторствуете джунов и как понимаете, что человек вырос? Как оцениваете задачу, если требования меняются каждую неделю? Как объясняете продакту, что фича займёт три недели, а не три дня? Мне задавали вопрос про конфликт с коллегой, который настаивал на своём решении, и про то, как я переубеждал человека старше себя по должности. На senior-уровне технические навыки считаются уже данностью, а вот умение договариваться, не ломая людей, проверяют целенаправленно.
А что почти не спрашивают? Жёстких алгоритмических задач на два часа с динамическим программированием. Тривиальных вопросов про разницу между списком и кортежем. Перечисления методов стандартной библиотеки. Мне ни разу не пригодилось писать сортировку с нуля на собеседовании, зато регулярно пригождалось умение прочитать чужой кусок кода и вслух объяснить, что в нём сломано и как это починить. Лайв-кодинг на senior-позиции — это чаще разговор о качестве, тестах и краевых случаях, чем гонка за оптимальной сложностью. Так что если вы готовитесь, не зарывайтесь в тренировочные платформы до потери пульса.
По итогам своих походов я собрал для себя несколько правил, которыми охотно поделюсь. Первое: выучите собственное резюме досконально, потому что любой пункт в нём — законный повод копать на три уровня вглубь. Второе: заведите пять-семь историй из практики по схеме ситуация, задача, действия, результат, и пусть в каждой будут конкретные цифры и выводы. Третье: на любой технический вопрос проговаривайте компромиссы, даже если уверены в ответе — это ровно то поведение, которое ищут. Четвёртое: обязательно задавайте свои вопросы про процессы, дежурства, техдолг и то, как принимаются решения. Пятое: не блефуйте. Фраза «я с этим не работал, но рассуждал бы так» звучит в разы сильнее, чем попытка изобразить экспертизу, которая рассыпается на первом уточняющем вопросе.
В целом, мой главный вывод простой: собеседование на senior-разработчика — это не проверка эрудиции, а разговор двух инженеров о том, как делать сложные вещи надёжно и не сойти с ума. Если вы честно работали над реальными системами, у вас уже есть почти все нужные ответы — их просто нужно привести в порядок и научиться рассказывать. А теперь вопрос к вам, форумчане: какой вопрос на собеседовании оказался для вас самым неожиданным — и что вы поняли про себя уже после того, как вышли из переговорки?