Lynx12

На Пикабу
Дата рождения: 01 января 1980
поставил 314 плюсов и 949 минусов
отредактировал 0 постов
проголосовал за 0 редактирований
6636 рейтинг 74 подписчика 56 подписок 2 поста 2 в горячем

Про собеседования в IT (для новичков)

Disclaimer

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


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


Пост может быть интересен новичкам, у которых еще или мало или совсем нет опыта собеседования именно в IT. (Для опытных коллег все наблюдения / советы могут показаться как “само-собой-разумеющиеся” и очевидными).



Assumptions

Для удобства и упрощения буду использовать несколько усредненных допущений:

1. Вы собеседуетесь в зрелую компанию, со здоровым/адекватным руководством и коллективом, зрелыми процессами и профессиональным HR

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



Приглашение на собеседование

Удобно выделить 2 принципиально разных варианта попадания на собеседование:

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

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


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


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


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

Т.е. в IT это значит - все проекты в работе, команды укомплектованы и работают по плану.

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


Поэтому, если вами заинтересовались, то это может значить, что

- или в компании планируются изменения (кто-то планирует уход, команде требуется расширение, планируется новый проект)

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


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

(Это дорого, но это стоит того, если в итоге человек очень хорошо впишется в компанию и проработает там несколько лет).


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



2-ой вариант. Вы откликнулись на запрос компании.

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

(это довольно дорогостоящий процесс (привлечение нового специалиста может стоить и 5-10 тысяч евро, а эффективность нового ресурса в полной мере может проявиться только через полгода), поэтому уже начало массовой рекрутерской кампании - это показатель, что этот процесс запланирован и посчитан, а значит есть сроки и цели)


Процесс инициализации рекрутинга в IT разработке происходит примерно так (самый популярный вариант):

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

- Он рассчитывает сколько человек ему нужны, с какими квалификациями, на какое время и по каким рейтам (цене).

- Для повышения шансов и уменьшения рисков он готовит несколько вариантов комбинаций (напр.: (10 сеньоров, 40 миддлов, 5 джуниоров) или (5 сеньоров, 50 миддлов) и описание необходимых навыков для каждой роли) - разные комбинации имеют разные стоимости для его бюджета но также и разные шансы для нахождения. Это его зона ответственности.

- Дальше может начаться т.н. процесс внутреннего рекрутинга, это когда заявка может отправиться гулять по внутренним структурам Resource Management’а - может оказаться, что людей смогут найти в самой компании (кого-то взять с бенча, кого-то с другого проекта на время, кого-то командировать из другого офиса)

-Или же заявка идет в отдел рекрутинга и начинается процесс внешнего рекрутинга (привлечение извне, через рекламу, объявления).


Важно понимать:

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

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


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

А т.к. за рекрутинг Project Manager часто платит сам (из бюджета проекта), то он лично заинтересован в максимально эффективном поиске и собеседованиях.


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

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

Или перечислить разные плюшки в компании (идет из бюджета или отдела или компании в целом).



Изменения на рынке IT после Ковида

Ковид, а точнее связанный с ним локдаун, серьезно повлиял на рынок IT (как минимум в странах ЕС).


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


Спрос на онлайн-сервисы, информационные системы, перестройку бизнес процессов - вырос в разы.


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

(а еще активизировались head-hunter’s (те, кто специализируются на переманивании из других компаний, но это другая история))


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


И стал формироваться рынок, на котором спрос сильно превышает предложение.

А предложение стало отличаться от привычного ранее

(если лет 5 назад джуниор это почти синоним парня лет 18-20-ти, у которого просто физически еще не было времени наработать опыт, то сейчас это вполне может быть зрелый специалист 40-ка лет, вынужденный сменить работу (и в чем-то он даже и привлекательнее 18-ти летнего (самодисциплина, ответственность, сторонние знания)). А т.к. IT очень прагматичен и ориентирован на бизнес, то: “подходишь под требования? Берем!”)


Поэтому после ковида, воронка выбора в IT рекрутинге стала примерно такой (реальный список на примере стран ЕС):

1. Берем того, кто по навыкам и опыту идеально попадает под проект

2. Берем того, у кого есть все нужные навыки (можно без большого опыта)

3. Берем того, у кого есть хотя бы часть нужных навыков

4. Берем того, кто хотя бы делал что-то похожее

5. Берем того, у кого хотя бы в бекграунде есть что-то про IT

6. Берем того, у кого хотя бы есть хоть какое техническое образование / опыт

7. Берем все равно с каким опытом, если только хочет работать в IT, адекватен и готов учиться


