Русский
Русский
English
Статистика
Реклама

Карьера в ит

Из песочницы Как стать специалистом по кибербезопасности? Страх и ненависть в ИБ

14.11.2020 18:04:39 | Автор: admin

Очередной раз начали появляться новости с аналитикой будто уже в следующие пару лет на рынке будет катастрофическая нехватка специалистов в области информационной безопасности (сократим до аббревиатуры ИБ). По версии ХХ в России не хватает уже порядка 30 тысяч специалистов. Звучит перспективно с точки зрения карьеры низкая конкуренция, иди и работай. Однако, как выглядит карьера ИБшника на Российском рынке?


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


Часто на разных ресурсах специализацию в области ИБ описывают как нечто сложное, загадочное, неопознанное и романтичное. В основном у всех, кто ещё не знаком с этой областью работа в ИБ ассоциируется непосредственно с хакерами и создается впечатление, что все ИБшники обладают этими навыками (взламывают сайты, крадут пароли, пробивают по IP и т.д.). Из-за этого вход на этот рынок выглядит максимально сложным и кандидату чаще кажется невозможным устроиться на работу ИБшником, не обладая этими знаниями. Однако, реалии таковы, что большинство специалистов ИБ даже не представляет, как это происходит. Более того значительная часть специалистов не особо и в ИТ разбираются. От чего же это так?


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


Основными заказчиками на рынке ИБ выступают Государственные организации (далее сокращу просто до слова ГОСы, банки, крупный и средний бизнес. Так сложилось, что половина моего трудового стажа прошла именно в Государственных организациях. О специфики работы в этом секторе можно написать книгу, но, всё же, постараюсь сократить до необходимого минимума.


Начнем с того, что главное задачей в ГОСах в ИБ является не защита от злобных хакеров и вредоносного программного обеспечения, а выполнение законодательных и отраслевых требований, и это является главной проблемой на Российском рынке. Зачастую в этом секторе важнее понимать какие законы в области ИБ существуют, как они трактуются, как они касаются конкретной организации и как их можно обойти закрыть. По факту это работа с бумажками: составление внутренней распорядительной документации, регламентов и положений, связанных с государственной и коммерческой тайнами, а также обработке информации, связанной с персональными данными или данными для служебного пользования. Здесь требуется знать как категорировать информацию, какая часть информационной системы к какой категории относится, и какими средствами защиты это должно закрываться (последнее описано курирующими государственными службами), и нужно ли вообще это защищать. При этом при всем, есть ещё отраслевые требования, которые могут быть шире, чем законодательные требования, приказы и положения. В этих секторах нет устоявшегося стандарта расположения блока ИБ в штате организации. ИБшники могут как существовать в блоке ИТ, так и в отдельном управлении. Однако, техническая сторона ИБ (внедрение средств защиты информации, настройка и сопровождение) ложится на блок ИТ (и это не только в ГОСах так). Связано это с тем, что бюджет на информационные системы как на актив ложится именно на блок ИТ. Отсюда возникает другая проблема бюджет на обеспечение средствами защиты информационной системы организации формируется именно в блоке ИТ. Из-за этого ИБшники и ИТ постоянно воюют за приоритезацию бюджета. При этом, если блок ИБ не сможет донести до руководства ИТ необходимость закупки того или иного решения ИБ, то в бюджетный план на следующий год это и не попадет. У высшего руководства тоже не всегда получается добиться поддержки, потому что в данном случае нужно описывать также экономическую целесообразность закупки того или иного решения (или сервиса). А как показать возможный финансовый ущерб от хакерской атаки, если она в этой организации ещё не возникала? Да и большинство организаций уверены, что их никто не атакует и они никому не нужны. В итоге приходится жить с тем, что имеешь!


image


Однако, недопонимание встречается не только со стороны ИТ, но и ИБ из-за отсутствия необходимых технических компетенций (а когда им их повышать, если они только что и делают, так это пишут проклятые бумажки): требования законодательства обязуют использовать в информационных системах средства от несанкционированного доступа, которое жрет достаточно много компьютерных ресурсов так ещё и является агентским решением, которое должно устанавливаться на каждую рабочую станцию в организации. А если это предприятие с 4к пользователями, где парк машин с ОС Windows 7 и не потому, что сложно закупить (хотя это тоже требует не мало финансов) новые версии Windows 10, а потому что этот парк компьютеров устаревший и не потянет эту операционную систему, а тут ещё и агент средства защиты информации будет жрать ресурсы как бешеный.


В итоге для того, чтобы внедрить только одно решение уже потребуется обновить парк компьютеров! Просто представьте сколько это денег! А они не у каждого ГОСа есть, а зачастую ещё главная отраслевая компания распоряжается этими финансами, а не само предприятие.


Конечно, это не везде так, но из-за таких ситуаций рабочими обязанностями обычного специалиста являются задачи по маранию бумаги. Не идет речь о работе с какими-то инцидентами информационной безопасности, нет работы с технической составляющей (напомню этим занимаются ИТшники). Отсутствует даже возможность узнать на сколько текущая ситуация в компании расходится со стандартами ИБ. Уже через год такой работы молодой специалист полезет на стенку от скуки, и эта работа будет больше связанна с менеджментом вопросов ИБ, вот такая романтика.


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


Несомненно, вы начнете разбираться в законодательной базе, это полезно. Но для того, чтобы изучить эту базу и понять требуется не так много времени. Для такой работы не требуется специфических знаний в ИБ. Но HR упорно продолжают писать в требованиях, что вы должны знать как работать с различными средствами защиты информации, знать всю законодательную базу, иметь высшее специализированное образование и вообще опыт работы не менее 3-х лет (это всё там даже применить не получится). А ЗП предложат всего 60-80к. Не так давно увидел объявление одной такой крупной компании в Москве:


image


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


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


Но за пределами госсектора всё обстоит гораздо лучше. Там не все относятся к ИБ так, будто главная задача это защититься от законодательных требований. В банках и крупных коммерческих организациях чаще всего уже сформирована финансовая оценка информационных активов компании и выбить бюджет на защиту этих активов у руководства не является сложной задачей. Нет требований к конкретным средствам защиты информации (здесь имеется в виду, что в некоторых государственных компаниях в отраслевых требованиях прописано у какого производителя закупать то или иное решение ИБ). Здесь и руками дадут пощупать и заставят разбирать вопросы легитимности того или иного инцидента ИБ, возникшего в инфраструктуре компании, да и ИТ с ИБ дружат лучше. И в этих секторах подбор специалиста будет уже более узконаправленный: под задачи менеджмента ИБ, сопровождения средств защиты информации, безопасную разработку программного обеспечения организации, поиск уязвимостей в инфраструктуре нанимаются отдельные специалисты, которым не вменяют в задачи делать всё подряд. Но надо учитывать, что большинство компаний не проявляют желания плодить разный парк производителей средств защиты информации (сократим до СЗИ) у себя в инфраструктуре. И это нормально, не всё так хорошо интегрируется с различными СЗИ. Подружить из между собой не всегда решаемая задача. Поэтому не особо надейтесь расширить свой кругозор по линейке производителей, но это и ненужно.


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


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

Подробнее..

Из тестировщиков в агенты изменений департамента путь в 10 лет и два выгорания

22.12.2020 10:22:28 | Автор: admin
image

Хабр, привет! Меня зовут Ася, я ведущий инженер-тестировщик (QA Lead) в КРОК.

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

Про профессию тестировщика часто слышу, что это самый легкий и быстрый порог входа в ИТ а там и на разработчика переучиться можно. Я же наоборот училась на разработчика и даже успела им немного поработать, но душа к этому не лежала, потому что искать баги намного веселее. За всю мою карьеру я участвовала в совершенно разнообразных проектах: документооборот, файлообменники, статистические наблюдения, обработка обращений пассажиров в ЦППК, учет оборудования. А потом поняла, что этот опыт можно масштабировать на свою жизнь и даже на работу целого департамента. Так я стала агентом изменений департамента разработки программного обеспечения (ДРПО).

В этой статье хочу рассказать про свой путь и постараться ответить на вопрос, который мучает многих тестировщиков а есть ли жизнь на Марсе задор и челленджи после многих лет в тестировании?

Как технарское во мне победило гуманитарное


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

Сочинение 4, математика 4, английский 2 Естественно, не прохожу, а в другие вузы даже пытаться не стала я хотела только в МГУ. После школы я нигде не работаю и готовлюсь к поступлению. И вот, следующий год, МГУ, все тот же филфак. Сочинение 3, математика 5, английский опять двойка

За год мое желание учиться только в МГУ немного поутихло, и я подобрала себе несколько запасных вариантов, одним из которых был МИСиС, в котором среди специальностей про сплавы и металлургию я нашла нейтральную прикладную математику. У меня, вопреки стереотипам про гуманитариев, с математикой всегда было так же хорошо, как с русским. В итоге этот запасной вариант выстрелил после нового фейла с МГУ так я стала студентом кафедры инженерной кибернетики. Как я потом узнала, девочки на прикладной лингвистике ездили летом на практику в деревни Мордовии, изучали мордовские диалекты и составляли частотные словари. Сейчас я думаю: Деревни Мордовии, частотные словари вообще какая-то параллельная Вселенная.

Как я фиксила баги собеседований и дофиксилась до тестировщика


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

Свою первую работу в ИТ я получила в 2008 году опыт этот длился где-то полгода, пока мою компанию не накрыл кризис, а вместе с ним сокращение штата. По трудовой я
была инженером-программистом, по факту системным аналитиком, а на самом деле занималась всем подряд и ничем одновременно. Из того что помню: я постоянно обновляла календарный план, составляла план работ проходил месяц, и я снова обновляла план работ. Работа была дурацкая, но что в ней было хорошо (кроме того, что я поняла, что вау, за мои знания можно получать деньги!) это ощущение взрослости и реальности того, чему я учусь. Я начала понимать, как на самом деле создается программное обеспечение, что есть заказчики и как проходят с ними встречи, что в команде с разработчиком работают еще аналитики.

Погуляв и отдохнув летом после увольнения, я перешла на 5 курс и пошла искать работу. Я была профоргом в группе, покупала на всех проездные (московские студенты середины 00-ых, вы помните такое?) в один из таких разов я наткнулась в профкоме на карьерную брошюру, где были неплохие советы о составлении резюме. Так появилось мое первое резюме и первое письмо работодателю.

image

Его я вывесила на hh.ru и сайт для студентов, которые ищут первую работу (он еще был в каком-то желтом дизайне). Когда готовила пост, решила немного окунуться в ностальгию и посмотреть, на что откликалась у меня почему-то отложилось, что я искала только вакансии разработчиков. Но оказалось, что я была готова работать и в техподдержке, и инженером-математиком. Мне важно было попасть в ИТ а кем и куда, было не важно. И хотя у меня был уже опыт (т.е. я вроде уже попала туда), человеком с опытом я себя не ощущала, поэтому по-прежнему считала себя начинающим. Смотрю и завидую даже немного нынешним джунам за нами тогда компании не охотились, в тележке, Хабре и Гитхабе не выискивали :))

image

Один из моих откликов выстрелил это была вакансия тестировщика в Яндексе. Кто такой тестировщик, я не особо понимала, но это казалось чем-то очень простым и доступным ну просто проверяет он и всё, что тут такого. В качестве тестового задания мне предложили протестировать функцию я составила много тест-кейсов, мама не горюй. И вот я отправляю свои варианты проверок, а мне в ответ: Вы еще не все проверили. Сажусь еще раз думать, что-то еще из себя выжимаю. И мне отказывают если честно, гештальт до сих пор не закрыт. Делала скрины для статьи с закрытыми глазами :)
Мое первое тестовое
image
image

А вот такой был ответ от Яндекса:

image

Потом я попала на одну карьерную выставку и увидела там стенд КРОК погуглила после сайт и решила откликнуться на одну из вакансий. Сейчас, конечно, смешно вспоминать свою мотивацию мне понравился офис (аж 11 этажей, не то что в моем прошлом офисе всего один), то, что с моей Калужской удобно делать пересадку на желтую и бесплатный обед (это ж можно домой булку или яблоко с собой унести). Сейчас студенты, конечно более осознанные :))

Собеседовалась я на стажера-разработчика все прошло нормально, я решила ситуационные задачки, ответила на вопросы. Но меня не звали. И потом отказали. Тогда я набралась смелости и попросила фидбэк, чтобы понять, как могу усилиться на рынке труда (осторожно, в письме сквозит темное прошлое с мыслями о филфаке). В общем, мне повезло мне перезвонили и пригласили на позицию стажера-тестировщика. Вот так корректировка бага собеседования привела меня в мир тестирования.

image

Взрослая работа и первые ошибки


1 декабря 2009 года был мой первый рабочий день в КРОК, но на серьезный проект меня поставили только в феврале. Мы писали софт для Всероссийской переписи населения 2010 года. Одним из условий работы на нем была необходимость сидеть всей командой в одной комнате. Не помню точно, сколько нас было кажется, почти под 50 человек. Это был кайф кайфный, даже жалею, что такого опыта больше пока что не случилось теперь команда не то что по комнатам-этажам раскидана, но даже по городам и странам. Кто бы что ни говорил про возможность работать из-под пальмы, но работать бок-о-бок непередаваемо-вдохновляющие ощущения.

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

Тестировщиков (включая меня) было 6, один из них тест-лид. Тогда у нас не было никакого скрама, было что-то вроде MSF мы писали большие и полные тест-кейсы, вели всю документацию. В тестировании старались дать каждому тестировщику отдельную подсистему, но бывало, что вместе проверяли одну. У нас был календарный план, и мне почему-то помнится, что у нас был каждый месяц релиз. Про проект, кстати, подробно рассказывали на Хабре, вот здесь можно почитать.

Меня очень вдохновляло то, что я делаю. Ведь результатом моей работы будет то, что несколько тысяч людей, которые будут работать с нашими подсистемами, смогут выполнять свою работу хорошо, значительно сэкономив свое время. И смогут собрать результаты Всероссийской переписи населения, и наверное, разработать какие-то полезные законы. В общем, в то время чувство ответственности зашкаливало, ошибки пропустить просто нельзя. Считаю нереальным везением, что удалось попасть на такой проект в начале карьеры мне кажется, что для молодого спеца особенно важно понимать, что результат работы можно пощупать, что он реально приносит пользу, а ты не просто что-то тестируешь (как я думала, когда шла в Яндекс). Если этот пост читает кто-то из джунов, мой вам совет идите в страшные проекты, это реально лучшее, что вы можете сделать для своего профразвития. Кстати, пока вспоминала первые месяцы работы, прокручивала в голове факапы, и кажется, собрала комбо. Поделитесь в комментах, какие у вас были кейсы?

У меня было вот так:
  • проверяла сначала негативные кейсы, не проверив позитивные
  • проверяла по настроению, без системы проверок (чтобы быть уверенным, что ты выполнил полное тестирование и ничего не забыл. с этим я разберусь позже, когда займусь своим образованием)
  • проверяла числовое поле, вводила туда буквы, а они не вводились. А потом оказывалось, что с помощью Ctrl+C-CTRL+V буквы в числовое поле очень даже прекрасно вводились:)
  • была и совсем дичь: проводя функциональные тесты через UI, не смотрела что там происходит в базе данных, как вся информация сохранилась.

Я подмастерье vs Я наставник


В КРОК развита система наставничества у каждого нового сотрудника есть человек, который помогает ему адаптироваться в компании в целом и в рабочей команде. Ну и вообще в любом профразвитии без наставника никуда :) Как правило, им логично становится наиболее опытный член команды. Сейчас я вспоминаю и понимаю, что мой наставник меня редко хвалил и как-то редко был доволен моей работой в общем, суровый тестировщик. Я из тех людей, которых мотивирует не злость от того, что он получил тройку (уу, ну я сейчас всех победю!), а пятерка с минусом. Мой наставник же действовал от противного (почему я об этом не говорила вопрос хороший) он был очень дотошный (что не удивительно для тестировщика) и делал акценты на том, что у меня не выходило, объяснял, как это можно исправить или не допустить в следующий раз. Но зато его первую похвалу я помню до сих пор. Я написала тест-кейсы для одной подсистемы и он сказал: Идеально, отличная компоновка кейсов, всё логично, проверки хорошие. Всё здорово. Видимо, меня это так поразило, что я помню это до сих пор. И тогда же я поставила себе галочку- поняла, что могу, что я не потеряна для тестирования:)

Когда я сама стала наставником, мне выпал шанс закрыть все профгештальты за себя и за того парня, как говорится. Я тогда только стала тест-лидом, к нам на проект пришел молодой человек из другого отдела. По факту, это была я несколько лет назад все, что он знал про тестирование, было ошибки есть, их не может не быть (Дима, если ты читаешь сейчас эту статью, а я надеюсь, что ты читаешь, я передаю тебе огромный привет!)

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

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

Порефлексировав, я поняла, что этот опыт, кроме радости воспитания нового спеца дал мне еще вот что:

  • я изменила свой подход к работе иначе стала смотреть на тщательность у нас появились Definition of Done. Если я раньше считала нормой что-то вроде Умри, но найди все ошибки, будь мастером придирчивости и дотошности, то я сейчас я выстраиваю свои проверки ровно с ожиданиями и договоренностями, не пытаюсь перепрыгнуть через свою голову.
  • умею определять критичные компоненты проекта
  • стала более заботливым специалистом я лучше понимаю, как себя ощущает новичок в карьере, развила профессиональную эмпатию.

Тестировщик без базы быть или не быть


После 1,5 лет работы подмастерьем я задумалась о профильном образовании университетские знания совсем не пригодились. Ну, разве что при тестировании методом белого ящика я читала код и понимала, что там написано (как никак, мы разные языки программирования в универе изучали). Но справедливости ради добавлю, что именно математическая база мне точно помогает как минимум, комбинаторика каждый день используется. В нагрузочном тестировании нужна теория вероятности, всякие там перцентили, когда анализируешь результаты и структурируешь. Еще теория случайных процессов наличие этой базы мне позволяет структурировать свои проверки по процессам, где есть статусы, переходы из статусов, длинные пути, циклы внутри пути.

Я была тестировщиком без базы и хотя работала я хорошо (пусть и под странным девизом найди все, что не так, а как найдешь не важно), понимала, что мне не хватает системы, чтобы как-то оптимизировать хаотичный набор моих действий. Помню, когда впервые узнала о существовании тест-дизайна, классов эквивалентности, граничных условиях, Pairwise и такая: аааа, так вот как надо!

