В своей колонке Java-разработчик Павел Вейник, основатель и преподаватель школы программирования ITStart.by, рассказал dev.by, как провёл два с половиной зимних месяца в поисках «работы, которая нравится».   

Читать далее

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

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

Почему я не поставил галочку «ищу работу» в соцсетях

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

При этом я сознательно не ставил галочку «ищу работу» во всяких LinkedIn’ах и не размещал резюме на джоб-бордах. Знал, что сразу обрушится полсотни предложений. Когда столько предложений (а каждое означает 2-3 собеседования), очень легко что-то перепутать, про кого-то забыть, кого-то обидеть или как-то ещё проявить себя не лучшим образом перед нашим маленьким и тесным HR-сообществом. Кроме того, на тот момент у меня в голове не было картинки компании и проекта, на которых я хочу работать. Поэтому я боялся: а вдруг кому-нибудь удастся уговорить меня на то, к чему я потеряю интерес через полгода, а контракт на год-два? В этом случае все будут недовольны. Нужно было сначала себя проверить.

Так что я действовал тихой сапой: кто поймёт, что я в поиске, тому повезёт.

Почему я никогда не готовлюсь к техническому собеседованию

На собеседованиях я всегда веду себя как можно более честно. Нет, не так: очень честно.

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

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

Обычно, приходя в разработку, люди видят свой рост в количестве технологий, которыми владеют. Так и должно быть. Но на уровне лет 6-7 опыта (у всех, конечно, по-разному) наступает перелом: они осознают, что уже забыли больше, чем знают. Пропадает уверенность в своих знаниях. Пройдя через этот кризис, человек начинает ценить не знания, а более общие паттерны — системное мышление, архитектурные подходы, общее понимание программирования. Такой человек может более-менее точно объяснить, как работает неизвестная ему технология, если просто знает какие задачи она решает, — потому что «я бы так сделал».

Собеседование N1: общая соображалка, «детские» вопросы и такт

Сразу после Нового года на фриланс-ресурсе меня выловил один белорус, эмигрировавший в США: мол, контора ищет умных ребят, ты как? СТО конторы — специалист по big data, очень зрелый и опытный технический человек, тоже выходец из Минска, часто сюда наведывается, участвовал в Highload 2014.

Собеседование было построено очень правильно и длилось часа три — говорили про всё, от Java-вещей до «просто за жизнь». Он уделял внимание не деталям технологий, а общей соображалке, технической сметке и интуиции. Удивлялся, что я так хорошо отвечаю на простые вопросы из области Java и «про компьютер» — хотя вопросы были детские, достаточно было просто подумать.

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

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

Собеседование N2: бизнес-модель «охватим всё и сейчас»

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

Эти товарищи вызвали у меня много вопросов. Для начала — со стороны бизнеса. Проект только начинается, живёт 2-3 месяца, по описанию — очень большой.

Я участвовал в нескольких стартапах с похожей бизнес-моделью «охватим всё и сейчас». Обычно жизненный цикл у них такой: через год инвесторы не видят явных результатов и нервничают, внутри команд начинается жёсткое давление на разработчиков — быстрее, выше, больше! Ещё через полгода инвесторы начинают вводить своих людей для контроля, и давление на разработчиков удваивается. Те потихоньку разбегаются в места поспокойней и поденежней. И стартап схлопывается за 2-2,5 года.

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

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

СТО, который «сидит на проекте»

В ходе собеседования по скайпу с техдиром этой копании я, если честно, взялся за голову и чуть не бился ею о стенку. На 40-й секунде, активно прокликав мышкой моё резюме, их СТО вдруг начал меня обвинять, что я «часто скачу по компаниям». Это был конкретный и жёсткий наезд. Как человек адекватный первые пару минут я вежливо, аккуратненько объяснял: вот здесь стартап умирал, пришлось уйти, вот здесь пригласили в Дубай. Да и вообще, у нас разные взгляды на карьеру разработчика, давайте как-то с этим жить! И тут он начинает утверждать, что я ничего не знаю и знать не могу, «потому что не сидел на одной технологии несколько лет». При этом собственно техническое собеседование ограничилось двумя-тремя простыми вопросами.

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

Напоследок он попросил рассказать про последний проект, где я освоил в базовом виде несколько JavaScript-технологий и использовал их в разработке. Здесь я почувствовал в его голосе неподдельное удивление («Ооооо!») и понял, что для этого человека изучить что-то новое — очень серьёзная задача. Мне стало очевидно, что он не будет нанимать людей круче себя, тем самым серьёзно ограничивая технический рост проекта и уровень людей, задействованных в нём.

