🐘 Как съесть слона и не подавиться: архитектура больших проектов шаг за шагом

Что делать архитектору, аналитику или техлиду, когда на стол падает огромный проект – с размытыми бизнес-требованиями, почти без NFR и с кучей регуляторных ограничений?

Разберём на реальном кейсе удачные решения и ошибки на пути к целевому решению:
🔹 дизайн бизнес-архитектуры
🔹 коммуникация со стейкхолдерами
🔹 выбор техстека
🔹 построение инфраструктурных и платформенных решений

🎤 Спикер: Артём Головачёв, Software Architect в Andersen (14 лет опыта в разработке, специализация: архитектура финтех-решений на Java).

📅 16 октября, 20:00 (GMT+3)

🔗 Зарегистрироваться

Сеньоры нанимают сеньоров: как проводить интервью

Интервьюирование senior-инженеров требует такого же системного подхода, как проектирование архитектуры — с четкими метриками, воспроизводимым процессом и защитой от когнитивных искажений

🎯 Hiring-бар и ожидания от сеньора

Senior — это человек, который берет неструктурированную проблему, декомпозирует ее, выбирает trade-offs и ведет решение до продакшена с учетом долгосрочных последствий

От сеньора ждем:

🔹 Способность принимать архитектурные решения в условиях неопределенности и обосновывать их

🔹 Опыт влияния на процессы и стандарты команды/компании

🔹 Умение масштабировать себя через менторство, код-ревью, документацию

🔹 Понимание бизнес-контекста и способность переводить его в технические требования

🔹 Track record доставки сложных проектов от замысла до метрик

Hiring-бар проходит там, где кандидат демонстрирует не только "как делать", но и "почему именно так" и "что будет через год"

🔍 Сигналы сеньорности и способы их проверки

Измеряйте конкретные индикаторы, а не общее впечатление:

🔸 Системное мышление: просите описать архитектуру последнего проекта с фокусом на trade-offs. Задавайте follow-up: "Почему выбрали X, а не Y? Как решение повлияло на operational cost?"

🔸 Ownership: спрашивайте про инциденты, которые кандидат расследовал. Проверяйте глубину: от симптома до root cause, от hotfix до долгосрочного решения

🔸 Влияние: интересуйтесь, какие процессы или стандарты кандидат изменил. Если нет примеров — красный флаг

🔸 Code quality на масштабе: разберите кейс про рефакторинг legacy-системы. Как приоритизировал? Как снижал риски? Какие метрики отслеживал?

🔸 Коммуникация: оцените, как кандидат объясняет сложное простым языком — это предиктор эффективности работы в команде

⏱️ Дизайн интервью-процесса

Сеньоры ценят свое время и ожидают прозрачности. Плохой процесс отсеивает лучших кандидатов до оффера

Принципы эффективного процесса:

🔹 Предсказуемость: заранее пришлите структуру интервью, темы, формат (coding/system design/behavioral)

🔹 Релевантность: никаких leetcode-марафонов. Давайте задачи, близкие к реальным проблемам вашей команды

🔹 Грамотное использование времени: 3–4 раунда по 60 минут достаточно. Каждый раунд измеряет разные компетенции без overlap-ов

🔹 Асинхронные опции: предложите home assignment как альтернативу live coding для кандидатов с жестким календарем

🔹 Обратная связь: обещайте конкретный timeline (например, решение за 48 часов) — и держите слово

Интервьюеры должны пройти калибровку: одинаковые критерии оценки, общее понимание hiring-бара, умение отличать "не подошел нам" от "недостаточно сеньор"

📊 Фиксация доказательств вместо впечатлений

Субъективное "понравился/не понравился" убивает качество найма. Используйте структурированный scoring

Создайте evaluation framework:

🔸 5–7 критериев (technical depth, system design, leadership, communication)

🔸 Шкала 1–4 для каждого критерия с описанием уровней

🔸 Требование: конкретные примеры из интервью в каждой оценке ("поставил 3 по system design, потому что предложил sharding, но не учел консистентность при failures")

🔸 Независимое заполнение scorecard каждым интервьюером до дебрифа — без влияния мнения коллег

