Cобеседование на позицию senior+ – вопросы для работодателя и что подмечать в ответах

⚠️Важное замечание. Если вы хорошо показали себя на собеседовании, то компания тоже постарается “продать” себя вам. Нужно понимать, что если что-то не так с процессами или условиями труда, то нанимающий менеджер вряд ли скажет об этом прямо.

Тем не менее, задать эти вопросы все равно стоит:

- Что будет обязательно входить в мою рутину?
- С кем я буду работать?
- Кто будет мой руководитель? Кто принимает решения?
- Как выстроен процесс разработки? Какие коммуникации и согласования в этом процессе?

В дополнение к этим вопросам стоит уточнить про технику и архитектуру:

- Насколько модульное приложение? Есть ли CI/CD?
- Какая архитектура системы? Кто контролирует ее развитие?
- Как принимаются архитектурные решения?
- Ведется и обновляется ли документация?

Например, если в ответах на эти вопросы ни разу не было слова “микросервисы”, а ПО разрабатывается 10 лет, – значит, скорее всего, там монолит с кучей легаси.

На что стоит обратить внимание:

✅ Если руководитель прямо говорит о косяках, с которыми приходится работать, – “Есть такая проблема, которую мы решаем”. Обычно все рассказывают, какой у них замечательный проект, но в процессе работы всегда всплывают недостатки. Честность на собеседовании – однозначно зеленый флаг.

🚩 “Как вы справляетесь со стрессовыми ситуациями?” – На это можно ответить “А как часто у вас бывают стрессовые ситуации, и почему?” Разумеется, в работе случается всякое, но если работа сопряжена с постоянным стрессом – это говорит о серьезных проблемах в процессах.

🚩 ”Мы создаем уникальную технологию”. Действительно уникальных технологий единицы на весь мир. Создать свой собственный алгоритм автоматизиции или свою базу данных – амбиции, которые крайне редко оправданы.

✅🚩 Работа с рекрутером. Если все быстро, четко, конструктивно – это свидетельствует о том, что в компании процессы работают хорошо. В отделе разработки, конечно, все может быть совсем не так

Напротив, стоит задуматься, если рекрутер сам не очень понимает, кого ищет, если в требованиях к вакансии 40 технологий, а сами требования размытые или, наоборот, опыт работы с конкретной БД 3 года и никак иначе. Не говоря уже о знаках зодиака, таро и “какой у вас тип личности”. 🫣

А о том, какие навыки нужны, чтобы претендовать на позиции выше сеньора, будем говорить в следующий четверг 23 января на митапе [Технический Лидер]. Приходите!

🏔 Для тех, кто хочет с душой провести выходные в Грузии!

8-9 февраля
IT SOUL WEEKEND: выходные в горном SPA с ИТ-коммюнити

Хочется вдохновения, качественного общения и перезагрузки в уютной атмосфере? Присоединяйтесь к нам!
Едем в Горную Аджарию, в отель Chateau Milisi с панорамным видом на горы, бассейном и SPA зоной, чтобы отдохнуть и зарядиться, провести время в теплой компании, уделить внимание телу и душе, и наполненными вернуться обратно.

🔧 Features included:
• Warm & soulful conversations
• Relaxed, easygoing, and fun vibes
• Low or no-alcohol mode
• Deep talks with talented minds
• Attention to body and soul aspects

🎒Что по программе выезда:
• проживание в отеле Chateu Milisi (завтрак включен)
• трансфер из Батуми и обратно (выезд в 9 утра в субботу, в воскресенье в 7 вечера обратно)
• чай, телесные практики и йога, теплое общение
• бассейн, сауна, настольный теннис и бильярд

📅 даты выезда: 8-9 февраля;

💰Стоимость участия:
* 300 GEL ( 250 GEL Early bird до 1 февраля )

Бронирование и подробности - @NikShc ⠀

👋 Привет! Вчера у нас прошло сразу два мероприятия, так что, если не знаете, чем занять вечер – приятного просмотра!

1️⃣ В девятом докладе из серии H&S Conclave Елизавета Булыгина рассказала о том, как в больших fintech компаниях выстраиваются процессы управления командами, формируется продуктовый бэклог, реализуются задачи из этого бэклога, и какую роль в этом играет Solution Architect.

📺 Запись мероприятия уже на нашем YouTube-канале.

2️⃣ Павел Вейник выступил для компании Andersen на тему “Кэши: виды, критерии выбора, проблемы и способы их решения”. Встреча проходила очно в Батуми

📺 Посмотреть запись можно вот тут.

А уже завтра встретимся на митапе [Технический Лидер], где поговорим о росте разработчика выше уровня senior, роли и навыках техлида, а также взглянем на текущее состояние рынка IT в Европе и США, и обсудим, как разработчику оставаться востребованным сейчас и в будущем.