В попытках образоваться я прошла несколько курсов на software-testing, но если честно, они были слегка мимо меня, не могу сказать, что было полезно. Но зато я очень оценила (и всячески рекомендую) их Школу тест-менеджеров она все супер разложила по полочкам и упорядочила мой огромный практический опыт. На этом курсе было 8 вебинаров учили оценке трудозатрат, целям тестирования, техникам тест-дизайна, какие метрики собирать. Тот курс меня так зарядил, что я потом все то время, что работала тест-лидом, продолжала распространять свои знания и понятия о прекрасном тестировании, как надо и как не надо. Совершенно точно после курса про тест-менеджмент я стала осознанным тест-лидом, проактивным, а не реактивным, стала вести статистику.

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

Еще одним мощным рывком в моем профессиональном развитии стал мой первый проект в роли тест-лида все потому, что я люто накосячила и узнала реальную цену ошибок. А также, что вообще есть такие понятия, как Severity и Priority, что может быть блокирующий дефект, но который не нужно исправлять в первую очередь. А есть критический и вот им как раз нужно заняться самым первым. С тех пор я с первых дней работы на новом проекте определяю, что точно должно работать в любых обстоятельствах, количество пользователей, кто они, на что это может повлиять. Больше рассказать не могу :)

image

Зацените качество камер смартфона тогда здесь я в своей первой рабочей командировке в Ростов-на-Дону в качестве тест-лида, приехала к пользователям, чтобы побеседовать с ними.

image

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

Два выгорания за 5 лет


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

  • я стала контрол-фриком я знала абсолютно все о каждой детали проекта и ни на секунду не давала себе и окружающим расслабиться
  • я повернулась на идеальности ошибок быть не могло, нужно было делать на 101% сразу, другой результат я от себя не принимала
  • я думала только о работе я просыпалась с почтой и засыпала с почтой. За ужином дома я говорила только о работе. Тогда я ждала первого ребенка, но даже мысли о таком крутом изменении в моей жизни не отвлекали меня от задач на проекте. Я даже год в декрете заходила в почту каждый день, чтобы проверить, не развалилось ли там без меня все.

Как с этим справиться не знаю, у меня случилось так, что я ушла в декрет (не специально, так вышло). Потом первый декрет перерос во второй и я выгорела уже от сидения дома.

Я вернулась в офис незадолго до пандемии успела побыть в старых условиях буквально пару месяцев. Меня немного подотпустило оказаться в привычной среде было приятно, а заодно выйти на один из самых крутых проектов в моей карьере (он пока под NDA, но если будет можно, расскажу об этом в отдельном посте).

Но чувство, что я попробовала в тестировании уже все, что можно, не отпускало. Ирония в том, что идти по классическому пути развития тестировщика в разработчики, большие руководители, бизнес-аналитики мне не хотелось. Мне нравилось (и нравится до сих пор) тестирование просто был нужен новый челлендж, что-то совсем необычное.

Несколько месяцев назад я поняла, что еще больше, чем тестированием, мне хочется заниматься улучшением процессов, поиском проблем в процессах именно в проектах и командах. Так я стала агентом изменений в департаменте разработки программного обеспечения (ДРПО) помогаю командам стать адаптивными.

Что это за зверь такой агент изменений?


Начну издалека.

В феврале 2020 года (еще до всего) я сходила на очный тренинг по Scrum. Очные тренинги, кто помнит такое?:) Я и до этого давным давно слышала про всякие стори-поинты, спринты, дейли скрам, но применять на проектах не получалось то ли знаний не хватало, то ли еще чего-то. А тут получилось и информацию новую получить, и сразу же обкатать в работе в группах.

Как был устроен тренинг: после каждого часа теории мы разбивались на группы для отработки навыков на практике. Задания на первый взгляд могут показаться очень легкими (например, нам раздали бумажки и предложили найти соответствие между ценностью Agile и ее описанием), но здорово помогали в игровой форме закрепить информацию. А еще была понятна структура вот 5 событий, у каждого есть таймбокс, присутствующие люди, цель, артефакты на входе и выходе.

image

На фото самая впечатляющая часть тренинга. Города + Lego = любовь. С каждым раундом мы понимали, что лажаем и лажаем но к третьему выровнялись и получилось круто.

После двухдневного тренинга я вернулась к себе в проект вся заряженная, с воплями и предложениями. А давайте начнем проводить дейли? А давайте начнем проводить ретроспективы? Понемногу процесс пошел, но мы еще не были скрамом. Потом в мае в команде КРОК появились Agile-коучи, и на первую встречу-знакомство я пришла, вооруженная кучей вопросов про ретроспективы. В середине сентября мне рассказали про идею агентов изменений в нашем департаменте, и я с радостью туда вписалась. Почему? Потому что еще два года назад, когда я была в декрете и грустила, я думала: А что же я люблю делать? Что же у меня хорошо получается? Кем же мне работать? Ответив самой себе на эти вопросы я поняла, что мне очень нравится вдохновлять людей какой-то идеей. Когда я сама чем-то проникаюсь и ко мне спускается инсайт, мне хочется как можно скорее им поделиться со всеми доступными мне людьми :)

Я сразу же побежала к своему РМ (ресурс-менеджеру) и поделилась, что узнала про такую инициативу и мне туда очень нужно, потому что это мое на все 100%. РМ, конечно, расстроился, ведь это значило потерять ведущего тестировщика в команде, но поддержал меня в этом решении принуждаловки у нас нет, внутри всегда поддерживают желание сотрудника менять вектор развития своей карьеры, даже если он такой неожиданный и нестандартный.

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

Три главных человека у нас в департаменте решили, что будущее точно за гибкими методологиями, они в них верят. И это значит, что команды должны быть точно такими же адаптивными и самоорганизующимися. Почему? У адаптивных команд никогда не бывает ситуации, что на почту пришло письмо про проблему на стенде, а потом ее каждый час дергают: ну что, получилось? А кто ответственный? А какие сроки? В адаптивных командах люди сами нацелены на решение проблем, им важно не просто завершать свои задачи, а работать как единая команда, совершенствовать процессы внутри себя и им для этого не нужен менеджер, который придет и скажет: С сегодняшнего дня на дейли отвечаем на три вопроса! Команды САМИ решают проблемы, потому что они сложившийся коллектив с большой степенью осознанности.

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

Если кратко, то вот результат, к которому мы стремимся:

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

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

Из ближайших целей мы хотим, чтобы про нашу инициативу знали не только в ДРПО (нас около 600 человек сейчас), но и как минимум 1000 человек за пределами департамента всего нас в компании 3000+. Хотим поработать с 15 проектами и оценивать их конкретными измеримыми метриками, а не только на уровне ощущений было-стало.

Сейчас в нашей команде 1 Agile-коуч и 8 агентов изменений. Мы еженедельно собираемся на синхронизации, ведем общую доску активностей в Trello с нашими общими целями и целями каждого агента изменений. Работаем по спринтам, в конце спринта анализируем, что удалось, а что нет.

Что мы делаем?

Мы приходим в проект, из которого поступил запрос, и начинаем исследование посещаем несколько проектных встреч, где наблюдаем, как проходит дискуссия, вокруг чего она строится, как команда общается друг с другом на встрече. Затем мы проводим интервью с каждым членом команды и готовим перечень проблем с пояснением и доказательствами того, как она связана с конкретными потерями (чаще всего это потеря времени, см. бережливое производство, оно же Lean). По каждой проблеме мы даем рекомендации какие Agile-инструменты могут помочь ее решить., которые бы помогли проработать эти проблемы. Рекомендации это что из Agile-инструментов (есть вот такая громадная карта инструментов от Deloitte, часть из них мы используем).

image

Примеры конкретных рекомендаций практики из Kanban Maturity Model, которые помогают команде перейти с одного уровня зрелости на следующий, какие-то события из Scrum, своевременная обратная связь друг другу.

В одном проекте мы раньше сроков выкатили финальный релиз, причем не увеличивая команду просто по-другому распределили работу. Стали по-другому проводить демо заказчику: раньше просто показывали то, что сделали за спринт, фиксировали замечания, отвечали на вопросы. А теперь мы стали еще спрашивать обратную связь как им вообще результат. И оказалось, что заказчики не только про замечания и доработки они еще бывают в восторге. Это очень сильно стало мотивировать команду на работу над следующими спринтами. Как будто тебе не только двойку в дневник поставили, но и пятерку туда за домашку застолбили:) А еще мы изменили нашу доску в Jira, стали пользоваться там Kanban-доской и добавили фильтры по имени каждого человека, добавили визуальное отображение заблокированных задач (а раньше это никак не было видно, нужно было держать в уме). Вся проектная команда перестала забивать на доску, и доска в Jira зажила активной социальной жизнью. А еще придумали Trello-доску для организации работы с другими компаниями, которые тоже были задействованы в этом проекте.

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

Мне кажется, что такое развитие тестировщика не исключение из правил. Знаю, что многие тестировщики уходят в менеджеры проектов, в скрам-мастера мне кажется, что тестирование и обеспечение качества (QA) (кстати, интересно, какое количество в мире холиварных статей на тему QA, QC и просто тестирования существует:)) очень близки по духу скрам-мастерам и агентам изменений. Я бы сказала, что агент изменений это что-то вроде скрам-мастера, только он помогает настроить вообще все, что угодно, и при этом нацелен на осознанность.

***
Закончить пост хочу вопросами.

Тестировщики, за что вы любите свою профессию и что вас держит? Как начинали свой путь? Если развиваетесь в автотестах тоже очень интересно узнать, как к этому пришли? (кстати, мы сейчас расширяем команду QA Automation инженеров детали тут). Если вы ушли из тестирования, то что делаете сейчас и делает ли вас это счастливыми? Если вернулись, то почему?

Моя почта для связи AnLivenskaya@croc.ru. В комментах тоже буду рада пообщаться :)
Подробнее..

Наблюдения за погодными условиями в проекте с CCLI

01.02.2021 12:14:39 | Автор: admin

Каждая команда в своей работе сталкивается с необходимостью внедрения новой технологии или языка программирования в проект. Иногда это внедрение проходит успешно, а иногда нет. В этой статье хотелось бы рассказать о нашем опыте использования C++/CLI.

Начало. Ожидается солнечная погода

Задание: разработать программный комплекс для моделирования различных процессов, протекающих на объектах в системах сбора, подготовки и транспортировки углеводородов. Объектами моделирования могут быть скважины (как добывающие, так и нагнетательные), трубопроводы, объекты подготовки нефти, газа и воды. В среднем каждое месторождение характеризуется более чем 100 объектами обустройства. Причём некоторые объекты имеют размерность либо по глубине, либо по длине в несколько километров. Приемлемое время расчёта модели одного месторождения порядка нескольких минут. Если совсем просто, то необходимо представить вот такой объект:

В виде вот такой модели и рассчитать её характеристики.

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

Команда: программист стека .NET/WPF, программист C++, методист, руководитель проекта.

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

высокую скорость расчётов;

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

Безоблачное продолжение

Уже существующий проект, на базе которого предстояло начать работать, был выполнен с использованием .NET/WPF, методики расчёта модели реализованы при помощи .NET/C# c промежуточными вызовами плюсового кода через P/Invoke. P/Invoke (для справки) это технология, которая позволяет обращаться к структурам, обратным вызовам и функциям в неуправляемых библиотеках из управляемого кода. Т. е. примерно вот так:

Код на C# содержал описание моделей объектов, участвующих в расчёте, а также расчёт сети объектов. За расчёт параметров отдельного объекта отвечала плюсовая часть. Время выполнения расчёта соответствовало заявленным требованиям, поэтому было решено оставить расчёт сети объектов на C# и сосредоточиться на расширении расчётов параметров самих объектов на C++.

Так как предстояло значительное увеличение количества вычисляемых параметров (и, соответственно, количества параметров, которые необходимо передавать через P/Invoke), то возник вопрос: "Использовать прежнюю схему взаимодействия с неуправляемым кодом или воспользоваться другими технологиями?".

Ключевыми критериями для выбора мы определили скорость взаимодействия и удобство использования.

В качестве альтернативы использованию P/Invoke, возникла идея использования технологии C++/CLI.

Спецификация языка C++/CLI (C++ modified for Common Language Infrastructure) была создана компанией Microsoft на замену Managed Extensions for C++. C++/CLI позволяет одновременно работать как с классами и методами языков .NET, так и с обычным кодом C++.

Приставка CLI расшифровывается как Common Language Infrastructure это открытая спецификация (технический стандарт), разработанная Microsoft и стандартизированная ISO и Ecma, описывающая исполняемый код и среду выполнения, которая позволяет использовать несколько языков высокого уровня на различные компьютерных платформах без переписывания под конкретные архитектуры. Т. е. C++/CLI нужен вот для этого:

В C++/CLI, прежде всего, нам показалось привлекательной возможность вызова уже написанного на плюсах кода при помощи управляемых оберток для существующих классов на С++. Сравнительный тест скорости вызова плюсового кода при помощи C++/CLI и P/Invoke, как ни странно, также показал уменьшение времени расчёта при использовании первого.

Вызовов P/Invoke на тот момент было совсем немного и поэтому в короткий срок нам удалось перейти на использование новой технологии. Стандартный вариант использования C++/CLI в нашем проекте выглядел примерно вот так:

public ref class DeviceBaseClr : public IDisposable, public Figures::Models::IItemBase

{

#pragma region Поля и свойства

protected:

/// <summary>

/// C++ unmanaged объект декоратора

/// </summary>

DeviceBase* obj_;

#pragma endregion

#pragma region IItemBase

public:

virtual IState^ GetState(DateTime date);

virtual IState^ SetState(DateTime date, IState^ state);

#pragma endregion

#pragma region Конструкторы

public:

DeviceBaseClr(IStateFactory^ stateFactory);

virtual ~DeviceBaseClr();

protected:

!DeviceBaseClr();

#pragma endregion

};

} // Simtep::Diagrams

#endif // _DEVICEBASECLR_H_

Предполагаемая архитектура приложения, выполненного в соответствии с парадигмой MVVM, выглядела следующим образом:

Тучи сгущаются

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

Во-первых, появилась необходимость вызова расчётов реализованных на C# внутри неуправляемого кода (и, кстати, да C++/CLI и это позволяет делать тоже).

Во-вторых, нам пришлось опустить часть модели в неуправляемую часть из-за того, что возникла необходимость использования сторонних библиотек, реализованных на С++.

После этих изменений архитектура приложения приобрела следующий вид:

В результате возникли как технические проблемы:

Мы не могли просто подключать сторонние библиотеки на C++ (имеются в виду библиотеки с расчётами предоставленные нашими коллегами из параллельных проектов), нужно было пересобирать их из исходного кода, используя специальные директивы для CLI.

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

Отсутствие возможности использовать умные указатели.

Постоянно возникали вопросы при использовании контейнеров, например при попытке добавления в коллекцию, созданную на стороне неуправляемого кода, объекта, созданного на стороне .NET.

Управление памятью, например, что будет, если для одного нативного объекта вдруг создастся две обёртки на CLI, и в какой-то момент будет освобождена сборщиком мусора?

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

Логика классов может усложняться, что неизбежно ведёт к усложнению обёрток.

Как уже было сказано выше, рано или поздно возникает необходимость обратного использования управляемого кода в неуправляемом. C++/CLI позволяет это сделать, при этом увеличивается сложность проекта.

Так и вопросы организационного характера:

C++/CLI это всё-таки ещё один язык программирования. Т. е. если к вам в команду добавляется джуниор с базовыми знаниями по C++, нужно учитывать, что ему необходимо влиться в предметную область, чуть подтянуть свой уровень владения C++ и плюс ко всему выучить ещё один язык программирования. Ну и, соответственно, ошибки можно сделать как в нативном коде, так и в обёртке.

Программистам C# будет тяжело в случае необходимости внести изменения в обёртку.

По мере развития проекта мы стали замечать, что большая часть времени уходит не на расширение функционала, а именно на изучение самого C++/CLI, особенностей его синтаксиса и поддержание кода именно обёрток. Разумеется, к обычным ошибкам, сопутствующим процессу разработки, добавились ошибки, возникающие на стыке C# и C++/CLI.

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

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

Множественный вызов CLI. Почти на каждой строке. Это значит постоянное создание декораторов, постоянный (почти непрерывный маппинг) как в одну сторону, так и в другую.

Использование декораторов означает их создание, т. е. постоянное выделение памяти внутри расчётного цикла.

Цикл расчёта на стороне .NET, не позволявший осуществить многопоточный расчёт в полной мере.

Плюс системные затраты на преобразование типов из managed в unmanaged и обратно (речь о передаче стандартных типов).

Разгон облаков

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

Какие факторы помогали нам верить в успешность задуманного:

сработавшаяся команда разработчиков;

высокая степень владения кодом;

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

запас времени перед сдачей этапа;

природный оптимизм.

Новая архитектура в наших планах выглядела следующим образом:

Подобное разделение позволило бы нам избавиться от проблем с CLI и воспользоваться, наконец, в полной мере скоростью расчётов на чистом C++. Из минусов( если это можно назвать минусом) появилась необходимость создания и поддержания эквивалентной модели на стороне С++, а также обеспечения взаимодействия между моделями.

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

Переход на новую архитектуру занял у нас около 3-х месяцев, и если говорить о каких-то подводных камнях, то они были такими:

Мы планировали завершить рефакторинг во время Х, а закончили во время 3*Х. Значительное превышение первоначальных сроков было связано с тем, что изначально в проекте были большие фрагменты кода, написанные на C#. Во время оценки времени, необходимого на переход, мы не учли того, что у нас отсутствует формализованное описание алгоритмов для этих фрагментов, а прямой перенос не всегда был возможен.

Рефакторить 3 месяца при отсутствии навыков программирования на C++ большей части команды было тяжело.

Ожидается солнечная погода без осадков

Подводя итог, хочется сказать, что:

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

Если у кого-то есть свой опыт использования C++/CLI, то нам было бы интересно о нём узнать.

Подробнее..

Карьерный level up технические интервью и работа в ИТ в 2021

28.01.2021 10:04:30 | Автор: admin

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

4 февраля мы проводим онлайн-митап о найме в ИТ. Хотим поделиться с миром результатами исследования об изменениях в ИТ-найме, которое провели наши нанимающие менеджеры из команды департамента разработки ПО КРОК. Для этого мы проанализировали почти 500 технических интервью, которые провели за последние полгода. А еще один из нас отправился на секретную миссию и получил от крупнейших компаний 6 офферов после 6 собесов.

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

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

Программа митапа Level up 2021: как собрать лучшие офферы в ИТ

Как изменился рынок труда ИТ-специалистов за последние полгода

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

Спикер: Василий Мухин, заместитель директора департамента разработки программного обеспечения.

Инхаус, аутсорсинг или аутстаффинг что выбрать ИТ-специалисту?

Поговорим о том, какие плюсы и минусы есть в работе на каждом из типов проектов и, как ИТ-специалисту выбрать проект, который даст супербуст для профессионального роста. А еще объясним, откуда взялся бум на аутстаффинговые проекты (ни при джунах упомянут будет), и где айтишнику жить хорошо.

