Вас спрашивали на интервью «Почему люди внезапно увольняются?» или «В каких случаях допустимо опаздывать на работу?»

Знайте, это – проективные вопросы. Замаскированная ловушка. Из-за неё вы расскажете о себе больше, чем хотите.

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

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

Мы с коллегами так не делаем. Ниже делюсь мнением, как из-за таких вопросов не потерять оффер.

Финансовое моделирование — это не просто таблички. Это способ прогнозировать, принимать решения и быть на шаг впереди. Мы, финансисты, любим Excel за простоту, в то же время, ненависть к этому чудесному инструменту возрастает пропорционально количеству переменных в формулах. И, когда задач становится больше, — он начинает тормозить и сильно раздражать.

Ниже я расскажу:

- Почему я, как гуманитарий, начала осваивать Python.
- Как связка Excel + Python работает на практике.
- Как один и тот же проект ведёт себя в этих двух мирах.

Вас спрашивали «Кем Вы видите себя через 5 лет»? Меня тоже. За двадцать пять лет в IT я понял, зачем они так делают. Понял – это значит, что я «привык и научился пользоваться» (С). Но «неприятно удивлять» они меня не перестали.

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

Дисклеймер:

Я не призываю врать или «играть по правилам» HR. Я делюсь практической схемой подачи опыта и скиллов, чтобы минимизировать отказы «по софтам». В моем случае она работает.

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

Решил поделиться своей историей. Вдруг кому-то будет полезно или просто интересно прочитать. Велком.

За 25 лет в разработке со мной произошло много занятных историй.

Мы сделали клиентов миллионерами, проводя тестирование на проде. Едва не получили дипломатический скандал, показав министру неполиткорректный экран.

Я общался «по понятиям» с боссом из 90-х с индийским колоритом. Корпел над секторами жесткого диска из-за пингвина-терминатора (да, это про Linux!). Физически ощущал запах сгоревшей премии дорогого сгоревшего железа.

Здесь нет вымысла – только ТруЪ истории и опыт, который я получил. Читайте, смейтесь и… никогда не повторяйте это дома.

Потому, что микро-сервисы часто оказываются не «микро», а «нано» сервисами.

Маленькими, изолированными сервисами под конкретную маленькую задачу. Они любят полакомиться чужими событиями. Но они не жадные: поймают одно событие, кинут три. Поодиночке они почти бесполезны. Про них можно слагать анекдоты: «Сколько надо сервисов, чтобы напечатать Hello World?». Поэтому нано-сервисов много, они плодятся как зайчики. Или как маленькие паучки, которые затягивают организацию своей паутинкой.

Систему нано-сервисов трудно спроектировать, легко уронить и невозможно поддерживать.

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

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

Знакомо?

За 15 лет в тестировании (IBS, Boeing, DHL, Сбербанк, MVIDEO) я убедилась: ключ к стабильности — не в гениальных отдельных специалистах, а в системе обмена знаниями. Расскажу, как мы:

- превратили разрозненный опыт в общую базу знаний, доступную даже новичкам;

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

- сделали тестирование ключевым звеном в принятии решений компании.

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

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

1. Сделать неотразимое резюме, чтобы у интервьюера задергался один глаз. Или оба.

2. Пройти незабываемое собеседование. Чтобы коллеги отпаивали интервьюера кофе, пока он делится острыми впечатлениями.

3. Получить оффер, оказавшись самым звездным кандидатом.

Подставляйте копилку, накидаю в нее вредных советов.

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

Знаете, что общего между тепловизионными камерами, взрывозащищёнными дронами и 90-метровыми колоннами? Или как в промышленной компании из трёх дронов вырос целый парк из более чем 20 машин, а мониторинг трубопроводов перестал зависеть от человеческого фактора?

В статье рассказываю — как ИИ с точностью 80% ищет утечки, дронопорты летают без операторов, а подводные роботы заменяют водолазов. Но обо всём по порядку.

Чтобы получить работу, это понятно.

Но кто сказал, что враньё сработает? А если наоборот?

Не буду занудствовать о том, что врать нехорошо. Либо родители научили этому в детстве, либо нет. Останусь сугубо в меркантильной плоскости.

Согласно исследованию CareerBuilder, 75% работодателей сталкивались с ложью в резюме, а 40% кандидатов признавались, что «приукрашивали» некоторые факты. Почему это происходит? И как ложь влияет на шансы трудоустройства?

Видеоаналитика в СИБУРе — это сложный и многогранный продукт, который внедряется на разных производствах. Несмотря на то, что это один продукт, его конфигурация может сильно отличаться: используются различные камеры, детекторы и параметры, а также интеграции с разнообразными сторонними системами.

В таких условиях инженеру не всегда понятно, что именно надо дописать, а валидация происходит только после окончания редактирования файла и перезапуска сервиса.

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

Меня зовут Владимир Кирилкин, я техлид в Цифровом СИБУРе, в команде Индустрии 4.0. Мы разрабатываем продукт «Видеоаналитика на производстве», и о наших задачах уже писали на Хабре.

Мы подошли к задаче нестандартно: вместо заранее заданных форм на фронте реализовали их автоматическую генерацию с использованием JSON-схем и немного ✨магии✨.

Наши сервисы построены на Python и React, но предложенный подход можно адаптировать и для других технологий — правда, с чуть меньшим количеством ✨магии✨.

Тимлидство — дорога с двусторонним движением. Я трижды становился тимлидом и дважды возвращался в разработку. Проехал все ямы на этой дороге, и каждая — это боль. Но я понял: одни ямы можно объехать, перед другими — просто притормозить.

