пятница, 11 октября 2013 г.

Что делать, если работа мечты на западе, а ты на востоке

     Данный пост является расширенной (и немного переделанной и дописанной) заметкой на G+

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


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

Немного лирики и того, как составляются вакансии и работают HR-ы. 

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


    Внешние HR-ы работают за бонусы. Многие конторы дают бонус за каждого кандидата, который прошел собеседование и испытательный срок. Соответственно HR-ам выгодно "продать" Вас как кандидата на вакансию и если Вы пройдете, то и они получат за Вас приличный бонус. Но при этом, если HR будет отправлять на собеседование множество кандидатов, которые будут проваливать его, то есть шанс, что рейтинг такого HR так же пойдет вниз. А вскоре с ним перестанут сотрудничать и брать кандидатов по его рекомендации только в самых сложных ситуациях: когда из других источников вообще не найти никого. Такие внешние HR-ы, пытаясь закрыть себя от неприятностей, существенно раздувают требования до огромных высот. Очень часто когда на вакансию проходят люди, которые очень хороши только в 1/3 из того, что написано в вакансии как обязательное и вообще не ведают в остальных 2/3х.


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

Почему же формальные требования к вакансии часто не соответствуют реальным 

     Потому, что мало кому нужен разработчик на Java с мега-глубоким знанием Spring, но всем необходим инженер, который, решая новую проблему, сможет грамотно выбрать средство для ее решения (это может быть Java, или Scala, или С++, или Си), быстро разобраться в тонкостях этого средства и преступить к реализации на уровне того человека, который в своем резюме будет писать об этом самом средстве. Что толку от Синьера, если он всю жизнь решал задачи с использованием средств ООП. В результате, если он столкнется с задачей, которая концептуальна просто в функциональном или аспектном программировании, но он банально ничего не знает кроме ООП, в таком варианте он превратиться в мидла (в контексте этой задачи), а то и хуже - в джуна, но при этом он по-прежнему будет получать зарплату Синьера.  


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



      Короче говоря, никому не нужны кодеры, а очень нужны инженеры, способные мыслить, с большим кругозором, хоть базовой математической подготовкой и очень-очень хорошей подготовкой в CS. И, конечно же, человек, который обладает всеми этими качествами наверняка неплохо программирует на нескольких (часто 2+) языках и вот именно эти языки и будут указаны в требованиях в вакансии, но на самом деле нужно не только это, а и все описанное выше!  


Ну ладно с девами, а что же требуется от Jun разработчика?:


     А вот тут я буду говорить о требованиях при устройстве в небольшую компанию. Итак: 
  • навык работ с системой контроля версий: теоретические знания по распределенным и не распределенным системам (их отличия) + практический опыт работы с одной из них (а лучше двумя - распределенной и не распределенной). Рекомендую выучить и попробовать работать с git (можно более простой mercurial), а после попробовать перейти на svn (именно в таком порядке, ибо от svn сразу начнет воротить после git и очень четко поймете их отличия (особенно когда попробуете активно ветвится на svn ;) )). Данный опыт без проблем можно получить за 1, максимум 3 месяца активной разработки своего проекта с другом (да в принципе и самостоятельно)
  • практические навыки написания своего проекта. Само собой проект должен быть оформлен так, чтобы можно было его легко показать (как код так и результат). В идеале сайт под проект, на котором будет и ссылка на открытый репозиторий. Будьте готовы отвечать на вопросы по проекту, так что "читерство" не прокатит. По большому счету работодателю до лампочки опыт и стаж - главное, что бы разработчик мог быстро вникнуть в задачу (уметь читать чужой код) и для этого очень важно практиковаться, именно по этому мы и устраиваем код ревью - с целью научится читать чужой код
  • уметь решать логические головоломки. Да-да, хоть Гугл много чего и говорил, но большая часть мировых лидеров и мелких контор тестирует умение кандидатов решать задачи путем задания им логических задач. Очень рекомендую прочесть книгу: "Как сдвинуть гору Фудзи?" - вы получите не просто массу удовольствия, но и ознакомитесь с 90 процентами задач, которые можете встретить
  • иметь навыки работы с какой-либо IDE: IDEA, Eclipse, NetBeans. Выучить шорткаты, как минимум
  • знать что такое BugTracker (есть множество бесплатных аналогов), можно прочесть мануалы по Jira, YouTrack, Redmine. А для практического опыта можно использовать багтрекер, например GitHub'а
  • иметь общие сведения о тестировании (знать что такое черный и белый ящик)
  • знать что такое Continues Integration. Как минимум на уровне теории, так как довольно трудно получить практику

А для больших организаций?

Сюда добавится:
  • знание комбинаторики и умение решать задачи
  • огромным плюсом будет знания в области искусственного интеллекта
  • само собой CS (сложности алгоритмов, алгоритмы и т.д.) - сортировки типа пузырек, гномья (подвиды), мержем, перестановками, вставками, подсчетом, кластерная, бинарная; деревья 2-3 дерево, черно-красное, балансировка; структуры хранения данных. Все это должно отскакивать от зубов!