Спикеры: Юрий Зайцев, владелец продукта Цифровой рабочий, Ренат Замалиев, технический менеджер и Александра Братухина, деливери-менеджер.

Кандидат-компания: чего хочет каждый

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

Спикер: Константин Линев, руководитель группы .Net-разработчиков.

Кто я? Как понять свой уровень

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

Спикер: Илья Смирнов, руководитель группы тестирования.

Секретная миссия. Как нанимающий менеджер обошел рынок и получил 100% офферов

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

А кто спикер не расскажем, на то он и секретный агент :)

По ту сторону технического интервью: рекомендации нанимающих менеджеров

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

Спикеры: Андрей Когунь, руководитель группы Java-разработчиков, Евгений Войнов, руководитель группы региональных Java разработчиков, Константин Линев, руководитель группы .Net-разработчиков, и Илья Смирнов, руководитель группы тестирования.

Для кого

Интересно будет специалистам с компетенциями в Java, JavaScript, .Net, C++, Python, QA, QA Automation, аналитике и других ИТ-направлениях. Даже если вы не ищете работу прямо сейчас.

И еще раз о месте встречи

Пока все еще в онлайне 4 февраля в 17:00. Регистрируйтесь на митап по этой ссылке, чтобы получить доступ к трансляции и материалы после мероприятия. Участие бесплатное.

Подробнее..

Аналитика для хантинга аналитиков продуктовых, data scientists, маркетинговых

22.06.2020 12:13:23 | Автор: admin


Аналитика рынка аналитиков:


  • Сколько денег хотят аналитики, которые не ищут работу и как можно повлиять на их мотивацию. Отдельно рассказали про продуктовых аналитиков, маркетинговых и data scientists.
  • Основные компетенции аналитиков разного уровня, от junior до head of analytics. Какие типовые задачи решают аналитики разных специализаций и какими инструментами пользуются.
  • Критичные факторы, которые могут снижать стоимость аналитика без учета его специализации, а также, что может повышать ценность аналитика разной специализации.
  • 7 причин, с помощью которых вы можете заинтересовать опытного эксперта, и факторы, снижающие привлекательность вашей вакансии.
  • Могут ли кандидаты стоить для вас дешевле. Что делать, если у вас проблемы с наймом. Как кризис и пандемия повлияли на хантинг. Общие рекомендации современного хантинга.


Мы в New.HR подготовили очередную Аналитику для хантинга. В этот раз она получилась настолько объемной, что мы решили разделить ее на три статьи: про продакт менеджеров, про аналитиков (продуктовых, маркетинговых и data science) и про разработчиков.

Если хотите прочитать сразу всю, полную аналитику для хантинга, по всем профессиям сразу, скачивайте нашу презентацию (осторожнее, там 83 слайда!)

Про каких аналитиков мы тут говорим:


  • Большинство аналитиков, про которых мы расскажем ниже, работает в средних, крупных или известных проектах, а также в успешных стартапах из IT и Диджитал-отрасли.
  • Для этого обзора мы не оценивали кандидатов, которые сейчас работают в банках или крупных финансовых организациях. Отчасти потому что зарплаты в таких компаниях могут быть выше, чем в среднем в интернет-отрасли, и будут сильно смещать вилки. Также мы не учитывали аналитиков, работающих в не-дидижитал индустриях, несмотря на то что там могут быть уже сформированные крупные аналитические практики (промышленность, нефтедобыча, логистика, фарма, производство и т.д.).
  • Мы не учитывали данные по аналитикам из маленьких проектов или стартапов, где такой специалист один и часто выполняет задачи из разных направлений аналитики. Либо, бывает, что функция аналитики размазана по другим профессиям/должностям.
  • В основном мы оцениваем кандидатов из Москвы, либо тех, кто работает удаленно на московские компании.
  • Наши респонденты готовы рассматривать предложения преимущественно в российских проектах.
  • Большинство опытных аналитиков, которых мы оценивали, не находятся в активном поиске работы, но готовы рассмотреть интересные предложения. Такие кандидаты обычно готовы к работе, интересной с точки зрения профессионального роста и других перспектив.
  • Мы не включали в нашу оценку тех кандидатов, которые ищут работу срочно, а значит, потенциально готовы соглашаться на то, что предлагает рынок, а не ждать действительно интересного им предложения.










Что может влиять на стоимость аналитика


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

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

3 ключевых причины, которые могут снижать стоимость аналитика вне зависимости от специализации


  1. Если основной результат работы аналитика отчёты ради отчётов, а не ради развития продукта или бизнеса.
  2. Большая часть работы аналитика не привязана к конкретным бизнес-метрикам, например, к деньгам, пользователям и проч.
  3. Невладение критичным инструментарием. Когда незнание той или иной технологии, либо инструмента становится барьером для решения задачи.


4 фактора, которые могут повышать ценность аналитика вне зависимости от специализации


  1. Общая универсальность специалиста. Например, аналитик владеет большим арсеналом аналитических инструментов, может решать широкий спектр задач, понимает их на уровне пользы для бизнеса.
  2. Личный бренд. Статус эксперта в сообществе, преподавание, выступление на конференциях, хакатонах, профильные статьи.
  3. Дополнительную ценность аналитикам может дать опыт работы в собственном стартапе. Такой опыт дает чёткий фокус на бизнес-целях, учит видеть физический смысл за цифрами, а не просто делать отчёты.
  4. Способность генерить множество гипотез, в том числе неочевидных. Умение оперировать не только аналитическими факторами, но и экономическими, логистическими, политическими, эмоциональными и прочими. Некоторые руководители оценивают умение генерить гипотезы на собеседовании. Пример вопроса, который проверяет вашу способность генерить неочевидные гипотезы: Не работает интернет. Назовите все возможные причины, почему это случилось. Другой пример вопроса: Придумаете продуктовую метрику, объясните, чем она хороша. А теперь, расскажите, чем она плоха.


Специализации аналитиков и факторы, повышающие их ценность




Что может повышать ценность продуктового аналитика


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




Что может повышать ценность data scientists


  • Опыт применения или уверенное знание классических алгоритмов машинного обучения (например: Линейная регрессия, Логистическая регрессия, LDA, Деревья решений, Бустинг, Байес, KNN и т.д.)
  • Опыт работы с нейросетями
  • Узкая специализация. Например, аналитик специализируется на применении NLP для оптимизации работы колл-центров или на построении рекомендательных систем и т.п.
  • Способность выполнять роль Data Engineer для решения задачи. Например, самостоятельно собрать, очистить и подготовить данные для дальнейшей работы. А также опыт выкатки моделей в продакшен.
  • Высокие результаты в профессиональных соревнованиях.




Что может повышать ценность маркетингового аналитика


  • Опыт работы с мобайлом и, как следствие, знание систем мобильной аналитики (например: Mixpanel, Amplitude, Flurry)
  • Знание математики, статистики, SQL
  • Опыт проведения АБ тестов
  • Наличие технического образования часто оценивается как плюс




Что может повышать ценность руководителя аналитики


  • Наличие в портфолио завершённых проектов, которые принесли очевидную пользу для бизнеса.
  • Опыт управления командами (от 15-30 человек и более).
  • Управление различными направлениями аналитики (продуктовая, бизнес, операционная и проч.).
  • Умение напрямую монетизировать данные. Например, продавать собственную аналитику сторонним компаниям. А также выстраивать партнёрские проекты с другими компаниями с использованием собственной аналитики. В этом случае мотивация руководителя может состоять не только из фиксированной части, но и иметь переменную часть (опционы, проценты от прибыли, бонусы и проч.).
  • Известность руководителя в экспертном сообществе. Это даёт возможность проще и быстрее нанимать аналитиков в команду к такому руководителю.


Как схантить опытного аналитика?


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

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

Факторы, снижающие привлекательность вакансии


  1. Noname компания, которая может и делает классный продукт, но об этом мало кто знает.
  2. Отсутствие амбициозных планов по развитию и/или сформулированной бизнес-стратегии.
  3. Микроменеджмент руководителя/фаундера. Например, может прийти и воткнуть в роадмап свои хотелки без аргументов и объяснений.
  4. Отсутствие профессионального окружения, не у кого учиться.
  5. Устаревший стек технологий и отсутствие возможности внедрения актуального стека.
  6. Аналитика в компании не влияет на принятие бизнес-решений.
  7. Отсутствие возможности вертикального и/или профессионального роста.
  8. Отсутствие ресурсов, а также возможности их получить.


7 причин, которые повышают интерес опытного аналитика к вашей вакансии


  1. HR-бренд компании/продукта. Хорошо, если ваша компания известна на рынке своей аналитической культурой, дата-дривен подходом, вы рассказываете о том, как аналитика в вашей компании влияет на бизнес-решения и т.д.
  2. Сфера применения вашего продукта. Многие аналитики сейчас ориентированы на социально-значимые и/или наукоёмкие проекты. Часть аналитиков даже готова снижать свои зарплатные ожидания, если есть возможность поучаствовать в проекте, оказывающим реальное влияние на жизнь людей. Например, это могут быть проекты, связанные с медициной, биотехнологиями, агротехом, обучением.
  3. Возможность профессионального роста. Есть общее правило: вам может быть непросто заинтересовать опытного профессионала, если вы предлагаете те же задачи, которые он успешно решает прямо сейчас. Поэтому мы рекомендуем рассматривать кандидатов из другого продукта или сферы, а также тех кандидатов, для которых ваши задачи будут вызовом и профессиональным ростом.
  4. Международный проект. Работа на других рынках интересна многим кандидатам, так как даёт возможность получить уникальный опыт.
  5. Работа в команде опытных и/или известных рынку аналитиков. Для многих аналитиков важна работа в профессиональной среде, возможность учиться у команды. Поэтому если у вас есть в команде опытные аналитики, обязательно рассказывайте про них кандидату. Большим плюсом будет наличие в команде аналитиков-амбассадоров, известных на рынке персоналий, чьим именем легко нанимать людей в команду.
  6. Удалённая работа. Мы видим растущий интерес к удалённой работе. Уже сейчас на рынке есть кандидаты, которые готовы рассматривать только remote-предложения.
  7. Деньги. Важно отметить, что этот фактор практически никогда не является первоочерёдным критерием выбора нового места. Аналитики предпочитают выбирать новые проекты по совокупности вышеперечисленных причин. Но деньги это гигиенический фактор. И если ваш бюджет ниже рынка, то, скорее всего, вы не сможете заинтересовать опытных и востребованных профессионалов.




Что у нас есть еще интересного?




Откуда мы берем данные?


Мы рассказываем только о том, в чём сами хорошо разбираемся:


  • New.HR хантинговое агентство, мы работаем на узком рынке: только IT и Интернет-компании.
  • Наша специализация: поиск специалистов конкретных профессий разработчики, тестировщики, девопсы, продакты, проджекты, аналитики, дата сайнтисты, перфоманс маркетологи и продуктовые дизайнеры
  • Такой узкий фокус позволяет нам постоянно работать с кандидатами из конкретных профессий, а значит, во всех подробностях знать, чего они хотят, сколько стоят, и какие тренды появляются в каждой из специальностей.
  • Каждый год мы готовим Аналитику для хантинга, основываясь на тех данных, которые мы напрямую получаем у кандидатов, с которыми работаем.

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

Какую информацию мы используем


  • Обобщенные данные. Для этого материала мы обобщали данные, которые напрямую получили от кандидатов из разных компаний. Да, они все работают в IT и в Диджитал проектах. Большая часть продактов работает в Москве или на московские компании. Но мы не сегментировали наших респондентов по отраслям или, например, по размеру компании. Если вам хочется получить больше конкретики для своей сферы, мы можем помочь вам собрать данные, которые наиболее релевантны именно вашему запросу. Пишите: contact@new.hr
  • Кандидаты не в активном поиске работы. Мы основывали наш анализ на оценке тех респондентов, которые либо совсем не ищут работу, либо ищут, но пассивно. Такие кандидаты, как правило, не готовы снижать свои ЗП ожидания, а ищут проект, который будет интересен не только уровнем дохода, но и другими критериями, например, задачами.
  • Бэкграунд. В основном мы оценивали кандидатов с бэкграундом из приличных продуктовых компаний, с хорошим опытом и подтверждённым трекшеном проектов. И не учитывали тех, кто работает в не в продуктовых IT и интернет-компаниях.
  • Постоянство. Мы не брали в расчёт прыгунов, которые работают менее 1 года на одном месте.
  • Российские проекты. Учтены ЗП ожидания только тех кандидатов, которые готовы рассматривать работу в российских проектах, а не нацелены на релокейт.
  • Также мы не учитывали зарплатные ожидания тех кандидатов, которые активно и срочно ищут работу, а значит, потенциально готовы соглашаться на то, что предлагает рынок, а не ждать действительно интересного им предложения.


Могут ли кандидаты стоить для вас дешевле?


Важные факторы, из-за которого наши цифры для вас могут быть неактуальны:


  • У вас классный и прокачанный HR-бренд
  • Ваш продукт крут и активно развивается
  • В команде есть известные эксперты
  • Вы предлагаете хорошие рыночные условия
  • У вас выстроена адекватная система оценки
  • Вы готовы нанимать на вырост
  • Вы быстро принимаете решения о найме
  • Даёте качественный фидбек при отказе
  • Делаете много хорошего для сотрудников
  • И много полезного для рынка
  • Хорошо расстаётесь с теми, кого увольняете

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

Почему мне столько не платят?


Если вы смотрите на наши цифры, и думаете: Почему я получаю меньше? специально для вас мы описали, что именно может повысить вашу стоимость. Несмотря на то что каждый кейс стоит оценивать отдельно, мы попробовали выделить несколько типичных паттернов: что ценится в опыте, а что может снижать ценность.

Хантинг в период кризиса и пандемии


  • Компании собираются выжить после карантина, а делать это лучше всего с сильной командой, поэтому опытные и крутые эксперты под сокращения не попадают.
  • Кандидатов на рынке стало больше в основном за счёт джунов и миддлов.
  • Удалёнка больше не конкурентный фактор. Сейчас на удалёнку перешли не только российские IT-компании, но и международные. А значит в ближайшее время рынок может ждать увеличение конкуренции за кандидатов.
  • Никто не готов снижать свои зарплатные ожидания, и в будущем ждать этого не стоит. Есть предположение, что после пандемии конкуренция за опытных и сильных кандидатов только возрастёт (смотри предыдущий пункт).
  • Пассивных кандидатов хантить стало труднее (это те, кто готовы рассмотреть вакансию, но только если она действительно им интересна). Некоторые кандидаты отказываются рассматривать новые предложения в общей ситуации неопределенности и не готовы рисковать переходом на новое место, если в текущей компании все хорошо.
  • Часть кандидатов не готова рисковать и переходить в потенциально менее стабильные проекты. Так что если у вас стартап без подтверждённого финансирования, вам может потребоваться больше времени и сил, чтобы заинтересовать опытного кандидата.
  • Если у вас серая зарплата, если вы оформляете по ИП или выплачиваете небольшой фиксированный оклад, а всё остальное оформляете премией, привлечь зрелых кандидатов вам будет сложнее. Они хотят работать с гарантией, что их не уволят в любой момент или перестанут платить часть денег.
  • Сильно вырос интерес к релокейту по сравнению с прошлым годом. Опытные кандидаты все чаще интересуются возможностью поработать с зарубежными проектами. Все больше иностранных компаний предлагают удаленку, а часть релокейт после открытия границ. На рынке существует достаточно большое количество кандидатов, которые готовы рассматривать предложения только с учетом международного проекта и заработной платы в валюте.


Что делать, если у вас есть проблемы с наймом?


  • Отталкивайтесь от предложений рынка, перестаньте мечтать об идеальном кандидате.
  • Обязательно пробуйте смотреть кандидатов с экспертизой ниже, чем вы хотите в идеале. Очень сложно привлечь кандидата, который не ищет работу и занимается тем же, что вы ему предлагаете. Обычно такие люди интересуются профессиональным ростом, поэтому всегда имеет смысл подумать, чем ваша задача привлекательна для конкретного кандидата. Далее мы рассказываем общие вещи, которые могут заинтересовать специалистов, но лучше всего отталкиваться от личности и мотивации каждого конкретного человека.
  • Удалёнка маст хэв для всё большего количества кандидатов. Многие IT и Интернет-бизнесы уже научились работать удалённо (спасибо, самоизоляция), а некоторые даже выстроили эффективный асинхронный процесс работы. Так что если у вас нет удалёнки, велик риск, что вы сможете привлечь значительно меньшее количество заинтересованных кандидатов.
  • Учитесь нанимать джунов. Их приток в индустрию растёт (здесь спасибо буму онлайн-образования). К сожалению, многие работодатели всё ещё скептически относятся к найму джунов. Кстати, мы в New.HR планируем в июле серию лекций на тему "Как нанимать джунов и не облажаться". Спикерами будут нанимающие менеджеры, которые видят ценность в найме джунов, они расскажут про свой опыт и ответят на вопросы. Приходите!
  • При работе с кандидатом в активном поиске крайне важна скорость принятия решения. Опытные и адекватные специалисты весьма востребованы, и если они начинают активно искать работу, то уходят быстрее, чем вы скажете Мы вам перезвоним. Так что если хотите отложить кандидата на недельку, а потом к нему вернуться, есть риск, что возвращаться уже будет не к кому, ведь он получит несколько интересных офферов.
  • Сокращайте этапы оценки (постарайтесь уложиться в 2-3 этапа).
  • Если вы претендуете на опытных экспертов, постарайтесь обойтись без тестового (особенно при найме опытных кандидатов senior уровня). Мотивация делать тестовое есть только у junior или тех, кто мечтает о работе в вашей компании.
  • Учитесь быстро принимать решения о кандидате. Идеальный срок не более суток. Терпимо 2-3 суток. Особенно важна скорость, если кандидат рассматривает и другие предложения, кроме вашего.
  • Постарайтесь формулировать развернутый фидбек. Это выделит вас на фоне множества собеседований, где кандидат не получил никакого фидбека вовсе.
  • Анализируйте причины отказов на всех этапах. Обращайте внимание на типичные паттерны в отказах и корректируйтесь, корректируйтесь, корректируйтесь.
  • Помните, что ваша задача решить задачу бизнеса с помощью найма подходящего кандидата, а не провести месяцы и годы в поиске того самого, идеально подходящего по всем фронтам единорога.


Общие рекомендации современного хантинга


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


Дисклеймер


Эта статья часть большой аналитики для хантинга продактов, аналитиков (продуктовых, маркетинговых и data scientists), разработчиков и CTO.

Вы можете скачать полный файл исследования по ссылке.

Или прочитать еще две статьи:


Подробнее..

Аналитика для хантинга разработчиков и CTO

22.06.2020 12:13:23 | Автор: admin


