Экспертность и детали реализации.
Популярный способ оценки хардов engineering manager – архитектурное интервью.
Когда-то мне казалось, что сложная часть – это, собственно, архитектура системы end to end: топология сервисов и сети, сторадж, распределение логики по доменам…
Я думал: до того, как добраться до решения масштабных архитектурных задач, люди долго ковыряются в кишках и строят 100 маленьких компонент разных систем руками. Если архитектура удаётся – почти наверняка и всё, что ниже, есть, правда же?
Оказалось, нет. System Design настолько распространён и заезжен в сети, что крупноблочная архитектура проверяет всего две вещи:
– Умение слушать заказчика
– Минимальную проактивность: погуглить, какие задачи дают на интервью и потратить несколько недель на разбор решений
С этим отлично справляются студенты 🙂
––
Означает ли это, что обсуждать архитектуру overall бессмысленно? Конечно, нет – если человек не обладает даже двумя вышеописанными навыками, как можно доверить ему что-то серьёзное?
Для себя я понял, что реальный способ оценивать не только проактивность, но и экспертность кандидата – это как можно глубже закапываться в детали реализации частей системы.
– Какую базу тут выбираешь? Редис? Он быстрый и ты с ним много работал? Круто. Кстати, а как он работает и почему он быстрый? Я слышал, инстанс делает записи однопоточно – это разве не медленно? А что будет, если…
– Какие из апишек должны быть идемпотентными? Ага. А как буквально ты бы здесь реализовал идемпотентность? Как выглядела бы табличка в бд и какой код (псевдокод) ты бы написал сверху? Ага, вот в такой транзакции будем код писать. А что, если вот в этот момент сеть порвётся?
– Вот здесь будет множество апдейтов впараллель. Какая там СУБД у тебя, постгрес? Ага, а какой уровень изоляции ты бы настроил? А как буквально бы апдейт написал? А индексы? А сколько памяти на такой понадобилось бы, поместится на тачку?
У экспертного кандидата, выбирающего стэк из своего опыта, всегда есть 100 историй о проблемах с каждым из выбранных инструментов. Задаёшь вопрос – и уже с первых слов и выражения лица понятно, видел человек некоторое дерьмо в жизни, или нет.
Разговор о деталях и «небольших» трудностях – очень сильный фильтр на реальную экспертизу. Без него проводить систем-дизайн просто не имеет смысла в 2025-м году.
––
Мой канал на сегодня (кстати, а вы хотели бы?)) почти не содержит глубоко-инженерного контента и тех самых деталей, однако..не так давно я увидел очень хороший контент от Саши (автор примечателен, с одной стороны, тем, что умеет доступно и интересно рассказывать о тех самых деталях реализации. А с другой – ещё, например, тем, что стал лидом бэкенда в Яндексе в 21 год :))
Например, про: redis, миграции без даунтаймов, кэши и многое другое. Очень рекомендую периодически развеиваться и таким контентом, помимо управленческого 🙂
Популярный способ оценки хардов engineering manager – архитектурное интервью.
Когда-то мне казалось, что сложная часть – это, собственно, архитектура системы end to end: топология сервисов и сети, сторадж, распределение логики по доменам…
Я думал: до того, как добраться до решения масштабных архитектурных задач, люди долго ковыряются в кишках и строят 100 маленьких компонент разных систем руками. Если архитектура удаётся – почти наверняка и всё, что ниже, есть, правда же?
Оказалось, нет. System Design настолько распространён и заезжен в сети, что крупноблочная архитектура проверяет всего две вещи:
– Умение слушать заказчика
– Минимальную проактивность: погуглить, какие задачи дают на интервью и потратить несколько недель на разбор решений
С этим отлично справляются студенты 🙂
––
Означает ли это, что обсуждать архитектуру overall бессмысленно? Конечно, нет – если человек не обладает даже двумя вышеописанными навыками, как можно доверить ему что-то серьёзное?
Для себя я понял, что реальный способ оценивать не только проактивность, но и экспертность кандидата – это как можно глубже закапываться в детали реализации частей системы.
– Какую базу тут выбираешь? Редис? Он быстрый и ты с ним много работал? Круто. Кстати, а как он работает и почему он быстрый? Я слышал, инстанс делает записи однопоточно – это разве не медленно? А что будет, если…
– Какие из апишек должны быть идемпотентными? Ага. А как буквально ты бы здесь реализовал идемпотентность? Как выглядела бы табличка в бд и какой код (псевдокод) ты бы написал сверху? Ага, вот в такой транзакции будем код писать. А что, если вот в этот момент сеть порвётся?
– Вот здесь будет множество апдейтов впараллель. Какая там СУБД у тебя, постгрес? Ага, а какой уровень изоляции ты бы настроил? А как буквально бы апдейт написал? А индексы? А сколько памяти на такой понадобилось бы, поместится на тачку?
У экспертного кандидата, выбирающего стэк из своего опыта, всегда есть 100 историй о проблемах с каждым из выбранных инструментов. Задаёшь вопрос – и уже с первых слов и выражения лица понятно, видел человек некоторое дерьмо в жизни, или нет.
Разговор о деталях и «небольших» трудностях – очень сильный фильтр на реальную экспертизу. Без него проводить систем-дизайн просто не имеет смысла в 2025-м году.
––
Мой канал на сегодня (кстати, а вы хотели бы?)) почти не содержит глубоко-инженерного контента и тех самых деталей, однако..не так давно я увидел очень хороший контент от Саши (автор примечателен, с одной стороны, тем, что умеет доступно и интересно рассказывать о тех самых деталях реализации. А с другой – ещё, например, тем, что стал лидом бэкенда в Яндексе в 21 год :))
Например, про: redis, миграции без даунтаймов, кэши и многое другое. Очень рекомендую периодически развеиваться и таким контентом, помимо управленческого 🙂