На дебрифе сравнивайте факты, а не ощущения. Если оценки расходятся — это сигнал копнуть глубже или признать недостаток данных

✅ Принятие решения и закрытие кандидата

Решение принимается на основе общей оценки плюс аргументированное мнение hiring manager

Правила финализации:

🔹 Нанимаем, если кандидат превышает hiring-бар минимум по 4 из 5 критериев

🔹 Не нанимаем, если есть critical gap

🔹 Если непонятно → дополнительный раунд, сфокусированный на компетенциях, которые вызывают сомнение, или отказ

Нанять неподходящего человека хуже, чем пропустить хорошего кандидата

При отказе давайте конструктивный feedback с примерами: "сильные алгоритмические навыки, но не хватило глубины в distributed systems — рекомендуем изучить consensus protocols и patterns for resilience". При оффере — быстро, четко, с четкими ожиданиями о роли и первых 90 днях

🇰🇿 Алматы, встречай!

Мы запускаем первый офлайн-митап From Code to Talk — вечер, где инженеры, архитекторы и тимлиды выходят за рамки кода, делятся peer-to-peer опытом и просто отлично проводят время!

Обещаем вдохновляющие доклады, много пиццы 🍕, живое общение и по-настоящему тёплую атмосферу комьюнити 🫂

🗓 31 октября, 18:30

🎙Программа:
▸ LLM In & Out: Twenty Minutes Adventure. As if… – Иван Луценко, Android Tech Lead в Bereke Bank
▸ Путь от браузера до приложения – Юрий Морозов, CTO в Paylink

Мероприятие организовано в партнерстве с:

🤝 Bereke Bank – казахстанский банк, активно развивающий цифровые продукты и API для интеграций, использующий современные IT-решения и технологии для улучшения сервисов и автоматизации процессов.

🤝 PayLink – финтех-компания из Казахстана, которая предоставляет бизнесу удобные решения для приема онлайн-платежей: подключение эквайринга, рекуррентных и каскадных платежей, поддержка Apple/Google Pay и другие инструменты, нацеленные на увеличение доходов.

🔗 Регистрация

💡 OaaA: Office as an Architecture.
Как организовать микросервисы в эпоху AI-агентов?

Каждая архитектура рождалась из необходимости − от Layered до Event-driven и микросервисов. Но где место AI-агентам? Отдельный сервис или часть существующего? 🤔

Архитектор и Microsoft AI MVP Alex Pshul представит концепцию Office as an Architecture (OaaA) − подход, в котором система работает как офис: сервисы − отделы, а агенты − новые сотрудники. Вместе они сотрудничают, учатся и создают результат.

🗓 Уже завтра на нашем митапе!
23 октября, начало в 20.00 по GMT+3

Зарегистрироваться и задать вопрос спикеру можно по ссылке🔗

Архитектурные катастрофы – часть 4: AWS US-East-1

На этой неделе AWS неожиданно сломали интернет: встали Netflix, Slack, Epic Games, Venmo, Zoom, Reddit и десятки других сервисов.

🔥 Что произошло?

Ночью 19–20 октября в регионе AWS US-East-1 резко выросли ошибки в DynamoDB. Следом посыпались IAM, Lambda, EC2, ECS, RDS и еще 140 сервисов.

AWS быстро локализовала проблему, но к тому времени глобальные таблицы и другие функции AWS уже успели пострадать и полное восстановление заняло 15 часов.

🧠 В чем причина?

Триггер – проблема DNS resolution для эндпоинтов DynamoDB. Из-за скрытого race condition два экземпляра DNS Enactor переписали планы, и региональная DNS-запись DynamoDB неожиданно очистилась (все IP стерлись).

Дальше эффект домино: EC2 не может запускать инстансы → мониторинг Network Load Balancer теряет связь → сетевая связность разваливается → все зависимые сервисы встают.

Интересно, есть ли какая-то связь со словами CEO AWS “AI is now pushing 75% of our production code” или это старый-добрый рукотворный факап? 🤔

🛠 Как AWS справились?

Инженеры AWS перешли в режим аврала. К утру они оперативно обнаружили DNS-сбой и восстановили записи DynamoDB. Затем началась вторая волна: поступивший поток запросов создал перегрузку.