Аналитика рынка разработчиков и CTO:


  • Сколько денег хотят разработчики и CTO, которые не ищут работу и как можно их замотивировать
  • 4 ключевых причины, которые могут снижать стоимость разработчиков и что может повышать их ценность;
  • 12 факторов, с помощью которых вы можете заинтересовать опытных экспертов;
  • Могут ли кандидаты стоить для вас дешевле. Что делать, если у вас проблемы с наймом. Как кризис и пандемия повлияли на хантинг. Общие рекомендации современного хантинга.



Мы в New.HR подготовили очередную Аналитику для хантинга. В этот раз она получилась настолько объемной, что мы решили разделить ее на три статьи: про продакт менеджеров, про аналитиков (продуктовых, маркетинговых и data science) и про разработчиков.

Если хотите прочитать сразу всю, полную аналитику для хантинга, по всем профессиям сразу, скачивайте нашу презентацию (осторожнее, там 83 слайда!)

Про каких разработчиков мы тут говорим:


  • Мы оцениваем разработчиков из средних, крупных или известных проектов IT и диджитал-отрасли.
  • Есть опыт с высоконагруженными проектами.
  • Мы не включали в оценку кандидатов с опытом работы в студиях, noname-стартапах, в проектах из не-диджитал компаний.
  • Для Java, C# мы также оценивали разработчиков из крупного энтерпрайза, финтеха, консалтинговых IT-компаний (среднего и крупного размера).
  • Мы не включали в оценку кандидатов из блокчейн-проектов.
  • Локация: в основном Москва или удалённая работа на проектах, про которые мы написали выше.
  • Наши респонденты стабильны в работе над проектами, не прыгуны, работают не менее 1 года на одном месте.
  • Указанные зарплатные ожидания корректны для тех кандидатов, которые готовы рассматривать российские проекты. При этом на рынке есть кандидаты, нацеленные исключительно на релокейт и/или на работу в зарубежных компаниях. Их зарплатные ожидания значительно выше среднего по рынку и представлены в валюте. Таких кандидатов мы не учитываем в текущем анализе.
  • Большая часть опытных разработчиков, которых мы оценивали, не находится
    в активном поиске работы. Но они готовы рассмотреть интересные предложения. Такие кандидаты обычно готовы к работе, интересной с точки зрения профессионального роста и других перспектив.
  • Мы не включали в нашу оценку тех кандидатов, которые ищут работу срочно, а значит, потенциально готовы соглашаться на то, что предлагает рынок, а не ждать действительно интересного им предложения.














Что может влиять на стоимость разработчиков


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

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

4 ключевых причины, которые могут снижать стоимость разработчика


  1. Непостоянство работы над проектами, частые переходы, работа менее года над одним проектом. Наиболее критично, если такой опыт частых переходов в последние 3-5 лет.
  2. Преимущественно фриланс-проекты в опыте, а также отсутствие достаточно сложных и больших проектов в опыте за последние 3-5 лет. Также, менее ценным считается опыт в диджитал-агентствах, работодатель обычно предполагает, что в таких компаниях чаще всего ведется разработка несложных, типовых, коротких задач.
  3. Опыт написания кода только с использованием фреймворка. Многим компаниям важно знание core языка, поэтому, если вы можете писать код только с использованием фреймворка, это может быть ограничивающим фактором.
  4. Ваш основной опыт в последнее время связан исключительно с поддержкой проектов, простым багфиксингом и т.д. Такой опыт может быть востребован в компаниях с подобными задачами, но может быть ограничивающим фактором там, где нужно писать активные продуктовые фичи, в том числе с нуля.


Что может повышать ценность разработчика


  • Опыт работы в известных, брендовых и масштабных проектах.
  • Опыт работы с конкретными технологиями, критично важными для компании может оцениваться выше. Например, тимлида с опытом разработки продукта с ML или CV при прочих равных оценят дороже, в случае, если компания разрабатывает продукт с использованием именно этих технологий.
  • Опыт работы с нативным языком часто ценится больше, чем опыт написания кода только с использованием фреймворка.
  • Чем релевантнее ваш стек стеку проекта, тем более ценным будет ваш опыт для компании.
  • Ценится опыт разработки highload-проектов, а также опыт разработки продуктов/проектов/крупных и сложных фичей с нуля.
  • Участие в open source проектах, опыт написания собственных библиотек, фреймворков и проч. может быть плюсом для некоторых компаний.
  • Чем более технологичный продукт предстоит разрабатывать, тем больше ценится техническое образование. Хотя мы знаем многих классных разработчиков, у которых нет законченного ВО.





7 факторов, которые могут снижать стоимость Руководителя разработки или CTO


  1. Опыт с неактуальным стеком. Например, если последний опыт CTO связан с проектами на Perl и в этих проектах не предпринимали шагов по переходу на другой, более актуальный стек, работодатель может увидеть в этом риск, что CTO плохо прогнозирует последствия выбора неактуальных инструментов (например, это может аффектить найм, саму разработку и дальнейшую поддержку продукта).
  2. Недостаточный (для конкретной компании) опыт управления командами.
  3. Преимущественно аутсорс проекты и заказная разработка в опыте. Такой бэкграунд заинтересует в основном компании похожего типа.
  4. Фокус не на решение задач бизнеса. Такие CTO часто не готовы подписываться под конкретные сроки реализации задачи.
  5. Нет продуктов в продакшене. Особенно если это систематическое явление.
  6. Частая смена работы. В среднем от CTO ожидают не менее 3х лет на одном месте.
  7. Преимущественный опыт на удалёнке может снижать интерес компаний, в которых core-команда находится в офисе.


Что может повышать ценность Руководителя разработки или CTO


  • Опыт разработки серьёзных highload-проектов, а также SOA проектов, где используются разные языки программирования и БД.
  • Масштаб команды в подчинении. Опыт управления несколькими командами ценнее в проектах, где это является базовой задачей.
  • Ответственность за сложный продукт. Продукт может быть сложным за счёт используемых технологий (например, CV) или архитектуры. А также сложность продукта может определяться сложностью бизнес-логики (например, разработка масштабной кастомной ERP-системы).
  • Диджитальный опыт может быть особенно ценным для крупных не-IT-компаний.


Как схантить опытного разработчика или руководителя разработки?


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

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

Гигиенический минимум


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

Вот что большинство разработчиков считают обязательным минимумом:


  • Белая ЗП
  • ДМС
  • Приличный офис рядом с метро, либо удалёнка
  • Парковка, особенно если офис далеко от метро
  • Гибкий график
  • Релокационный пакет, если вы нанимаете из регионов


12 причин, которые могут заинтересовать опытного разработчика


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


  1. HR-бренд. Что рынок знает про вас, почему у вас классно, интересно, перспективно работать. Чем вы отличаетесь от других похожих работодателей. По нашему опыту, именно системная работа над HR-брендом часто позволяет сформировать правильное представление о компании с учётом всех возможных особенностей и ограничений.
  2. Tech-бренд или HR-бренд, нацеленный на определённых профессионалов.
  3. Мы рекомендуем развивать ваш HR-бренд на конкретную аудиторию. Такой подход может быть эффективнее, если у вас есть потребность в регулярном или масштабном найме большого количества специалистов определённого профиля, или если вы планируете усилить команду опытными экспертами. Например, если планируете сильно нарастить команду разработки, то вашим текущим экспертам имеет смысл заняться написанием экспертного контента на Хабр, выступать на профильных конференциях, заняться преподаванием и проч.
  4. Продукт. Большинство опытных разработчиков интересует разработка практичного продукта, который востребован широкой аудиторией. Если вы занимаетесь заказной разработкой или ваш продукт не рассчитан на большое количество пользователей, вам может быть сложнее привлекать кандидатов.
  5. Задачи. Большинство разработчиков готовы работать с ежедневной рутиной, из которой состоит большая часть проектов. Но многим важна возможность периодически участвовать в чем-то действительно интересном, сложном, реализовывать задачи, которые позволяют профессионально прокачиваться. Поэтому мы рекомендуем рассказывать не только про текущие задачи, но и про челленджи и вызовы, которые планируются у вас в проекте.
  6. Актуальный стек или стек, который интересен конкретному кандидату. Наиболее частые сочетания текущего стека и стека, который интересен разработчику на перспективу:

    • PHP Go
    • .Net Go
    • Ruby Elixir
    • C++ Rust
    • Java Scala, Kotlin
    • Python ML задачи

  7. Для тимлидов, руководителей разработки и CTO важна также возможность влиять на выбор стека.
  8. Наличие интересных open source проектов может быть ключевым фактором для определённой части кандидатов.
  9. Опытная команда важна многим разработчикам. А ещё вы можете привлечь больше заинтересованных кандидатов, если в вашей команде есть известные в профессиональном сообществе эксперты.
  10. Возможность карьерного и/или профессионального роста.
  11. Удалёнка. Весьма востребованный тренд, который значительно вырос за время пандемии. Всё больше компаний готовы предлагать удалённую работу, поэтому, если вы не можете себе такого позволить, вы априори можете расчитывать на меньшее количество кандидатов, которых вы сможете заинтересовать.
  12. Деньги. Важно отметить, что этот фактор практически никогда не является первоочерёдным критерием выбора нового места. Разработчики предпочитают выбирать новые проекты по совокупности вышеперечисленных причин. Но деньги это гигиенический фактор. И если ваш бюджет ниже рынка, то, скорее всего, вы не сможете заинтересовать опытных и востребованных профессионалов.




Что у нас есть еще интересного?



  • 25 каналов с вакансиями, в том числе: отдельные каналы с вакансиями для каждого языка программирования, канал с вакансиями для ИТ-ТОПов. Общая аудитория больше 65 000 человек.
  • Geekjob.ru сервис анонимного поиска работы для экспертов из ИТ и Диджитал индустрии.
  • Podcast.New.HR подкаст про карьеру и найм в ИТ и Диджитал.
  • Repository.New.HR статьи про карьеру и найм в ИТ и Диджитал


Откуда мы берем данные?


Мы рассказываем только о том, в чём сами хорошо разбираемся:


  • New.HR хантинговое агентство, мы работаем на узком рынке: только IT и Интернет-компании.
  • Наша специализация: поиск специалистов конкретных профессий разработчики, тестировщики, девопсы, продакты, проджекты, аналитики, дата сайнтисты, перфоманс маркетологи и продуктовые дизайнеры
  • Такой узкий фокус позволяет нам постоянно работать с кандидатами из конкретных профессий, а значит, во всех подробностях знать, чего они хотят, сколько стоят, и какие тренды появляются в каждой из специальностей.
  • Каждый год мы готовим Аналитику для хантинга, основываясь на тех данных, которые мы напрямую получаем у кандидатов, с которыми работаем.

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

Какую информацию мы используем


  • Обобщенные данные. Для этого материала мы обобщали данные, которые напрямую получили от кандидатов из разных компаний. Да, они все работают в IT и в Диджитал проектах. Большая часть продактов работает в Москве или на московские компании. Но мы не сегментировали наших респондентов по отраслям или, например, по размеру компании. Если вам хочется получить больше конкретики для своей сферы, мы можем помочь вам собрать данные, которые наиболее релевантны именно вашему запросу.
  • Кандидаты не в активном поиске работы. Мы основывали наш анализ на оценке тех респондентов, которые либо совсем не ищут работу, либо ищут, но пассивно. Такие кандидаты, как правило, не готовы снижать свои ЗП ожидания, а ищут проект, который будет интересен не только уровнем дохода, но и другими критериями, например, задачами.
  • Бэкграунд. В основном мы оценивали кандидатов с бэкграундом из приличных продуктовых компаний, с хорошим опытом и подтверждённым трекшеном проектов. И не учитывали тех, кто работает в не в продуктовых IT и интернет-компаниях.
  • Постоянство. Мы не брали в расчёт прыгунов, которые работают менее 1 года на одном месте.
  • Российские проекты. Учтены ЗП ожидания только тех кандидатов, которые готовы рассматривать работу в российских проектах, а не нацелены на релокейт.
  • Также мы не учитывали зарплатные ожидания тех кандидатов, которые активно и срочно ищут работу, а значит, потенциально готовы соглашаться на то, что предлагает рынок, а не ждать действительно интересного им предложения.


Могут ли кандидаты стоить для вас дешевле?


Важные факторы, из-за которого наши цифры для вас могут быть неактуальны:


  • У вас классный и прокачанный HR-бренд
  • Ваш продукт крут и активно развивается
  • В команде есть известные эксперты
  • Вы предлагаете хорошие рыночные условия
  • У вас выстроена адекватная система оценки
  • Вы готовы нанимать на вырост
  • Вы быстро принимаете решения о найме
  • Даёте качественный фидбек при отказе
  • Делаете много хорошего для сотрудников
  • И много полезного для рынка
  • Хорошо расстаётесь с теми, кого увольняете

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

Почему мне столько не платят?


Если вы смотрите на наши цифры, и думаете: Почему я получаю меньше? специально для вас мы описали, что именно может повысить вашу стоимость. Несмотря на то что каждый кейс стоит оценивать отдельно, мы попробовали выделить несколько типичных паттернов: что ценится в опыте, а что может снижать ценность.

Хантинг в период кризиса и пандемии


  • Компании собираются выжить после карантина, а делать это лучше всего с сильной командой, поэтому опытные и крутые эксперты под сокращения не попадают.
  • Кандидатов на рынке стало больше в основном за счёт джунов и миддлов.
  • Удалёнка больше не конкурентный фактор. Сейчас на удалёнку перешли не только российские IT-компании, но и международные. А значит в ближайшее время рынок может ждать увеличение конкуренции за кандидатов.
  • Никто не готов снижать свои зарплатные ожидания, и в будущем ждать этого не стоит. Есть предположение, что после пандемии конкуренция за опытных и сильных кандидатов только возрастёт (смотри предыдущий пункт).
  • Пассивных кандидатов хантить стало труднее (это те, кто готовы рассмотреть вакансию, но только если она действительно им интересна). Некоторые кандидаты отказываются рассматривать новые предложения в общей ситуации неопределенности и не готовы рисковать переходом на новое место, если в текущей компании все хорошо.
  • Часть кандидатов не готова рисковать и переходить в потенциально менее стабильные проекты. Так что если у вас стартап без подтверждённого финансирования, вам может потребоваться больше времени и сил, чтобы заинтересовать опытного кандидата.
  • Если у вас серая зарплата, если вы оформляете по ИП или выплачиваете небольшой фиксированный оклад, а всё остальное оформляете премией, привлечь зрелых кандидатов вам будет сложнее. Они хотят работать с гарантией, что их не уволят в любой момент или перестанут платить часть денег.
  • Сильно вырос интерес к релокейту по сравнению с прошлым годом. Опытные кандидаты все чаще интересуются возможностью поработать с зарубежными проектами. Все больше иностранных компаний предлагают удаленку, а часть релокейт после открытия границ. На рынке существует достаточно большое количество кандидатов, которые готовы рассматривать предложения только с учетом международного проекта и заработной платы в валюте.


Что делать, если у вас есть проблемы с наймом?


  • Отталкивайтесь от предложений рынка, перестаньте мечтать об идеальном кандидате.
  • Обязательно пробуйте смотреть кандидатов с экспертизой ниже, чем вы хотите в идеале. Очень сложно привлечь кандидата, который не ищет работу и занимается тем же, что вы ему предлагаете. Обычно такие люди интересуются профессиональным ростом, поэтому всегда имеет смысл подумать, чем ваша задача привлекательна для конкретного кандидата. Далее мы рассказываем общие вещи, которые могут заинтересовать специалистов, но лучше всего отталкиваться от личности и мотивации каждого конкретного человека.
  • Удалёнка маст хэв для всё большего количества кандидатов. Многие IT и Интернет-бизнесы уже научились работать удалённо (спасибо, самоизоляция), а некоторые даже выстроили эффективный асинхронный процесс работы. Так что если у вас нет удалёнки, велик риск, что вы сможете привлечь значительно меньшее количество заинтересованных кандидатов.
  • Учитесь нанимать джунов. Их приток в индустрию растёт (здесь спасибо буму онлайн-образования). К сожалению, многие работодатели всё ещё скептически относятся к найму джунов. Кстати, мы в New.HR планируем в июле серию лекций на тему "Как нанимать джунов и не облажаться". Спикерами будут нанимающие менеджеры, которые видят ценность в найме джунов, они расскажут про свой опыт и ответят на вопросы. Приходите!
  • При работе с кандидатом в активном поиске крайне важна скорость принятия решения. Опытные и адекватные специалисты весьма востребованы, и если они начинают активно искать работу, то уходят быстрее, чем вы скажете Мы вам перезвоним. Так что если хотите отложить кандидата на недельку, а потом к нему вернуться, есть риск, что возвращаться уже будет не к кому, ведь он получит несколько интересных офферов.
  • Сокращайте этапы оценки (постарайтесь уложиться в 2-3 этапа).
  • Если вы претендуете на опытных экспертов, постарайтесь обойтись без тестового (особенно при найме опытных кандидатов senior уровня). Мотивация делать тестовое есть только у junior или тех, кто мечтает о работе в вашей компании.
  • Учитесь быстро принимать решения о кандидате. Идеальный срок не более суток. Терпимо 2-3 суток. Особенно важна скорость, если кандидат рассматривает и другие предложения, кроме вашего.
  • Постарайтесь формулировать развернутый фидбек. Это выделит вас на фоне множества собеседований, где кандидат не получил никакого фидбека вовсе.
  • Анализируйте причины отказов на всех этапах. Обращайте внимание на типичные паттерны в отказах и корректируйтесь, корректируйтесь, корректируйтесь.
  • Помните, что ваша задача решить задачу бизнеса с помощью найма подходящего кандидата, а не провести месяцы и годы в поиске того самого, идеально подходящего по всем фронтам единорога.


Общие рекомендации современного хантинга


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


Дисклеймер


Эта статья часть большой аналитики для хантинга продактов, аналитиков (продуктовых, маркетинговых и data scientists), разработчиков и CTO.

Вы можете скачать полный файл исследования по ссылке.

Или прочитать еще две статьи:


Подробнее..

Welcome on board или по ту сторону оффера

05.04.2021 18:06:45 | Автор: admin
Где-то над Балтийским моремГде-то над Балтийским морем

"Войти в АйТи" уже не кажется чем-то за гранью фантастики и привилегией для избранных. Бытует мнение, что тестировщик - легкая профессия. Полтора - два месяца на курсах и Voila! Вы в IT-community. Порог входа низкий, наличие технического образования не обязательно. И любой, от курьера до домохозяйки, может освоить данную профессию. Так ли это?

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

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

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

Погнали ;)

