дай дорогу дураку

как инструмент

важно при разработке

кто заберет детей из школы

Вводная

Привет

Всем привет, меня зовут XXX, и в XXX мы занимаемся XXX.

О чем расскажем

Когда мы начинали, команды и отделы ещё не были собраны и только намечался запуск XXX, культура разработки, а тем более собеседований, ещё не стабилизировалась. Многие из интервьюверов, а так же руководители разработки, понимали проблему: нанимать нужно быстро и качественно. Пришедшие из YYY (бигтехов) понимали, что их привычный долгий процесс найма не годится в нашем стартапе. Но могли рассказать как повысить качество проводимых собеседований. Пришедшие ребята из небольших компаний и стартапов, где обычно голое поле, а все делаю всё сразу, так же делились своим опытом собеседований. Отсюда вырос наш немного особенный вид задач, который я называю service design.

TLDR

…

Что спрашиваем на собеседовании

Чем отличается от system design

Дизайн сервиса, очень похоже по названию на устоявшийся тип задач на собеседовании System Design. И это не просто так, многие моменты и структуру мы взяли из него. Но основное отличие, почему мы спрашиваем, как проектировать сервисы, а не системы, это наша потребность в инженерах, которые могут сразу после выхода начать создавать сервисы с бизнес логикой. Мы не делаем много микросервисов, а скорее стараемся придерживаться тактики проектирования именно сервисов - единиц выполнения бизнес логики. Когда внутренняя функциональность сервиса начинает разрастаться, или нагрузка (???) на функциональность начинает мешать хорошему темпу разработки, мы начинаем процесс отрезания частей сервиса в отдельный микросервис. В дальнейшем этот микросервис опять начинает разрастаться до нормальных объемов. Как раз умение проектировать конкретные сервисы в ограниченное время мы ценим.

Нам не очень интересно, как быстро разработчик спроектирует очередную соцсеть или агрегатор такси. В наших реалиях проектирование таких объемных систем занимает многие дни, несколько команд и набор человеческих процессов (в т.ч архитектурное ревью). А вот оценить способность кандидата разбираться, развивать и “хлопотать” над его частью системы нам намного интереснее. Это как раз та деятельность, которую мы ожидаем от разработчиков (от сеньёора и выше?) на каждодневной основе.

Дизайн сервиса

Сначала даются некоторые функциональные требования, что сервис должен делать. Так обычно дается и задачи system design-а. Можем прикладывать некоторые не функциональные требования, которые уже соблюдаются. Наше любимое - нельзя терять пользовательские данные. Либо, мы любим давать уже готовый сервис, некоторую важную часть API, существующие таблицы данных. И некоторый набор “проблем”, которые сейчас есть в сервисе. Далее интервьювером задается стандартный вопрос “что нам делать?”.

На что обращаем внимание

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

Вот тут мы начинаем лезть в глубь ответа, спрашиваем как то или иное решение в системе повлияет на функциональные и не функциональные требования. Спрашиваем, как

Не просто так я выше написал про наш любимое не функциональное (или всё же функциональное?) требование - не терять данные. Работа XXX системы накладывает это важное требование, на которое обычно никто не обращает внимание. Это кажется само собой разумеющееся. Но за эти года мы испытали все прелести жизни при большом бигтехе - перерезания ковшом линков между датацентрами, недоступности инфраструктурных компонентов (волта, етцд), массовые изменения конфигов посгреса, породившее включение автовакума на всём кластере одновременно - что по сути вылилось в недоступность мастера базы данных. После всех пережитых инцидентов мы выработали некоторый набор практик, правил и библиотек, поддерживающих наличие данных.

Кандидат добавляет таблицу в базу данных - мы просим описать в деталях структуру данных, а лучше DDL. Добавление или изменение API всегда должно сопровождаться схемой запросов и ответов. Нужно прокомментировать, как пользоваться этим API, что бы все стороны обмена сообщений имели возможность работать эффективно и корректно. Когда кандидат добавляет кеш перед сервисом - мы спрашиваем как этот кеш инвалидировать. Когда нужно сходить консистентно в несколько сервисов, и хочется добавить “двухфазный коммит” - мы спрашиваем, как его будешь реализовывать. Когда добавляется брокер мы спрашиваем кто будет писать в него, а кто читать. Как писать в брокер, что бы не терять данные. Как читать из брокера, что б не терять данные. А так же интересен план Б - что делать, если вторая сторона, может быть и рада перейти на получение данных из брокера, но у них уже есть пять задач других команд, которые тоже попросили перейти на брокер?

Когда все основные моменты были обсуждены, время добавить новые вводные. Ведь разработчики у нас не только пишут новый код, но и развивают его дальше. Одним из самых сложных вводных, которые вообще встречаются в проектировании сервисов и систем, является ввод в эксплуатацию. Сервис уже крутится в проде, там есть пользователи и трафик. База данных начинает наполняться событиями. Приложения пользователей уже обновились на новую версию, внутри которой зашит спроектированный API. Всё происходит ровно по ранее обсужденным требованиям. Либо, не менее интересная вводная - а как сделать эту часть системы быстрее, что бы запустить фичи быстрее или разблокировать работу других команд. Как сделать не просто идеальную систему, а ещё запустить её по аджайлу и за несколько майлстоунов?

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

писать ли в тексте про конкретные технологии/слова?

Практическая задача

Шардирование сервиса.

Вводная

Минимальное решение

Отличное решение

Неожиданные вводные

Заключение

и проблем в зависимости от уровня