Как стать автором
Обновить

Java-программист в Петербурге. Обзор рынка труда с точки зрения соискателя. Часть 2/3. Подводные камни для «новичка»

Время на прочтение 14 мин
Количество просмотров 24K
Часть 1/3. Какие бывают 'плюшки'.
Часть 3/3. Какие бывают работодатели. Характерные особенности.

Подводные камни для новичка.


Первые подводные камни, вообще-то, могут начаться ещё на собеседовании — например, проект новый, процесс интервьюирования ещё не налажен, первый вопрос может быть “Do you have a printed copy of your CV?” от иностранного представителя, в общем, на вас в качестве одного из подопытных кроликов этот процесс и будут отлаживать. Ещё вас могут внезапно поставить на “конвейер”: пропустить через три стадии собеседования по часу с лишним каждая сразу. Проблемы это может породить, если вы не подготовились к собеседованию или если у вас на это день назначены ещё другие собеседования. Но это так, к слову.

Общие соображения.

«Если кто-то виноват, то заранее ясно кто».

Во-первых, есть некоторая естественная склонность при возникновении непоняток (что там было про управленческие и коммуникативные навыки?), трений и, тем более, конфликтов с участием новичка истолковывать их не в его пользу. Даже если новичок прав, то всё равно есть причины чтоб его уволить: ‘менеджер не может с ним сработаться’, чел ‘не вписывается в неформальный корпоративный формат’ или ещё что-то в этом роде. Если такое “не сработался” повторится и со следующими, то или через пару-тройку кандидатов с кем-нибудь наконец сработаются или задумаются, а может быть «что-то в консерватории поправить». В общем, если вы кому-то из начальства или “старожилов” из тех, к мнению которым прислушиваются «внезапно» чем-то “не понравились” или почему-то вызываете у него постоянное желание подколоть вас или уязвить или продемонстрировать своё остроумие вместо чёткого и ясного выражения того, что от вас требуется, то, если дело «дойдёт до ручки», то ясно, кого будет проще уволить — новичка на испытательном сроке, которому надо заплатить за три дня, или «более полноправного» работника, которому надо при прекращении трудового договора не по его инициативе заплатить за два-три месяца и с которым уже как-то сработались? И если они за пару-тройку итераций всё же найдут кого хотят и с кем сработаются, то спишут случай с вами на “мало ли что бывает”. Да ещё и вопрос, захотите ли сами работать в такой обстановке.

«Вася — бесконфликтный. Это — аксиома. Если у тебя конфликт с Васей, то виноватым можешь быть только ты. Это — следствие из аксиомы».

Приблизительно тем же пахнет ситуация, когда начальник на новом месте сразу говорит сам о себе (и о нём говорят другие начальники) как о “бесконфликтном” человеке: это всего лишь толстый намёк на то, что если между вами возникнут непонятки и конфликт, то виноватым заранее назначены вы, а не “бесконфликтный”. Непонятки, как ни странно (хотя, в общем, не странно), могут при этом возникнуть буквально на ровном месте. Например, в самом начале работы над проектом ведущий разработчик, назовём его “Пётр”, описывает, какие плугины для IDE должны быть установлены. Вы просите у него списать всю IDE с уже установленными плугинами (время не ждёт, вам, и не только вам, уже неоднократно прочти «мотивационную вводную», что надо быстрее начинать работать), он же, из соображений большей корректности, вместо этого даёт xml-файл с update-сайтами плугинов, успешно сработавший у него полгода-год назад. Вы в течение суток пытаетесь этот файл применить, и у вас ничего не получается: какой-то из плугинов больше не находится по указанному адресу и не может установиться, а заодно не могут установиться и все плугины, которые в списке стоят после него. Когда вы сообщаете об этом «бесконфликтному» начальнику, он отвечает, что “Пётр” “не может посоветовать плохого”, и это, наверное, у вас кривые руки. (P.S: самокритика «post mortem»: тупо применять непонятно какой файл непонятно куда — «некруто» (хотя частично оправдано тем, что «надо очень быстро»). Вместо этого надо уметь быстро врубаться в малопонятные вопросы с помощью гугла и ассоциативного мышления. По крайней мере можно было (за те же самые «бесплодные сутки», возможно на другой машине) 1) найти как устанавливать плугины по одному, 2) вычленить «пропавшие» плугины 3) найти куда они «переехали» либо установить, что пропали с концами.)