Респондент: Екатерина Бернадцкая, тестировщик из Кремниевой долины, опыт работы в тестировании 4 года. В настоящее время работает в IT компании по разработке приложения для ресторанов. Имеет опыт работы ручным тестировщиком в одной из крупнейших IT компаний России. Технического образования нет. В Штаты попала, выиграв грин карт. Собственно, выигрыш и послужил стимулом переквалифицироваться в тестировщики ПО. Пол года назад начала писать тесты на Python. Считает, что это именно тот случай, когда человек выбрал правильный путь.

- Катя, расскажи о своем первом месте работы. Ты была одним тестером на проекте или работала в команде? Опиши кратко процесс онбординга.

- Катя: Первое место работы - одна из крупнейших IT компаний России. Я попала в распределенную команду сильных профессионалов с четкой структурой, отлаженными процессами. Как такового онбординга с погружением, с тьюторами не было. Мне предложили посмотреть видео о компании и ее продуктах. И тут сразу возникла первая сложность. Люди, которые уже в компании проработали какое-то время (от полугода, к примеру) знают продукт, процессы. Соответственно, у них и не возникает мысли о том, что кому-то может быть трудно и что-то понятно. Я считаю, что это проблема для новичков, особенно, когда входишь в новую профессию. Знаний в этой сфере недостаточно. Профессия сложная, продукт неочевидный. Сложно влиться, понять, чего от тебя хотят и начать полноценно работать. Если бы этот процесс был хорошо организован, то сократился бы уровень стресса и времени, на то, чтобы влиться в коллектив и почувствовать себя полноценным членом команды.

Еще одна сложность заключалась в том, что ты видишь только маленький кусочек огромной системы. И сложно понять, как эта система работает целиком. Но тем не менее, когда ты работаешь в команде, ты видишь, куда расти, к чему стремиться. Есть, к кому обратиться с вопросом, психологически проще, чем быть одним тестером на проекте. Потому что видишь, что люди сталкиваются с проблемами и решают их. Самое главное в жизни тестировщика, да и человека в целом - умение решать проблемы. Не бывает так, что все гладко. Но если умеешь решать и справляться с трудностями, знаешь, как правильно задать вопрос, к кому с ним подойти, это уже 80 % успеха.

- Как проходило взаимодействие с командой?

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

Сейчас, когда я сама бываю очень занята, я тоже не очень охотно отвечаю на вопросы. Иногда злюсь, когда у меня спрашивают что-то очевидное. Но в эти моменты я переношусь на 4 года назад и вспоминаю себя. Беру себя в руки и терпеливо объясняю. Рисую схемы пока не увижу, что человек действительно понял. Ребята все были сильные, хорошие, умные. И просто времени не было что-то мне объяснять. Многие злились, кто-то откровенно показывал свое раздражение. Да, сначала тебя рассматривают, как винтик, который должен работать и не задавать дурацкие вопросы. Но когда я дошла до определенного уровня, стало проще. Люди привыкли ко мне. Мы стали дружить. Ходить, пить кофе. Был забавный парень ведущий программист на проекте. Он всегда после релиза покупал мне кофе. Я буду всегда с теплотой вспоминать, как этот чудесный парень покупал мне кофе. И знал, что я люблю лавандовый (улыбается).

- Как и кто оценивал твою работу?

- Катя: В основном, менеджер QA команды и продакт менеджеры. После окончания испытательного срока был сделан разбор полетов. И мне сказали, что нужно стараться больше. Они видели, что я старалась, но нужно стараться больше. И это было большим ударом по самооценке. И тем не менее я начала стараться больше. Но самое сложное было понять, куда стараться. Потому что старайся больше - слишком абстрактная фраза. И я не понимала, что делаю не так и в какую сторону двигаться. Были странные ощущения. Ты лезешь из кожи вон, не спишь ночами, читаешь, штудируешь какие-то дополнительные материалы, задерживаешься на работе, стараешься брать задачи посложнее, берешь задачи соседней команды, чтобы понять как работает система, а не конкретно твой болтик. И при всем при этом люди говорят: Старайся больше. Это неприятно. Но знаете, что самое удивительное? Когда ты начинаешь работать чуточку больше, чуточку дольше, ты начинаешь понимать, чего от тебя хотели. Ты начинаешь понимать, довольный клиент - самый основной показатель, показывающий, как хорошо ты поработал. Клиент доволен, компания не теряет, а зарабатывает деньги. Значит ты поработал хорошо и получишь свою зарплату (улыбается).

- Как ты распределяла свое рабочее время?

- Катя: Расскажу на примере текущей компании в Штатах. Многие думают, что тут работают какие-то нереальные гики, и все строго. Да еще и работают сутками на пролет. Это не так. Здесь работать гораздо проще. В российской компании время распределялось очень строго. Мы отчитывались за каждую минуту. Писали, сколько времени потратили на какой тикет, весь процесс фиксировался в багтрекере, сколько тикет висел в каком статусе. Если тикет висел в статусе testing слишком долго, нам задавали вопросы, с нами проводились беседы. Рабочий день с 10 до 19. А если ты пришел позже или ушел раньше,в конце недели получал письмо с фамилиями тех, кто позволил себе опоздать на 10 минут.

Такое отношение к сотрудникам накладывало дополнительный отпечаток. Психологически было достаточно тяжело: сложный проект, сложная работа, тебя контролируют. В Штатах гораздо проще, демократичней. Если нужно уйти, ты можешь поставить руководителя в известность о том, что у тебя семейные дела или дела по здоровью, и уйти пораньше. И никто не следит, сколько времени твой тикет находится в работе.

Мне комфортнее работать в Штатах. Я люблю наш продукт, сама являюсь активным пользователем. А с недавнего времени начала работать над автоматизацией. Очень много всего нужно сделать. У меня всегда есть какая-та работа. Или просто я умею найти эту работу (смеется). Сейчас в приоритет ставлю тикеты, один день в неделю на автоматизацию. Никто не стоит над душой, время четко не учитывается, я давно работаю в компании и все знают, что я покажу результат. И если я взялась за это дело, то доведу его до конца.

- С техническими скиллами были сложности? Чему ты научился на первом проекте?

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

А научилась всему (улыбается). Помню, меня очень напугало слово рефакторинг. Я погуглила и не особо поняла, что же они имели ввиду. Пошла спрашивать: Мальчики, что это за тикет? Как его проверить? Они: Да это же рефакторинг. Я про себя думаю: Ага, замечательно. Очень понятно. Хорошо, что муж - разработчик. Он мне и объяснил, что это такое, и что от меня хотят. Так что пришлось учить все, несмотря на то, что я думала, что готова. Миллион курсов прошла перед тем, как искать первую работу, но практику и опыт ничто не заменит.

- От чего пришлось отказаться (взгляды/убеждения)?

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

В Долине были сложности с языком. При этом, уезжая туда, я думала, что все знаю. В России я училась на языковой специальности, путешествовала, меня понимали. А когда пошла на первую работу в Штатах, поняла, что не только я не понимаю, что мне говорят, но и меня не понимают. Первые полгода было очень тяжело. Но американская культура располагает задавать вопросы. Это хорошо. Если ты чего-то не знаешь, ты не дурак, ты человек, который хочет что-то узнать. Пришлось привыкнуть к тому, что задавать вопросы и чего-то не знать, это нормально. И сейчас я придерживаюсь политики, что не нужно начинать тикет, если ты не понял, о чем он. Приходит тикет, ты читаешь. Не понятно. Начинаешь общаться с разработчиком. И общаешься с ним до тех пор, пока не поймешь, о чем тикет. И даже, если человек воет от моих вопросов, меня это мало волнует (смеется). Меня волнует только то, что это нужно проверить. Эта фича должна работать, а чтобы это проверить, я должна знать, как она должна работать.

И еще момент. Если кто-то другой нашел баг, а не я, это не значит, что я дурак и плохо поработала. Это значит, что я нашла что-то другое. Распределила свое время и приоритеты таким образом, чтобы сфокусироваться на чем-то другом. И это что-то другое работает хорошо. А тот человек тоже большой молодец. Потому что наш общий проект стал только лучше.

- У тебя есть лайфхаки?

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

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

- Катя: Как бы не было тяжело, нужно идти вперед. Если есть цель и желание развиваться в тестировании. Если в процессе поймете, что тестирование все-таки не ваше, это тоже нормально. Не всем это нравится. Но, если ваше, то идите. И поймите для себя, зачем это нужно. Если есть понимание зачем, то и все ресурсы организма будут собраны и мобилизованы. И цель будет достигнута. А еще сказала бы, как бы не было сложно сейчас, продолжай. Потому что все эти сложности даны для того, чтобы было легче потом. Ничего не бывает просто так.

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

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

И, конечно, учи как можно больше всего. Сейчас я изучаю Python. Помню, смотрела первый курс. Ничего не понятно. Ладно, смотрю второй и стало понятно 5%. Смотрю третий курс. Вспоминаю слова и определения из первых двух, и картинка складывается. И вот на десятом курсе напишется функция, метод или класс. Да, кому-то нужно больше времени, кому-то меньше. Но получится у всех. Составь список того, что нужно выучить. Иногда нужно учить не для того, чтобы понимать это и быть в этом специалистом, а знать, где это можно найти.

- Согласна ли ты с утверждением, что тестер - лёгкая профессия в IT?

- Катя: Приведу пример. Это было уже здесь, в Штатах. К нам в компанию пришла девочка китаянка, биолог по образованию. На тот момент она не знала ничего. Я к тому моменту работала в компании года полтора. И объясняла ей все. А через два года эта девочка стала программистом. И теперь я проверяю ее тикеты. Так что да, если есть желание.

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

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

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

В тестировании нужно любить новое и к этому новому уметь адаптироваться. И это не должно вызывать какой-то дикий страх. Помню, когда я получала тикет, читала его. Мне было страшно даже начинать, потому что все непонятно. Что это? Что эти люди хотят от меня? А сейчас такого страха нет. Теперь у меня возникаю совершенно другие мысли: О, прикольно! Что-то новое придумали. Зарелизим, посмотрим, как работает. Или наш говнокод упадет (смеется)?

В качестве заключения

Хочу подчеркнуть, что это опыт Кати, ее мысли и ощущения. У Вас может быть совершенно другой опыт. И возможно, Вы столкнетесь с совершенно другими сложностями. А те, о которых говорила Катя, Вас обойдут стороной. И это нормально. Все мы разные, классные и уникальные. У каждого будет что-то свое. Главное, помните, что сложности, это нормально. Без них нет роста и развития. Так что, ничего не бойтесь! Идите вперед! И добро пожаловать на борт ;)

PS: Благодарю Катю за интервью. И читателей за то, что дочитали до конца.

Подробнее..

Я занялся преподаванием и не бросил работу. Совмещать офигенно

02.11.2020 18:18:10 | Автор: admin


В 11 классе я пошел на курсы для сертификации CISCO. Я, как всегда и везде, был самый молодой в группе. Вокруг сидели дядьки руководители IT-отделов, а мне было 16 лет.

У нас был очень крутой инструктор Сергей Петухов. Мы хорошо с ним общались, и он рассказывал про то, как трудно получить последний уровень ССIE. Его сдают в Брюсселе, в лаборатории. Привозят туда на 8 дней, дают огромный тест на теорию и реальную задачу: Вот железо, настрой вот такую схему, делай, как считаешь правильным.

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

У Сергея был друг, который работал в МТС, и он постоянно говорил: Серега, проблема в том, что ты преподаешь. Ты хорошо знаешь только теорию. Друг был наоборот первоклассным практиком.

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

Но соль в том, что поехать и сдать CCIE не смог ни тот, ни другой.



Вот я и думал, что сочетать невозможно


Когда я занимался сетями, у меня все строилось от практики. Я читал статью про IP-протокол и пытался понять, как это работает но нифига не понимал, зачем мне все это нужно. Потом я начал настраивать маршруты, AP-tables, роутинг, BGP. Набравшись практики, я перечитал статью про IP и вот тут у меня все сошлось.

Все, что было написано в теории, резонировало с практикой. С тех пор я всегда сначала пробовал, потом читал, как это работает.

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

Я вдруг стал и как мой инструктор Сергей, и как его практикующий товарищ. Им обоим не хватало навыков друг друга, а я решил совместить в себе все. Вот только с практикой я был в своей тарелке а преподавание оказалось для меня совершенно неизведанной территорией.

В 2018 году мы начали проводить первые вебинары и постоянно собачились.

Я продалбывал все сроки, потому что очень боялся выступать хотя меня слушали всего 10-15 человек


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

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

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



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

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


И один их первых нафига?

Сейчас у меня каждый день разбит по часам, и я каждый час меняю свою маску. С утра планерка по задачам, потом нужно поработать гендиром, посмотреть договора, подписать бумажки. Потом час побыть девопсом, настроить очередную автоматизацию. Еще час поработать терапевтом и успокоить коллег, потому что там опять что-то упало. Потом час нужно готовиться к вебинару и еще час его проводить. Затем надо побыть методистом и поработать над курсом для корпоративного обучения.

Если бы мне лет пять назад сказали, что мой день будет выглядеть так я бы порядочно насторожился. Как вывезти такой бешеный темп?!

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

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

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

Я пришел к этому неосознанно просто не мог отказать себе в делах, которые мне хотелось делать. У меня было такое, что работа превращалась в постоянную рутину настраиваешь везде одно и то же nginx, куберы и все остальное. А потом вдруг встречаешь маленькую прикольную утилитку или какую-нибудь архитектуру, которая работает идеально. Ее не просто хочется применить про нее сразу хочется всем рассказать. Показать людям, как можно сделать лучше.

То есть, преподавание спасло меня от скуки и рутины. И оно радует меня я рассказываю людям о вещах, которые мне нравятся.



Мои проблемы начались не из-за времени и сил. Беда была в другом:

Основной груз преподавания в ответственности


Я, например, никогда не любил Кубернетес, но мне приходилось проводить по нему вебинары. Он громоздкий, там куча фич, которыми, блин, никто не пользуется. Мне нравятся продукты с четким назначением и мне не нравятся вещи, в которых используют только 20%, а остальные нужны одному человеку раз в сто лет. Для меня это перегруженная система. Чем больше движущихся частей, тем больше может быть ошибок.

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

И тогда я понял я разобрался в Кубере глубже, когда его преподавал, чем когда решал рабочие задачи. В тот момент я вспомнил, как моего инструктора упрекали, что якобы преподаванием он себя закапывает. Так вот.

То, что преподавание тормозит твое развитие как профессионала это полная чушь


Вранье чистой воды.

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

И я начинаю копать эту тему вглубь, разбираться с TLS-протоколом, начинаю понимать, почему делают SSL-терминирование на выделенных узлах. Соответственно, там используется и асимметричное, и симметричное шифрование, Начинаю разбираться, как происходит валидация сертификатов и во многом другом.

То есть, я взял и прокачался просто потому, что готовился к выступлению


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

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

Ну и все пошел, разобрался, провел пару тестов и рассказал. И снова прокачался. Не будь вебинара так бы и не узнал о них никогда.

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

Ты всегда отвечаешь на вопросы и знаешь ответы.

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

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

Больше того когда я начал преподавать, необходимость в собеседованиях просто исчезла. Я не ищу вакансии, они приходят ко мне сами.

Ты, сам того не заметив, становишься известным в профессиональных кругах


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

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



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

Был парень, который три года назад занимался чем-то вроде диджитал-маркетинга, он имел косвенное отношение к айти, но для него все это было в новинку. И вот сейчас он очень мощно изучил Кубер, сдал по нему сертификацию и теперь сдает сертификацию на Google cloud professional architect. Сейчас он работает тимлидом в нашей команде.

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


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

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

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



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

Ну и присоединяйтесь к нашему сообществу в телеге я регулярно делюсь там своим опытом.
Подробнее..

Recovery mode DevOps amp SRE Hiring Day оффер в DINS за один день

19.11.2020 12:06:35 | Автор: admin
image

Привет, Хабр! 11 декабря мы проводим Hiring Day это возможность для DevOps и SR-инженеров получить предложение о работе всего за один день. Ищем коллег, которые будут вместе с нами работать над UCaaS-платформой для бизнес-коммуникаций. В проекте вас ждет сложная архитектура, современные технологии, международная команда профессионалов.


Читайте подробности под катом и присоединяйтесь!


Что делаем в DINS


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


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


Кого ищем


  • DevOps-инженеров (Middle/Senior): вам предстоит активно участвовать в проекте на этапах проектирования, разработки, тестирования, деплоймента и сопровождения.
  • Site Reliability Engineer (Middle/Senior): вы будете участвовать в разработке архитектуры продукта с упором на высокую доступность и масштабируемость, готовить компоненты и сервисы к продакшну и отвечать за их стабильную работу в AWS и приватном облаке.

Узнать подробнее о ключевых навыках, задачах, стеке и откликнуться здесь.


Зачем участвовать в Hiring Day


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


Вот еще несколько причин присоединиться к команде:


  • Сейчас работаем удаленно, но в Петербурге у нас два офиса, и новым коллегам поможем переехать: выделим Relocation Bonus, подскажем, как найти жилье.
  • Сотрудникам оформляется ДМС со стоматологией, полагаются ежегодные премии и индексация зарплаты.
  • У нас много возможностей для обучения: курсы английского языка, внутренние и внешние тренинги по soft и hard skills.
  • Несмотря на удаленку скучать не приходится: ходим на онлайн-конференции, проводим регулярные корпоративы, делаем квартирники, играем в онлайн-квесты.

Как устроен Hiring Day


  1. Отправьте заявку на сайте мероприятия, и в течении трех рабочих дней координатор свяжется с вами, чтобы назначить дату собеседования.
  2. Подключитесь к онлайн-собеседованиями с нашей командой. Они пройдут 11 декабря и займут до 3-х часов.
  3. В конце дня мы дадим обратную связь или сделаем оффер.

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

Подробнее..

Я бросил свой бизнес и стал разработчиком в 43 года

06.07.2020 12:10:38 | Автор: admin
Интернет пестрит захватывающими историями о людях, которые бросили наёмную работу ради собственного бизнеса. У Сергея Парахина, разработчика из московского офиса EPAM, ситуация другая. Он больше 20 лет развивал свой собственный бизнес, который всегда был связан с IT. По иронии судьбы именно стремительное развитие информационных технологий в корне изменило его компанию, и бизнес всё дальше уходил от IT-сферы. Это побудило Сергея задуматься о смене профессии, и он решил стать разработчиком.

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



Как я решился уйти из собственного бизнеса в разработку


Я закончил институт по специальности Информационные системы и сети и следующие 20 лет вместе с партнёром развивал собственный бизнес по поставке и обслуживанию справочно-правовых систем. Разработчиков как таковых у нас не было, но была своя техническая поддержка, которая устанавливала клиентам справочно-правовые базы и устраняла неполадки в их работе. Я занимался всем от набора новых сотрудников до взаимодействия с поставщиками и клиентами. За эти 20 лет я накопил очень большой технический кругозор: начинал работать ещё во времена MS-DOS, дискет и первых версий Windows. Многое понимал и знал из IT-области, но каких-то системных и глубоких знаний для того, чтобы зарабатывать именно программированием, тогда у меня ещё не было.

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