Можете представить состояние рынка, если IT компания на полном серьезе рассматривает 6-ую и 7-ую строчки (любой рекрутинг - это всегда прямые расходы для компании)?


Кого из списка называть “джуниором” - даже не важно т.к., компания может и не искать “джуниора” как такового. Ей нужен кто-то, “у кого есть определенные навыки и кто сможет делать определенную работу”.

То, что эту позицию маркируют как “junior” - это может быть просто некая конвенция для удобство рекрутеров и самих кандидатов, чтобы упросить фильтры поиска.


Полезно:

Во время собеседования попробуйте понять, вот вы для этой компании/проекта - на какой строке списка воронки выбора находитесь?

И если окажется, что вы не на первой, то интересно для себя подумать: “а почему тогда компания тратит свои деньги на общения с вами?”

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


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


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



Первое собеседование

Ок, вы получили приглашение на первое собеседование.


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


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


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


Но если HR опытный и умеет адаптировать какие-то техники под местную реальность - они могут работать.


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

Позже, после собеседования, можно будет обдумать и сделать дополнительные выводы.


(Например, самое начало.

Первый митинг - он по онлайн-конференции или вас пригласили в офис?

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

(напр. когда приглашают в офис - это может быть косвенная цель “продать” вам компанию, а онлайн-звонок - проявление уважения вашему времени. А может и ничего не значить.

В офисе вас HR может попросить в процессе что-то нарисовать фломастером на доске, а вы берете фломастер и понимаете что он не пишет. Это что? HR хочет проверить вашу реакцию? Или он просто забыл перепроверить, что в кабинете все есть и все работает)).



Интервью. Сколько и какие?

Во время рекрутинга есть серия областей, которые рекрутерам важно проверить по каждому кандидату:

- Проверить на общую адекватность

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

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

- Оценить, насколько человек впишется в компанию, команду, насколько ценности и культура близки вам или нет

- Оценить, что самому человеку интересно и понравится ли ему в проекте, куда ищут людей, или скорее нет и они могут предложить что-то еще?

- Опционально: проверка на что-то специфическое: стрессоустойчивость, креативность, чувство юмора и т.д.


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


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

(Можно уже про себя отмечать, какие области проверили и примерно предположить потребуется ли еще одна сессия или нет)



Собеседование Онлайн или Оффлайн, что лучше?

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


Но в большинстве случаев форматы взаимозаменяемы.


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


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

Совет: если хотите держать “eye contact” (зрительный контакт) и хорошо выглядеть, то при ответе надо смотреть не на собеседника, а в камеру.


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



Само собеседование

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



На что можно обратить внимание, о чем важно помнить:



1. “Кто все эти люди?”

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


В любом случае:

- По-хорошему HR должен всех представить, чтобы вы понимали, кто перед вами, зачем он здесь и что от него ожидать (напр. “Это Йонас, наш архитектор, он задаст вопросы по технологиям”) (можно про себя отметить что к вам пригласили целого архитектора, интересно почему)

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



2. План интервью

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

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



3. Сами вопросы

За часовое интервью можно успеть задать 15-20 хороших вопросов (над которыми стоит подумать, дать развернутый ответ и ответить на комментарии)

Это очень, очень мало для всесторонней оценки.


Поэтому для технического интервью (или проверки hard skills) могут выделить и отдельную сессию (часто так и делают, за редкими исключениями. Напр. т.к. у джуниора априори немного знаний, то опытному техническому специалисту хватит несколько коротких вопросов, чтобы прикинуть его уровень - тогда HR может совместить оба интервью в одно).


Есть ряд тем/вопросов от HR, которые спрашивают с большой вероятностью и их полезно продумать заранее и сделать рассказ более интересным, запоминающимся:

- Это вопросы про “расскажите про себя” - может быть как вводный для начала общения, или чтобы проверить - будете сухо повторять факты CV или добавите что-то новое.

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

- Вопросы про “карьерные цели“ - могут задаться, чтобы понять, как надолго вы планируете быть в IT в целом и на этой позиции в частности (любой ответ не хорош и не плох, это как некий дополнительный маркер. Это ведь ваши цели)

- Вопросы про “увлечения вне работы” - могут задать просто так, для расслабления (людям порой нравится говорить о себе), или чтобы косвенно проверить, увлечения социальные или нет, или найти дополнительную зацепку (“любите настолки? Мы каждый месяц делаем вечер настолок с пивом и пиццей!”)


