Cronis Academy

Вывод System Design интервью — это не экзамен на знание всех sysctl-параметров Linux. Пытаться казаться всезнающим архитектором, прочитавшим две книги и знающим «идеальное» решение для Edge-платформы — это тупиковый путь, ведущий к субъективным спорам. Истинная ценность инженера на интервью заключается в его способности признать границы своего опыта, разложить незнакомую задачу на базовые абстрактные принципы и предложить жизнеспособный компромисс. А задача хорошей компании — не искать человека, который уже знает их внутренний ответ, а найти того, кого имеет смысл этому ответу научить.

Как победить, зная только один инструмент: Стратегия для кандидата Что делать инженеру, если его опыт ограничен условным Nginx, а на интервью просят спроектировать сложную распределенную edge-систему? Вместо того чтобы имитировать всезнание, необходимо применить стратегию «глубина вместо широты», превратив знание одного инструмента в доказательство системного мышления. Продавайте «шрамы», а не синтаксис конфигов. Не нужно просто перечислять параметры ядра, которые вы крутили. Расскажите историю их деградации. Аргумент «Я знаю, как выжать из Nginx максимум, потому что при росте трафика у нас сначала забился CPU на обработке TLS, затем закончились дескрипторы файлов, и мы решали это через worker_connections и тюнинг sysctl» звучит в разы ценнее, чем абстрактное знание пяти разных прокси-серверов по верхам. Глубокое понимание узких мест одного инструмента доказывает, что вы поймете узкие места любого другого. Переводите специфику инструмента на язык абстрактных паттернов. Если вы умеете настраивать только Nginx Mirror Module для дублирования трафика на edge, опишите это как паттерн проектирования. Скажите: «Я использовал асинхронное дублирование запросов на уровне прокси. В теории архитектуры это решает задачу безопасного тестирования продакшн-нагрузки без риска для пользователя. Если в вашем стеке вместо Nginx используется Envoy или кастомный роутер на Go, этот паттерн будет работать точно так же, поменяется только синтаксис». Это мгновенно поднимает вас с уровня «администратора Nginx» на уровень системного архитектора. Атакуйте ограничения своего решения раньше интервьюера. Лучший способ защитить неоптимальную систему — самому назвать её минусы. Если вы предлагаете синхронизацию через Nginx, сразу добавьте: «Я понимаю, что эта схема уязвима к потере пакетов на edge-уровне, и если сеть между ЦОД и сервером будет мигать, мы получим Thundering Herd эффект при восстановлении сети. В своей практике я решал это через буферизацию и ступенчатые таймауты (keepalive_timeout). Если у вас для этого внедрены очереди сообщений вроде Kafka, я быстро разберусь с их концепцией, так как физика проблемы мне понятна».

