✨ Друзья, 18 сентября мы провели офлайн-митап в Батуми! 🎉

В последний момент у нас произошла замена спикера, но митап всё равно получился очень насыщенным, мы успели:

🎙 Послушать доклад от Павла Вейника и обсудить вопросы о роли CTO
🤝 Побрейнштормить в командах, какого стартапа не хватает Батуми, провести питчинг и выбрать команду-победителя (чурчхела нашла своих героев 🍬)
🍕 Пообщаться за пиццей и напитками в неформальной атмосфере
🎁 Разыграть книгу Мартина Клеппмана Designing Data-Intensive Applications — настоящий must-read для инженеров, работающих с высоконагруженными системами

Книга уже дошла до победителя, Никита ещё раз поздравляем! 🙌

Спасибо всем, кто пришёл, участвовал и сделал этот вечер таким живым и ярким ❤️

PS. 🇰🇿 Алматы — вы следующие! До встречи офлайн уже в конце октября!

Если вы думаете, что у вас в компании все плохо, – подумайте еще раз

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

50% компаний все еще деплоит код вручную. А у 36% даже нет четкой стратегии деплоя. Это одни из выводов исследования Harness – “State of Engineering Excellence 2025”.

Вот еще некоторые цифры:

🔹 10% компаний регулярно пропускает критические баги в продакшен
🔹 76% не используют feature flags или не умеют ими управлять
🔹 Больше трети не следуют единой branching-стратегии
🔹 У 60% компаний тестовая среда не совпадает с продакшеном
🔹 Две трети не могут собрать и протестировать dev-окружение быстрее 15 минут
🔹 В 55% пайплайнов нет ни одного quality gate
🔹 81% компаний не обучают своих инженеров
🔹 У 61 % команд код-ревью занимает больше суток

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

Мы хотим углубиться в эту тему.

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

Зачем это вам:

🔸 Оценить, где вы находитесь в сравнении с другими командами
🔸 Получить чек-лист шагов, которые можно предпринять, чтобы улучшить ситуацию
🔸 Внести свой вклад в развитие инженерной культуры

Результаты исследования мы обязательно опубликуем в подробной статье.

👉 Присоединяйтесь к исследованию

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

Что делать архитектору, аналитику или техлиду, когда на стол падает огромный проект – с размытыми бизнес-требованиями, почти без 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-стартапа.

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