Важно помнить: собеседование - это НЕ экзамен. Компания оценивает вас, вы оцениваете компанию. Если собеседование превращают в “экзамен” (вас бомбардируют вопросами и не дают ничего сказать / спросить), то это означает, что рекрутеры или составляют быстрый профиль (актуально когда например кандидатов сотни и нет времени подробно с каждым общаться) или это косяк HR.


Если заданный вопрос глупый или неуместный - это косяк HR (он только что зря потратил один из своих 15-20-ти вопросов).


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

Хотя под такими вопросами HR чаще интересует не ваше личное мнение, а умение отделять свое мнение от интересов компании, если они не согласуются.



4. Next steps (Следующие шаги)

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

(при небольшой сноровке можно оценить удалось ему это или нет)


Дальше он должен сказать как будет выглядеть процесс дальше.

(все что угодно в стиле: “мы рассмотрим и свяжемся в течении 2-ух недель”)

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


Внутри же, “следующий шаг” определяется тем, как собеседование прошло и чем закончилось. Если рекрутер свои цели не выполнил (не проверил все по списку), то он может сразу назначить след. интервью (так еще делают, когда на следующий раз планируется общение с другим специалистом).

Если же все задачи выполнены, ему останется оформить результаты, написать заключение и… дальше 2 популярных варианта: или результаты сразу идут к заказчику (напр. Тому Project Manager который инициировал рекрутинг), или подождет пока закончится неделя и вышел общим пакетом, чтобы было проще сделать выбор.

Вот отсюда определяется время на ожидание.

(косвенно по последней фразе можно прикинуть - с вами уже все и теперь только ждать, или будут еще сессии)


Этот момент достаточно рискован для компании: множественные интервью, время “на подумать” - все это удлиняет рекрутинг и повышает шансы что вы раньше найдете другую работу. Т.е. Это уже конкуренция с другими компаниями.

Поэтому показатель эффективности процесса рекрутинга в компании - это в том числе и умение выдержать этот баланс.



Техническое интервью.

Обязательный этап проверки hard skills, который есть почти всегда (кроме очень редких случаев, когда уровень и так понятен (знаний / опыта почти нет, или наоборот куча престижных сертификатов или люди уже знакомы - бывшие коллеги))


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


Даже если на техническое интервью выделили отдельную часовую сессию, то это все равно те же 15-20 открытых вопросов. Полноценно проверить знания за такой срок - невозможно.

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


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


К каким вопросам готовиться?

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

Именно по ним чаще всего и будут строить интервью.


В интернете можно встретить кучу статей на тему “как подготовиться к техническому интервью на <название_технологии>” - там можно подсмотреть хорошие вопросы и ответы (м.б. забавная ситуация, когда приходите на интервью и оказывается, что и технический специалист, который должен вас проверять, читал ту же статью и распечатал ее для собеседования).


Вопросы часто могут строится по схемам:

- “Расскажите, что такое <...>? Для чего это используется?” (один из самых простых типов вопросов, т.к. что-то вы наверняка знаете и сможете рассказать)

- “Сравните <...> и <...>. Что лучше / хуже и для чего?” (чуть сложнее, т.к. тут может оказаться, что про одну часть знаете хорошо, а про вторую - впервые слышите)

- “Если вам потребуется <какое-то сложное действие или цель>, как поступите?” (сама цель может быть очень техничной и искусственно сложной. Тут уже нужен или практический опыт, которого может не быть, или хотя бы теоретические знания, что можно попробовать.) (Но для уровня джуниора на подобные вопросы, если не уверены, вполне можно отвечать в стиле, что попробуете разобраться сами, а потом обратитесь к коллегам за помощью)

- “<какая-то проблема, вызов>. Как будете решать?” (тут часто может не быть одного правильного ответа. Есть ответ который от вас ждут, но он не всегда единственно возможный.) (но для джуниора вариант ответа с эскалацией вполне может быть ок)


В любом случае техническое интервью в какой-то степени “угадайка”. Вам достанутся или знакомые темы или нет.


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

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


На что полезно обратить внимание:

- Тот кто вас собеседует - вообще готовился или увидел ваше CV только сейчас и выдумывает вопросы из головы?

- Как вы сами оцениваете качество вопросов? (если вопрос энциклопедический хочется ответить: “не знаю, если потребуется нагуглю” - так и говорите. Это может быть недосмотр спрашивающего)

- Следите за временем. Если на какой-то вопрос ответили быстро или вообще не ответили - значит на другой вопрос у вас будет больше времени

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

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



На что ещё полезно обращать внимание

