Нанимать джунов — это настоящая pain in ass. Откликов приходит больше ста в неделю, а кандидаты отличаются по уровню: одни только вчера окончили курсы, другие — почти мидлы. Пока разберем все отклики, проверим тестовые, проведем собеседования — проходит полтора месяца. А потом найденный сотрудник не проходит испытательный, и все повторяется снова.

Чтобы облегчить поиск, мы в Mindbox настроили конвейер стажировок. Теперь на отбор тратим меньше времени, а получаем разработчиков, знакомых с процессами, проверенных «в бою» и лояльных к компании. В статье — подробная инструкция для нанимающих менеджеров: как построить процесс, проводить собеседования и онбордить стажеров.

Далее >>>

Об авторе

Меня зовут Глеб Ковалев, я ведущий frontend-разработчик в Mindbox. Пару лет назад я начал проводить стажировки для frontend-разработчиков. А сейчас начинающих фронтов мы нанимаем преимущественно через стажировки. О том, как это происходит, расскажу в этой статье.

История, как в Mindbox выстраивали продуктовый подход: о неудачных запусках, поиске роли продакт-менеджера и испробованных за это время фреймворках. По докладу CPO Mindbox на Product Sense.

Всем привет, на связи Петр Никитин, frontend-разработчик Mindbox.

Mindbox — это платформа автоматизации маркетинга. Одна из задач, которую наши клиенты решают с помощью нее — запуск email-рассылок и сценариев. Чтобы облегчить им задачу и не заставлять маркетологов писать HTML-код, мы разработали конструктор рассылок: письмо собирается из готовых блоков, а содержание можно настраивать под свои задачи.

В этой статье я расскажу про процесс разработки конструктора, с какими вызовами мы сталкивались и как находили решения. Например, почему в какой-то момент мы решили, что нам тесно в рамках HTML и решили поменять способ разметки шаблонов, а для этого понадобился собственный язык на базе C# — Quokka Mindbox

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

Меня зовут Михаил Новиков, я архитектор в команде, которая развивает один из пользовательских сервисов. В статье расскажу, зачем мы за 5,5 недель внедрили хаос-тесты, что учли при их настройке и почему ломаем прод Mindbox. 

Привет, Хабр!

Меня зовут Тимур Маннапов, и я самый обычный senior-разработчик в Mindbox.

На примере нашего продукта я расскажу, почему при загрузке CPU наполовину или меньше скорость параллельных вставок на SQL-сервере упирается в «невидимый» предел, а потом и вовсе замедляется. На нашем железе предел был в районе ~120 тысяч строк в минуту в одну таблицу. Поделюсь, как его преодолеть, не потратив годы на разработку и миллионы на новый сервер.

Меня зовут Михаил Кузнецов, я product owner в команде, которая развивает внутреннюю платформу разработки Mindbox. В этой статье я расскажу, как мы отказались от легаси-фреймворка, который пронизывал все микросервисы. И убедились — такая трансформация осуществима даже в компании на 100+ разработчиков и 1000+ корпоративных клиентов.

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

Чтобы ускорить сборку, разработали систему из шаблона и CLI утилиты. Теперь новый микрофронтенд со всей обвязкой создается за 20 минут. В статье — подробное решение для тех, кто захочет повторить.

Привет! На связи Ира Белица и Святослав Сычев. Мы работаем в Mindbox над высоконагруженным продуктом рассылок: более 850 наших клиентов генерируют свыше 20 тысяч RPS. Такой продукт требует много ИТ-поддержки, при этом клиенты постоянно запрашивают новые функции. Отсюда рассинхрон в команде: разработчикам важно поддерживать стабильность рассылок, менеджерам продукта — помогать клиентам решать их проблемы, зачастую с помощью новых фичей.

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

Внутри — шаблон модели для автоматического скоринга техдолга. Копируйте его, чтобы приоритизировать бэклог и систематически его вычищать.

Привет! На связи Митя Кожевников и Юра Соколов из Mindbox, и это третья, финальная часть гайда по софтам для джунов. В первой части мы говорили о том, что значит «приносить пользу» в разработке. Во второй — об ориентации на результат. В этой части речь пойдет о развитии: что делать, чтобы расти быстрее. 

О гайде. Этот гайд — внутренний документ разработчиков Mindbox. Его писали не один год, опираясь на ошибки тех, кто давно стал мидлами и синьорами. И хотя Mindbox — продуктовая компания с особенной культурой, большинство советов из гайда подойдут и для работы в других командах. 

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

Кому читать. Этот гайд — для джунов, которые хотят сделать софты своим конкурентным преимуществом. Если джун ответственно выполняет работу, умеет самостоятельно обучаться и не проходит мимо говна, его готовы оторвать с руками, даже если ему не хватает знаний. К тому же советы из этого гайда помогут быстрее закрепиться в команде и вырасти. Пользуйтесь!

.NET разработчики знают, что такое ждать сборки кода. Работать при этом невозможно: пока не увидишь, как обновится приложение, — не перейдешь к следующему шагу. А переключиться на другую задачу за это время не успеешь. Получается, если в день переписать код 5 раз, можно потерять полчаса при сборке, а то и больше.

Теперь на примере платформы автоматизации маркетинга Mindbox. Основное программное решение — это монолит на C#: несколько миллионов строк, 50 проектов, над которыми одновременно работают десятки команд. Даже сэкономленная при сборке минута выливается в кучу продуктивных человеко-часов. Поэтому, когда речь зашла о переходе всей компании на MacBook в будущем, мы решили выяснить, как это отразится на производительности.

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

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

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