Иллюзия объективности в System Design, или Почему архитектурное интервью - это социальный контракт В ИТ-индустрии существует устойчивый миф: System Design интервью - это объективная оценка инженерной зрелости. Предполагается, что два профессионала садятся у белой доски и на основе фундаментальных законов computer science проектируют оптимальную систему. Однако в реальности, когда речь заходит о сложных низкоуровневых задачах, например, синхронизации edge-серверов и ЦОДов с помощью тюнинга ядра и Nginx, этот процесс обнажает глубокий кризис методологии найма и упирается в фундаментальные ограничения человеческого опыта. Эффект колеи и заложники контекста Главная правда, которую часто замалчивают, звучит так: инженер, работающий на пятидневке, физически не может знать все архитектурные варианты в мире. У него нет времени читать сотни RFC, исходники ядра Linux или мануалы ко всем существующим прокси-серверам. Вместо этого каждый специалист становится заложником стека своей текущей компании и возникает «эффект выжившего инженера». Если в его компании edge-синхронизация годами работала через Nginx proxy_cache и тюнинг net.core.somaxconn, этот опыт становится для него эталоном. Он знает, как эта система ведет себя в три часа ночи, где она «течет» и как её чинить. Когда такой инженер приходит на интервью или вступает в спор в интернете, у него часто нет других аргументов, кроме субъективного: «У нас вот так работает, и оно держит миллиард запросов». Дискуссия неизбежно превращается в столкновение двух персональных бэкграундов, а не в поиск инженерной истины. Инженер не может «выдумать» оптимальное решение из головы, если он никогда не сталкивался с ним на практике. Две развилки дизайн-интервью В условиях этого когнитивного ограничения исход любого System Design интервью сводится к двум сценариям, которые зависят не столько от кандидата, сколько от зрелости нанимающей стороны. Сценарий 1. Викторина «Угадай, что у меня в голове» Если интервьюер ищет конкретный ответ, основанный на его личном опыте или специфическом стеке его команды, интервью превращается в лотерею. Кандидат либо совпал по контексту со своим прошлым местом работы, либо не совпал и провалился. Это признак незрелости процессов в компании: здесь ищут не инженера с системным мышлением, а готовый «винтик», который закроет горящую задачу прямо завтра. Сценарий 2. Оценка мышления и социальный контракт Зрелые технологические компании (уровня BigTech) понимают: найти человека, чей опыт на 100% совпадает с их кастомной инфраструктурой, невозможно. Архитектура крупных систем уникальна, в ней используются собственные форки ядер и глубоко кастомизированный софт. Готовых специалистов для таких систем на рынке просто нет. В этом сценарии System Design интервью превращается в социальный контракт: Кандидат честно очерчивает границы своего опыта, не пытается угадывать термины, но демонстрирует понимание базовой физики процессов (ограничения сети, памяти, законы CAP-теоремы) и умение рассуждать в условиях дефицита информации. Компания, видя умение системно мыслить, берет на себя обязательство обучать инженера за свой счет. Она инвестирует ресурсы в его онбординг (который может длиться месяцами), понимая, что научить умного человека специфике конкретного тюнинга Nginx можно за пару недель, а вот научить человека думать — невозможно.

https://youtu.be/76wzB8-GB98?si=T5K4cCGKkJI_j0JQ В универе пели почти 20 лет назад)) Кто хоть чуть чуть это время застал?

История про эго В 8 классе нам задали домашку изучить что такое молекула. И там было определение, как сейчас помню: молекула - это наименьшая частица вещества. И такой дома это читаю и думаю: «так атом же меньше! Что за бред?» Перечитал еще раз весь параграф сначала, там пояснений нет этой фразе. Прочитал учебник сначала, там написано, что молекула состоит из атомов. Значит атом меньше! Еще раз читаю параграф на дом, там написано: молекула - это наименьшая частица вещества. На следующий день я, думая, что имею на это полное право, прихожу к учителю и прям разгневанно говорю: в учебнике ошибка! Как это можно учить? Она мне показывает пальцем в одно слово и говорит: - Это слово ты читал? - Читал! - И что это значит? Я резко осознал свою ошибку, мне стало стыдно, я замолчал, постоял. Потом сказал «спасибо» и ушел. С этого момента у меня пропало эго типо «я и так всё знаю» и я начал очень ответственно и внимательно относится к информации и понял, что спешка и самоуверенность - это тупо. К чему история — не знаю. Наверное, если вы чувствуете в себе самоуверенность — чем дольше это будет длиться тем меньшего добьетесь и тем сильнее в какой-то момент жизнь покажет, где вы слишком высоко задрали нос. Поэтому чем раньше наступит спокойствие и некое смирение, тем выше будут результаты. P.S. Как думаете, что это было за слово?