Ключевое решение: временный throttling критичных операций. AWS ограничил rate новых запусков, давая системам время на восстановление без повторного коллапса.

Постепенно трафик выровнялся и ограничения сняли спустя примерно 15 часов после начала инцидента. В 15:01 PDT все сервисы официально вернулись в штатный режим.

💸 Сколько это стоило?

Час простоя US-EAST-1 – $66-100 млн. При 15 часах ущерб составил $1-1.5 млрд для индустрии.

Для Amazon – SLA компенсации и репутационный удар: акции просели на 2.3% ($40 млрд капитализации).

Для пользователей – больше 140 сервисов AWS оказались недоступны или работали некорректно, из-за чего посыпались системы клиентов AWS: самого Amazon, Netflix, OpenAI, Cursor, Slack, Venmo, Perplexity AI, Coinbase, Canva, Duolingo, The NY Times, Apple TV, Twitch и еще десятков компаний с миллионами пользователей.

🔍 Что можно было сделать иначе?

🔹 Chaos Engineering: регулярно и целенаправленно моделировать отказы и сбои в разных местах чтобы протестировать систему на надежность и отработать процесс восстановления.

🔹 Резервные пути и дублирование: снизить зависимость от US-East-1, внедрять мульти-региональные кластеры (например, Global Tables для DynamoDB) или дополнительные DNS-планы, чтобы при сбое был план Б.

🔹 Тестирование автоматизации: регулярно эмулировать аварии DNS (гонки транзакций, сброс старых планов) и тщательно ревьюить критические скрипты обновления. Пусть “AI генерирует 75% кода”, за оставшиеся 25% ручного контроля всё равно отвечают люди.

Что думаете – какие ещё меры могли предотвратить катастрофу? Пишите в комментариях!

🚀 Друзья, уже завтра ждём вас на доклад!

📅 28 октября, 20:00 (GMT+3)

От API-запросов к промптам: как Model Context Protocol (MCP) меняет взаимодействие с внешними сервисами и открывает новый уровень интеграции между людьми, AI и системами.

🎙️ Спикер: Максим Сальников, AI Dev Tools & Platforms Solution Engineer в Microsoft, лидер техсообществ и международный спикер из Осло.

👉 Регистрация

🎙31 октября в 18:30 − офлайн-митап из серии From Code to Talk в Алматы!

🔥 Спикеры митапа:
▸ Иван Луценко, Android Tech Lead в Bereke Bank − LLM In & Out: Twenty Minutes Adventure. As if…
▸ Юрий Морозов, CTO в Paylink − Путь от браузера до приложения, или что происходит, когда вы в браузере вбиваете google.com
▸ Тимур Дуюсов, Technical Product Owner в Bereke Bank − Выгореть, чтобы вырасти: честная история разработчика, ставшего лидом

🍕 Вдохновляющие доклады, пицца, живое общение и уютная атмосфера комьюнити − всё, как мы любим!

🤝 При поддержке Bereke Bank и Paylink
🔗 Регистрация

Как выбрать базу данных для проекта и не пожалеть 🤔

🗓 30 октября, 20:00 GMT+3

От реляционных баз до NoSQL, NewSQL, lakehouse и векторных − за полвека индустрия баз данных прошла длинный путь, полный неожиданных открытий и болезненных ошибок. Мы разберём, как выбор хранилища может привести систему к успеху или краху, какие идеи действительно изменили подход к данным, и как не наступить на старые грабли при проектировании новых решений.

📚 В докладе:
‣ краткая история эволюции систем управления данными;
‣ архитектурные идеи, изменившие индустрию (ACID, LSM-деревья, мультимодельные подходы и др.);
‣ реальные кейсы и уроки, которые помогут не повторять ошибки прошлого;
‣ мини-гайд по осознанному выбору базы данных.

👨‍💻 Спикер: Максим Аршинов, Solution Architect в EPAM Spain

👉 Зарегистрироваться

Гигиенический чеклист техлида при делегировании задач

Корректное делегирование задач — ключ к эффективности команды, но даже опытные техлиды часто упускают важные детали.

⚠️ Ошибка: Делегировать задачу, не передавая полномочия принимать решения

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

