Круглый стол. Как стать сеньором

Начали с понятий. Один из участников, назвавший себя «наиболее сомневающимся», предложил разделять две рамки: если вопрос «сеньор ли я» задаёт себе сам разработчик, речь о навыках, опыте и знаниях; если тот же вопрос задаёт работодатель, речь об ответственности — за продукт, за домен или за технические решения. Ему тут же добавили, что без знаний ответственность не вытянуть. Дальше сошлись на том, что грейд — не то, с чем рождаются, а то, как тебя оценивают другие: коллеги-разработчики, текущий работодатель, работодатель на рынке. Системы оценки у всех разные, поэтому списка «знать это, это и это» не существует, есть набор областей, в которых стоит развиваться, чтобы попадать в критерии максимального числа компаний. Зарплату как метрику не отвергли, но уточнили: текущая цифра говорит скорее о том, насколько крепко вас держат на нынешнем месте, а честнее пройти пять-десять собеседований и посмотреть на офферы.

Второй ответ на тот же вопрос — «зависит от компании». Одно дело студия, где клепают одинаковые проекты, другое — сложная система: один из участников рассказал про коллегу, который перешёл в другую команду ради сложности задач, там делают внутреннюю замену покупному решению для работы с логами. Отсюда совет узнать, какие критерии для сеньора выставляет ваша компания, и посмотреть на матрицу компетенций. Александр описал свою: инженер сам подаёт заявку на повышение и прикладывает артефакты — над какими задачами работал, с кем, что получилось; заявки собирают и разбирают каждый месяц признанные внутри эксперты, «лидеры профессии», а ожидания по каждому уровню лежат во внутреннем документе. Обсудили и дробление шкалы: сеньором нельзя быть «в вакууме», ты сеньор в чём-то. В большом desktop-приложении на WinForms и WPF, которое развивают двадцать лет, system design почти не нужен, зато нужны паттерны проектирования.

Как это проверяют на входе, подробнее всех рассказал Александр. Инженер проходит три секции: алгоритмы и структуры данных с задачами в духе LeetCode, секцию по платформе .NET и system design, где кандидат собирает систему из набора требований, а интервьюер её «шатает» — а если сеть мигнёт, сервис загорится, кто-нибудь перерубит провода? Через system design проходят не только инженеры, но и тимлиды, руководители отделов и управлений: без этой секции выше определённого грейда в компании не подняться. Одно такое интервью он проводил в онлайн-части конференции по C++, и запись можно посмотреть. У Антона подход другой: он задаёт кандидату два вопроса — самое большое достижение и главный факап. Важен не сам ответ, а способность разобрать, в чём именно было достижение, где именно человек провалился и как он на это повлиял; если не было ни достижений, ни факапов, а были формочки, для него это не сеньор.

Дальше разбирали признаки, которые не работают. Рейтинг специалистов от независимого сообщества, о котором спросили из чата, Антон считает возможным, но это работа, за которую кто-то должен платить; сертификации есть у нескольких вендоров, только большинство компаний, которые он встречал, на них особо не смотрит. Знание кодовой базы — скорее знание домена и нюансов бизнеса, нарабатывается оно в среднем месяца за три, поэтому оценивать стоит широту понимания области и impact: сделать сервис технически лучше, а не просто перекладывать JSON. Долгий срок в одной компании красным флагом тоже не назвали, лояльность считают плюсом. Сам impact Александр меряет количеством головной боли: если дело встало, боль поднимается по цепочке вверх, вплоть до CEO, — и тут же признаёт изъян метрики, ведь у того, кто тихо сидит в углу, голова тоже ни у кого не болит. Хуже всего, по его словам, сеньоры, которым погоны выдали за то, что всё идёт стабильно: пока поток задач ламинарный, они его держат, но стоит бизнесу измениться — начинают сопротивляться изменениям, и с такими обычно прощаются.

Во второй половине перешли к тому, как дорасти. Один из участников рассказал свою историю: его когда-то нанял человек, которому он до сих пор благодарен, — Лёша Кауфман, — вокруг оказалось много сильных людей, у которых он и учился; этот путь он называет самым прямым и самым ненадёжным. Андрей добавил, что расти можно только на задачах и что задачи должны быть разными по сложности. Другой участник согласился и уточнил: менять работодателя ради плюс тридцати процентов к зарплате в долгую работает хуже осознанного перехода, когда задач под тебя на текущем месте больше нет. Частые переходы лишают инженера обратной связи — он успевает начать и уйти, не увидев, чем всё кончилось. Менторство назвали делом добровольным с обеих сторон, а Александр заметил, что звать людей во что-то новое лучше объяснением выгоды, а не приказом: так он расширял круг интервьюеров по system design, когда сам вёл по десять интервью в неделю.

Ближе к концу трое сформулировали то, что готовили заранее: четыре критерия сеньора — ответственность, умение делать руками, кругозор и насмотренность. Насмотренность объяснили так: ты видел, как соседняя команда чинила развалившийся кластер, сам не делал, но прожил рядом. За этим и идут на конференции и в подкасты — чужой опыт без своих шишек, соседние технологии, рассказы о том, как делать не надо; правда, это не практические знания, а расширение картины мира, зато помогает от синдрома самозванца. Обязательных книг не нашлось: одни копают теорию вглубь, другие идут за white paper крупной компании, ещё один участник назвал книгу концентрированным опытом — пять-шесть лет чужой работы за месяц чтения с карандашом. Антон посетовал, что системного обучения для работающего мидла нет, и предложил перенести к инженерам формат западной медицины — разбор клинического случая панелью из двух-трёх экспертов, куда один в один ложится разбор инцидентов.