CV

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


     Главная цель резюме - заинтересовать HR-а и того, кто его увидит и МАКСИМАЛЬНО объективно отразить Вашу квалификацию; и да, это не всегда может совпадать с формальными показателями. 

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

      Очень рекомендую прочесть по этой теме:http://www.amazon.com/books/dp/098478280X - она небольшая и очень четко показывает "закулисные" процессы приема на работу. Ну прямо must-have! Я бы даже сказал, что идти на интервью стоит как минимум проделав все, что описано в этой книге. ИМХО хочу сказать, что для компаний уровня Гугла те примеры, которые есть в книге немного слабоваты, хотя зависит от офиса: для не США может и подойдет. Но эта книга прекрасный маячок, если задачи из нее не вызывают у Вас трудностей, то значит Вы на правильном пути.

Еще раз о том, что нужно знать

Какие теоретические темы очень желательно знать (ну прямо чуть-ли не на зубок):
  • принципы ООП
  • коллекции и их основные реализации
  • нотация большого О
  • азы многопоточности
  • очень полезными могут оказаться знания основ сети (модель OSI)
  • знание комбинаторики и умение решать задачи
  • огромным плюсом будет знания в области искусственного интеллекта
  • само собой CS (сложности алгоритмов, алгоритмы и т.д.) - сортировки типа: пузырек, гномья (подвиды), мержем, перестановками, вставками, подсчетом, кластерная, бинарная; деревья 2-3 дерево, черно-красное, балансировка; структуры хранения данных. Все это должно отскакивать от зубов!
что желательно просто знать (Java):
  • SQL, NoSQL (хотя бы в теории: что это такое)
  • Один из UI frameWork: Swing, FX, Android, etc...

Как повысить свои шансы на прохождение собеседования

     Один из самых главных советов - ХОДИТЕ по собеседованиям, даже если Вы не готовы. Любое собеседование - это игра в рулетку: чем более подготовлены, тем шансы выше, но они никогда не будут 100%. Первые интервью однозначно будут зафейлены и это случится низависимо от прохождения сейчас или потом. Просто если пойдете позже, то и дольше будете искать, ибо прийдется все равно пройти через череду первых фейлов. 



   Так уж устроен процесс приема: взяв человека от него ОЧЕНЬ трудно избавится, а при условии огромнейшего наплыва кандидатов, им лучше не взять хорошего парня, чем взять нехорошего. Поэтому компании абсолютно нормально смотрят на повторные попытки пройти, ибо если человек нормальный, то он рано или поздно поймет как нужно себя вести, как отвечать и тогда сможет раскрыться, а раскрывшись - его оценят и примут действительно объективное решение по нему.



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

     Хочу лишь дополнить пост словами основателя LinkedIn: "вокруг ОЧЕНЬ много людей, которые хотят заполучить работу Вашей мечты" и поверьте, они не сидят сложа руки!

На сколько важно высшее образование (особенно СНГ-шное) при устройстве на работу на западе

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


        Плюс, как показывает практика, самому выучить достаточно глубоко комбинаторику, мат. анализ, CS и еще много чего - можно, но очень трудно. И, как показывает опыт, такие люди, если не уходят с инженерных позиций на менеджерские, остаются всю свою жизнь кодерами, пусть и с высокой з/п (высокой имеется в виду не для нормального инженера, а для стороннего наблюдателя), но все же обычными кодерами, которых я бы не называл ни инженерами, ни программистами. В Украине на данный момент потолок для таких кодеров - 4-5 тысячи $ в месяц, и такую цифру еще надо заслужить. Но это потолок, потом или в менеджеры, или все-таки начать учить более глубокие дисциплины. А то будет как-то так:

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

4 комментария :

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

    Самостоятельно никак :) Кто как не друг подарит тебе замечательное: "Я тут разложил свой код в вот этих двух ветках. Сделай мердж пожалуйста"?

    ОтветитьУдалить
    Ответы
    1. :D ну оно то да, соглашусь, но освоить git и уметь мержить все же можно=)

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

    А в чем разница между "кодером", "инженером" и "программистом"? Может "инженер" это обобщенное слово для людей с техническим образованием, тогда как "кодер" это просто модное слово, но в общем это все про одних и тех же людей?

    ОтветитьУдалить
    Ответы
    1. Я думаю что Инженер умеет решать Архитектурно-алгоритмические проблемы, а кодер вооплощать их на каком либо конкретном языке. Часто один человек может делать обе задачи но хорошие Инженеры очень часто не самые лучшие кодеры =) и наоборот. трудно поддерживтаь свои занния МатАнализа если ты постоянно читаешь про JVM и наоборот

      Удалить