Вместо этого сформулируйте не просто задачу, а ожидаемый результат: какой итог вам нужен и как вы поймёте, что цель достигнута.

🔸 Чёткий результат: опишите конечный исход и критерии успеха, а не просто набор шагов.
🔸 Полномочия: обозначьте, какие решения человек может принимать самостоятельно и где нужно с вами согласовать изменения.
🔸 Рамки ответственности: уточните ограничения, в которых исполнитель действует, и как поступать при возникновении сложностей или вопросов.

❗️ Ошибка: Недостаточно контекста и приоритета у исполнителя

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

Что включить в делегирование:

🔹 Бизнес-контекст: "клиент X грозит уйти, если не решим до конца квартала"
🔹 Технический контекст: ссылка на ADR, связанные PR, метрики до/после
🔹 Explicit приоритет: P0 (бросаем всё), P1 (в текущий спринт), P2 (backlog). Без P0/P1/P2 задача не делегирована
🔹 Зависимости: "блокирует миграцию БД, нужна до 15 ноября"

⏰ Ошибка: Делегировать не тому человеку или в неподходящий момент

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

Учитывайте сильные стороны и текущую загрузку команды: выбирайте того, кто сможет качественно выполнить задачу и заинтересован в её результате.

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

Про что нужно помнить:

🔸 Capacity check: у человека есть 60–70% времени на новую задачу? Если нет — это не делегирование, а перегрузка
🔸 Growth zone: задача чуть сложнее текущего уровня (70% умеет, 30% новое). Если 100% знакомо — скучно, если 50% новое — стресс
🔸 Bus factor: не давайте критические задачи одним и тем же людям. Распределяйте экспертизу

🔄 Ошибка: Превращать контроль в микроменеджмент или не контролировать вовсе

Частые проверки мелких деталей подавляют инициативу, а полное отсутствие контроля может привести к неприятным сюрпризам на завершающих этапах.

Найдите баланс: доверьте исполнителю свободу действий, но введите прозрачный цикл обратной связи. Регулярно проверяйте прогресс через отчёты или короткие митинги и корректируйте курс по необходимости.

🔹 Checkpoint 30%: "покажи дизайн/RFC, обсудим риски" — на этом этапе дешево менять направление
🔹 Checkpoint 70%: "code review драфта, проверим интеграцию" — исправляем архитектурные косяки
🔹 Checkpoint 100%: "demo + метрики, готовность к production"

🔹 Критерии успеха: согласуйте заранее, что конкретно должно быть сделано (например, в виде Acceptance Criteria или тестового списка), чтобы в конце не было разногласий.
🔹 Автономия с отчётностью: позвольте исполнителю самому выбирать подход, но попросите периодически информировать вас о ходе и возникающих проблемах.

🧱 Ошибка: Не убирать системные блокеры и не закреплять результат в процессах

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

После выполнения задачи убедитесь, что её результат интегрирован в процессы: обновите документацию, внесите изменения в план работ и автоматизируйте новый процесс – это поможет закрепить результат и избежать возврата к задаче в будущем.

🎙Друзья, редкий в наше время Архитектурный Трёп − уже завтра!

🗓 4 ноября, 20:00 (GMT+3)

Тема − огонь🔥: если вы когда-либо совмещали несколько проектов, думали о втором источнике дохода или проходили через удачный (или не очень) опыт работы на двух фронтах − приходите обсудить и поделиться опытом.

Модерирует Настя Бакулова, ей тоже есть что рассказать. Ждём честного, живого разговора.

💬 Приходите участвовать вживую! Напоминаем, что Трёпы не записываются. Пожалуйста, не подключайте свои AI-тулы для записи бесед − мы будем их удалять со встречи из соображений безопасности.

Подробности и регистрация по ссылке🔗

⚡️ High-load будущего: serverless, edge computing и AI-driven оптимизации

Как меняются архитектуры под нагрузкой и зачем крупные компании уходят в edge и serverless? Разберём, где заканчивается бесконечный скейл и как ИИ помогает в автоскейлинге, capacity planning и anomaly detection.

🎙 Спикер: Андрей Якушин, Solution Architect и Engineering Manager с 18+ годами опыта в IT.

📅 Сегодня в 20.00 GMT+3