Регистрируйтесь и задавайте интересующие вас вопросы в форме!

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

1️⃣ "Designing Data-Intensive Applications" (Martin Kleppmann)

Это must-read для тех, кто работает с высоконагруженными системами. Книга особенно ценна тем, что:

- Детально разбирает различные модели данных (реляционные, документные, графовые) и помогает понять, когда какую использовать
- Объясняет принципы построения распределенных систем, включая работу с Apache Kafka, Hadoop и Spark
- Рассматривает стратегии масштабирования и отказоустойчивости
- Дает практические рекомендации по выбору технологий хранения данных

Плейлист с подробными разборами каждой главы от senior+ инженеров из нашего сообщества.

2️⃣ "Software Architecture in Practice" (Bass, Clements, Kazman)

Эта книга - отличный фундамент для понимания базовых концепций архитектуры ПО:

- Объясняет, почему архитектура - это не просто дизайн, а набор осознанных решений
- Детально разбирает архитектурные стили и их применение
- Показывает, как архитектура влияет на жизненный цикл разработки
- Учит работать с качественными характеристиками системы

3️⃣ "Building Evolutionary Architectures" (Ford, Parsons, Kua)

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

- Вводит концепцию "fitness functions" для оценки качества архитектуры
- Объясняет, как делать архитектуру адаптивной к изменениям
- Рассматривает практики resilience engineering
- Учит выстраивать процессы непрерывного улучшения архитектуры

4️⃣ "Software Architecture: The Hard Parts" (Ford, Richards, Sadalage, Denghani)

Практическое руководство по современной распределенной архитектуре:

- Глубоко погружает в особенности распределенных систем
- Разбирает архитектуру микросервисов и связанные с ней компромиссы
- Охватывает serverless и облачные решения
- Помогает понять trade-offs при проектировании распределенных систем

Эти книги дополняют друг друга: Kleppmann даст глубокое понимание работы с данными, Bass и соавторы обеспечат фундаментальную базу, Ford научит делать архитектуру эволюционной, а Richards поможет разобраться с современными распределенными системами.

👉 Ключевые моменты из этих и других книг + примеры из продакшена реальных проектов + практические задачи на проектирование архитектуры высоконагруженных систем + фидбек от solution-архитектора Miro и EPAM Павла Вейника = курс [Технический Лидер].

Узнать о курсе подробнее и записаться на консультацию вы можете здесь. В феврале стартуем следующий поток, не пропустите!

📍Друзья, уже в этот четверг 30 января ждем вас на второй встрече из мини-серии, посвященной Structurizr. В этот раз в формате Live Session вместе шаг за шагом разберем:

1. Установка и настройка: как поднять разные версии Structurizr и базово администрировать их в своей среде.
2. Решение реальной задачи: определим примерную задачу, напишем для нее код и детально разберем, что, как и почему.
3. Документация и ADR: покажем, как эффективно документировать архитектуру с помощью Structurizr и использовать подходы архитектурных решений (Architecture Decision Records, ADR).

Спикер: Cаша Белян, Python developer .

Запись первой встречи можно посмотреть на нашем Youtube-канале

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

Все чаще сталкиваюсь с проблемами найма техлидов, архитекторов и CTO, поэтому написал статейку для нанимающих менеджеров и фаундеров, ликбез о том, как нанять техлида/архитектора/CTO в небольшую компанию.
(Павел Вейник)
https://www.linkedin.com/pulse/%D0%BD%D0%B0%D0%BD%D0%B8%D0%BC%D0%B0%D0%B5%D0%BC-%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D0%BE%D1%80%D0%B0-%D0%B2-%D0%BD%D0%B5%D0%B1%D0%BE%D0%BB%D1%8C%D1%88%D1%83%D1%8E-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B0%D0%BD%D0%B8%D1%8E-pavel-veinik-lnajf/?trackingId=wFYikCLISMmsVwB2ZAd%2FoA%3D%3D

Принцип 80/20 в выборе технологий: как senior-разработчикам и архитекторам фокусироваться на главном

На что смотреть при выборе инструментов?

Критичные Non-functional Requirements. Если ваш сервис обрабатывает 1 млн TPS, но вендор СУБД хвастается «горизонтальным масштабированием», проверьте, как это работает при частичной потере сети. Для highload систем смотрите не на «среднюю» производительность вендора, а на p99 latency под нагрузкой.

Экосистема, а не фичи. Более высокая производительность не стоит того, если для внедрения нового инструмента в вашу систему придется 3 года писать кастомные интеграции.

Команда > Технология. Работали ли вы и разработчики в вашей команде с инструментом? Если нет, то как быстро вы сможете изучить его? И не стоит забывать про bus factor.