Сейчас будет откровение, потому что мы часто (я так годами) называем сложным то, что является простым. Вот метрики, которые прям со 100% точностью скажут объективно сложная у вас задача \ цель жизни или простая. Поехали) Сложность\ простота задачи или любой цели делится по двум критериям: • Психический (субъективный) • Объективный Есть следующие психические критерии сложности, когда объективно простая задача человеком воспринимается как сложная: • Высокая неопределенность. Нет алгоритма действий, а правила могут меняться в процессе. Например: готовитесь к интервью, но не знаете какую задачу решать следующей • Дефицит ресурсов. Не хватает времени, денег, знаний, людей или инструментов для выполнения работы. • Психологическое давление. Высокая цена ошибки, страх неудачи, внутреннее сопротивление или критика со стороны. • Отсутствие опыта. Человек делает это впервые в жизни, у него еще нет готовых навыков и нейронных связей. • Длительное время. Результат виден не сразу. Нужна серозная самодисциплина на протяжении месяцев или лет. • Приходится преодолевать активное сопротивление людей, конкурентов или внешних обстоятельств. ❗️То есть все это не имеет отношения к задаче\цели, а только к вам и вашему взаимоотношению с миром. Поэтому если видя такую задачу вы испытываете эти чувства - задача не сложная, это вам лишь кажется. Объективно сложная задача — это задача, чья структура перегружена элементами, связями и переменными. Любая задача / цель измеряется следующими объективными параметрами: 1️⃣ Многокомпонентность: Процесс состоит из огромного количества взаимосвязанных этапов. Ошибка в одном ломает всё. 2️⃣ Колмогоровская сложность: Инструкцию и описание системы невозможно сжать без потери смысла. Алгоритм решения или план действий занимает тысячи страниц, и в нем нет повторяющихся шаблонов. Проектирование и сборка космического корабля, подготовка с нуля в MAANG или свод законов государства. Описать этот процесс несколькими словами невозможно без потери смысла. 3️⃣ Ресурсная и термодинамическая сложность: Для достижения цели требуется колоссальный объем энергии, редких материалов, процессорного времени или труда людей, который находится на грани своих возможностей . Постройка термоядерного реактора. 4️⃣ Архитектурная сложность: Система состоит из тысяч элементов, которые влияют друг на друга. Изменив один элемент, вся система непредсказуемо меняется. Управление экономикой страны, прогнозирование погоды на месяц. Здесь элементы, т.е. люди, циклоны постоянно меняют свое поведение в ответ на действия системы. 5️⃣ Вычислительная сложность: Количество шагов решения/достижения цели экспоненциально растет при увеличении входных данных, как мы знаем в программировании это обозначается как O(2^n) Подбор порядка задач наугад в leetcode: без знания системы невозможно за разумное время найти правильные порядок обучения ❗️Главное отличие от «простой» задачи В объективно сложной задаче даже при наличии 100% информации решение остается тяжелым, долгим и энергозатратным. Устранение неопределенности не делает алгоритм короче. Следуя этой инструкции можно сразу понимать в какое дело вы залазите и на работе (особенно на работе) верно делать оценку задач, т.к. вы будете отталкиваться не от субъективизма, а объективной реальности.

Господа) Как вы думаете, что такое «сложная задача/цель», а что такое «простая задача/цель»? Мы ведь тут все ставим цели большие (надеюсь). Вопрос: как определить, что цель сложная или простая, где граница?)

Пока мелочи покажу, потом, наверное, скину видео

Всем привет) Буду пробовать сюда писать, что у нас происходит за кулисами. Можно подумать, что ничего не происходит, т.к. никаких новостей нет. Сейчас у нас идет курс по System Design, и я каждый день готовлю материалы. Что-то из головы, что-то из книг, что-то из интернета с проверкой источников. Вопрос 1: Давайте пока вопрос, напишите в комментарии: кто разбирался с топологией сети для высоконагруженных приложений? То есть кто хотя бы знает, что существует в любом приложении деление на 3 уровня: • Периферийный (англ. edge level) • Региональный (англ. regional level) • Центральный (англ. core level) Вопрос 2: Сейчас у нас идет изучение периферийного уровня, а в нем конкретно ядра линукс + драйвера сетевой карты. И вот в драйвере используются многопоточные алгоритмы для ограничения кол-ва запросов (по сути, балансировка нагрузки) без блокировок. Как думаете, как синхронизировать что-то, не используя блокировки?

Господа, Нужен движ, предлагайте идеи. Сейчас сам занят плотно system design’ом. Там вообще дебри. Фантазия не работает) И у кого ИИ тоже стоит уже поперек горла?

Ну что, господа) Кто хочет веб про выгорание инженеров? или лучше долгосрочное планирование карьеры?

Кто интенсив пропустил на той неделе, на канале запись появилась в YouTube

Господа, завтра веб. Будет много пользы, даже тем кто раньше был. Приглашаю, группа тут: https://t.me/+mRtJMFnjutU4M2Fi

