#машины_разное #люди

Время от времени я провожу system design интервью, которые в простонародье известны как архитектурные. Многим моим читателям такой вид собеседования должен быть знаком: предлагается спроектировать что-то, и у вас 45 минут чтобы собрать все минимальные требования, набросать высокоуровневый дизайн, в нужных местах опускаясь ниже и адресуя ряд пунктов.

Очевидное отличие этого интервью от других (например от алгоритмов) - отсутствие одного правильного ответа и какого-то логического конца. Напротив, здесь идет игра против времени и нужно “успеть” покрыть максимум тем.

Поэтому к такому интервью нужно относиться как к reverse bullshit bingo: чем больше ключевых слов вы успеете назвать (CDN, LB, Cache, Queue, DB, NoSQL, SQL, Read/Write API, Sharding, Consensus, CAP, и т.д.) - тем лучше. Интервьюер, cпускаясь в нужных местах пониже, проверяет вашу эрудицию.

Дескать, сказал “балансировщик” - накинь базовые алгоритмы балансировки. Кеширование - caching algorithms и eviction policies. Базы данных - ну расскажи про индексы и какие бывают разновидности. Тут можно помнить, что не все удастся знать наизусть, да и интервьюер не дурак - будет лезть туда, где сам разбирается.

Однако есть еще один момент, про который многие кандидаты благополучно забывают - откупы (trade offs). По мере роста архитектуры будут добавляться все новые и новые требования, и одно из них может выбить из колеи, потому что нивелирует все остальные.

Неопытный кандидат в таком случае начинает нервничать - ведь есть где-то “правильный” ответ, который все аспекты учитывает! И ищет собеседуемый серебряную пулю, да не найдет - нет ее. Ваш покорный, кстати, не исключение.

Достаточно сказать: “Да, можно сделать. Но”. И далее списком откупы.