👉 Регистрация

12 зон ответственности CTO – и главная ошибка, из-за которой ломаются компании

💥 70 % digital-трансформаций проваливаются – и не из-за технологий.

Когда CTO зацикливается на технологиях – компания теряет скорость.
Когда CTO фокусируется только на людях – теряет качество.
Когда CTO забывает про бизнес – теряет смысл.

🔭 Мы собрали карту из 12 зон ответственности CTO – от архитектуры и инноваций до найма, безопасности и бюджета.

Но на практике почти каждый CTO проваливает одну и ту же вещь: Коммуникации и доверие.

CTO может идеально считать ROI, управлять облачными расходами и внедрять GenAI –но если команда не доверяет друг другу, все эти метрики ничего не стоят.

🗣 Бизнес рушится не из-за багов или неэффективных пайплайнов, а из-за сломанных коммуникаций.

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

Согласно опросу Gartner Peer Community 2023 года, 63% опрошенных назвали навыки межличностного общения и 55% – навыки ведения переговоров – самыми важными качествами CTO для успеха в бизнес-роли, тогда как чисто технические навыки подразумеваются как базовые.

А значит, что лучшие технические директора сейчас – это переводчики. Интерпретаторы неоднозначности. Не потому, что они забыли, как писать код. А потому, что они научились более важному: когда нужно отступить и позволить другим заниматься разработкой.

А в какой из 12 зон вы чаще всего «проваливаетесь» – технологии, люди или бизнес?

Почему одни команды работают стабильно и предсказуемо, а другие регулярно роняют продакшен? – Результаты исследования уровня инженерной зрелости

Месяц назад мы рассказывали, что совместно с Алексеем Обыскаловым, CTO и автором канала «CTO: порядок из хаоса» проводим исследование, чтобы выявить инженерные практики, которые сильнее всего влияют на зрелость инженерных процессов.

🔭 В исследовании приняли участие 106 инженеров. После обработки данных и проверки 1900 статистических гипотез, мы выявили 10 практик, внедрение которых кратно повышает качество процессов, интересные взаимосвязи между размером команды и инженерной зрелостью, а главное, что настоящая инженерная зрелость – это когда система устойчиво растёт без героизма.

👉 Полные выводы исследования читайте в статье на нашем сайте

👉 Также мы подготовили тест, в котором вы сможете оценить инженерную зрелость в своей команде

А пока, вот некоторые результаты:

🔥 Хаос не масштабируется. Команды с 30+ разработчиками не опускаются ниже индекса зрелости 4 из 10. Вероятно, при таком размере со слабыми процессами просто не выживают.

🔢 80% зрелости дают всего 4 блока практик. Самый влиятельный блок – тестирование. Тесты с управляемыми данными, которым доверяет команда, дают почти половину прироста зрелости. Подробнее в статье.

🕸 Чем больше команды, тем сильнее они похожи друг на друга. Если небольшие компании еще могут себе позволить не обновлять документацию, релизить по готовности, а не в рамках четкого цикла, то с ростом числа разработчиков приходится отлаживать процессы и вводить best practices.

✨Всего одна практика позволяет существенно улучшить ревью и инцидент-менеджмент, и, тем самым, существенно прибавить зрелости команде. Это внедрение PR/MR “паспортов” (цель, тест-ноты, откат).

🔌 Networking as a System: как построить сеть, которая приносит офферы

18 ноября в 20:00 (GMT+3) говорим о том, как осознанно прокачать свой нетворкинг.

В программе:
• Как пробить “стену” AI-рекрутеров и сотен резюме на вакансию
• Социальный капитал и «слабые связи»: почему они работают лучше всего
• Архетипы нетворкеров – какой ваш?
• Как превратить хаотичные связи в систему, которая работает даже без вас

Спикер:
Никита Щетько – человек, который объединяет IT-шников. Ментор HardSoftSkills, организатор IT SOUL CAMP ⛺️, Frontend Lead в 3dway.io и кофаундер healthtech-стартапа.

Регистрация🔗

"Двойная жизнь" разработчика: выводы Архитектурного Трепа #128

💻 Планирование и физическое разграничение

Ключ к выживанию – жёсткие границы. Эффективно работает разделение по времени: один проект утром, второй – вечером.

