Я работаю в Тинькофф и по долгу службы иногда хожу на собеседования, общаюсь с кандидатами, даю обратную связь. Не сказать, чтобы это очень сложно, но чтобы заинтересовать кандидата, надо постараться произвести приятное впечатление. Казалось бы, ничего хитрого здесь нет: всего лишь задать правильные вопросы, рассказать, какой у вас крутой и уникальный проект, упомянуть про печеньки и еще 100500 приятных мелочей, которые есть только у вас.

Однажды, во время пробежки, я слушал передачу, где речь шла про подбор персонала, рынок труда и про то, как правильно искать нужного кандидата. Я невольно задумался, насколько правильно я себя веду во время интервью. Задумался и вспомнил эпизоды, в которых мог бы вести себя более профессионально. Затем вспомнил, как рассказывал друзьям о своем опыте в роли соискателя и о фейлах нанимающей стороны. Хочу представить вашему вниманию несколько эпизодов, в которых я постарался обыграть весьма распространённые ошибки нанимателей. Надеюсь, мои наблюдения и выводы окажутся полезными.

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

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

Kotlin — еще молодой язык, но уже стремительно ворвался в нашу жизнь. Из-за этого не всегда понятно, каким образом правильно реализовать тот или иной функционал и какие best practice применять.

Особенно тяжело обстоит дело с возможностями языка, которых нет в Java. Одним из таких камней преткновения оказались расширения.

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

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

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

2018 год принципиально изменил наш подход к разработке бизнес-процессов. Ниже — о том, как эволюционировал этот подход и как менялись мы.