Но может быть и наоборот — вы можете сразу произвести впечатление особо “перспективного” работника, которому, наоборот, дадут фору перед “не проявившими себя” давно работающими сотрудниками (например, вас возьмут на должность ведущего Java-программиста в web-проект даже при полном незнании вами языка Javascript (правда, при наличии опыта использования GWT, при котором знание Javascript'а не необходимо)).

Ну и, при хорошем развитии коммуникативных навыков, в случае конфликта с менеджером даже есть шанс объяснить вышестоящему начальству, что неправ таки менеджер. Хотелось написать, что не проще ли сделать это до конфликта, но стало понятно, что до конфликта просто нет повода для обращения к вышестоящему начальству.

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

В-третьих, то, что испытательный срок будет “завален”, обычно становится понятно недели через две-три: всё как-то странно идёт наперекосяк, и остаются непонятными элементарные вещи (как будто их специально удерживают в состоянии “непонятности”). Занимает такой заваленный испытательный срок обычно полтора месяца при «нормальном» стечении обстоятельств и два — при наличии фиксированной общей даты увольнений (подробнее коснусь ниже).

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

  • Руководство плохо понимает, что в техническом плане хочет.
    Встречается, по идее, редко, но автор лично на такое один раз попал. Это был “затянувшийся стратап”, финансирование которого продолжалось по доброй воле его финансового директора, являвшегося параллельно одним из топ-менеджеров в одном агентстве недвижимости, для этого агентства эта фирма служила заодно и вместо IT-отдела. Фирма хотела написать КИС, хотели иметь для неё модуль GUI, который мог бы работать как и в качестве веб-клиента, так и в качестве «тяжёлого» приложения на Swing (понятия «Rich client» не знали тогда ни я ни они, было начало 2005 года). В конце концов автор выбрал с качестве универсального промежуточного слоя некоторую обрезанно-модифицированную версию SwiXML. Работодатели не могли чётко сформулировать что им надо в качестве базы — веб- или swing-версию. Автор там был на этом участке как минимум вторым, после него решили передать дело некоему аутсорсеру из Москвы.

    В качестве некоторой самокритики «post mortem» можно сказать, что если бы автор был опытнее, то он, может быть и смог быстро найти и «продвинуть»/«впарить»/«втюхать»/«навязать»/«внедрить» им решение, но есть встречное контрподозрение, что будучи таким умным, автор навряд ли бы польстился на ту вакансию;-). В прочем, спустя после увольнения месяц, из которого поиск работы занял последнюю неделю (остальные три недели — временная подработка), автор нашёл другую работу, где и зарплата и понятность задач были больше.

  • «Нужен человек на пять минут, чтобы его уволить».
    Формулировка несколько утрирована, но по крайней мере пара разновидностей подобного явления существует: 1) нужно временно занять кем-то место, чтоб потом перевести на него нужного человека или 2) заранее берут больше людей, чем планируют оставить. Первое может быть, например, когда в аутсорсинговой компании из-за сокращения рынка идёт массовое закрытие проектов, и вдруг удалось запустить один проектик: получилось «раскрутить»-найти заказчика. В этом случае на проект берут одного “лишнего”, причём даже, по настоянию собеседовавшего менеджера, человека, который чуть-чуть не дотягивает до уровня вакансии, и потом всячески скрывать от него «жуткие профессиональные секреты» типа автоматического форматирования средствами IDE, полуавтоматического рефакторинга и прочего “причёсывания кода” ими же — чтоб дать человеку наработать негатива в личное дело. Вторая причина может сочетаться с первой и даже маскировать её.

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

    «Бонусом» к такому «кадровому конвейеру» идёт несколько “несправедливое” и вообще пофигистское отношение к новичкам: раз всё равно половину увольнять, тогда «если мы обидели кого-то зря» — то это мелочь на общем фоне. «Значит, вам не повезло. Значит, вы — неудачник. Идите вон! Неудачники не нужны „Корпорации“!». Если посреди процесса выполнения задачи, на выполнение которой отпущена неделя, вас вдруг заставляют мигрировать с тормозного компьютера, который вам дали сначала, на новый, иначе его отдадут в соседний отдел, при этом при миграции надо при этом скопировать ~100 GiB workspace'ов, и ещё параллельно осваивать на нём работу в Windows 7 после XP — то это как раз такой случай.

  • «Русский SCRUM, бессмысленный и беспощадный».
    Встретилось автору осенью 2009 года в одной компании из «топ 10» софтверных фирм в СПб (правда, через пару-тройку месяцев в той компании начались массовые сокращения персонала — корректные: «по соглашению сторон» и с выплатами зарплаты за два месяца в качестве выходного пособия). Следуют не столько “духу” SCRUM-методики, сколько её “букве”, причём не везде, а произвольно, в основном тогда, когда это ситуативно наиболее противоречит духу и отрицательно влияет на результат. Команда набирается на 60-70% из людей, по SCRUM-методике до этого не работавших и вообще из новичков. Успешно сочетаются недостатки «гибких» и «водопадных» технологий: от первых берётся малосерьёзное отношение к планированию — не него отводится очень мало времени: час на трёхнедельный спринт с разбиением задач на подзадачи не длиннее пяти, а желательно двух-трёх, часов (итого в среднем около 10 секунд на планирование одной задачи), от вторых — невозможность отступить от наспех напланированного и исправить ошибки планирования в течение спринта. Служит источником “косяков”, которые можно легко перевести на “кого надо” (с записью в личном деле), благодаря чему хорошо совмещается с практикой “брать людей с запасом” из предыдущего пункта.

  • «Рекуррентный» испытательный срок.
    По окончании испытательного срока (да, полноценных трёх месяцев) вам говорят, что вы им не подходите, но можете уволиться по собственному желанию и тут же написать заявление о приёме на работу — вас возьмут. И так постоянно.

  • Недооцененные и «мутные» задачи.
    Точнее было бы назвать этот подводный камень «hidden investigation abyss». Когда и объём работ и время, потребное для их выполнения, должны быть результатом отдельного, не предполагавшегося заранее, исследования, которое ещё нужно провести, и результат может иметь разброс раз в 10, ну или отличаться раз в 10 от того значения, которое выставлено при первоначальной оценке. Тут как раз имеется в чистом виде “плавающий косяк” (неизвестный вначале новичку). Может сработать упомянутый выше пункт про “непонятки и конфликты”: когда на такую задачу “нарывается” работник со сформировавшейся хорошей репутацией, то ему скорее поверят, что задача была ранее неправильно оценена, чем новичку.

    Да, и такие задачи имеют свойство сваливаться именно на новичков. “Старожил” нередко имеет право, не совсем формальное, но по факту, не то, чтобы «выбирать себе задачи по вкусу», а «расставлять для себя приоритеты» (на основании своего опыта), что делать в первую очередь, а что — во вторую, и расставлять задачи в очереди и по приоритетам какая задача, исходя из того, какая из них, по его мнению, нужнее и важнее для проекта в целом и, занимаясь какой из них, он сможет быстрее принести для проекта больше пользы. До третьей-четвёртой очереди очередь может так и не дойти, в том числе из-за того, что включающая её “над-задача” может быть перепланирована с выбором другого пути её решения, и тогда исходная задача — сюрприз! — исчезнет. Да, “старожилы”, стараясь всячески “отпихивать” от себя такие «мутные» задачи, нередко правы: дело имеет шанс обойтись workaround’ом. У новичка же есть повышенный риск «попасть» на такие «мины» ещё и потому, что начальство может лелеять заднюю мысль, что вот придёт свежий человек со свежим взглядом и с этой новой точки зрения решение проблемы может видеться проще и быстрее.

    Особенно “весело”, если у вас в плане на испытательный срок будет поставлено несколько задач по неделе каждая, и первая же, за которую вы берётесь, оказывается из серии «hidden investigation abyss»: эдак вы могли бы сделать к сроку три с четвертью задачи из четырёх, а так сделаете из же четырёх — ноль с половиной задач. Чтоб «выкрутиться» и преуспеть по максимуму, в такой ситуации нужны менеджерские навыки (чего вначале не предполагалсь): заранее оценивать задачи на обилие подводных камней (для этого надо иметь навыки разбиения задач, покомпонентной оценки рисков и прочего планирования), “пробивать” себе в качестве первых по очереди те задачи, которые менее “мутны”, аргументированно “соскакивать” с задачи или добиваться её перепланирования, если во время её решения вдруг выяснилась её “мутность”, “переводить стрелки” на смежников (типа постановщиков задач) и педалировать тезис, что это они подставляют вас путём (провоцирования) срыва сроков работ, за которые вы поставлены отвечать. Если же у вас при этом по какой-то причине имеется личный “пойнт” на “бесконфликтности” (как выше упомянуто), то он в значительной степени связывает вам руки.

    С другой стороны, «мутные» задачи — это и шанс;-). Шанс изучить новые технологии и приёмы (типа запуска ELF-файлов из-под Tomcat в МСВС на виртуальной машине — надо не забыть убить дочерний процесс через 5 секунд, что непонятно как сделать кроме как из специально запущенного параллельного потока), потренироваться в (овер-)инжиниринге типа написания фреймворков на аннотациях. Особенно если это не обернётся увольнением по причине непрохождения испытательного срока;-)

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

    Не особо большое, но фатально существенное для некоторых количество «мутных» задач появляется также в случае «бессмысленного и беспощадного SCRUM»'а из предыдущего пункта. Это не только задачи из серии «hidden investigation abyss», но и те, которые слишком зависят от других задач (нельзя приступить разу, пока не решены другие), что поначалу незаметно или может преднамеренно не акцентироваться. Тут надо проявлять изрядную расторопность на том кратком этапе, когда исполнители разбирают себе задачи, чтоб тебе не остался подобный -последний — проблемный участок. Здесь тоже надо иметь некоторый опыт, которого поначалу обычно нет. Хотя, подозреваю, эта экзотика осталась в 2009 году и ранее.

    Пункт «Руководство плохо понимает, что в техническом плане хочет» тоже может считаться гипертрофированным вариантом данного пункта — до степени «ищем мидл-девелопера для выполнения задач ведущего архитектора». Но в общем, тут главное — не льститься на такие вакансии и уметь аргументированно и доходчиво объяснить людям, в чём они “хотят на грош пятаков” — могут и понять.

  • Общая “гнилость” конкретного узкого участка работы.
    Стоит выделения в пункт, отдельный от предыдущего… Работы бывают разные. Если организация большая, и делает один большой продукт с вариациями, то велик шанс, что в ней будут участки работы с существенно разной «интересностью» задач и перспективами профессионального роста. Не то, чтоб это был подводный камень именно «для новичка», но… Кто-то пишет ядро, а кто-то с таким же красивым ярлыком «Java developer» занимается срочным выяснением «почему у заказчика в опытной эксплуатации эта хрень перестала работать, да, блин, оно же неправильно написано и никогда нормально не работало — спасал дефолтный механизм, да тут последние изменения вносились полгода назад, почему об этой ошибке написали только вчера??» и занимается собственно программированием в общей сложности три месяца за два года, из которых два месяца — во время испытательного срока, и, так, собственно, и не изучив толком дальше общего уровня систему, которую фирма делает. И — сюрприз! вовсе не сюрприз — что именно на таких участках повышенная текучка кадров, люди через полгода уходят по собственному желанию (да-да, на 146% собственному), и новичку по теории вероятностей больше всего светит попадание именно на такой участок. Говорить начальству об этом в общем бесполезно, наличие таких участков — объективное следствие способов организации работы, эту работу в любом случае кто-то должен делать, «организация социальной справедливости» — не цель фирмы, фирме тупо проще мириться с доп. издержками из-за текучки кадров на таких участках. Участков может быть немного, но основной вклад в общую текучесть кадров на фирме вносят именно они, и неизменным существенным поставщиком вакансий являются тоже именно они.

  • Общая “экзотичность” новичка.
    Редко, но… Если вы «неформатны» по какому-нибудь критерию, например, возрасту — вам за 35, то есть ещё один повод для предвзятости: стереотип «в 30 лет давно пора быть менеджером, а не кодером» и тем более «не искать работу иначе как по личным связям» ещё не выветрился, вы для некоторых превращаетесь в экзотического «лузера», которого «не жалко». Тут надо быть готовым больше чем обычно “себя объяснять”, “рвать шаблон”, “создавать свой имидж” и проявлять другие грани коммуникативной эквилибристики. С другой стороны — а оно стоит того, раз с самого начала такие непонятки пошли?

  • Более мелкие непонятки.
    Из мелких менее опасных непоняток хочется отметить ситуацию, когда начальник, по его мнению, точно знает, как надо выполнять данное им задание, а вы в выполнении вот конкретно подобных подобных работ имеете больший опыт и знаете, как сделать быстрее, но начальство не может оценить ваш метод. Например, надо сделать интернационализацию русского веб-интрефейса на JSP (~150 файлов) — вынести куски текста в файлы ресурсов и заменить ссылками на них, начальство не знает о существовании вордовых макросов и настаивает, что надо делать всё руками в «блокноте». Тут варианты могут быть разные — например, сделать как говорит начальство, или сделать как считаешь нужным сам, или сделать, как считаешь нужным сам но пока начальство не видит, или «защитить» перед начальством свой подход.