Идеально, если клиенты находятся в разных часовых поясах. Физическое разделение – обязательно для фокуса.

У меня два ноутбука. То есть один клиент на одном ноутбуке, второй клиент на втором. И вот этот момент очень круто сработал, потому что фокус внимания смещается

Для переключения контекста помогают «точки остановок» – фиксация в конце дня (или недели), что сделано, а что нет. Многим удобнее всего вести их в бумажном блокноте.

Я вернулась к старому доброму способу. Я каждое утро пишу точку остановок. В конце дня я зачеркиваю, что сделано. У меня ушла тревога, что я что-то забуду

⚖️ Юридические рамки и конфликт интересов

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

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

Важные юридические моменты:

🔹 Проверьте пункты о Non-compete и NDA.
🔹 Контракты со сложными или стремными пунктами лучше отдать на ревью юристу, который поможет найти лазейки.
🔹 Для фриланс-проектов удобно использовать статусы ИП или самозанятого, чтобы легализовать доход.

🚀 Эффективность vs Выгорание

Две работы резко повышают личную дисциплину. Уже нет времени на «раскачку», мозг ищет кратчайший путь к решению и перестает бояться просить о помощи.

То, что ты раньше делал 8 часов, тебе желательно впихнуть в 6, а еще лучше в 4. Мозг работает максимально

Обратная сторона: есть риск потерять время на рефлексию и стратегическое мышление, так как фокус смещается на решение тактических задач в моменте.

Нет времени на вот эту рефлексию. Ты как бы эффективен, но ты эффективен в моменте. Ты не можешь думать наперед

Восстановление становится критически важным: ритуалы (режим дня), спорт или массаж, и делегирование бытовых задач (клининг, готовка). Многие также делегируют рефлексию психологу.

Я начала ходить к психологу. Я просто начала выгружать туда. Всё, я прихожу, я за неделю что-то обдумала, я туда выгрузила, и всё

🗣 Коммуникация и ожидания

Говорить ли о второй работе? Консенсус: не афишировать с флагом, но и не врать, если спросят. Важно выстроить прозрачные отношения через регулярные 1:1, чтобы убедиться, что качество вашей работы не страдает.

У нас есть one-to-one митинги, когда я спрашиваю у своего менеджера, типа, все окей, всем все нравится?

Идеальный второй проект – тот, где нет микроменеджмента и жёсткого контроля, а фокус на результате. Иногда можно преподнести вторую занятость как платное хобби (например, менторство или свой проект).

🏁 Стратегия совмещения и горизонт

Мотивы со временем меняются: часто начинают из-за денег, но потом остаются ради интереса, изучения нового стека или развития soft skills.

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

Ключевое – иметь стратегию выхода или пересмотра:

🔸 Заранее определить срок (например, полгода-год), после которого будет принято решение.
🔸 Сформировать финансовую подушку, чтобы иметь возможность спокойно отказаться от одной из работ.
🔸 Понимать, что будет дальше: переход на один фулл-тайм или фокус на собственном проекте.

Я дала себе год. Через год я буду садиться и уже решать, в каком варианте я останусь. Возьму одну в фулл-тайм, вторая, скорее всего, что это будет свой личный проект

На следующей неделе встретимся, чтобы обсудить найм инженеров: как определить толкового специалиста, как проводить собеседования и как оценивать soft skills и что вообще происходит на рынке.

🔗 Регистрируйтесь по ссылке

Друзья, рады сообщить, что впереди нас ждут два Трёпа, и ближайший уже завтра! 🚀

🎙 Архитектурный Трёп №129
📅 20 ноября, 20:00 (GMT+3)

Тема: Как искать толковых инженеров и проводить собеседования, когда рынок перегрет

Обсудим самое важное и живое:

1️⃣ Кто такой “толковый инженер” сегодня?
2️⃣ Как проектировать интервью: задачи, архитектурные кейсы, обсуждение фейлов — что реально раскрывает кандидата?
3️⃣ Soft skills: что и как оцениваем?
4️⃣ Эра LLM и новая инженерная роль — что теперь важнее?
…и многое другое!

👤 Модератор: Юрий Морозов

🔗 Регистрация