Есть ряд моментов на которые интервьюеры обращают внимание в процессе собеседования, и на которые стоит обращать внимание и самому.

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

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

- Тайминг (время). Как правило все собеседования распланированы (обычно это 1-2 часа), и распланированы по времени их составные части (если за одну сессию планируют проверить несколько областей). Если видите, что выходите за рамки - скорее всего что-то не так с процессами или навыками HR.



Несколько общих советов / наблюдений

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

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

Поэтому вы вполне можете ожидать от него профессионального отношения.

(собеседования пройдет хорошо и у вас останутся приятные воспоминания)


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

Для компании - каждое собеседование это еще и возможность “продать себя”).

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

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


IT разработка - это всегда про деньги. Организация интервью, найм нового сотрудника - это расходы. Пригласить еще одного интервьюера на собеседование - это опять расходы. Организовать 2-ое, 3-е, 5-ое собеседование - это опять расходы.

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


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


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

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


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



(В итоге статья про собеседования получилась больше, чем планировал, но меньше, чем можно было бы еще написать. Если про какие-то аспекты будет интересно узнать подробнее/дополнительно - welcome!)

Показать полностью

Как зайти в IT после 30+(40+)? (взгляд изнутри)

Intro


Периодически на ресурсе можно встретить авторские истории в стиле: “Как я стал разработчиком на Х в 30 лет” или “Как я перешел в IT на позицию Y в 40 лет” и т.д.

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


Работая в IT (software development) больше 25 лет в разных компаниях (западные, до 10к. человек) на менеджерских позициях, я наблюдал кого компании ищут, как происходит отбор, как кандидаты себя ведут на интервью и как они меняются попадая в команду, кто в итоге остается, а кто нет.

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


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



Scope Definition


Для кого это?

Зачем люди вообще идут в IT? Цели у каждого, конечно же, могут быть разные.

И логично, что от цели и причин будут зависеть и весь остальной выбор и следующие шаги.


Но я бы хотел сфокусироваться на 2-х самых популярных и прагматичных целях, которые можно встретить:

1. Возможность работать удаленно (актуально для тех, у кого в месте их проживании не очень хорошо с доступной работой offline. Актуальность особенно выросла в период локдауна во время ковида);

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



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


С чего начать?

Общий большой план может выглядеть примерно так:

1. Выбираем позицию(роль) на которую хотим пойти;

2. Изучаем минимально необходимый объем материала (+получаем первый тестовый опыт);

3. Выбираем компанию;

4. Проходим собеседования;

5. Пытаемся удержаться;

6. …

7. Profit?


(Пункты 1-3 могут быть в разной последовательности, т.к. все действительно зависит от стартовых условий.)



Задайте себе простые вопросы:

1. Я уже знаю кем точно хочу быть и чем заниматься?

2. Или может я уже что-то умею и/или хочу на чем-то специализироваться?

3. Или может есть компания, в которую я хотел бы попасть и не важно кем?


(если уже что-то известно, то от этого и проще отталкиваться)


Важно:

Эмпирически, минимально-реальное время на первоначальное обучение - это месяцев 3-6.

И с вами уже могут начать разговаривать на собеседованиях.


Но это если ориентироваться на full-time (полный рабочий день) на обучение. Если планируете оставаться на текущей работе и учиться параллельно, то на обучение может потребоваться год или два.


Но как обычно, нюансы в деталях.



Поэтому чуть подробнее по пунктам.



Кем быть? (О ролях)

-Кем ты хочешь быть в IT?

-Не знаю, а кем можно?

(реальный диалог)



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

Когда говорят об IT, то самые популярные позиции которые на слуху - это “программисты” и “тестировщики” (которых еще ошибочно называют QA)


Но конечно же, мир IT гораздо шире.

В целом IT сейчас это больше про “информацию” и ее обработку, чем про технологии как таковые.


Процесс разработки. Как это происходит и кто участвует?

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


Процесс разработки (инициализация)

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

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


Процесс разработки (реализация)

Дальше идет собственно сам этап разработки.

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


В целом, общий процесс разработки выглядит примерно так:

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

- системные аналитики превращают требования в описания проектировок,

- UI/UX дизайнеры рисуют пользовательские интерфейсы,

- архитекторы, на основе общих проектировок, создают технические описания реализации, (архитектуры) и реализуют базовые вещи: основные интерфейсы/компоненты/фреймворк/базу данных и т.д.,

- программисты, на основе базовых вещей, дальше реализуют весь основной функционал по описанию аналитиков,

- тестировщики проверяют соответствие реализации требованиям,

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

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


Процесс разработки (поддержка)

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

- Специалиста поддержки (1st line support, 2nd line support) - которые обрабатывают заявки от пользователей (проблемы, вопросы, улучшения) и помогают/направляют на разработку


Процесс разработки (дополнительные роли)

Еще добавьте

- всевозможных узких специалистов/консультантов которые нужны только в конкретном проекте (блокчейн, GDPR, искусственный интеллект, BigData, эксперты предметных областей и т.п.),

- возможных social специалистов, вроде Mental Health specialist (что-то среднее между психологом и коучем который следит чтобы в проекте никто не перегорел - обычно он один на организацию)


Оберните сверху всевозможными

- менеджерами процессов,

- дополнительными службами управления качества и

- безопасностью,


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



Так что же выбрать?

Вот во всем этом вы где себя видите???


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

- “Не знаю, но вот точно не <название_роли>, потому, что <причина>!”

- “Не знаю, но вот это, <название_роли>, кажется интересным и я бы попробовал”

- “Просто не знаю”. (А что проще? Или что я смогу научиться делать?)



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

В идеальном варианте, нормальное распределение: 1 человек = 1 роль.

Но довольно часто бывает, что в конкретном случае (проекте/компании) выделенная роль не требуется вовсе или требуется в ограниченном виде (или компания просто пытается сэкономить).

Тогда роли начинают объединять.

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

И это одна из причин почему можно услышать мнение что “в IT надо очень много знать и уметь делать кучу разнообразных вещей”


Если сразу нет каких-то предпочтений и хочется выбрать с позиции “минимального времени на обучение”, то по наблюдениям самый низкий порог эффективного вхождения (из популярных ролей), это роли:

1. Поддержка пользователей (1st/2nd line Support specialist)

2. Тестировщик

3. Программист



Что изучать? (О скилах)


Условно все навыки можно на hard skills (технические) и soft skill (не технические).


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

Хотя это как раз и не важно. Вернее не настолько важно, как может думаться.


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


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


Что касается развития hard skills как таковых, то для всех кто не "программист / администратор” процесс первоначального обучения достаточно straightforward (прямолинейный):

для аналитиков есть их BABOK, для 1-st line суппорта - ITIL, для тестировщиков - ISTQB, для QA и прочего качества - CMMI, ISO, IEEE, для менеджеров PMI/Agile, и т.д.)


А вот для программистов и администраторов все гораздо сложнее и не тривиально.

Потому что это уже ТЕХНОЛОГИИ!


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



Технологии (как выбрать?)

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


Конечно, если хочется быть на переднем крае (on the bleeding edge), или в модерновом стартапе, то да, важно следить за трендами и вовремя переключаться.

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

А вот в конкретных компаниях/проектах все может быть совсем не так.


Т.к. при переходе в IT потом придется где-то работать, то эффективным может быть для начала посмотреть, какие сейчас есть актуальные вакансии и что там перечислено? (совпадающие названия и будут теми технологиями которые сейчас “популярны / востребованы”)

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



Технологии (как начать изучение)

Ок, допустим смогли определить с какой технологии попробовать,

что дальше, с какой книги/курса начинать изучение, так, чтобы это было эффективно?


И тут нет “серебряной пули” (идеального решения). Т.е. для начала можно пробовать любую доступную книгу/курс/ресурс для новичков (где есть слова for dummies, за 24 часа, 30 дней, или любую другую - для начала это не принципиально).


Важные критерии на этом этапе:

1. Понимать, что там написано (т.е. чтобы сам язык был доступным для понимания)

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


На этом этапе первичная цель - просто начать что-то изучать, попробовать что-то сделать и оценить ощущения:

1. Было ли легко разобраться? Или наоборот приходилось продираться?

2. Было ли интересно разбираться? Или безразлично?


Потом, для сравнения, попробовать другую технологию и сравнить ощущения.


В идеале - найти то, что будет доставлять удовольствие от процесса (или, как минимум, легко изучаться).

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


И если работа вас “не прет”, то продолжать конечно же можно, просто может быть чуть сложнее.



Технологии (продолжение обучения)

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


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

Хотя конечно эта грань “я уже умею достаточно хорошо программировать, чтобы работать или еще нет?” во многом субъективна и условна.



Есть и вполне объективные критерии именно на знания (не навыки), которые одинаково могут признаваться и коллегами и компаниями.

Это официальные сертификации. А курсы для подготовки так же можно рассматривать как вариант обучения.

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

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



(продолжение следует)

Показать полностью
Отличная работа, все прочитано!