Если всё же не получилось.

Когда фирма нанимает на одно и то же место пять человек подряд, и не один в итоге не удерживается, то это выглядит не так плохо (по крайней мере не так заметно), как если человек меняет пять мест работы и ни на одном из них итоге не удерживается. Если вы (или “вам”, но “крайним”, конечно, всё равно оказались вы) “завалили” испытательный срок, то надо думать, как это отразить на следующих интервью. Можно отразить в резюме этот эпизод трудовой деятельности, можно не упоминать (особенно если нет записи в трудовой книжке), можно упомянуть устно, на второй-третьей стадии собеседования, можно начать упоминать и в резюме, но не сразу, а через пару мест работы (их ещё надо получить!). Если не упоминать, то надо как-то объяснить, почему вы в это время якобы не работали (ага, уволился чел 22 мая во вторник — ни с понедельника ни с конца месяца — по собственному желанию, проработав год с хвостом, и что-то внезапно с 8 сентября ищет работу). Если при этом «по закону подлости» причиной ухода с предыдущей работы была низкая, по вашему мнению, зарплата (ага, картина маслом: “ушёл с низкой зарплаты в никуда”), то придётся искать другое объяснение, в общем, решайте, что вам лучше: репутация работника, “завалившего” испытательный срок или репутация работника, склонного внезапно “с балды” бросать работу. Если работа отражена в трудовой книжке или вы по другой причине решили её упомянуть — то надо думать как объяснить причины ухода. Если, например, вас попросили написать “по собственному” из-за плохого качества вашего кода и потому что вы оказались лишним в команде (точнее, в команде был заранее намечен кто-то лишний и этим “крайним” оказались вы, может быть и из-за того, что качество рабочего процесса, в т.ч. и качество кода, намеренно “запустили” везде где можно), а вы при собеседовании на следующее место работы будете говорить, что ушли сами из-за конфликта в команде, то тем самым вы сами на себя прямо с этапа собеседования будете клеить ярлык “конфликтного”, что может отяготить прохождение испытательного срока уже там;-). Ну, никто не обещал, что маленькие хитрости будут совсем бесплатны и никогда не выйдут боком;-). Потом, через пару лет/мест работы, “подтянув” качество кода, можно будет называть (устно) и “настоящую” причину.

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

Нечто вроде вывода.

Выше уже мелькала фраза про «боевое крещение». Это так — в случае успешного прохождения испытательного срока, потом будет проще (по крайней мере, будет какая-никакая положительная репутация). В общем, для успешного «боевого крещения» и преодоления стресса, связанного с встраиванием в новую структуру, требования вакансии желательно удовлетворять “на 146%”, быть “на голову выше” требуемой работы. Ведь требуемую производительность надо будет выдавать с учётом неожиданных рисков, непоняток, предвзятостей и прочих возможных мешающих и демотивирующих факторов. Для этого надо по крайней мере чуть-чуть быть менеджером: планирование и риски — это уже менеджерские компетенции.

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

Надо также быть внутренне готовым к тому, что испытательный срок может быть “провален”, в том числе и не по вашей вине. В утешение можно сказать то, что обычно, т.е. более чем в 50% случаев, эта неприятность всё же не случается ;-)

Часть 1/3. Какие бывают 'плюшки'.
Часть 3/3. Какие бывают работодатели. Характерные особенности..
Теги:
Хабы:
+16
Комментарии 4
Комментарии Комментарии 4

Публикации

Истории

Работа

Java разработчик
359 вакансий

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн