Чем отличается Middle, Senior и Staff на примере Google?
Если максимально упростить, разница в основном в масштабе ответственности, влияния, и количестве неопределённости.
Возьмём для примера 🔠0️⃣0️⃣🔠🔠🔠.
🔤4️⃣ a.k.a. Middle Software Engineer
На этом уровне от тебя ожидают, что ты можешь самостоятельно решать достаточно чётко определённые технические задачи: разобраться в требованиях, выбрать решение, написать код и довести всё до production без постоянного «стояния за спиной».
Это видно и по интервью: основной упор на миддла идёт на алгоритмы + поведенческое, а отдельного полноценного дизайна систем обычно вообще нет. Скажу сразу, это только у Google нет дизайна систем на миддла, в остальных компаниях он всё же есть, но требования не слишком жёсткие ☕️.
🔤5️⃣ a.k.a. Senior Software Engineer
Тебе могут дать достаточно размытую проблему, где сначала нужно самому разобраться, что вообще нужно делать, принять архитектурные решения, объяснить их компромиссы, найти потенциальные проблемы, расписать последовательность действий, разбить на подзадачи и вместе с другими инженерами или самостоятельно довести всё до прода.
Если говорить про собеседования, то если сервис перестал справляться с растущей нагрузкой, от сеньора уже хочется не просто услышать «давайте добавим кэш», а понять, где вообще узкое горлышко в системе, какие есть варианты решения и почему один из них подходит лучше остальных.
Поэтому на сеньора появляется полноценный дизайн систем с глубоким погружением, где от тебя уже ждут намного большей самостоятельности, проявления лидерских качеств, и рабочего решения и понимания всех нюансов этой системы.
🔤6️⃣ a.k.a. Staff Software Engineer
Стафф - это не сеньор, который просто ещё лучше знает дизайн систем (хотя и это тоже). Здесь сильно растёт масштаб ответственности. Вообще, это происходит на всех уровнях: растёт масштаб ответственности, задачи становятся всё менее конкретными, появляется больше неопределённости и делегирования.
Вернемся к стаффу, например, ты видишь, что три разные команды решают одну и ту же проблему каждая по-своему. Стафф может предложить общее архитектурное решение, договориться с этими командами, определить ownership, учесть, как всё это будет развиваться дальше, и убедить остальных двигаться примерно в одном направлении. То есть от тебя уже ждут не только хороших технических решений на уровне твоего проекта, но и влияния за пределами своей команды.
На дизайне систем это тоже хорошо заметно. Уже на сеньор уровне от тебя ожидают, что ты сам будешь находить узкие горлышки системы, думать про рост нагрузки и сценарии сбоя, а не ждать, пока интервьюер укажет на каждую проблему.
На стафф от тебя ждут ещё большей самостоятельности и широты: ты должен не только найти проблемы в текущем дизайне, но и подумать, как система будет развиваться дальше, какие появятся операционные и финансовые компромиссы, как решение повлияет на другие системы и команды и какие проблемы действительно стоит решать сейчас.
Из этого следует:
Стафф вполне может писать меньше кода, чем миддл, но при этом иметь намного большее влияние на проекты вокруг и компанию в целом. Техническая база, конечно же, с каждым уровнем должна становиться глубже, чтобы принимать правильные технические решения. Просто чем выше уровень, тем меньше твой вклад определяется количеством кода, который ты написал лично.
Если максимально упростить, разница в основном в масштабе ответственности, влияния, и количестве неопределённости.
Возьмём для примера 🔠0️⃣0️⃣🔠🔠🔠.
🔤4️⃣ a.k.a. Middle Software Engineer
На этом уровне от тебя ожидают, что ты можешь самостоятельно решать достаточно чётко определённые технические задачи: разобраться в требованиях, выбрать решение, написать код и довести всё до production без постоянного «стояния за спиной».
Это видно и по интервью: основной упор на миддла идёт на алгоритмы + поведенческое, а отдельного полноценного дизайна систем обычно вообще нет. Скажу сразу, это только у Google нет дизайна систем на миддла, в остальных компаниях он всё же есть, но требования не слишком жёсткие ☕️.
🔤5️⃣ a.k.a. Senior Software Engineer
Тебе могут дать достаточно размытую проблему, где сначала нужно самому разобраться, что вообще нужно делать, принять архитектурные решения, объяснить их компромиссы, найти потенциальные проблемы, расписать последовательность действий, разбить на подзадачи и вместе с другими инженерами или самостоятельно довести всё до прода.
Если говорить про собеседования, то если сервис перестал справляться с растущей нагрузкой, от сеньора уже хочется не просто услышать «давайте добавим кэш», а понять, где вообще узкое горлышко в системе, какие есть варианты решения и почему один из них подходит лучше остальных.
Поэтому на сеньора появляется полноценный дизайн систем с глубоким погружением, где от тебя уже ждут намного большей самостоятельности, проявления лидерских качеств, и рабочего решения и понимания всех нюансов этой системы.
🔤6️⃣ a.k.a. Staff Software Engineer
Стафф - это не сеньор, который просто ещё лучше знает дизайн систем (хотя и это тоже). Здесь сильно растёт масштаб ответственности. Вообще, это происходит на всех уровнях: растёт масштаб ответственности, задачи становятся всё менее конкретными, появляется больше неопределённости и делегирования.
Вернемся к стаффу, например, ты видишь, что три разные команды решают одну и ту же проблему каждая по-своему. Стафф может предложить общее архитектурное решение, договориться с этими командами, определить ownership, учесть, как всё это будет развиваться дальше, и убедить остальных двигаться примерно в одном направлении. То есть от тебя уже ждут не только хороших технических решений на уровне твоего проекта, но и влияния за пределами своей команды.
На дизайне систем это тоже хорошо заметно. Уже на сеньор уровне от тебя ожидают, что ты сам будешь находить узкие горлышки системы, думать про рост нагрузки и сценарии сбоя, а не ждать, пока интервьюер укажет на каждую проблему.
На стафф от тебя ждут ещё большей самостоятельности и широты: ты должен не только найти проблемы в текущем дизайне, но и подумать, как система будет развиваться дальше, какие появятся операционные и финансовые компромиссы, как решение повлияет на другие системы и команды и какие проблемы действительно стоит решать сейчас.
Из этого следует:
Стафф вполне может писать меньше кода, чем миддл, но при этом иметь намного большее влияние на проекты вокруг и компанию в целом. Техническая база, конечно же, с каждым уровнем должна становиться глубже, чтобы принимать правильные технические решения. Просто чем выше уровень, тем меньше твой вклад определяется количеством кода, который ты написал лично.