Как проверить инструмент, если лично с ним не работали?

Документация и бенчмарки. Главное, отфильтровать маркетинговые истории от реальных данных. Если вендор хвастается скоростью в 1 млн RPS, проверьте: размер полезной нагрузки (1 байт vs 1 КБ?), тип дисков (NVMe vs HDD?), уровень изоляции (Read Uncommitted?). В идеале, ищите бенчмарки, где код и конфиги выложены на GitHub.

Реальные кейсы. Поищите, какие вопросы задают на stackoverflow, с чем возникают проблемы и как их решают. Читайте инженерные блоги компаний вашего масштаба.

Прототип. Сделайте не «демку», а эмуляцию реальной нагрузки. Пример:

— Для базы данных: напишите скрипт, который генерирует 70% read / 30% write запросов (ваш реальный сценарий), и добавьте фоновую нагрузку на сеть.
— Для очереди: проверьте, как поведет себя система при повторной обработке 100k «зависших» сообщений.

Новые технологии: инновации vs хайп

Концепция «innovation tokens» от Dan McKinley: у каждой команды ограниченный ресурс на поддержку «модных» инструментов. Больше рисков возникает там, где пересекаются unknown unknowns. Если вы внедряете новые технологии, делайте это постепенно.

Спросите себя:

🔸Что случится, если этот инструмент перестанет развиваться через год?
🔸Какие 3 основные операции он должен выполнять? Если инструмент решает почти все нормально, но ваши 3 — плохо, это провал.
🔸Сколько человек в команде готовы экстренно чинить его в 3 часа ночи?

Выбор правильной технологии – одна из задач техлида и архитектора при проектировании системы. На курсе [Технический Лидер] вы научитесь решать архитектурные задачи по шаблону, основанному на опыте десятков реальных компаний – от сбора и уточнения бизнес-требований до проектирования устойчивой к переменам архитектуры, а также узнаете, как отстаивать свои технические решения перед стейкхолдерами, чтобы обеспечить долгосрочное развитие системы.

👉Записывайтесь на консультацию!

🚀 Software Craftsmanship Meetup №29 уже в этот четверг!

📅 Дата: 6 февраля
⏰ Начало в 20.00 по GMT+3

Как техлиду и архитектору правильно работать с бизнес-метриками? Почему они так же важны, как и технические? Об этом и не только поговорим на ближайшем митапе!

Программа митапа:

✅ Что такое бизнес-метрики и чем они отличаются от технических?
✅ Почему эти метрики важны? Практические примеры.
✅ Как собирать и работать с бизнес-метриками на всех этапах проектирования и разработки?
✅ Влияние архитектуры на бизнес-метрики. Связь нефункциональных требований с бизнес-метриками.
✅ Заключение: бизнес-метрики как связующее звено между бизнес-целями и технической реализацией.

🔗 Регистрация: https://hardsoftskills.dev/meetup29

Друзья, если вчера пропустили, Software Craftsmanship Meetup уже доступен на нашем ютубе.
🔗 Майндмэп по ссылке
Приятного просмотра и хороших выходных!

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

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

💡Системы строятся на нескольких уровнях абстракции:

1. Низкоуровневый код (ассемблер, машинный код)
2. Языки высокого уровня (Java, Python и др.)
3. Фреймворки и библиотеки
4. AI-инструменты, no-code и low-code решения

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

Чем шире скоуп ответственности, тем на более высоком уровне абстракции нужно рассуждать:

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

❗️Преодоление боязни отрываться от кода – умение делегировать и доверять тем, кто реализует код. Рост выше сеньора без этого невозможен. Архитектор может не знать особенностей recovery в Kafka или всех деталей работы Cassandra. Достаточно понимать:

▫️ Основные принципы работы технологий
▫️ Их сильные и слабые стороны
▫️ Типовые сценарии применения
▫️ Базовые гарантии, которые они предоставляют

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

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

Архитектор может и должен знать, как устроены наиболее критичные части системы. Но погружение в детали не должно мешать видеть общую картину и решать главную задачу – создание работающего продукта для бизнеса. Как это делать – учим на курсе [Технический Лидер]. Стартуем уже на этой неделе – успейте записаться!

Привет! Завтра в 20.00 GMT+3 на H&S Conclave будем разбираться как обращаться с токсчиными звездами в команде.

Обсудим:
✔️ Почему мы терпим разработчиков, которые приносят отличные результаты, но отравляют атмосферу в коллективе?
✔️ Правда ли, что "гений" может быть незаменимым, или он тянет команду вниз?
✔️ И самое главное — почему софт-скиллы для разработчиков так же важны, как технические знания?

🔗 Регистрация на сайте. До встречи!