Нужно было думать, чем заниматься дальше. Мне хотелось что-то делать руками, работать самостоятельно и не зависеть от посторонних людей. У многих ошибочное представление, что бизнесмен ни от кого не зависит, но это не так. Ты зависим от своих сотрудников, клиентов, партнёров, поставщиков, государства и ещё десятка других факторов. Программирование так или иначе сопровождало меня всю жизнь, и я начал думать в сторону этой области. На рынке достаточно большой спрос на разработчиков, и я понял, что могу вскочить на IT-поезд и чего-то достичь, даже если мне за 40. У меня были перед глазами примеры: несколько моих 33-35-летних знакомых в своё время закончили в Иннополисе курсы по Java. Сейчас все они опытные разработчики и успешно работают в IT. Мне захотелось повторить их путь. Ведь раз они смогли сменить профессию, то же самое было под силу и мне. Меня ещё сильно мотивировали и подстёгивали истории успеха на JavaRush. Я мечтал, что когда-нибудь смогу написать про собственный удачный опыт, а теперь вот рассказываю вам о своём пути.

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

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

Бывший партнёр по бизнесу сомневался во всей этой затее и говорил, что молодые разработчики задавят меня и вообще уже поздно так кардинально менять жизнь. Но я его особо не слушал. Нужно думать не Мне уже 40, а Мне только 40. Впереди минимум 20-30 лет активной жизни, поэтому я не рассуждал, где нахожусь сейчас, а думал о том, где буду через несколько лет.

Для меня самым главным было то, что семья меня полностью поддержала. На тот момент мы жили в Орле, но моя старшая дочь заканчивала 11 класс и хотела поступать в московский вуз. Она активно готовилась к ЕГЭ, участвовала и побеждала на всероссийских олимпиадах и во всевозможных конкурсах. Меня мотивировали её стремление и старания, и я уже просто не мог отступить. К тому же оставшаяся от продажи бизнеса финансовая подушка позволила мне не работать несколько месяцев и посвятить всё время обучению.

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

Как я учился: самостоятельно, с ментором и на курсах


Самостоятельная учёба

Летом 2018 года я начал изучать Java. На тот момент работы как таковой у меня не было я уже передавал дела по бизнесу, и мне удавалось ежедневно посвящать учёбе по 4-8 часов. Начинал с ресурса JavaRush. Решал задачки, смотрел обучающие видео, читал. Самостоятельно дошёл до 20 уровня из 41. Проблем с материалами не было: всегда можно найти что-то полезное в интернете. Не зря же говорят, что главное умение программиста умение гуглить. Учиться самому можно, было бы желание и, самое главное, время.

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

Менторская программа и первые проекты

Вскоре я нашёл проект Java Mentor, и обучение пошло быстрее. Я общался уже не с ботом на сайте, а с живым человеком. Опытные менторы давали обратную связь по выполнению заданий, проводили код-ревью, объясняли ошибки. В феврале я даже побывал на двухнедельном хакатоне Java Bootcamp в Санкт-Петербурге, где наконец-то поработал в команде над небольшим проектом.

После хакатона я прошёл отбор на онлайн-курс по Java EE при Университете Иннополис. Здесь всё было по-серьезному: очень плотный график занятий, ментор из IT-компании, настоящий и большой командный проект (мы разрабатывали аналог виртуальной торговой площадки).

Таким образом, у меня за плечами были уже два проекта. Неважно, что это был не продакшн и за них не платили. В любом случае, это была моя реальная работа. Советую всем новичкам в IT: не пишите в резюме учебный проект, лучше укажите, чем именно вы занимались и каких результатов добились, например, реализовал систему сортировки данных, улучшил производительность системы с 50 до 100 запросов в секунду. Точно так же не стоит оценивать себя как специалиста и указывать в резюме, что вы джун или мидл. Пишите просто: Java-разработчик. Оценят вас уже на собеседовании, которых может быть десяток, и в одной компании дадут джуна, а в другой синьора. Поэтому всегда лучше сосредотачиваться на своих реальных достижениях и результатах.

Первые офферы, переезд в Москву и работа в EPAM


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

Получается, спустя год после того, как я всё бросил и начал изучать Java, я имел на руках три предложения о работе. Меня звали на позицию мидла, но в Иннополисе я работать не хотел это очень далеко от Орла. Но и в моём родном городе не было подходящих вакансий. Встал вопрос о переезде.

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

В офисе в основном работают ребята до 30 лет, и иногда на меня посматривали молодые коллеги, мол, что этот дядя тут делает. К тому же меня не миновал синдром самозванца: я не мог понять, как меня вообще сюда взяли, казалось, я не на своём месте. Потом понял, что всегда, когда приходишь в новую компанию, ещё и на большой проект, первое время чувствуешь себя неловко. И это нормально! Иногда проще спросить и сэкономить время, своё и своей команды, чем сидеть и копаться. Если ты, допустим, за час даже примерно не понял, как выполнить задачу, лучше спроси у коллег. Не бойся выглядеть глупцом, какие бы регалии у тебя не были.

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

Что изменилось после того, как я пришёл в разработку


Один из самых больших плюсов IT для меня возможность удалённой работы. У нас распределённая команда, и мы работали в таком режиме ещё задолго до кризиса. Я могу работать из Орла, Москвы и откуда угодно, лишь бы был интернет и оборудование.

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

Полезные ресурсы для начинающих Java-разработчиков


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

Книги
  • Изучаем Java, Кэти Сьерра и Берт Бейтс книга для совсем новичков не только в Java, но и в программировании в целом.
  • Философия Java, Брюс Эккель.
  • Java. Библиотека профессионала. Том 1 и 2, Кей Хорстманн и Гари Корнелл.
  • Java. Полное руководство, Герберт Шилдт.
  • Java. Руководство для начинающих, Герберт Шилдт.
  • Основы Java, Николай Прохоренок .
  • Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих, Адитья Бхаргава очень хорошая книга для понимания основных алгоритмов.

Видеоресурсы

alishev YouTube-канал с видеуроками.
Бесплатный курс на Stepic по основам web-разработки на Java.
letsCode YouTube-канал.
Лекция Основы разработки на Java.

Автор: Элиза Ильязова
Подробнее..

Из песочницы Как я проработал 4 с лишним года в семье Газпрома, уволился и выращиваю помидоры

20.07.2020 02:22:36 | Автор: admin
Чувак: Что писать?
НЛО: А что ты хочешь?
Чувак: Попрактиковаться в русском, проверить не вмерло ли чувство юмора, да чтоб молодёжь (рус. джуны) поучилась на чужих ошибках.
НЛО: Так и пиши

Update: НЛО вынудило автора выкинуть весь syntactic sugar из статьи, хотя он был изменён до неузнаваемости буквой @. Афтор от шока сначала хотел выпить йаду, но потом передумал кто ж за помидорами да перцем ухаживать будет!? Он просто заменил syntactic sugar тэгами [ОПС] очень плохое слово а потом понял что и это запрещено. О дивный новый мир! В итоге получилась статья без эмоций. Не обессудьте. Хоть и скучная, но зато политкорректная.

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

А как и почему вы решили стать фронтенд-разработчиком? Что в профессии хорошо, а что нет? Рассказывайте в комментариях, поможем тем, кто стоит на распутье написали относительно недавно ru_vds в самом конце статьи, а жирным выделил я.

Прочтя поможем, без всяких задних мыслей сразу вспомнился человек который всем помогал, из Моря исчезающих времён от Маркеса, Габриеляна Гарсиевича.

Из Моря исчезающих времён
Он не пошёл спать. Он появился в лавке Катарино, в сопровождении мужчин, которые несли его баулы, а за ним всё шли толпой люди со своими проблемами. Он решал их одну за другой, и решил столько, что в конце концов остались только женщины и несколько мужчин, чьи проблемы были уже решены. В глубине комнаты одинокая женщина неторопливо обмахивалась какой-то рекламной афишкой, словно веером.
А ты, крикнул ей сеньор Герберт, у тебя что за проблема?
Женщина перестала обмахиваться.
Я вашего праздника не касаюсь, мистер, крикнула она через всю комнату. Нет у меня никаких проблем, я проститутка, так уж у меня устроено нутро.

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


Чуть раньше, прочитав как и почему, вспомнилась занимательная история о том, как обстоятельства заставили сменить профессию. Бывает что авторы на Хабре жалуются на неправильных работодателей, а я им благодарен. Спасибо за то, что вы были неправильные. За то, что заставили двигаться вперёд и искать новые горизонты. Как говорится во всем нам известной басне не каждый, кто на вас нагадил ваш враг.

Всем нам известная басня
Маленькая птичка не успела улететь в тёплые края в начале зимы. Было холодно, птичка замёрзла и упала на поле. Мимо шла корова, и коровья лепёшка попала прямо на птичку. Птичке стало тепло, она отогрелась и на радостях запела. Мимо шёл кот, услышал пение птички, раскопал коровью лепёшку, достал оттуда птичку и съел.
Мораль:
1. Не каждый, кто выливает на вас дерьмо ваш враг.
2. Не каждый, кто достаёт вас из дерьма ваш друг.
3. Если сидишь в дерьме, держи рот закрытым.

/* С третьим пунктом категорически не согласен. Ведь не может же благородный дон молчать ни при каких обстоятельствах! */

Хабр вам, люди добрые! Да и прочим не хворать


Жил да был на белом свете богатырь Газпром (в дальнейшем Богатырь). Да и до сих пор живёт и здравствует. И была у Богатыря, да и до сих пор есть, дочка красавица, отличница, комсомолка и вот тут остановимся на секунду. Я не знаю на что соглашался подписывая БНДШ договор (в просторечии NDA). Я его просто не читал. Тупо подписал. А потом и вообще выкинул. По этому впредь не буду указывать настоящие названия, не дай бог какие-то ФИО и тому подобное.

Так что и была у Богатыря дочка (в дальнейшем Дочка). Поехала как-то Дочка за тридевять земель, в тридесятое царство. Чем она там занималась я не знаю, свечку не держал. Своими глазами не видел, а выдумывать не буду. Как бы там ни было, у неё появился младенец (в дальнейшем Внучка). И решили Богатырь с Дочкой, Внучку в люди вывести.

Тем же временем за тридевять земель, в тридесятом царстве, жил да поживал, да и до сих пор здравствует, обыкновенный сисадмин (sysadminus primitivus), в дальнейшем Чувак. Может не грамотно, зато коротко (по крайней мере короче чем Абдумухаммадалибекжон Всеволодович Константинопольский). И, познакомился как-то Чувак случайно с очередной красоткой. Когда красотка попросила номер телефона для организации дальнейшего углубления межполовых культурных связей, Чувак ей тупо протянул визитку ибо только что расплатился в кафе и кошелёк, в т.ч. с визитками, был под рукой.

О-го-го, улыбнулась красотка посмотрев на визитку, да ты же у нас настоящий ИТ-менеджер!
И тут наступило затмение разума у Чувака, и решил он провести ликбез безалаберной молодёжи.
Да какой я нахрен ИТ-менеджер? Какой нахрен менеджер если у меня нету своей команды? Менеджер это тот, который организует работу, а я, а я один единственный из двенадцати сотрудников нашей компании умеющий отличить розетку 230 В от USB порта!
Но ведь написано ИТ-менеджер.
Солнышко ты моё, проходила бабушка мимо забора..., написать можно что угодно!
А зачем?
Ё моё!

Про бабушку, про забор, про икс, игрек и комплексное сопряжение
Проходила бабуля мимо забора, а на заборе слово из трёх букв на букву Ха написано было. Бабуля заглянула в щёлку а там дрова лежат.
Как же после такого верить написанному!?

Изначальный уговор с владельцем компании был прост и разумен. Сфера ответственности: канал связи, локальная сеть, сервера, VoIP, обучение персонала по работе с десктопной Убунту. И всё! Обыкновенный сисадмин. Однако. Компания была компактная, все общались между собой на перекурах, на обеденном перерыве, после работы, и очень скоро знали друг о друге почти всё. Кое что из этой информации просачивалось к владельцу и он не преминул воспользоваться этим.

Слышь, ребята говорят что у тебя неплохой опыт работы в препрессе, что занимался этим раньше, а ты не мог бы нам сделать новогодние открытки, календари и рекламные проспекты?
Конечно (ошибка номер 1).

Слышь, а ребята говорят что ты сделал несколько веб сайтов, ты не мог бы сделать сайт для моей другой фирмы?
Сделаю (ошибка номер 2).

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

После всех этих слышь Чувак решил поговорить с ним о зарплате. Ведь договаривались об одном а получилось чёрт-те чё. Бестолку. Кризис нету свободных средств ну, ты держись.... Дней через десять получил новые визитки, сисадмин стал ИТ-менеджером. Ну, наверное хасяина думал что Чувак в магазине расплачивается визитными карточками, а не кредитной.

После проведения ликбеза, по дороге домой вспомнились стихи великаго российскаго поэта Шнурова С. В. из его поэмы В Питере пить (по крайней мере из клипа) А не пошло бы всё оно!?. На следующий день Чувак сделал то, что настоятельно не рекомендовал делать своим друзьям и знакомым. Уволился до того как нашёл позицию получше.

Чувак ищет работу


Ищем работу? Готовим резюме, сидим в интернете, ищем вакансии, отправляем резюме десятки раз и надеемся, и надеемся. Чувак решил сделать по другому. Сначала выяснить где хочу работать, а потом попытаться устроится именно в эту компанию. Две недели ушло на исследование. Ничего из этой затеи скорее всего не вышло бы, если бы Чувак не наткнулся случайно на информацию о том, что Дочка только что стартовала большой проект (в дальнейшем Проект) тут неподалёку.

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

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

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

Закончил, написал в сообщении сопроводиловку, сказал себе Ни пуха ни пера и отправил. К чёрту! И вы знаете, ему позвонили. Чувака пригласили на собеседование.

Чувак на собеседовании


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

Собеседование проводил лично директор Проекта (в дальнейшем ДП). Нормальный (судя по физиономии, речи и поведению) человек. Фишка была в том, что у Чувака не было ни малейшего представления о том, о какой именно позиции идёт речь. Он только надеялся что ДП прочитал его резюме и что не предложит ему сейчас позицию повара.

Вы говорите по-...?
Вроде бы говорю. И не только по- Владею и языком Заказчика, и языком Подрядчика, и местным наречием.
А на стройке работали когда либо?
Месяц назад организовал тендер, лифты закупал, через день бегал на стройплощадку у бывшего работодателя.
А как на счёт вычислительной техники? Вы себя считаете продвинутым пользователем?
Никак нет! Пользователем себя не считаю, но раз мне выдали сертификат системного администратора Линукс, то кое что в компьютерах и сетях понимаю /* да и в резюме всё */.
Вы знаете, у нас беда с документ контролем. Самый загруженный отдел. Набирали сотрудников вроде бы владеющих всеми тремя языками, а потом оказывалось что они и в языках не очень, да и в компьютерах ничего не смыслят. Вы бы взялись за такое?
Давайте попробую ответил Чувак, всё ещё не понимая что это такое документ контроль, сроду такого не слыхал.

Зазеркалье


Твою ж дивизию, такую-сякую, быть такого не может, мама роди меня обратно! Я вам расскажу, а вы не поверите. Не может такого быть, потому что быть такого не может. Но было.

Участники Проекта самые известные в своей отрасли мировые корпорации (рус. энтерпрайзы). Круче них только горы, варёные яйца, да ВДВ. Учитывая эти факты Чувак ожидал что попадёт в какой-то аналог ЦУП-а. Ну хорошо, может не в ЦУП, но всё-таки ожидал по крайней мере крутейшее железо и хитрейший софт.

image

Ничего подобного. Офисная мебель помнившая аварию на Чернобыльской АЭС, такой себе компьютер на порядок порядков слабее домашнего. Из софта Майкрософт Офис, и всего две полезные вещи: ABBYY FineReader и Adobe Acrobat. Надо отдать должное ДП, его задумка была в высшей степени разумна, проблема заключалась в том, что эту задумку было выполнять некому и не с чем.

/* драматическая пауза покурить можно */

В одной из статей более-чем-тыщустраничного договора указывалось что ответы на все вопросы Стороны должны отправлять в течение не более пяти рабочих дней. Проморгаешь это, проморгаешь то, и вот тебе заявка на продление срока и доп. оплату (миллионы летят в небо). А тебе это нужно? Нэт, нэ нада! Спасыба!

ДП прекрасно понимал что для полного контроля процесса необходимо полностью контролировать всю информацию (чтобы всё отыскать, воедино созвать, и единою проектною целью сковать). Вот он и решил создать документ-контроль (в дальнейшем ДК) через который в обязательном порядке проходит вся информация, в т. ч. вся переписка проектного офиса (в дальнейшем ПО). Входящая и исходящая. Сотрудники не имеют права общаться напрямую с партнёрами, партнёры не имеют права напрямую писать сотрудникам ПО. ДК отвечает за сохранение и поиск всех документов (технических, правовых, отдела закупок, всех!). ДК контролирует все задачи сотрудников ПО что на ком висит и когда надо ответить. Полный контроль всей информации! И с чем прикажете всё это контролировать? Да у вас есть Майкрософт Офис.

/* драматическая пауза 50 грамм принять можно */

Вот и получилась такая система: получаешь сообщение, регистрируешь (copy/paste; copy/paste; copy/paste...) в реестре (Excel), сохраняешь приложения в общую папку ПО на корпоративном сервере (щёлк-щёлк, щёлк-щёлк, щёлк-щёлк, щёлк-щёлк, щёлк-щёлк, щёлк-щёлк, щёлк-щёлк, щёлк-щёлк, Save), копируешь ссылку (ссылки) и вставляешь в реестр, устанавливаешь счётчик 5 дней, пересылаешь кому надо, добавляешь в реестр на ком висит.

Реестры получились размером с простыню огромной кровати. С тех пор Чувак возненавидел прокрутку на которую уходило полдня. Даже начал ругаться вот так: Шоб те scroll! и даже Scroll твою мать!. Слегка реже Шоб те щёлк-щёлк! и даже Щёлк-щёлк твою мать!.

Позже, по этой причине, он вступил в секту SPA. Минимум движений максимум результата.

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

В среднем по 300 сообщений в день. В самом начале Проекта бывало всего по 50, но зато в самых загруженных месяцах, в месяцах пик, ежедневно обрабатывали почти по 500 сообщений. Если на обработку одного сообщения уходило всего 2 минуты (прочитать, понять смысл, зарегистрировать, переслать кому надо...), сколько же это рабочих часов уходило в день?