Привет! На связи Митя Кожевников и Юра Соколов из Mindbox, и это вторая часть гайда по софтам для джунов. В первой части мы говорили о том, что значит «приносить пользу» в разработке, а в этой поговорим об ориентации на результат.

О гайде. Этот гайд — внутренний документ разработчиков Mindbox. Его писали не один год, опираясь на ошибки тех, кто давно стал мидлами и синьорами. И хотя Mindbox — продуктовая компания с особенной культурой, большинство советов из гайда подойдут и для работы в других командах. 

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

Кому читать. Этот гайд — для джунов, которые хотят сделать софты своим конкурентным преимуществом. Если джун ответственно выполняет работу, умеет самостоятельно обучаться и не проходит мимо говна, его готовы оторвать с руками, даже если ему не хватает знаний. К тому же советы из этого гайда помогут быстрее закрепиться в команде и вырасти. Пользуйтесь!

Привет! На связи Митя Кожевников и Юра Соколов из Mindbox. В этой статье мы делимся внутренним гайдом, как джунам нарастить софскилы, быстрее закрепиться в команде и вырасти. Эта часть посвящена пользе.

О гайде. Этот гайд — внутренний документ разработчиков Mindbox. Его писали не один год, опираясь на ошибки тех, кто давно стал мидлами и синьорами. И хотя Mindbox — продуктовая компания с особенной культурой, большинство советов из гайда подойдут и для работы в других командах. 

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

Кому читать. Этот гайд — для джунов, которые хотят сделать софты своим конкурентным преимуществом. Если джун ответственно выполняет работу, умеет самостоятельно обучаться и не проходит мимо говна, его готовы оторвать с руками, даже если ему не хватает знаний. К тому же советы из этого гайда помогут быстрее закрепиться в команде и вырасти. Пользуйтесь!

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

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

О том, какой путь проходит релиз и какие инструменты обеспечивают его надежность, расскажет engineering manager Mindbox, Бадал.

Всем привет! Меня зовут Марина, я product manager в Mindbox — сервисе автоматизации маркетинга.

Моя команда отвечает за развитие ядра Mindbox — платформы клиентских данных, или CDP. Нам важно соблюдать баланс между поддержкой имеющихся функций и внедрением новых. С этим должен помогать бэклог: он выступает связующим звеном между желаниями клиентов и развитием продукта. Но в какой-то момент мы поняли, что это перестало работать: наш бэклог стал похож на гараж, в который складывают все без разбора. В итоге мы перестали слышать наших клиентов, отклонились от целей компании и вызвали недоверие коллег. 

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

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

Может показаться, что ChatGPT работает непредсказуемо: то уверенно пишет документацию к коду, то не может решить школьную задачу по математике. Самое опасное, что во втором случае нейросеть умеет ввести в заблуждение. Чтобы понимать, какие задачи можно доверить чат-боту ChatGPT, важно знать особенности его работы. 

В этой статье data scientist Mindbox, в прошлом преподаватель и научный сотрудник РАН, без лишнего философствования расскажет о работе нейросетей типа ChatGPT. На своем примере он покажет, как упрощать повседневную работу с помощью ChatGPT и подобных моделей. А в конце приведет ссылки на полезные статьи.

На связи Антон Бевзюк и Дмитрий Кожевников, инженерные менеджеры Mindbox. 

В Mindbox большая команда, и мы долгое время искали способ, как масштабировать Agile. Пробовали Kanban, Scrum, XP, LeSS — все не то. Полгода назад перешли на Pipedrive Agile Framework и остались довольны: уменьшили количество рутинных задач, повысили уровень счастья среди разработчиков и стали быстрее выпускать фичи — реализовали обновления, которых клиенты ждали годами. Готовы поделиться опытом.

Статья будет полезна тем, кто хочет организовать работу команды из более чем 100 разработчиков и сбалансировать развитие продукта и поддержку. Мы подробно расскажем, какие сложности испытывали и как Pipedrive Agile Framework помог с ними справиться, какие ошибки допустили во время внедрения, поделимся советами, как их не повторить, и дадим подробные гайды по запуску фреймворка.

Привет! Меня зовут Петя Никитин. Я пришел в Mindbox менеджером клиентского сервиса и за четыре года перешел во frontend-разработку. Расскажу, как я учился и что помогло мне проходить внутренние собеседования.

Фронтенд-разработка может жить без независимого деплоя, пока у нее не больше 7 микрофронтендов. Но, чем выше число, тем сильнее страдают процессы. Наша команда в Mindbox прошла через это с Octopus, когда деплоила в Yandex Cloud S3. Причем на все обновления был один свободный бакет. Заливаешь код в мастер, а в это время то же самое делают еще пять разработчиков. Скапливается очередь, код еле ползет, а через час деплой вообще обваливается — Octopus не справился с нагрузкой. Пока чинишь это, оказывается, что твои обновления уже попали в продакшен заодно с чужими. 

Когда число проектов возросло до 14, все это повторялось с каждым разработчиком по несколько раз в день. Поэтому мы решили вслед за коллегами-бэкендерами перейти на независимый деплой в Kubernetes.

В этой статье собран опыт платформы автоматизации маркетинга Mindbox по реформированию фронтенда:

Kubernetes вместо Yandex Cloud S3: деплоим микрофронтенды без сбоев

Автоматизированный вывод метаданных: экономим ресурсы разработки

Постепенный переход: меняем деплой без вреда для пользователей

Хот-тестинг: ускоряем обновление фронтенда

Советы: как улучшить деплой без микрофронтендов и Kubernetes