Одна из главных болей — нехватка программирования. Невозможность просто сесть и пописать код беспокоит почти всех начинающих тимлидов. Да и опытные от этого не застрахованы. Ведь востребованность тимлида зависит от того, насколько он держит свои hard skills в тонусе.

Как найти баланс между управлением и кодом? Как не стать «менеджером-менеджером»?

Меня зовут Иван, я работаю лидом в Цифровом СИБУРе, делюсь опытом и своими мыслями.

Дисклеймер:
Если вы уже полностью в менеджменте и код для вас — это прошлое, тут вряд ли найдёте что-то новое. Но если вы всё ещё пытаетесь совмещать управление и программирование, welcome to the club. Буду рад критике и надеюсь, что кому-то станет легче (или нет).

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

Но тем не менее, мы одни из первых начали применять ИИ в промышленности и проводить цифровизацию процессов. То есть у нас активно внедряются современные технологии и реализуются смелые проекты. В портфеле СИБУРа сегодня более 30 реализованных кейсов на базе ИИ. В проработке 200+ гипотез и это число постоянно растет.

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

А еще получать печеньки, респект и уважение.

Бизнес большой, а значит, и печеньки большие.

Бизнес ставит цели для IT. У крупного бизнеса цели расписаны минимум на квартал. Чаще — на год. Такие себе водопадные цели. Их сложно поменять, легко принять и невозможно избежать.

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

Почему я об этом пишу?

Разрешите представиться, я — Иван, I solve problems. Я — тимлид в Цифровом СИБУРе. Помогаю команде доставлять ценность. Техника, процессы, команда, продукт — это все мое, родное. И я угодил в жернова корпорации. Судьба такая. Поделюсь своим кейсом по выживанию — методом револьвера.

Привет, Хабр! Меня зовут Илья Олексив, я лидер компетенции направления DevOps в Цифровом СИБУРе. Вместе с моим коллегой Мишей Фуфаевым aka @Redemax, техлидом, в ноябре мы выступали на Industrial++ и обещали выложить наше выступление со слайдами сюда.

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

Чтобы понять, почему тема релизов проблемная, для начала давайте разберёмся, что из себя представляет компания СИБУР. Мы крупная, географически распределённая компания, в состав которой входит 26 заводов и работает более 40 тыс. высококвалифицированных сотрудников.

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

Я, Вячеслав Базанов, руководитель проекта, и моя команда инженеров и аналитиков из Цифрового СИБУРа взялись за разработку собственной модели прогнозирования. Это был вызов по масштабу и срокам, но мы справились и за три месяца создали решение, которое не только заменило прежнюю систему, но и улучшило её эффективность. Добро пожаловать под кат — расскажу, как мы это сделали.

Современное производство — это уже давно не просто набор станков и всяких железок в ангарах, теперь это ещё и автоматизации, IT-инфраструктура и много, очень много данных, которые в режиме реального времени стекаются в DWH (Data Warehouse — хранилище данных) из сотен источников.

Эти данные нужно собирать, хранить, обрабатывать и анализировать, чтобы компания могла принимать правильные бизнес-решения. Качество данных (Data Quality, DQ) в таких условиях становится критически важным показателем, от которого зависит рентабельность бизнеса в целом.

Это вторая статья из небольшого цикла, в котором мы разбираем опыт СИБУРа в создании, поддержке и развитии DQ-сервиса. И этот опыт универсален — его можно применять в любой компании, перед которой стоят задачи по обеспечению качества данных.

В первой статье мы рассказывали про импортозамещение DQ-решений после ухода вендора с рынка РФ. В этой статье мы поговорим о задачах, которые решает DQ в целом, и рассмотрим архитектуру решения, которое мы строим в СИБУРе.

Рассказывать об этом опыте будет Александр Бергер, Lead DQ Analyst в СИБУРе, которому посчастливилось лидить процесс создания DQ-сервиса в компании последние несколько лет.

В СИБУРе много данных, которые текут в режиме реального времени с многочисленных датчиков на разных производствах, эти данные нужно собирать, хранить, обрабатывать и анализировать, чтобы компания могла принимать правильные бизнес-решения. И от качества инфраструктуры для работы с данными зависит рентабельность производств и прибыль компании в целом, а это жизненно важные показатели.

В небольшом цикле из двух статей мы разберём опыт СИБУРа в создании, поддержке и развитии DQ (Data Quality — качество данных) сервиса для DWH (Data Warehouse — хранилище данных) в условиях санкций и исчезающих вендоров проверенных и привычных решений.

Рассказывать об этом опыте будет Александр Бергер, Lead DQ Analyst в Цифровом СИБУРе, которому посчастливилось лидить процесс создания DQ-сервиса на решениях вендора, который решил покинуть рынок РФ в разгар рабочего процесса.

Привет, Хабр! Меня зовут Толя, я лидер компетенции Java в Цифровом СИБУРе. Наш прошлый материал о Docker собрал классный фидбэк, поэтому мы решили развить тему и подготовить ещё несколько статей, двигаясь от простого к сложному.

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

В 2020 году мы рассказали о нашем продукте «Удалённый эксперт AR» — платформа для дистанционного обслуживания и ремонта оборудования, а теперь рассказываем, как он обрастает новым функционалом. Передаем слово Алле Емец, бизнес-аналитику Индустрии 4.0 Цифрового СИБУРа.

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

К вашему вниманию «ВидеоСОП» — платформа с видеоинструкциями, оптимизированная для работы со специализированными мобильными устройствами, которая даёт возможность пользователю перейти к набору видеоинструкций, отсканировав QR-код на объекте.