Ко всему этому надо добавить просиживание на утренней планёрке, отсканируй чертёж пожалуйста, распечатай на плоттере пожалуйста, отредактируй этот PDF чтобы коммерческая информация не была видна, инженерам надо переслать на согласование, сделай OCR, и т. д. Вот и считайте.

Не странно что сотрудники ДК (и тот, и другой) одичали, и что после работы мчались в ближайшее кафе напиваться пивом до отключки. Первым сгорел руководитель ДК. Не прошло и 5-и месяцев с тех пор как Чувак попал на Проект, как руководитель уволился. С улыбкой. С меня хватит!, и отчалил в Среднюю Азию, на другой проект, зарплата побольше, геморроя поменьше.

Хороший человек. Все свои запасы воблы, непосильным трудом переправленной из Астрахани, перед отъездом оставил Чуваку. Спасибо брат! Век не забуду!

Чувак понадеялся что сейчас ему предложат позицию руководителя ДК, однако, в корпорациях так просто не бывает. У кого-то из нужных людей был знакомый с опытом работы в документ контроле крупной американской корпорации. Новый руководитель отличался от старого тем что в два раза труднее переносил нагрузку, наверное потому что в два раза меньше бухал. Всего-то он выдержал 3 месяца на Проекте. Послал всех подальше и улетел на Балтику. А жаль, нормальный человек, работяга

/* последняя драматическая пауза */

Вот и предложили позицию руководителя Чуваку, и разрешили ему принять двух сотрудников к себе в ДК (хоть он и просил пятерых). И стал Чувак думать что делать чтобы с ума не сойти, никого никуда не посылать, зарплату задержать? Ведь зарплата была по местным меркам сверхприличная, выше официальной зарплаты президента страны.

Налаживание отношений с корпоративными айтишниками


Первым делом налаживание отношений! Ну а самолёты и девушки потом.

Привет, нас часто просят отредактировать PDF файлы. Что-то убрать или добавить, а в них сплошной скан. Нам бы Gimp. Программа опенсорсная, т.е. бесплатная. Сделаете?
У нас не положено. Нету такой программы в перечне разрешённых программ.
Ну хорошо, попрошу ДП зайти к вам
Нет! Не надо! Он злой. Всё сделаем!

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

Привет
Да отвяжись ты, ради бога! Вот те админский пароль и делай у вас в ПО чё хочешь!
/* Вот, что крест животворящий вежливая настойчивость делает! */

Всё прекраснее и прекраснее! Уже есть Gimp, Inkscape, LibreOffice, Apache Tika, Audacity. Уже ежедневно под рукой свой ноутбук на котором можно запустить sed, grep и т.д. Ребята, будем жить!

Поиск выхода из положения


Жить хорошо, а хорошо жить ещё лучше. Слава богу отношения уже были налажены, и Чувак обратился за советом к корпоративным айтишникам. Им же виднее чего в корпорации есть/нет, что возможно/невозможно. Обрисовал им проблему и попросил намёка. Никакого намёка не получил. Ему только показали такое диво заморское под названием SharePoint, и с улыбкой стали рассказывать о том как в этом чуде-диве несколько сотрудников могут одновременно редактировать один и тот-же документ. Одновременно редактировать, Карл!

Чувак представил себе как ДП строчит серьёзнейшее письмо Генподрядчику, и вдруг зрит как предыдущий его абзац исчезает. Он представил себе грозный вопль с явно матерным уклоном на весь ПО, он представил себе гору трупов сотрудников у парадной ПО. От греха подальше, Чувак поблагодарил айтишников за помощь и ушёл.

Звонок коллегам из Сибири. В их документ контроль. Тоже внучка Богатыря.
Привет! Подскажи пожалуйста чем вы пользуетесь для организации и поиска документов?
Летописью (название изменено в связи с БНДШ договором).
И сколько оно стоит?
млн долл. США.
Ну и как? Реально ускоряет работу?
Да как тебе сказать, вот уже третий год внедряют а оно всё ещё барахлит.

Не вариант. Даже если позволят потратить млн. долл., то три года уж точно нету на внедрение. Через три года Проект должен закончится.

Следующая попытка подобрать опенсорсные решения для ускорения и упрощения работы. Не получилось. Ведь у этих, таких-сяких программистов, под словом Проект подразумевается в основном разработка софта, а на Проекте Проект и есть Проект. Заказчик, подрядчики, тонны документации, разрешения, огромный объём переписки, соблюдение сроков У Чувака была мысль подобрать какое-то опенсорсное решение, исследовать как там оно внутри устроено и затем переделать его под нужды ДК, однако, отправляться в дальнюю дорогу на чужой тачке не вариант. Чёрт знает что в ней может сломаться через месяц или полгода, и возможно ли будет такое починить.

Вывод напросился сам собой. Если спина у тебя чешется, то никто кроме тебя самого не сможет почесать её именно там где надо. Тебе нужен софт? Так сам его и пиши. Другого выхода просто нет!

Ночной дозор / Дневной дозор


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

Днём пашешь как лошадь разгребаешь текучку. Ночью пашешь как лошадь создаёшь прогу.

image

Чувак до сих пор с улыбкой вспоминает те времена. Единственный случай когда ТЗ было чёткое. Когда перед глазами была ясная картина что и как надо делать. Было, да сплыло. А сейчас Вот нам бы такое, но мы не уверены, ты сделай а мы потом скажем что надо переделать, а то, что делал последний месяц выкинь, всё-таки это не нужно, а то, что два месяца назад выкинул, верни....

Гуглил днями напролёт. В итоге остановился на а: jQuery, DataTables, css. б: LAMP, Bash, Gammu.

Силу давали хорошие отзывы своих ребят и коллег. Ребята с первого дня в ДК были обучены говорить то, что думают. В т. ч. посылать Чувака подальше когда сочтут необходимым. Прога на самом деле, с первого модуля, оказалась полезной вещью.

Озарение


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

Народ в ПО был среднестатистический, обычный, трепались обо всём как и все. Вскоре все сотрудники знали что он родственник аднаго очэн уважаемого чэловека из высших эшелонов власти. Корпоративных вроде бы. Приехал на Проект бабло колотить. Ему позволено делать что хочет, в т. ч. не делать ничего.

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

На следующий день Чувака опять пригласили в кабинет чтобы сообщить пренеприятнейшую новость. Я договорился с ДП что буду курировать ДК. На утренние планёрки больше не будешь ходить /* ур-р-р-р-аааа! */. С ДП больше не будешь общаться, только через меня, все вопросы, предложения, идеи только ко мне. И продолжил:

Ты знаешь что для нас самое главное?
Как что!? Мы же работаем на Проекте! График производства работ и бюджет.
Ну да, да, это само собой, но не это я имел в виду для нас самое главное чтобы ни один вопрос на нас не висел. Как только появляется проблема, тут же её перекидывать дальше. В Cost Control, в отдел закупок, ISBL менеджеру, директору проекта, да кому угодно. Понятно? спросил он с хитрющей улыбкой.
Да ответил Чувак, вспомнив почему-то Поделись улыбкою своей, И она к тебе не раз ещё вернётся... Михаил Пляцковский.

Ему и на самом деле всё было понятно. Халявщик. Искал где бы на халяву поживиться. Узнал что разрабатываем крутую весчь и решил стать руководителем руководителя подразделения которое решает проблемы. Премию унюхал наверное.

Возвращался Чувак из кабинета к себе с широчайшей улыбкой на морде, напевая Ну, что ж, пам-пам-парам со всеми вами! Эх, мать прыжок и полетел куда-то вниз, но вот за что-то зацепился и повис Меееееж ваааа-луууууу-нами облаков пополз, глядите, змей [ БНДШ...], и скрылся где-то глубоко под небесами ДДТ.

Что с ним произошло? Мазохист что ли? Почему улыбается? Почему напевает? Дело в том, что на Чувака во время этой короткой беседы снизошло прозрение. Раз опытный халявщик молниеносно произвёл рейдерский захват ДК, то он однозначно увидел какую-то ценность в нём. Ш-што с-сие такое увидел, с-сокровище моё, а? Мою прелесть, сокровище моё? Чувак решил что ни за что не отдаст свою прогу всевластия задарма, тем более в его руки.

А ведь всего 15 минут назад и мысли такой не было. Была проблема. Большая проблема. Проблему начал решать. Решал её что бы облегчить жизнь (работу) себе, своим ребятам, своим коллегам. И тут, вот тебе у тебя пытаются отнять то, что ты разрабатываешь в свободное от работы время. Никакого программирования в должностной инструкции нет. Никаких указаний разрабатывать от руководства не было.

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

Как же эта мысль была наивна!

Скука


Скука не в том смысле что ничего не происходило, а в том смысле что каждый день был как понедельник. После работы разработка проги, усваивание чужого опыта на StackOverflow, чтение DataTables API, php.net, и пиши, пиши, и так до отключки. А утром, а утром: а-а-а-апять-апаздываю!!! Душ, зубы, шмотки, с лестницы кувырком, со седьмого этажа, тачка, превышение скорости, стройплощадка, коллега на парковке говорит Я бы так не посмел, нехороший ты человек! Дурак! ТАК испугал когда обгонял на дороге! Рассказываешь своим ребятам чего сегодня нового в проге, что надо протестировать, проверить, здравствуй новый день! Здравствуй новый понедельник!

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

Надо уйти отсюда! Закончить разработку проги до конца, и попытаться её продать кому-то. Вещь же хорошая, отзывы пользователей более чем положительные. С корпорацией вряд ли получится о чём-либо договориться. Да и с кем разговаривать? Между Чуваком и ДП сидит змей посредник, непосредственный руководитель. Обходить руководителей и обращаться напрямую к высшесидящим как-то некультурно. Некрасиво. Благородные доны так не делают. А змей у Чувака на blacklist denylist с первой улыбки, любой разговор с ним даже обсуждению не подлежит.

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

Ну а чё деньги? В чём сила брат? Сила в здоровье! Нахрен все эти деньги если всё до последней копейки придётся отдать врачам, клиникам. Стресс тут зашкаливает. Последствия уже чувствуются.

И хочется, и колется, и мамка не велит твою же мать!

Раздорожье


Проект готов. Закончен. Очередная, их меняли чаще чем они меняли трусики, эйджа (рус. HR manager) пригласила.
Мы вам зарплату временно снизим на 1 шт. евро. Но это временно, до начала следующего проекта, а там договоримся.
Чувак подвоха не увидел, не узрел. Если честно, он бы розового бронтозавра размером с Москва Сити, в кружевных трусиках, с айфоном (размером с КрАЗ) в левой лапе, на пешеходном переходе не узрел проехал бы под хвостом чудища. Состояние такое. Перегрузка, переутомление, называется. Всё тупо подписал.

Потом ещё ухитрился в отпуск свалить. Байдарку в тачку да на море, на остров посреди моря.

image

Нет, не отдохнул. Сколько бы ни старался вести себя нормально, не получалось. Всё время тянуло побольше пива прикупить и, сидя вечерком на террасе с прекраснейшим видом на море и соседний остров, вести в собственной башке холивары на тему переговоры по следующему Проекту: Если они предложат это, то тогда...., Когда они скажут ..., то надо ответить ..., и т.д. и т.п. При всём этом, он прекрасно понимал бессмысленность всех этих селфи-холиваров но ничего не смог поделать. Башка извергала все эти глупости в автоматическом, подсознательном режиме. Оставалось только гасить эти потоки лавы потоками пива, грести и плавать с утра до вечера, до изнеможения, пока вся дурь из башки не выйдет

И вот наступил день, тот день. Предложили новый контракт, на новый проект. Бери или уходи. Зарплата та-же. Я не знаю что вам моя предшественница наобещала, меня это не касается. В должностной инструкции твоя же прога. За просто так. Любой бы согласился работать на нас, даже за вдвое меньшую зарплату. Вы знаете сколько у нас в стране безработных?. Нет, не послал. Чувак всегда чуждался агрессии, крика да шума, громких слов, угроз, тем более просьб. Или получается с кем-то поладить (женщина, рабовладелец работодатель, друзья, соседи, родня) или нет. Так что он просто отказался подписывать предложенный договор. Разошлись тихо и спокойно.

Как говорится, что Макаронный Монстр не делает всё к лучшему!

Следующих полтора года


Следующих полтора года пролетело быстро и интересно. Чувак работал над последней необходимой составляющей клиентом эл. почты. Главная фишка была в том, что этот клиент должен был быть интегрирован (рус. объединён) с остатком проги. Чтобы вместо щёлк-щёлк, щёлк-щёлк... было зарегистрировать договор, зарегистрировать чертёж, назначить задачу, прямо из сообщения. Плюс крутейший поиск, да неограниченный объём ящика. Всего 6-8 месяцев и закончил. Потом очень долго доводил до ума всякие детали. Всякие мелочи.

Всё! Прога есть. Проверенная (большей частью) в бою. Крутая прекрутая, IMHO. Что дальше делать?

Чувак прекрасно осознавал окружающий мир и свою позицию в нём. Я никто. Со мной и разговаривать не будут. А надо было придумать как предлагать прогу. Четыре пи шлюхи маркетинга. Product, price, place, promotion.

Целевая группа ПАО, ОАО, да любой гос. или частный монстр стартующий проекты стоимостью в сотни млн. долл/евр. Те, которые могут попасть на деньги. На десятки миллионов. Что им стоить отвалить лимон чтобы сохранить двадцать, или десять, или пять миллионов!? Но как к ним подобраться?

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

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

Связывался, предлагал, они соглашались, одним словом два слова: везение и счастье.

Никаких слайдов не готовил. Купил новый крутой ноутбук (чтоб красиво смотрелось), брал с собой свой сервер, да Wi-Fi роутер со старым 3G модемом чтобы в чужую сеть не лазить. Только проекторами пользовался ихними. Один только раз попался на 800 х 600. Приходил, подключал, две минуты вступление о чём дальше речь пойдёт, и уже показывал прогу.

Первая презентация прошла на ура. Никто из присутствующих не заснул. 10 15 минут длилась, а потом ещё минут двадцать отвечал на вопросы. То же самое и на второй, и на третьей, четвёртой, пятой Технари балдели от сервера. Старенького ЕЕЕ первой серии, 1 Гб памяти, ноль дисков. Весь бэкэнд (LAMP) жил да поживал на SD-карте. И работал. Быстро. Присутствующим интересно, они задают вопросы, одобряют, просят показать то или сё, говорят крутая вещь и всё. После презентаций никто не звонит, никто не обращается. В чём же дело!?

Я тебе умный вещь скажу, но только ты не обижайся Мимино


После очередной презентации, после вопросов и ответов, совладелец компании, инженер, айтишник, говорит Прога у тебя получилась очень интересная, и ты прав такое может сэкономить кучу денег, но ты это никому не продашь. Ты просто не понимаешь с кем имеешь дело. Твоя целевая группа покупает не то, что полезно, твоя целевая группа покупает то, что сверху приказывают купить. Даже если тебе попадётся толковый ИТ-директор который может без приказа сверху самостоятельно принять решение, даже он такое не возьмёт. Никого ещё не увольняли за покупку Майкрософт софта, несмотря на У них же ПУО (Противоувольнительная Оборона комплекс мер по обеспечению защиты (обороны) от увольнения или сокращения) так настроена, что покупают то, что покупают все. Пусть это стоит миллионы, пусть барахлит, пусть пользователи жалуются, главное за такую покупку не уволят.

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

Поехали Юрий Алексеевич


Ну, а потом всё потихоньку поехало. Привет, у нашего клиента пять фармскладов в разных городах, да ещё офисное здание. Закупили на тендере самую дешёвую систему контроля доступа и сейчас мучатся с ней. Персонал отмечается как положено, но доступ к этой информации только на сервере в городе n. Надо каждый раз звонить туда в службу охраны (сообщения игнорируют), диктовать им ФИО сотрудников, потом ждать пока пришлют отсканированную распечатку. Ты бы мог сделать веб приложение чтобы с любого компьютера компании можно было получить отчёт, желательно в Екселе? Да? Вот и прекрасно.

Контроль доступа одним, контроль рабочих заданий на заводе другим, приложение для разработки технологий производства, система управления частной клиникой (из Perl сделать react), и прочая, и прочая.

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

Чувак стал крутым программистом? Да нет, такой себе, средненький. Но даже такие могут найти клиентов. Жадных Экономных клиентов пруд пруди. Когда делаешь всё сам (фронтэнд, бэкэнд, CSS, администрирование сервера), то можешь предложить более низкую цену чем другие.

А ведь всё могло быть иначе


Если бы Чувак побоялся уволится из слышь компании. Если бы не решился напрямую писать туда, где открытых вакансий не было. Если бы работа на Проекте была налажена. Если бы корпоративные айтишники взялись решить проблему крупнейшего корпоративного проекта. Если бы не посмел сунуться в программирование. Если бы не решился уволится из корпорации. Если бы сдался когда ему сказано что перспектив нет. Если бы не сделал за копейки приложение для фармкомпании, то не имел бы дело с XML. Не умел бы работать с XML не заполучил бы клиента из Канады (у него все данные в eXist-db). Не договорился бы с канадцами, не имел бы дело с XQuery и React. И прочая, и прочая, и прочая. Эффект бабочки, твою же мать!

Везёт же дуракам иногда.

Выбери свою судьбу. Не каждому суждено умереть на работе Особо опасен

Эпилог


Бывает такое, кажется не так уж редко. Чувак это понял уже после Я тебе умный вещь скажу. Когда прочитал на Хабре что отдала концы RethinkDB, СУБД которую он очень уважал и намеревался использовать. 10 лет разработки, или сколько там, коту под хвост. Очень жаль. А Mongo жив им все пользуются.

Потом ещё один заказчик рассказал про своего бывшего партнёра. Парень разработал софт для, извините за медицинскую неграмотность, ну, магнит, т.е. МРТ щёлкает некий сосуд, а эта прога считает пропускную способность. т.е. сколько крови протекает этим сосудом. Парень взял кредит, большие деньги, на расходы по получению лицензии FDA. Он был на 100% уверен что его прога весчь. И он был прав, но его угробила та же ПУО его целевая группа по прежнему закупает значительно медленнее, значительно дороже, и значительно менее точные проги одной немецкой и одной американской корпораций, потому что так делают все.

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

Мир так устроен и никуда не денешься. Не забывайте о ПУО!

А рассказы про то как толковый чувак покинул институт, и в гараже Не смешите мои подковы!

image

/* Спасибо translit.net за возможность проверки орфографии, несмотря на то что их проверка не распознаёт некоторые исконно русские слова: прога, [ОПС], [ОПС], [ОПС], сцуко, джун, энтерпрайз, [ОПС], ЦУП, гуглил, [ОПС], весчь, ЗОЖ, хасяина, [ОПС], [ОПС], и т. д. */
Подробнее..

Что нужно знать начинающим специалистам о процессе найма перед собеседованием? 12 вопросов рекрутерам