Письмо об отказе мне не прислали.

Собеседование N3: 50 эйчаров

По-прежнему не ставя галочки «ищу работу», я добавил в LinkedIn 50 эйчаров. Почему именно 50? Это вышло случайно.

Дальше интересная вещь: из всех 50-ти эйчаров мне написало только двое. Только двое, Карл! Даже пускай 10 из 50 эйчаров ищут джависта в Минске, хотя бы от 5 из них я ожидал бы более осмысленной реакции. Это удивляет. Ну да ладно.

Одна эйчар спросила, чем могу помочь. Эй, мы в LinkedIn, ты эйчар, я разработчик, угадай, что мне от тебя надо? Другая – единственная из всех! — попала в точку, сразу прислав описание вакансии.

Речь шла про очень молодую компанию — стартап как стартап, доля амбиций есть, окна в офисе чистые, ничего особенного. Правда, по словам эйчара, у СТО есть персональные особенности. Мне ещё любопытней стало: иногда странные люди делают интересные вещи!

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

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

СТО: как ты относишься к тому, когда на тебя кричат?

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

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

И, наконец, вопрос, после которого у меня запищали все предохранители: как ты относишься к тому, когда на тебя кричат?

Олимпиадники: идиот и код

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

И вот ещё одно собеседование в этой конторе — с теми самыми двумя олимпиадниками. Увы, они спрашивали о том, что сами знают и используют, а не о том, в чём я силён. Это не даёт человеку показать себя.

Дальше — ещё «страньше». Спросили про принципы объектно-ориентированного программирования (уж их-то я вспомню даже в следующей реинкарнации!) и про некоторые подобные вещи. Даю определение, а мне говорят: оно слишком книжное, есть получше! Ёлы-палы, книги пишут умные товарищи, чего тут выпендриваться? В итоге они приводят то же самое понятие немного другими словами.

Потом стали задавать совсем странные вопросы. Можно ли сделать перечислимые типы (enum в java) без единого значения? На секундочку, перечислимые типы предназначены для того, чтобы в них были значения! Сделать-то можно, но тот, кто читает код, будет, скажем так, сильно заинтригован.

Или: что будет, если идиот возьмёт, через reflection пооткрывает закрытые методы и будет их вызывать напрямую? Идиот есть идиот, против него ничего не сделаешь! По-моему, с этим бороться нужно организационно — не подпускать идиота к коду, или положить код на сервер и предоставить доступ через API.  Это вопросы примерно такого уровня: «а можно ли пойти в магазин на руках» или «а что будет, если идиот отрубит тебе топором руку, когда ты будешь идти на руках в магазин»? Ребята демонстрировали свою «некнижность» и нестандартное мышление, но для меня это выглядело странно.

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

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

Собеседование N4: адекватный индус

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

Прошёл два теста — по Java и по IQ, оба очень неплохие, на удивление. К тестам по IQ я вообще отношусь скептически: обычно они требуют продлить последовательность, что требует навыка поиска похожих деталей, у меня же мозги устроены так, что обычно я ищу отличия. Однако смог переключиться.

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

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

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

Процесс моего вхождения в эту команду запущен и идёт.

Через два дня после после начала работы в этой команде компания из главы «Собеседование N1» наконец нашла проект для меня. Увы, поздно. Теперь я работаю в одной команде вместе с Joachim Haagen Skeie, автором книги Ember In Action, повышаю свою квалификацию в JavaScript-технологиях. Правда, по проекту ещё не пришлось пересечься с Иоахимом.

Пример для подражания: хорошее собеседование

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

Собеседование всегда содержало:

• Вопросы по азам, без которых джавист не может быть джавистом. Это простейшая предосторожность: отвечают на вопросы все, но глубина ответа говорит о многом. Как человек думает, настроен ли он искать проблему, насколько он быстро думает, может ли использовать подсказку.
   
• Беседу о более продвинутых вещах, технологиях, но на уровне опять-таки не деталей, а общих принципов.
   
• Одна или две задачки на сообразительность, связанных с программированием. От человека не требуется реально решить или написать код — нужно продемонстрировать свои подходы и отношение к ошибкам и подсказкам.
   
• Общение за жизнь.

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

Резюме: 2/4

Что ж, из 4 собеседований —- 2 успешных, 2 неуспешных, работу нашёл, причём именно ту, какую хотел. Если бы я не нашёл подходящую компанию и проект после этого собеседования, то предпринял бы ещё пару попыток, а потом бы уже выставил галочку «ищу работу».

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

 

 

Колонка подготовлена при участии Натальи Провалинской

 

 

*Мнение колумнистов может не совпадать с позицией редакции.

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.