Комментарии 44
«Лаборатория Касперского»: как попасть и чем заняться?
Тут главный вопрос — «А надо ли?» Душок у вас, прям скажем, не очень
Статья «Медузы» написана интересно, но насколько это всё правда — каждый пусть решит сам. Вы ей верите? Хорошо. Я не верю. Вот, к примеру, Форбс пишет про Гребенникова:
В июне Гребенников проиграл иск к «Лаборатории Касперского» в суде первой инстанции, но подавать апелляцию не намерен. В интервью с Forbes он просит не искать конспирологической подоплеки в происходивших событиях.На этом, пожалуй, завершу эту дискуссию.
Вообще не содержательная: https://www.kaspersky.ru/blog/yet-another-post-truth/19559/
Как часто ревью?
Какие критерии успеха?
Как происходит защита оценки сотрудника?
Какие критерии для повышения грейда сотрудника?
Бонусы, опционы по-результатам ревью?
Разработчик и его руководитель подводят итоги работы на one-to-one встречах. Здесь анализируются как количественные, так и качественные показатели. В результате встречи руководитель и разработчик должны прийти к согласованной оценке работы за год. Для части разработчиков выставляются еще и годовые цели, а также оценивается их достижение.
Как часто ревью?
Результаты ревью фиксируются в системе раз в год. Однако бывает и так, что ревью проходят чаще: непосредственно во время работы, при каких-либо значительных достижениях, или наоборот, если возникли ошибки, недоработки. При этом в большинстве своем критерии успеха зависят от команды и руководителя.
Какие критерии для повышения грейда сотрудника?
Для разработчиков грейды и позиции соответствуют один к одному. Самый частый переход — от разработчика к старшему разработчику. Основной критерий здесь заключается в том, может ли сотрудник решать сложные задачи самостоятельно, или ему требуется помощь. Кроме этого, технические навыки сотрудника должны находиться на высоком уровне. Оценивается это следующим образом: разработчик вместе со своим руководителем подготавливают артефакты работы — программный код, документацию, примеры прохождения код-ревью, как в качестве ревьювера, так и в качестве автора, разработанные фичи или инструменты и т. д. Далее артефакты отправляются в экспертную комиссию, в рамках которой три эксперта независимо друг от друга рассматривают эти артефакты и принимают решение о соответствии разработчика новой позиции. Кроме непосредственно вердикта, эксперты подготавливают рекомендации, что разработчику можно улучшить.
После старшего разработчика можно пойти в тимлиды, архитекторы и эксперты. Процесс перехода несколько отличается в зависимости от позиции, однако ключевое требование остается тем же – необходимо показать результаты своей работы, они должны соответствовать новой позиции.
Бонусы, опционы по-результатам ревью?
Бонусы платят за какие-либо выдающиеся достижения, которые привели к получению результата.
Может показаться, что в крупную ИБ-компанию очень сложно попасть...
Ха! Да что там устроиться, мне было сложно даже найти в интервью имя сотрудника, который отвечал на вопросы (имя и фамилия только перед описанием задач, имя ещё в одной реплике в середине). Труъ разведчики :)
ЗП предложили меньше ожидаемой и обсуждаемой на первых этапах, аргументируя — ну зато это работа в Касперском, и потом можно дорасти.
Рабочий процесс технического специалиста смещен в социальную часть. Не учитывая личных предпочтений, будут склонять к обучению младшых специалистов, проведению каких-то выступлений, обучению у старших. В целом, очень много общения. Мне, например, нравится работать в тишине и чтобы никто не мешал.
Бонусы можно получать только перевыполняя план, за работу просто по плану полагается чистый оклад.
Предложение, в итоге, отклонил в пользу более комфортных условий, которых на рынке оказалось достаточно много при сравнении.
+ ответ к
Как у вас проходит performance review разработчиков?
Как часто ревью?
Какие критерии успеха?
Как происходит защита оценки сотрудника?
Какие критерии для повышения грейда сотрудника?
Бонусы, опционы по-результатам ревью?
Проходит раз в год, критериев особо нет. Есть абстрактные при повышении. Типа сотрудник должен вырасти. Но как правило расти особо не на чем. Много легаси, например. Потому в проектах можно встретить мешанину фреймворков, вставленных ради цели «вырасти». В конце года отчитался что выучил много нового: молодец. Далее, когда идешь на как тебе кажется, повышение, надо писать большую балладу с копией куче разработчиков. Какой ты клевый, умный, как в результате твое работы разгрузились отделы (автоматизировал кучу всего). А еще! Что написал много умных новых сттаей на Хабр, выступал на конференциях. Мне как-то по ошибке такое письмо прилетело от разработчика. Он там краснея, объяснял что сорян, нечаяно поставил в копию. Там, ребята, такой список был что я себя ленивым почувствовал. Он, кстати, работал по 11-12 часов в день. Так вот ему отказали! Почему? Потому что недостаточно вырос в их глазах.
Самое забавное что найм там не отличается для позиция среднего там, старшего разработчика. Задачи тоже не сильно. Зато чтобы подняться я не знаю что надо сделать. )
99% C++ в 2018 году тоже вызывает удивление. А как-же rust, go?
Rust только три года, как получил версию 1.0, вы ожидаете, что на него сразу все кинутся переписывать?
gcc -Wall -pedantic exapmple.cpp
вот почему. И ответ будет
error: use of deleted function 'ItemEx::ItemEx(ItemEx&&)' ItemEx newItem = std::move(item); ^
Что мгновенно интерпретируется даже новичком.
Очень упрощая можно процесс code review описать так (у всех же нормальных людей он есть):
- Человек вносит изменения, собирая их и прогоняя тесты у себя на машие
- Изменения выкладываются на портал для review
- CI собирает их и прогоняет тесты, Опционально: покрытие, статический анализ и пр.
- Непосредственно review
- push
Где тут можно протащить ошибку компилляции?
Не лучше ли будет использовать вопросы в духе, объясните причину такого сообщения от компиллятора стена из ошибок использования например Boost.MPI или давать к таким заданиям компиллятор?
Нет, в этом нет никакого смысла. Конкретно вот в этих вопросах смысла нет. Я провожу регулярно собеседовния на разработчиков разного уровня, когда-то даже 5 лет работал в ЛК. Мне кажется, что конечно по-другому надо делать. Некоторую базовую грамотность обращения с инструментом проверить конечно нужно, но это, как мне кажется, нужно делать по-другому.
Каждые две недели здесь проходят трехчасовые вводные встречи для таких сотрудников.… рассказывают о том, как устроена наша жизнь. Например, как оформить отпуск, уйти на больничный
Касперский так адски забюрократизирован, что уйти в отпуск можно только пройдя тренинг по уходу в отпуск?
мы сейчас уходим от компонентной разработки.… Поэтому мы хотим изменить подход и перейти в так называемый монорепозиторий… Для менеджеров новая система детерминирует риски использования нового кода, которые будут всегда актуальными.
Статья Промо-материал вроде бы преследует цель привлечь разработчиков, но при этом почему-то рекламирует удобства для менеджеров. Для программистов в таком переходе какой плюс?
Трехчасовая встреча… Я б уже через 25 минут убился.
Какая-то дикая бюрократия.
Там несколько блоков (кадры / охрана труда / IT/ ИБ), плюс ответы на вопросы из зала (достаточно много времени уходит на них). Хороший, подробный вводный инструктаж по пожарной безопасности. Рассказ про принятые в компании принципы и процедуры IT и ИБ.
Интересно послушать, сколько по вашему мнению долженно занимать подобное мероприятие в «небюрократизированном» варианте.
Статья, как крик о помощи: "ну придите уже на собеседование! Мы пушистые!"
Серьезно, лучше бы условия сделали конкурентными, бюрократов проредили, обстановку в офисе попроще слелали.
Крик о помощи однозначно
"Лаборатория Касперского": как попасть и чем заняться? Взгляд изнутри