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

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

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

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

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

Массовый переход от монолитов к микросервисам решает ряд проблем:

• раздельный деплой и рефакторинг;

• удобное масштабирование частей системы;

• прозрачное разграничение ответственности команд;

• снижение бласт-радиуса;

• снижение когнитивной нагрузки на разработчика.

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

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

Из этой статьи вы узнаете, когда стоит применять gRPC, а когда лучше воздержаться, как решаются типичные задачи, включая конфигурирование, отладку, healthcheck, а также то, о чем умалчивает документация. 

По материалам выступления на конференции DotNext.

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

• цель грума,
• необходимый минимум,
• уточнение требований и контекста,
• типичные этапы,
• особенности при доработке механик.

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

• как устроен Powershell DSC и чем он отличается от Ansible при управлении инфраструктурой на Windows;
• почему мы перешли на Ansible;
• с какими проблемами столкнулись и как их решали;
• как соотносятся ожидания и реальность после перехода на Ansible;
• кому стоит выбрать Powershell DSC, а кому — Ansible.

в 23 раза
больше целевых отправок email с помощью нейросети по сравнению с триггером

в 8,5 раз
увеличился доход от email-рассылки по атрибуции last click

в 2 раза
уменьшился процент отписок

в 17 раз
выросло число открытий в абсолютном значении

• почему решили использовать LSTM-модель нейросети для предсказания даты отправки email вместо алгоритма градиентного бустинга;
• как устроена LSTM;
• какие данные нейросеть использует для обучения;
• какую архитектуру нейросети использовали и с какими сложностями столкнулись;
• каких результатов достигли и как их оценивали.

Mario Berluchi — российский производитель обуви, сумок и аксессуаров с пятью офлайн-магазинами в Москве и онлайн-магазином.

Масштаб. 200 тысяч посетителей сайта в месяц.

ИТ. Сайт на Bitrix, бэк-офис на «1С», платформа клиентских данных Mindbox.

Задача. Повысить выручку за счет работы с накопленными данными.

Результат. Рост конверсии сайта на 16,5% в рамках AB-теста, рост ARPU на 35,7%, снижение доли брошенных корзин на 17,2%.

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

Наши клиенты-магазины хотят делать крутой маркетинг. Чтобы люди больше покупали, они регулярно шлют им email-рассылки. И каждый раз думают: “Что же написать в письме?”.

Можно писать просто: “Покупайте у нас почаще!”, но это не очень-то работает. Идея получше — вставлять в письмо рекламу товаров. Желательно, рекламу товаров, которые заинтересуют покупателей.

Дальше расскажу о том, как мы с нуля делали настоящие персональные рекомендации.

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

Регулярные ретроспективы вызывающие изменения снизу — важнейший признак организовавшейся живой команды.

К сожалению, достаточно часто ретроспективы становятся скучным формальным ритуалом не приводящим к изменениям, или вовсе сходят на нет. Возможно, это происходит из-за потери сути ретро, как встречи для работы с эмоциями.

Для проведения ретроспективы желателен опытный фасилитатор. Особенно это важно в стартующих командах.

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

Цель

Распространено мнение, что цель ретроспективы — улучшить работу. Это упускает ключевую деталь — самостоятельность. Считаю, цель ретроспективы — чтобы команда сама улучшила свою работу.

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

Для контроля инструкций нужен менеджер. А автономная команда должна сама их контролировать, что требует принятия решений членами команды на личностном уровне.

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

Недавно мы рассказали, почему придумали свой RFM-сегментатор, который помогает сделать RFM-анализ за 20 секунд, и показали, как использовать его результаты в маркетинге.

Теперь рассказываем, как он устроен.

С тех пор как в компании Mindbox впервые произнесли Machine Learning, общей целью стала Большая Зеленая Кнопка. Это такая кнопка во весь экран, при нажатии на которую всё работает само и приносит прибыль.

В аналитическом проекте «RFM» цель менее амбициозная — Маленькая зеленая кнопка. Нажимаешь, и база автоматически делится на сегменты, по которым запускается отправка писем (например).

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

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

• на ретро тратили по 2 часа и сильно выматывались
• обсуждения периодически уходили в затяжные бесполезные споры
• некоторые мелкие проблемы не успевали решить и постоянно переносили на следующее ретро
• отдельным членам команды надоедали ретроспективы из-за однообразия

Предыстория

Уже много лет мы помогаем нашим клиентам отправлять потребителям хорошие, информативные и человеческие письма. В них вместо сухого “Добрый день” мы пишем “Здравствуйте, Никита!”, а вместо “Ваш баланс пополнился” сообщаем “вы получили 25 баллов”. Но маркетологи становятся все изобретательнее, и современное письмо от интернет-магазина должно выглядеть так:

И мы хотим уметь генерировать такие письма автоматически.

Вместо вступления