Почему 5 лет в outsource часто превращаются в «день сурка» До интенсива осталось 5 дней, и сегодня я хочу поговорить о самой болезненной ловушке для Middle и Senior разработчиков. Многие ребята пишут мне: Я 5 лет в индустрии, знаю 3 фреймворка, почему меня не зовут на собеседование в Яндекс или MAANG? Ответ жесткий, но честный: в outsource мы часто проживаем один и тот же год опыта 5 раз подряд. Мы учимся быстро клепать фичи, гуглить готовые решения и надеяться на ИИ. Но когда дело доходит до фундамента Computer Science - наступает тишина. Computer Science - это не теория для олимпиадников. Это ваша суперсила. Без CS вы видите только поверхность кода. А вот с ним вы навсегда снимаете с себя синдром самозванца. Потому что разобравшись в сложных алгоритмах и свойствах структур данных, любой новый фреймворк, библиотека или проект на работе для тебя - это просто вопрос пары недель. Ты перестаешь зависеть от моды на технологии, потому что видишь, что под капотом у них одни и те же принципы. В первый день интенсива мы начнем именно с этого - с разбора Computer Science: ✅ Мы рассмотрим метод, как решать задачи, не заучивая код наизусть, а зная, какие свойства структур данных используются для их решения. ✅ Разберем, как все в программировании связано, и покажем, что хаоса не существует, но существуют плохие учебники, заставляющие вас поверить, что вы ничего не можете и всё это для гениев. ✅ И в доказательство, что подход работает, решим задачи с интервью и вы увидите, как все может быть просто Вопрос) leetcode часто превращается в бесконечную зубрежку, которая не дает уверенности. Какая тема в алгоритмах для вас самая "сложная, на котором вы чаще всего спотыкаетесь?

50% из вас застряли из-за одной ошибки Вчерашний опрос подтвердил мои догадки. Большинство из вас (ровно половина!) ответили, что главная преграда на пути к оферу в BigTech - это отсутствие четкого плана действий. И я вас прекрасно понимаю. Когда ты Middle или Senior в outsource, на тебя валится гора информации: ☑️ Зубри LeetCode ☑️ Разберись с Kafka ☑️ Купи курс по System Design Ты хватаешься за всё сразу, тратишь вечера после работы, но через месяц понимаешь, что стоишь на месте. Знаете, почему в университете я стал первым в рейтинге и получил президентскую стипендию? Не потому, что я гений. А потому что знаю секрет, про который говорил выше: Не зубрить, а понимать, какие процессы вселенной отображаются в программировании. Что я умею лучше всего, так это структурировать хаос. И я знаю, как даже сверхсложную задачу разложить на понятный алгоритм. Чтобы не быть голословным: на 3-м курсе я провел эксперимент: разложил сложные методички на понятные шаги, из-за чего быстро изучил программу семестра за 1 месяц и сделал все лабораторные работы. Пока остальные только начинали вникать в темы, у меня освободилось 3 месяца семестра, которые я полностью посвятил развитию себя как специалиста и работе. Побочный эффект: экзамены были сданы на 10 (в Беларуси это что-то вроде 5-ки с двумя плюсами, т.е. эту оценку не ставят), самый придирчивый преподаватель поставил 9, потому что не принципиально не ставил никому 10. Но обсудив со мной работу виртуальной памяти, был настолько удивлен, что попросил показать, где я всё это вычитал. На это я показал ему свой конспект, который собирал по крупицам (был 2010 год). Просмотрев его, он поставил мне 10 и включил этот конспект, как методичку к своему курсу. Этот навык, - находить суть в хаосе и бить точно в цель, в 2016 году я применил для помощи ребятам к подготовке в MAANG. Я убрал всё лишнее, оставил суть и упаковал это в систему Cronis. 🥇Результат: 6600+ учеников прошли по этой карте. Все, кто дошел до конца - работают там, где мечтали. Им не нужно было гадать, что учить сегодня вечером. У них был ПЛАН. До интенсива осталось всего 6 дней. Я искренне жду нашей встречи. Мне хочется не просто «рассказать про карьеру», а помочь вам превратить хаос в голове в четкую стратегию из 3х шагов: 1️⃣ Фундамент (CS): чтобы вы умели решать задачи не заучивая и видели баги в Redis раньше, чем их найдет ИИ. 2️⃣ Масштаб (System Design): чтобы вы проектировали системы на миллионы пользователей, а не «красили кнопки». 3️⃣ Офер (Soft Skills): чтобы вы знали, как получить именную благодарность от Google, даже если в начале пути вас называли «худшим». План у меня есть. Буду рад, если он поможет вам так же, как когда-то помог мне. Чтобы попасть, вступайте в группу Ниже фото зачетки, с исправленной 9-ой на 10-ку.