01.11.2020 16:04:58 | Автор: admin

Нас часто спрашивают, берём ли мыjunior-специалистов в командуEPAM, какими знаниями нужно для этого обладать, как проходит отбор и многое другое.Не секрет, что наша компания проводит бесплатное обучение специалистов в тренинг-центре, лучшим студентам по итогам тренинга предлагается пройти собеседование на проект.Сейчас в компании проводится подготовка по 14 программамв 11 городах, каждый год тренинг-центр обучает более 600 студентов,и 60%студентов трудоустраиваются в компанию по итогам тренингов.Мы собрали ответы рекрутеров на вопросы, которые помогут лучше понять процесс отбора и наймаjunior-специалистов.

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

1.Как вы оцениваете уровень кандидатов на первом этапе (тестовые задания, собеседования)? По каким критериям вы отбираете релевантных кандидатов?

НинаСказобова,LeadResourceDevelopmentLabHeadНинаСказобова,LeadResourceDevelopmentLabHead

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

2. Джуновотбирают опытные разработчики или рекрутеры?

Мария Выгузова, Resource Development AdministratorМария Выгузова, Resource Development Administrator

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

НинаСказобова, Lead Resource Development Lab Head:

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

3. Какими минимальными знаниями должны обладать джуны?

МарияВыгузова, Resource Development Administrator:

Всё зависит от направления и языка программирования. Еслибрать общие требования, тоджуниорыдолжны знать как минимум принципы ООП, один из языковпрограммированияна уровнеAdvanced, один из фреймворков, уровень английского должен быть не ниже A2+.

4. Что вы можете сказать о среднем уровнеджуниоров, которые приходят на собеседования?

НинаСказобова, Lead Resource Development Lab Head:

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

АлександраЗайцева,Front-endDeveloperАлександраЗайцева,Front-endDeveloper

Я прошла весь путь: от внешнего тренинга поFront-endдо обучения во внутренней лаборатории. <>. Во внутренней лаборатории нас погрузили в реальную жизнь. Здесь уже была немного другая атмосфера, более серьезная, мы начали изучение новых инструментов и фреймворков. Работали со сборщиками иtask-runner, учились писать юнит-тесты ипростенькиесервера на Node.js. После этого мы начали погружаться в изучение фреймворков:Angular,React,ReactNative. <>

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

Так вышло, что я попала на достаточно крупный проект нас было около 20 человек в команде: разработчики, тестировщики,автоматизаторы, бизнес-аналитики,projectmanager. Поначалу всё казалось очень странным и сложным, мне давали какие-то небольшие задачки (чаще всего баг-фиксы), к тому же под наблюдением старших товарищей. Когда я почувствовала уверенность в собственных силах, стала брать маленькие фичи, а также помогать коллегам с решением их задач.

Через 2-3 месяца я уже спокойно брала задачи на самостоятельную разработку с интеграцией с API, написание юнит-тестов и всё, что включало в себя полный цикл разработки.<>

Полное интервьючитайтенапортале Тренинг-центра.

5. Насколько большой может быть разница по скиллам между несколькимикандидатами, которые претендуют на одну позицию?

НинаСказобова, Lead Resource Development Lab Head:

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

Для каждогоспециалистана каждое направление (Javadevelopment, .NET,web-developmentи так далее) в нашей компании есть матрицыкомпетенций, именно на основании этой матрицы оцениваются приходящие кандидаты. Разница в знаниях кандидатов иногда может быть значительной, но это выясняется в процессе общего интервью с рекрутером. После обучения в тренинг-центре разница в знаниях почти не заметна.

МарияВыгузова, Resource Development Administrator:

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

ГригорийСилкин, Software Testing Team LeaderГригорийСилкин, Software Testing Team Leader

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

6. Что вы думаете про то, что для входа в индустрию всё меньше требуется вузовское образование, и люди обходятся специализированными курсами?Как вы относитесь к кандидатам, у которых за плечами полгода-год онлайн курсов?

МарияВыгузова, Resource Development Administrator:

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

АртёмЦибенков,JavaDeveloperАртёмЦибенков,JavaDeveloper

Чтобы яснее представить, стоит ли мне идти в IT-сферу, начал изучать рынок труда в нашем городе, направления и специализации. Я понял: чтобы стать разработчиком не обязательно тратить время на получение высшего профильного образования, это плюс. Выбрал для изученияJava, как наиболее востребованный на рынке язык.<>

Записался на бесплатное онлайн-обучение. Прошёл, убедился, что разработка мне интересна.Решил пройти платный полугодовой онлайн-курс поJavaот одной известной компании.Пока проходил онлайн-курсы, в параллели узнавал, какие IT-компании есть в городе, какие у них требования дляcтажрови на вакансииjunior-специалистов.<>

Узнал, чтов офисеEPAMпланируется запуск обучения для начинающих специалистов и одно из направлений разработка наJava. И что новички после окончания получают возможность трудоустройства в EPAM, если пройти техническоесобеседование.<>

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

Понял, что есть немалыйобъминформации и его надо усвоить за 2 месяца. Составил план, получилось, что ежедневно надо заниматься по 8-9 часов. В итоге, после интервью, по окончании обучения меня взяли на позициюJuniorDeveloper.

Полное интервью на сайтеТренинг-центра.

7. Компании борются за сильных специалистов. Борются ли они заджунов?

НинаСказобова, Lead Resource Development Lab Head:

Да, сджуниорамиработа начинается ещёв вузе (со2-го, 3-гокурса) компании проводят мероприятия для студентов, приглашают на практику, выстраивают долгосрочные отношения ещё на этапе обучения кандидата.

8. Как вы считаете, компания должна продавать свои вакансииджунамилиджуныдолжны убеждать компании, что они ей нужны?

НинаСказобова, Lead Resource Development Lab Head:

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

9. Что эффективнее и выгоднее стажировки или поискджуновна рынке?

МарияВыгузова, Resource Development Administrator:

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

10. Что происходит послеоффераджуниор-разработчику: процесс обучения,онбординг, менторство? Как скоро он получит боевые задачи?

МарияВыгузова,ResourceDevelopmentAdministrator:

Всё зависит от проекта.Иногдаджуниорсразу начинает решать технические задачи, а естьтакиепроекты,куда специалистонбордитсяпорядка 1-2 месяца.

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

11. Как вы относитесь кджунам, которым за тридцать или за сорок кандидатам, которые резко решили сменить карьеру и пришли из других сфер?

МарияВыгузова, Resource Development Administrator:

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

ГригорийСилкин,SoftwareTestingTeamLeader:

Мы оцениваем кандидатов по их профессиональным качествам, по знанию технической базы, софт скиллам и английскому языку. Если по этим параметрам кандидат нам подходит, неважно какого он пола, сколько ему лет и так далее. Кроме того у нас есть программа переквалификации из смежных областей. По статистике, примерно 20% наших студентов в возрасте 30+. Надо понимать, что это люди с опытом, и это их не первое место работы.

Владимир Малюгин, Front-End разработчик Владимир Малюгин, Front-End разработчик

<> Когда несколько лет назад я решил выбрать новое направление развития, по совету знакомого преподавателя, обратил внимание на образовательные программы ЕРАМ. Но поступить на внешние курсы поFront-endмне удалось только с третьего раза. Слабым местом был уровень владения английским.

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

<>Я решил повторить путь своего старшего сына, но в отличие от меня, покаджуниора, он ужеteamlead.

Если есть желание и мотивация, то сменить сферу деятельности или научиться чему-то новому не проблема в любом возрасте<>.

Подробнее насайте Тренинга-центра.

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

НинаСказобова, Lead Resource Development Lab Head, EPAM:

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

МарияВыгузова, Resource Development Administrator, EPAM:

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


Подкидывайте идеи, о чём вам ещё было бы интересно почитать. Задавайте свои вопросы в диалогах.

Подробнее..

Что и кому должен продуктовый аналитик? ч.1

29.11.2020 12:04:16 | Автор: admin


Последние несколько месяцев я проходила квест под названием уволиться с позиции маркетингового аналитика в FMCG и получить оффер на позицию продуктового аналитика в IT. Хочу поделиться опытом и систематизировать информацию, собранную за это время из разных источников. А для того, чтобы не быть голословной, рассказывая, о том, какими навыками должен обладать продуктовый аналитик, начну с обзора открытой информации о требованиях к соискателям в вакансиях hh.ru.

Я спарсила открытые данные о вакансиях, размещенных на сайте headhunter.ru на 28/10/2020 по запросу Аналитик и Продуктовый аналитик. Полный ноутбук и ссылки на данные выложены тут.

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

Список требований, необходимых для конкретной вакансии, я брала из раздела Ключевые навыки в описании позиции. Не все HR качественно заполняют это поле: кто-то опечатался (Прим: Phyton), кто-то вообще плохо понимает, что происходит ошибся (Прим: Массивы, Медицинское оборудование), кто-то не стал заполнять этот раздел. Однако, судя по тому, что для разных специальностей видны очевидные отличия в требованиях, большинство вакансий заполнены корректно, по крайней мере, критичные навыки упомянуты.

Возможно, для более точного учета навыков, особенно soft skills (Прим: обладаете хорошими коммуникативными навыками для общения с бизнес-, и с техническими командами) стоит выделять требования из полного описания вакансии и разбивать их на смысловые группы.

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

Всего для анализа было доступно 1178 объявлений, более 60% которых приходится на 5 специальностей: аналитик, бизнес аналитик, продуктовый аналитик, маркетолог аналитик и веб аналитик.

Как отличаются навыки, необходимые для каждой специальности?



Видно, что ключевые навыки для каждой специальности свои: для Продуктового аналитика важны технические навыки (SQL, Python), для Маркетингового аналитика чаще упоминают маркетинговый анализ и PowerPoint, а для Веб аналитика GA и Я.Метрику (вот за что я люблю аналитику. за такие инсайты!).

Если продолжить список топ навыков для Продуктового аналитика, окажется, что за техническими скиллами идут аналитические (анализ данных, аналитическое мышление, аналитические исследования) и знание статистики (математическая статистика, статистический анализ, a/b тесты, data mining). Полный список с интерпретацией частот навыков на самой первой картинке с облаком тегов.

В какую специальность легче всего зайти без релевантного опыта?



Легче всего искать работу на junior и intern позиции в области анализа данных по специальностям Маркетолог аналитик и Веб аналитик около 10% вакансий готовы нанять людей без опыта.

А на позицию Продуктового аналитика чаще всего ожидают более опытных людей: более чем в половине вакансий ищут человека с 3-6 годами релевантного опыта.

Как отличается заработная плата по специальностям?


Вакансий с открытой информацией о заработной плате мало всего 63. Тем не менее, невозможно удержаться и не посмотреть распределение. Для адекватного сравнения, рассмотрим медианы зарплат начального уровня (ожидаемый опыт работы от 1го до 3х лет).

Бизнес аналитик в среднем может рассчитывать на 140т, продуктовый аналитик на 100т, а меньше всего готовы платить маркетологу и веб аналитику: 60т. Маркетологи и веб аналитики, срочно учите BPMN или Python, SQL!

Напоследок дам ссылки на занимательные материалы на схожую тему:

  1. Аналитика для хантинга аналитиков обзор вакансий, навыков и зарплат от людей, которые в hr штучках понимают гораздо больше, чем я.
  2. Текст о необходимых навыках на разных грейдах в Яндексе.
  3. Статья о видах аналитиков в IT (читать голосом Дроздова).

Во второй части статьи я поделюсь полезными материалы, лайвхаками, курсами и задачниками, которыми пользовалась, когда наверстывала недостающие hard skills для позиции продуктового аналитика. Stay tuned!
Подробнее..

Работа ИТ-специалистов в Русфинанс Банке от найма до реализации амбициозных проектов

23.12.2020 14:04:12 | Автор: admin
При поиске работы у кандидатов часто возникают вопросы: рассматривать или не рассматривать ту или иную вакансию, оправдаются ли ожидания от работы, как будет выстроено взаимодействие внутри команды, чего ожидать при трудоустройстве. Поиск ответов на них и сбор информации отнимает силы и время (опросы знакомых, обращение к Google, получение рекомендаций на рынке и т.д.).

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

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



О найме разработчиков


Какие этапы нужно пройти кандидату, чтобы попасть на работу в Русфинанс Банк?
Процесс подбора чаще всего включает в себя 3 этапа. Первый отбор резюме. По заранее определенным критериям рекрутер выбирает CV и обсуждает их с экспертами из IT. Если разработчику поступает звонок от рекрутера банка, он может быть уверен, его скилы и навыки интересны техническим специалистам. Второй этап онлайн встреча-знакомство. На ней присутствует HR, ИТ-эксперт и Product Owner (если вакансия открыта в Agile-команде). Проведение встречи со всеми заинтересованными сторонами экономит время кандидата, а также позволяет составить впечатление о будущих задачах и атмосфере в команде. По некоторым позициям есть 3-й этап тестовое задание. По итогам его выполнения организуется встреча с техническими специалистами для обсуждения хода решения. Если все этапы пройдены успешно, кандидат получает предложение о работе.

Какие критерии отбора резюме кандидатов на ИТ-вакансии?
Требования к успешному кандидату могут отличаться в зависимости от позиции, но, как правило, если речь идет о позиции разработчика, оцениваются следующие аспекты: опыт в разработке, знание необходимых технологий (например, Oracle PL/SQL), образование, предыдущий опыт работы (профиль компании, продолжительность работы, реализованные проекты).

Как организован процесс проведения интервью в пандемию?
До пандемии мы рассматривали кандидатов преимущественно из 2-х городов: Москва и Самара (там у нас находятся центральные офисы). Сейчас, когда большинство сотрудников работает удаленно, мы стали более гибкими и рассматриваем кандидатов из разных городов России.
Все этапы отбора проходят по видеосвязи. Это дает возможность нашим кандидатам не тратить время на дорогу, а нам более оперативно организовать интервью и закрывать вакансии. Оформлять на работу новых сотрудников мы также можем в городе их проживания.

Как происходит онбординг нового сотрудника?
После того, как все этапы интервью пройдены и кандидат принял предложение о работе, он присоединяется к нашей команде. Мы никогда не бросаем нового коллегу одного. Стараемся помочь ему быстрее адаптироваться, знакомим с коллегами, корпоративной культурой, приглашаем на адаптационные мероприятия (например, Induction Day), помогаем почувствовать себя в новой среде более уверено и комфортно. Как нам кажется, у нас в команде приятная, дружеская и по-настоящему воодушевляющая атмосфера.

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

Знакомство новичка с членами команды сейчас выглядят так:



О работе


В каком формате сейчас работает команда?
С конца 2019 года мы внедряем технологию FLEХ-офис переводим сотрудников в Москве на работу с flex-ноутбуков. Благодаря этому наши ребята могут подключаться к работе из любой точки, где есть Интернет (из дома, из кафе и т.д.). В офисе больше нет закрепленных рабочих мест. Если сотруднику нужно выйти в офис, он выбирает любое понравившееся рабочее место в своей логической зоне. Это удобно.

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

О ключевых проектах


Над какими проектами работала команда?
Можно выделить несколько ключевых проектов, над которыми в последнее время активно работала команда.

1. Новый сайт банка. В июле 2020 года мы запустили современный и отвечающий последним требованиям технологий сайт банка. На новом сайте можно онлайн рассчитать стоимость кредита, отправить заявку на кредит, зайти в свой личный кабинет (для клиентов физических лиц). Личный кабинет для клиентов юридических лиц также уже разработан, и в начале 2021 года он станет доступен первым дилерам.



2. Продукт Автокредитование. В пандемию одним из направлений, развитием которого мы занимались в рамках продукта Автокредитование, стала онлайн интеграция с брендами/ дилерами/ класифайдерами.

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

Цель перед нами стояла амбициозная реализовать 5 интеграций с брендами/дилерами/ класифайдерами до конца 2020 года. И несмотря на форс-мажор с пандемией, мы сейчас очень близки к её достижению. Если 2020 год не преподнесет новых сюрпризов, мы можем даже превзойти свои первоначальные ожидания.

Об Agileтрансформации


Какие изменения внедряются в банке?
2020 год стал для нашей команды годом перехода на новый уровень в Agile-трансформации. Если раньше мы могли говорить только о том, что у нас есть несколько продуктовых SCRUM-команд, то теперь можем рассказать куда больше. Изначально мы черпали опыт, базируясь на том, что смогли имплементировать в текущие процессы разработки и сопровождения несколько SCRUM-команд. А потом с полученными знаниями пошли дальше.

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

Отдельно хочется рассказать про работу продуктовой команды Автокредитование нам удалось настроить её работу в классическом понимании LeSS.

Команда планирует свой спринт в два этапа, отбирая задачи из единого Backlog на Sprint planning 1 в фича тимы, и планирует работу непосредственно в Scrum командах на Sprint planning 2.

Демонстрирует результаты работы спринта на едином Sprint Review. Совершенствуется и решает системные вопросы внутри команды на Overall Retrospective. Опирается в своей работе на практики DevOps, постепенно внедряя новые инструменты и подходы.

Это позволяет нам эффективно работать над продуктом и выносить на прод новые фичи. Конечно, многие из них остаются незамеченными для клиентов физических лиц, так как большая часть работы происходит в направлении B2B, но и для конечных потребителей продукта в 2020 году были интересные изменения. Например, возможность входа и авторизации в онлайн-заявку на автокредит через Госуслуги, заполнение с помощью Dadata полей паспорта в онлайн-анкете, изменение дизайна онлайн-анкеты и еще много косметических доработок по отзывам и обратной связи от клиентов.

О технологиях


Какие стеки разработки используются на проектах?
Большинство проектов реализовано на стеке разработки Java EE + Oracle. Он обеспечивает высокую надежность, производительность и масштабируемость. Фреймворк используется собственной разработки.
Для фронтов развиваем направление React / TypeScript.
При разработке сайта используется JavaScript + Angular.
Управление разработкой ведем в Jira. Причем он используется как продуктовыми SCRUM-командами, так и core-сервисными командами, работающими по Waterfall.
Для тестов используется Selenium, есть тесты на Java, Kotlin, немного на Python.
Для мониторинга Grafana и Gattling.
Активно развиваем DevOps практики. Сервис CI/CD состоит из следующих компонентов: Jenkins, Nexus, SonarQube, сервер сбора метрик CI/CD (Grafana + InfluxDB).

Какова политика стандартов разработки и код-ревью?
Для основного стека внедрены стандарты разработки для унификации подходов к реализации. Активно проводится код-ревью.

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

О планах на будущее


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

А еще новый год будет ознаменован важным событием в 2021 году Русфинанс Банк будет присоединен к Росбанку.

Поэтому все новости о достижениях и реализованных проектах наших команд теперь можно будет узнавать в блоге Росбанка на Хабр.

До встречи на новой площадке в новом году!
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru