А не синьор ли ты часом? О чем спрашивают на собеседованиях для синьоров

Десять лет назад Евгений Афонасьев, совсем еще зеленый джун, попал на первый в своей жизни PyCon, который проходил на турбазе под Екатеринбургом. С тех пор многое изменилось, PyCon вырос и перебрался в Москву, а Евгений превратился в опытного python-разработчика, который уже сам выступает на конференциях и проводит собеседования. Именно о том, как проводятся собеседования на позицию синьора, он рассказал на PyCon Russia 2022. Доклад признали лучшим докладом конференции, поэтому мы решили с вами поделиться его текстовой версией. Далее — от лица Евгения.

Я занимаюсь развитием python-комьюнити в рамках Тинькофф и, как часть этого развития, я провожу собеседования разработчиков. Сегодня мы препарируем тему собеседований синьор-разработчиков. Поговорим о том, кто такой синьор, пробежимся по форматам собеседований, поговорим про основные тематики и что в рамках этих тематик обычно ожидают услышать.

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

Дисклеймер: все это — мое личное мнение, а не официальное мнение компании «Тинькофф».

Синьор — это тот, кто владеет всеми необходимыми инструментами для решения задач. Его не нужно наставлять, менторить. Он либо уже знает, как пользоваться всем, что нужно, либо может это изучить в короткие сроки без ущерба для текущих задач бизнеса.

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

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

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

Встречаются такие полумифические собеседования, которые можно назвать как «разговор по душам». Когда один очень умудренный опытом (желательно бородатый) айтишник задает кандидату вопросы про жизнь, про собаку, про то, как дела у его мамы, и потом принимает решение интуитивно, на основе своего опыта — нанимать его или нет. Этот процесс никак не масштабируется, потому что таких людей в индустрии единицы.

Стандартный вариант — когда у нас есть одна техническая встреча на всё. В рамках ее вас собеседует какое-то количество людей на любые тематики. Это самый распространённый вариант, чтобы сэкономить и свое время, и время кандидата.

Более формализованный вариант, подходящий для крупных компаний — это набор секций. То есть, разные технические секции, зачастую с разными интервьюерами. По этому пути мы идем в «Тинькофф». У нас есть три технических секции, две из которых обязательны для всех разработчиков. Это секция программирования, на которой вы решаете задачи и отвечаете на достаточно простые вопросы и языковая секция — на знание питона и экосистемы. Для высокоуровневых специалистов, тех, кто претендует на синьорские позиции, есть секция системного дизайна.

Но здесь я буду говорить про тематики, которые встречаются на всех собеседованиях в разных соотношениях.

Алгоритмы

Это такая вещь, которую кто-то очень любит, а кто-то люто ненавидит. Минимально, что я рекомендую знать каждому синьору в этой части, — это свободно ориентироваться в базовых структурах данных, уметь оценивать сложность алгоритмов и, что очень важно для собеседований, писать рабочий код прямо на собеседовании.

Совет 1: уточняйте условия, прежде чем начать писать код.

Совет 2: стиль кода имеет значение, даже если вы на собеседовании. Тот, кто вас собеседует, не видит тот код, который вы спокойненько, со смузи, пишете у себя на работе. Он видит лишь то, что вы впопыхах накидали за час — с однобуквенными переменными, непонятными названиями, циклами. Именно по этому коду вас будут оценивать. Помните об этом.

Python

Что ждут от синьора в рамках тематики по Python:

Тесты

Не во всех собеседованиях вас это попросят, но лично я всегда предпочитаю убедиться в том, что кандидат умеет писать тесты, подбирать краевые случаи, тест-кейсы. То есть, он умеет использовать тот код, который только что написал. Умеет работать с генератором извне, а не только написать то, что находится внутри.

Для питона, как для динамического языка, у которого нет компилятора, который за вас найдет множество ошибок (как, например, на Rust) написание надежных больших приложений — это краеугольный камень. Тесты писать нужно, покрытие нужно делать достаточно большим.

Совет 3: Даже если ваша текущая команда по какой-то причине не пишет тесты, но вы хотите в перспективе стать синьором, начинайте писать тесты! На свой код, в pet-project — как угодно.

Контекстные менеджеры

Нужно уметь писать декораторы — параметризованные и простые. Зачем, если можно раз в году загуглить и скопировать чужой? Несвободное владение базовыми концепциями сужает инструментарий, в каждой конкретной ситуации вы уже не видите все возможные варианты решения.

Свободно владея языком, вы сможете делать то, ради чего Python создан — вы можете делать простое еще проще, а сложное — настолько простым, насколько это возможно. Вы можете использовать Pythonyc Way, следовать по пути Python.

На мой взгляд, высокий уровень разработки на питоне подразумевает понимание философии этого языка, следования ей.

GIL — Global Interpreter Lock

Что такое GIL? Этот теоретический вопрос может встретиться практически на каждом собеседовании. Надо понимать, зачем он вообще появился. Как именно он влияет на программу, когда он нам не мешает делать наши задачи, когда мешает.

Asyncio

Теоретических вопросов может быть много, я хочу ещё один выделить. Мне он очень нравится, потому что на нём многие проваливаются. С версией 3.4 у нас появилась Asyncio, с версии 3.5 — Asyncio.wait. Все стало очень хорошо, все стали писать стильный модный молодежный код. Но многие, научившись писать Asyncio.wait в своем коде, не поняли, зачем они это делают. И это проблема.

Важно понимать в принципе, в чем подход асинхронности. Зачем она вообще нужна, какие задачи решает, чем принципиально отличается от тредов. Если вы не понимаете эту разницу, а просто взяли Asyncio, потому что не тормозит, это не синьорный подход.

Для разработки очень важно понимание сущностей процессов, потоков и корутин. Вы должны понимать, как они работают, как связаны между собой, какие у них есть плюсы и минусы и какое количество тех или иных сущностей нужно подобрать под вашу конкретную задачу. Это не должно происходить наугад. Если вы не понимаете, как работает ваш рантайм, не понимаете его особенности, то написание сколько-нибудь сложно нагруженной программы будет сродни тому, что вы стреляете с завязанными глазами. Вы, конечно, куда-нибудь попадете. Но скорее всего не туда, куда планировали, или не так качественно, как хотели бы.

У многих может возникнуть вопрос, почему на собеседовании меня не спрашивают, допустим, как сделать на Django класс View или ещё что-нибудь? Для синьорных позиций понимание фреймворка — это настолько тривиальный навык, сродни с использованием библиотеки request. Никто же себя request программистом не называет? Поэтому и Django-программистами вам тоже быть не рекомендую. Вы должны быть python-разработчиками. Фреймворки уходят и приходят, а язык и его концепция всегда остаются.

Переходим к вещи, которая очень редко встречаются на собеседованиях, особенно в небольших компаниях, но про которую хочется отдельно сказать. Это все, что связано с инфраструктурой.

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

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

Недостаточно хорошо писать код. Нужно понимать, с чем он взаимодействует и как не положить то, с чем он взаимодействует.

Что я ожидаю услышать точно от каждого — что синьор понимает, как деплоится его приложение. Как развернуть его самым тривиальным способом на виртуалке. Самое главное, что вы понимаете, что это не просто программа на питоне, которую вы кому-то отдали и этот кто-то магическим образом куда-то его выкатил. И оно там начало перемалывать какие-то РПС.

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

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

Тематика с собеседованиями по архитектуре более интересна для тех, кто уже сам синьор или собеседует синьоров. Я бы разделил эту тему на два направления:

Архитектура приложения Application Design

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

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

Системный дизайн

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

Совет: правильно понятые требования — половина решения. Особенно в таких задачах, где очень много нюансов.

Чтобы спроектировать систему, сначала нужно зафиксировать сценарий. Затем нарисовать концептуальную схему, которая будет описывать только классы компонентов, но не как они будут реализованы. А уже потом выбирать технологии.

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

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

От синьора на подобных секциях ждут:

Кто-то скажет, что эта куча требований ни к чему. Могу ответить только одно. Самые интересные задачи, самая высокооплачиваемая работа находится там, где требования к квалификации очень высоки. И если вы хотите там оказаться, то развивайтесь, учитесь, планируйте свой рост осознанно. Можно десять лет делать одну и ту же задачу, делать ее хорошо, но роста никакого не будет. Если ваша цель — куда-то двигаться, то планируйте свой путь и удачи вам на собеседованиях!

Это сокращенная версия доклада, прослушать его целиком можно в YouTube

В этом году мы решили вернуться к корням и организуем почти ту самую теплую ламповую python-конференцию в Екатеринбурге, о которой Евгений вспоминал в начале своего доклада. Теперь она называется EkbPy и пройдет 4 февраля. Участвовать можно офлайн или онлайн. Программа уже сформирована, а билеты можно купить на сайте.