^{Картинка взята из видеоролика с канала Воинствующие Аметисты}

Около 10 лет я работал системным программистом под Linux. Это модули ядра (kernel space), различные демоны и работа с железом из пространства пользователя (user space), различные загрузчики (u-boot и др.), прошивки контроллеров и многое другое. Даже иной раз случалось пилить web-интерфейс. Но чаще бывало, что приходилось и с паяльником посидеть, да с проектировщиками печатных плат взаимодействовать. Одна из проблем такой работы это то, что достаточно сложно оценить уровень своей компетенции, поскольку одну задачу ты можешь знать очень глубоко, а рядом можешь не знать совсем. Единственный адекватный способ понять куда идти, и какие течения сейчас есть это ходить на собеседования.
В данной статье хочу обобщить мой опыт похода по собеседованиям на вакансию системного программиста linux, особенности интервью, работы и как по общению с будущим работодателем оценить личный уровень знаний и чего от этого ожидать не стоит.
В статье будет небольшой конкурс с призами.

Особенности профессии

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


Типичное рабочее место системного программиста.

На фото выше моё типичное рабочее место в момент отладки драйверов. Логический анализатор показывает корректность передаваемых посылок, осциллограф контролирует форму фронтов сигнала. Так же в кадр не попал jtag-отладчик, который применяется тогда, когда стандартные средства отладки уже не справляются. И со всем этим парком оборудования необходимо уметь работать.
Часто бывает, что перепаять какие-то элементы, исправить ошибки топологии быстрее и проще самому, чем носить изделие монтажнику. И тогда на твоём рабочем месте поселяется ещё и паяльная станция.
Ещё особенность разработки на уровне драйверов и железа заключается в том, что гугл не помогает. Часто приходится искать информацию по своей проблеме, а там три ссылки, из которых две это твои же вопросы на каком-то форуме. Или ещё хуже, когда встречаешь вопрос такого же бедолаги, который задавал его 5 лет назад в списке рассылки ядра, да так и не получил на него ответа. В этой работе, кроме ошибок в проектировании как аппаратной части, так и программной, сплошь и рядом встречаются ошибки документации это наверное самые лютые и неприятные проблемы. Бывает некорректно описаны регистры, либо вообще отсутствует описание на таковые. Такие проблемы решаются только методом научного тыка случайных чисел в определённые регистры (этакий реверс). Часто бывает ещё такое, что в процессоре заложен какой-то функционал, а кроме тебя этот функционал никто не реализовывал (особенно, если процессор новый). И это хождение по полю с граблями, из которых 70% детские. Но когда есть документация, даже с ошибками это уже прогресс. Достаточно часто бывает, что документации вообще нет, и вот там начинается хождение уже по минным полям, когда горит железо. И да, такие задачи тоже с успехом решал.

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

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

• расскажите о себе;
• у нас такие задачи;
• вам нравится?

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

Задачи на собеседованиях

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

Вопросы 1

I. На знание СИ. Что означают следующие записи:

const char * str;char const * str;const * char str;char * const str;const char const * str;

Все ли записи корректны?

II. Почему эта программа выдаст ошибку сегментации?

int main (){       fprintf(0,"hello\n");       fork();       return(0);}

III. На сообразительность.

Имеется палка длинной в один метр. На неё случайным образом падают десять муравьёв, которые ползут в разные стороны. Скорость движения одного муравья 1 м/с. В случае если муравей встречается с другим муравьём, то он разворачивается и ползёт в противоположную сторону. Какое максимальное время нужно прождать, чтобы все муравьи упали с палки.

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

Вопросы собеседования 2

Аппаратные вопросы.

• Как устроены системные вызовы linux на языке ассемблера на ARM-процессоре, на х86. В чём отличие?
• Какие средства синхронизации бывают? Какие средства синхронизации можно использовать внутри контекста прерывания, какие нет и почему?
• Чем отличается шина i2c от spi?
• Для чего на шине i2c стоят терминаторы и какой их номинал?
• Может ли интерфейс RS-232 работает ТОЛЬКО по двум проводам: RX и TX? Тут дам ответ: Оказывается, что плохонько, на 9600, но может!!!
• А теперь второй вопрос: почему?
• Как лучше располагать сигнальные линии и питание в многослойных платах и почему? Питание внутри слоёв, или сигнальные линии внутри слоёв? (Вопрос вообще сугубо по схемотехнике).
• Для чего у дифференциальных линий дорожки идут везде вместе?
• Шина RS-485. Обычно на такой линии есть терминаторы. Однако, у нас схема звезда, с переменным количеством подключаемых модулей. Какие средства избежания коллизий и помех нужно использовать?
• Что такое красное и бинарное дерево?
• Как работать с cmake?
• Вопросы о сборке yocto linux.

Задачи на этом собеседовании:

1. Написать функцию, которая инвертирует в uint32_t все биты. (работу с битами очень любят на собеседованиях, рекомендую)
2.

int32_t a = -200;uint32_t b = 200;return *(uint32_t * (&a)) > b

Что вернёт данная функция? (решение на бумаге, без ЭВМ)
3. Функция расчёта среднего арифметического двух чисел int32_t.
4. Какие способы вывода в программах, в т.ч. в поток ошибок.

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

Вопросы собеседования 3

1.Приводится пример кода обхода дерева, необходимо рассказать что делается в данном коде и указать на ошибки.
2.Написать пример утилиты ls. С простейшей опцией -l.
3.Привести пример как сделать статическую и динамическую линковку. В чём разница?
4.Как работает RS-232? Чем отличается RS-485 от RS-232? В чём отличие RS-232 от RS-485 с точки зрения программиста?
5.Как работает USB (с точки зрения программиста)?
6.Перевод технического текста с русского на английский язык.

Успешное собеседование не залог успешной работы

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

Выводы

Программисты, ходите на собеседования! Причём старайтесь идти всегда на повышение. Допустим, если вы получаете N денег, то идите на собеседование минимум на оплату N*1,2, а лучше N*1,5. Даже если вы не возьмёте эту вакансию сразу, то поймёте что же нужно для этого уровня оплаты.
Мои наблюдения, показали что решает хорошее знание английского языка, достаточно богатый опыт работы в отрасли и уверенность в себе. Последнее это главное качество, как и везде в жизни. Как правило, более уверенный кандидат может успешнее пройти собеседование, даже при наличии большего количества ошибок, чем отличный, но более стеснительный и инициативный соискатель. Удачи на собеседованиях!

P/S Конкурс

Если у вас есть интересные примеры задачек, которыми вас загрузил HR, то welcome в комментарии. Мы подготовили небольшой конкурс условия просты: вы пишете самое необычное задание которое у вас было на интервью, читатели проводят его оценку (плюсом), а мы через неделю подводим итоги и награждаем победителя весёлыми ништяками.

Как готовиться ксобеседованиям, чтобы устроиться вкомпанию уровня FAANG? Вместе сОлегом Громовым, фронтенд-инженером излондонского офиса Facebook (ex. Yandex, Toptal etc.), составили план подготовки помотивам прошедшего вебинара опираясь наего личный опыт.

Обсуждаем:

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

FAANG аббревиатура Facebook, Amazon, Apple, Netflix, Google, название, насколько язнаю, появилось 35 лет назад. Это были компании снаибольшей капитализацией вIT. Они как планка, докоторой все пытаются дотянуться: если дорос доFAANG, товыше только звёзды. Многие инженеры хотят туда попасть: большие зарплаты, хорошие условия, возможности для развития это лучшее, что бывает вмире среди корпораций.

Кто-то включает Microsoft, Uber, Airbnb, кто-то пытается перенести термин нароссийские крупные tech-компании: Яндекс, Mail.ru, Авито, ABBYY. Намой взгляд, вFAANG они невходят, само понятие только про перечисленные выше tech-гиганты.

Ноесть фаанговский стиль собеседования, иэто другая история. Стиль переняли многие компании, которые наFAANG непохожи ниразмером, ниприбыльностью. Всобеседование входят 4ибольше секций, которые включают: алгоритмическое интервью, system design, behavioral-интервью. Подготовившись ктакому собеседованию, выможете устроиться ивкомпании помимо FAANG: формат становится знакомым. Предлагаю использовать этот широкий подход, будем говорить окомпаниях, которые собеседуют пофаанговской структуре.

Плюсы иминусы работы вкомпаниях уровня FAANG

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

Плюсы:

• развитие.
  Если выочень любите свою работу, если вам хочется челленджей исложных проектов, хочется развиваться иобщаться сбольшим количеством людей, втом числе случшими специалистами.
  Первое, что понял, когда попал вЯндекс: все вокруг умные, аянет. Это типичная история, тоже самое происходит, когда устраиваешься вGoogle, Facebook: вкрупных компаниях очень питательная среда для роста. Особенно для людей, заинтересованных невпостроении бизнеса, авразвитии себя как специалиста.
• Стабильность, хорошая зарплата.
  Ещё разработчикам дают RSU restricted stock unit, особый вид денежного вознаграждения. Обычно люди ихтутже конвертируют вденьги завычетом налогов. Так что RSU своего рода прибавка кзарплате. Теденьги, которые яполучал RSU-шками вЯндексе откладывал, апотом пожил наних полгода вШтатах без работы.
• Статус.
  Можно сказать: яработаю вГугле! Иэто звучит круто.

Минусы зависят оттого, какой вычеловек ичего вам хочется отжизни. Основной: нестоит устраиваться вFAANG, если вам ненравится быть винтиком вмеханизме, причём механизме сильно регламентированном.

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

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

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

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

Если ищете позиции срелокейтом, подписывайтесь нанаш бот @g_jobbot. АIT-рекрутер в gmate поможет упаковать резюме так, чтобы заинтересовать интервьюеров. Бот просто ибыстро настраивается: сфера, зарплата, локация релокейт. Подходящие вам варианты будут приходить вТелеграм.

Резюме

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

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

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

Убираем нерелевантное, подчеркиваем сильные стороны, весь подходящий для вакансии опыт. Невсмысле бить себя пяткой вгрудь: команда ничего несделала, всё толькоя. Задача рассказать отом, что выкомандный игрок, понимаете бизнес. Особенно если устраиваетесь напозицию разработчика высокого уровня. Отнего требуется понимать процессы командной работы, как ихналадить, как ликвидировать боттлнеки тоесть узкие места, где производительность страдает. Всё это подайте ввыгодном свете, ноневыдумывайте, говорите правду: покажите адекватные достижения, идеально, если количественно все большие компании это оценят. Например, технические достижения опишите так: время прохода тестов вContinuous Integration-среде сократилось на30%, увеличилась прибыль или конверсия тоже наN%. Расскажите прокомандные достижения: где выпомогли наладить процесс, кого икак нанимали.

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

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

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

После того, как резюме одобрили, перед 4-этапным интервью обычно есть ещё скрининг.

Скрининг

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

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

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

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

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

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

Алгоритмические секции

Следующие этапы зависят откомпании. Янесобеседовался вGoogle, Amazon или Apple. Насколько мне известно, увсех них достаточно характерные процессы, следующие шаблону, нодетали отличаются. Например, уAmazon есть Leadership Principles набор правил, который рекомендуют выучить, потому что про них насобеседовании тоже будет разговор. ВFacebook такого нет.

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

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

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

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

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

Кодинг обычно совмещён салгоритмической секцией. Причём есть небольшая разница между бэкендом ифронтендом вFacebook. Теже алгоритмы надеревьях, графах или связанные сциклами, смассивами носфронтенд-спецификой. Как правило, всё наJavaScript. Выбор языка достаточно свободен. Когда собеседовался вдругую компанию, писал наС# хотя доэтого никогда его неиспользовал. Нотак как онобъектно-ориентированный ипохож наJava, тояпросто уточнял впроцессе: вот так можно? Атак?

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

Адальше бывает system design-интервью иbehavioral: ясталкивался только стакими этапами.

Где готовиться

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

• Leetcode бесплатен для подборок задач воткрытом доступе. Там есть платные подборки, есть премиум аккаунт, где можно найтито, что замесяц довас спрашивали насобеседованиях вFAANG.
• HackerRank
• Codility
• Interviewing.io
• Codewars
• AlgoExpert

Архитектурная секция: system design

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

Секция открытая, проблема неставится также, как взадачах наалгоритм. Одновременно важны иsoft skills: умение поговорить, вывести ипринять решение, спроектировать конкретную систему. Когда говорят про System Design, обычно идёт речь про дизайн чего-то высоконагруженного: надо сделать Твиттер или Инстаграм. Разумеется, за40минут нельзя спроектировать полноценный Твиттер.

Бывают испецифические задания: сделать форму ввода савтокомплитом. Вслучае сфронтендом может быть что-то типа: спроектируйте фронтенд для Яндекс.Карт: как выструктурируйте код, какие будут компоненты, какая подчиненность компонентов друг другу. Можно говорить про доставку контента для пользователей, CDN.

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

Если сравнивать сproduct design, думаю, вsystem design акцент натехнические требования, умение оперировать стандартными понятиями: какая будет нагрузка, какой скорости нужны жесткие диски, чтобы система работала. Product design, видимо, больше про умение вас как инженера договориться спродукт-оунером, дизайнером, приоритезировать идеи, возможно, провести эксперименты. Это скорее про бизнесовую составляющую иорганизацию работы. Уменя небыло product design, допускаю, что поговорите опродукте, ценностях, проблемах отом, что обычно является областью ответственности продакт-менеджеров.

Где готовиться

• Interviewing.io дают возможность проходить анонимные интервью слюдьми, которые работают вFAANG. Шифруется голос ивидео. Задают вопросы, просят решить задачу.
• раздел System Design наAlgoExpert
• раздел System Design наPramp
• Educative.io
• FAANG Interview. Бортовые заметки сообщества. Раздел про system design
• Видео Jackson Gabbard про system design

Что важно ивпроцессе всего собеседования, инаbehavioral-части

Soft skills

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

Расскажите осебе?
Ну, япрограммист.
Ачем вызанимаетесь?
Делаю сайт.

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

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

Ятак начал делать ещё давно, когда впервые готовил презентацию. Мне надо было всё рассказывать устно, аяписал текст выступления вдокументе. Письменная речь совсем несоответствовала устной, получалось нелепо инеказисто. Тогда ясел стелефоном можно сдиктофоном, можно перед зеркалом истал репетировать: где-то раз надесятый речь стала связной ипонятной.


Я рассказываю про парсер HTML, написанный в самолёте по пути на офсайт.

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

Английский язык

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

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

Яучил английский напротяжении 10лет, ивсегда думал, что уменя сносный уровень, особенно технического языка: читал мануалы, как все. Нов2016 году поехал вНью-Йорк ипонял, что непонимаю ничего. Просто неслышу, что мне говорят это меня шокировало. Затрудняюсь сказать, какой втот момент был уровень, наверное, В1, upper-intermediate. Нояпрактически непонимал носителей итерялся внасыщенном разговоре.

Явывел для себя критерии, покоторым можно понять, что уровень подходит для прохождения интервью. Если натехнической конференции выпонимаете 5070% того, что говорит выступающий иможете за12 минуты рассказать про свой проект так, что вас поймут этого должно хватить. Успикеров обычно очень внятный язык, без сильного сленга ипроглатываемых звуков. Для собеседования сертификаты ненужны, нопонадобятся для переезда вВеликобританию. Уровень формальный, В1или В2 если учить снуля, накаких-нибудь курсах можно дорасти донего загод.

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

Как готовиться

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

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

Итоги

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

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

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

Что почитать дополнительно:

• Статьи Олега наVC.ru
• Канал Олега вТелеграме
• Русскоязычное сообщество вТелеграме для подготовки кинтервью
• FAANG Interview. Бортовые заметки сообщества (Google Doc)
• Как устроиться вкомпанию мечты вСША: советы продакт-менеджера (Хабр)
• Изсоискателя внаниматели: продакт советует, как проходить интервью вСША (Хабр)
• Netflix за45минут: Краткий рассказ оsystem design-интервью, чего ожидать + подборка полезных ссылок (Хабр)
• Amazon vsMicrosoft: чем отличается процесс собеседований вкрупных ИТ-компаниях (Хабр)
• Что такое soft skills для инженера в2020году, зачем икак компании ихпроверяют насобеседованиях (Хабр)

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

Унас вg-mate минимум 3050% готовы рассматривать ремоут, арелокейт среди локаций навторой месте попопулярности. Завремя пандемии ивРоссии, изарубежом наём ускорился в3раза. Регистрируйтесь вботе, чтобы получать лучшие вакансии вtech прямо вТелеграм.

Спросили Алексея Петрова pifagor_mc, Head ofQAСбермаркета, про интервьюQA-инженеров изаписали ответы. Аещё для подготовки прикрепили ссылки, которые онсоветовал ищите ихвконце статьи.

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

• какое резюме прочитают внимательно, какое закроют через пару секунд,
• очём спросят наинтервью вас иочём стоит спросить работодателя,
• какие soft skills прокачивать QA-инженеру
• икак обсуждать зарплату наинтервью.

Про метрики качества продукта, смерть QA смотрите взаписи вебинара наЮтубе.

3основные рекомендации посоставлению резюме для QA

1. Объём неболее 1,5страниц. Этото, что бросается вглаза сразу резюме должно быть лаконичным. Многие пытаются написать Повесть временных лет, иописать опыт вдесятках, сотнях строчек. Старайтесь делать выжимку самого важного: больше 3листов интервьюер нечитает, лучше всего одна страница или полторы.
2. Описаны результаты. Здорово, когда резюме структурировано попринципу зона ответственности + достижения. Тоесть непросто написано, что сотрудник работал работу, участвовал втестировании, асформулирована понятная зона ответственности: зачто отвечал, что снего спрашивали. Ивработе любого специалиста существуют достижения: знаковые релизы, выпущенные фичи, карьерный рост это очень важно, надо указывать.
3. Опыт иинструменты соответствуют. Например, если человек занимался мобильным тестированием упомянут инструментарий, характерный для мобильного тестирования, прямо ключевые слова. Например, Fiddler, Charles, Android Studio, Xcode итак далее. Если тестировал бэкенд Insomnia, Postman, что-то такое. Когда видишь только опыт без инструментов, возникает вопрос, насколько поверхностно специалист знаком сработой. Инаоборот если использованные инструменты выглядят как ключевые слова без реального опыта применения. Например, указан Zabbix, аинженер всю жизнь занимался клиентским тестированием наверное, оночень мало работал сZabbix.

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

Изкаких блоков состоит стандартное интервью

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

1. Сначала представить компанию, описать процессы, рассказать про команду иожидания отбудущего коллеги. Сразу скажу, вэтой части люблю оставлять ловушки: очём-то сознательно нерассказываю, чтобы наэтапе вопросов откандидата ему было, очём спросить, амне можно было углубиться вподробности.
2. Дальше очередь кандидата: его опыт, контекст применения инструментов, методик. Как часто они вкомпании релизили, что делали, зачем, почему. Наэтом этапе меньше интересует рассказ про продукты. Иногда люди уходят вдебри, говорят про тонкости реализации архитектуры ихприложений. Это здорово, носамое важное для меня инструменты, подходы, решения различных кейсов.
3. Следующий этап собственно решение кейсов. Уменя есть своё собрание вопросов, которые использую для разных профилей: для мобильных тестировщиков одни, для специалистов побэкенду другие, для кроссфункциональных тестировщиков третьи.
4. Завершает обязательный этап свопросами откандидата. Есть такое понятие как инвертированное собеседование. Это для меня как интервьюера круче всего. Когда создается впечатление, что нетысобеседуешь, атебя собеседуют: задают вопросы, как устроен процесс разработки, что сCI/CD, как увас автотесты, акакой фреймворк, зачем, почему Вэтот момент понимаешь, что специалисту невсё равно, онвовлечён, аеще понимаешь, что его волнует. Идля себя делаешь пометки: например, человек больше смотрит вширь. Очень важно, чтобы человек задавал вопросы, которые помогалибы ему подстраховаться отошибок, которые онсовершил напрошлом месте. Если человек рассказывает, почему ушёл изпрошлой компании инасобеседовании неподкладывает себе соломки под туже причину для меня это тревожный звонок.
5. Под конец оргвопросы. Зарплатные ожидания: всегда прошу озвучить кандидатов минимум, исходя избазовых потребностей дети, семья, ипотека. Имаксимум: если учеловека есть адекватная профессиональная оценка собственных навыков, компетенций порынку это здорово. Повозможности ястараюсь прямо давать кандидатам обратную связь, чтобы уних было понимание, как всё прошло. Хотелосьбы, чтобы собеседования проходили втаком свободном формате это позволяет расстаться напозитивной ноте, даже если конкретно сейчас кандидат наместо неподходит. Уменя много примеров, когда скандидатами расстались попричине сейчас невремя, испустя какой-то период мысними работаем.

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

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

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

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

Наверное, теперь придётся исключить изсобеседований этот вопрос! Ноприведу пример. Форма авторизации: логин-пароль, всё просто. Логин помаске либо телефон, либо имейл, пароль имеет какое-то ограничение. Большинство кандидатов начинают перебирать комбинаторные варианты: введу много пробелов, ещё что-то такое. Адля пользователя важны другие кейсы: при существующем аккаунте, пускай при корректной связке логин-пароль (имейл+пароль, номер телефона+пароль) пускает, понесуществующей связке непускает. Дробить тут можно бесконечно. Почему-то забывают про кейс свосстановлением пароля. Ярегулярно сталкиваюсь стем, что забываю пароль оточередного сервиса, инадо его восстанавливать.

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

Втестировании безусловно играет роль иproduct vision. Сейчас есть такая модная штука: shift-left testing. Тестирование подключается как можно раньше, включается впроцедуру планирования, проработки требований. Такой подход всё популярнее вомногих крупных компаниях, иразумеется, что QA-инженер понимает, какое есть продуктовое видение. Пусть вбэклоге заложено 1520задач: зачем мыихделаем, какую пользу приносим пользователю взависимости отэтого строятся кейсы. Например, хотим повысить ретеншн умобильного приложения. Значит всё, что связано среактивирующими пушами для нас ввысоком приоритете. Поэтому они должны работать идеально, как часы: приходить ровно, таргетировать человека втоместо, куда должны, итак далее. Безусловно, QAдолжен понимать, зачем икак это происходит.

Есть альтернативный подход: shift-right testing. QA-инженер неначинает работу, когда тикет приходит всостоянии ready for test подключается раньше, инебросаетеё, когда тикет перешел вtested. Инженер помогает зарелизиться, помогает сопровождать впродакшене.

Речь ипро регрессионные тесты, которые вбудущем повторяются иговорят отом, что данный функционал недеградировал. Речь ипро продуктовые метрики. Нередко, глядя наних, можно сделать предположение, что что-то пошло нетак: смотрим натотже DAU, аонрезко просел после последнего релиза. Может, потехническим метрикам мыэто неуловили, нарегрессах проблемы нет, новсё равно это сигнал разобраться, что пошло нетак, что повлияло наэти события. Плюс ненадо забывать А/В-тестирование, feature toggling итак далее. Многие компании выпускают фичи начасть аудитории, QAвместе спродуктовыми аналитиками оценивают, оправдываетли фича возложенные нанеё надежды, если да занимаются раскаткой дальше. QAнедолжны бросать фичу, протестировал незначит, что работа закончена.

Что спрашивать интервьюеров насобеседовании

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

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

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

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

Soft skills для QA: 3качества, которые стоит прокачивать всебе потвоему мнению

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



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

Второе: важно, чтобы человек излучал уверенность. Иногда встречаешь кандидатов, просишь рассказать, какие http-методы онзнает. Неуверенным голосом онговорит: get, post, кажется, patch, put delete options.... Спрашиваешь, вчём отличия get иpost, авответ: ну, янеуверен по-моему, один получает, другой создаёт объект, или что-то такое.... Если видно, что человек выдаёт правильные ответы насобеседовании, ноделает это очень неуверенно вреальной работе его съедят.

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

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

Аотсюда иинициативность. Нужно еёпрокачивать, небояться выражать мнение, подсвечивать проблемы. Может, попросить добавить новый статус? Аможет, начать делать код-ревью? Сопротивление илегкая конструктивная оппозиция. Для всего этого, безусловно, должна быть инициативность.

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

Зарплата погрейдам: про какие цифры может идти речь, кчему стремиться

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

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

Умиддлов зарплаты тоже отличаются взависимости отрегиона, компании, вкаком секторе она работает. Финтех обычно платит больше всего область специфичная. Для миддла от7080тыс.до150160тыс. Тут ещё вопрос, кто какой уровень считает миддлом вмоём представлении, это сформировавшийсяQA, который представляет, куда развиваться, чувствует почву под ногами, понимает, что хочет, может ответить напять почему.

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



Тимлиды получают от140тыс.до300тыс., для хэдов явидел вакансии до500 тысяч рублей. Все цифры называю сучётом налогов.

Как торговаться озарплате

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

Лайфхак давать вилку снебольшой горкой, так, чтобы даже отступив отверхней планки, держать марку. Нормальная техника, если назвал: от100 до150, апофакту устроит и130, ктакому можно прибегать.

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

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

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

Ресурсы для подготовки ксобеседованию

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

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

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

Подготовка ксобеседованию

• Собеседование для собеседующих (Хабр)
• Погружение вCharles Proxy (Хабр)
• Образ современного тестировщика. Что нужно знать иуметь (Хабр)
• Что должен знать тестировщик бэкенда (Хабр)
• Обратное собеседование (Github)

Потренироваться

• Тестовые площадки для тренировок настоящих ниндзя (блог Noveo)
• Cant Unsee

Помощь

• Software Testing
• Automated Testing
• Testbase
• Про Тестинг
• Качество итестированиеПО (Youtube)

Конференции имитапы

• SQA Days
• Heisenbug 2020 Moscow
• TestCon Moscow 2020
• Podlodka

Школы

• GeekBrains
• Яндекс.Практикум
• Нетология
• Otus.ru

Авторские программы

• QA.Guru
• RFT.QA

Пошабашить

• uTest
• TestBirds

Telegram-каналы

• https://t.me/qa_ru
• https://t.me/qa_bad_company
• https://t.me/qaevents
• https://t.me/yetanotherqa
• https://t.me/radioqa

Книги

• Тестирование Дот Ком или Пособие пожестокому обращению сбагами винтернет-стартапах, Роман Савин
• Тестирование программного обеспечения. Базовый курс
• 5лучших книг потестированиюПО отНатальи Руколь
• Книга для начинающих тестировщиков

В g-mate много крутых вакансий для QA. Используйте бот @g_jobbot, чтобы получать вакансии посвоему профилю прямо вTelegram.

Нужныли soft skills инженеру наэтот счёт больше всего споров ихоливаров. Поэтому мыпозвали СТО инанимающего менеджера портала mos.ru, Романа Ивлиева (спикера ируководителя программного комитета TechLeadConf), поделиться своими мыслями. Приводим часть его ответов навопросы, запись полной версии вебинара в конце статьи.

Софт скиллы ассоциируются сузким количеством навыков. Этонетак

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

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

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

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

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

Качать все навыки сразу всё равно что учить все языки программирования

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

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

<реклама>

Вебинары проводит g-mate бот cлучшими вакансиями вtech. Регистрируйтесь в @g_jobbot, подходящие вам варианты будут приходить вТелеграм.

</реклама>

Нехватает некоммуникации как таковой Ноибез неё никуда

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

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

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

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

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

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

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

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

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

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

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



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

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

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

Сначала поковырялся всебе. Потом пытаешься понять, что хочешь

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

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

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

• долго торчал насовещании;
  
• долго пришлось объяснять коллеге, что что-то пошло нетак;
  
• мучился три дня, потом пошел, спросил изапять минут решил проблему;
  
• насобеседовании растерялся инесмог задать какой-то вопрос;
  
• начальник считает, что ябезрукий черт, нехочет сомной сотрудничать, потому что непонимает, что делаю икак;
  
• ничего незапоминаю;
  
• вечно нехватает времени: 35задач на20часов работы итак далее.
  

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

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

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

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

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

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

Для развития навыков должна быть система ирегулярные тренировки

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

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



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

Янеоднократно слышал хорошие отзывы отеатральных кружках. Часть софт скиллов, которые касаются социальных навыков, они поднимают нанебывалую высоту закороткое время: умения разговаривать, запоминать, реагировать наситуации, когда забыл слова.

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

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

Публичные выступления

Презентационный навык, ораторское искусство порядок такой: ставить цель хочу выступить наTeamLeadConf, искать тему, искать возможности выступить, идти ктем, кто может сэтим помочь, следить законференциями имитапами. Благо ихмного иуровень очень разный: где-то берут только крутых специалистов, где-то готовы взять инекрутых специалистов, есть открытые микрофоны, можно собрать друзей ивыступить перед ними. Регулярные тренировки: например, выделить время впятницу, в18.00. Тычто-то говоришь, записываешь себя навидео, ипотом смотришь сам насебя иследишь запрогрессом. Надо постоянно пересматривать ролики, искать мусорные слова, говорить сзеркалом ианализировать. Самое главное практика ипочаще выводить себя иззоны комфорта.

Разрешение конфликтов

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

Тайм-менеджмент

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

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

Если понятно, что квалификации достаточно, скорость нормальная, нопокаким-то причинам чувствуешь, что можешь делать больше, хотя неделаешь есть феерическая техника, про которую мне рассказывал втом числе Лёша Катаев @deosdeorum, технический директор изSkyEng.

Когда онпонял, что оказался втакой ситуации, тонеделю записывал, что делал втечение дня. Набольшом сроке это упражнение вымораживает, анакороткой дистанции можно потерпеть иусилием воли фиксировать всё, чем занимаешься. Разговоры, чтение почты, отвлечение настроительство фермы, нафейсбук, чужие чаты спустя неделю видишь список из1500 задач изадаешь вопрос: зачем язанимался тем или этим? Задач поделу 40%, аостальные 60% это таймкиллеры.



Янеимею ввиду, что отработы отвлекаться ненадо ноесли таймкиллеры становятся проблемой, сней надо что-то делать. Если жать накаждый попап, что курица стала матерью цыплят инужно отправлять ихвсоседнюю деревню время будет пропадать. Либо другой пример: пришли насовещание, оно было посвящено чему-то интересному ивместо 15минут проторчал там 1,5часа. Вышел счётким пониманием, что полтора часа продолбал. Таких совещаний, ксожалению, вагон ималенькая тележка, поэтому нужна аналитика: что реально происходит? Тогда истанет понятно, что сэтим делать. Это важно, если чувствуешь проблему начинать еёисследовать. Потому что чаще всего исследование начинается изаканчивается поиском виноватых, чтобы оправдать его или заставить сожалеть, получается, это перекладывание ответственности, анерешение проблемы.

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

Развитие софт скиллов это терпение, труд исистема

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

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

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

Все подряд книжки читать ненадо, достаточно одной. Нашел курс наSkillbox/Udemy/Coursera, послушал бесплатные версии, цепанул расшифровки докладов понял, куда копать дальше. УНетологии есть бесплатные курсы пософт скиллам, улекторов-менторов есть бесплатные материалы. Поним можно понять, насколько душа лежит ктому, что рассказывают эти люди. Если откликается можно потратить наэто несколько тысяч рублей, ноне800к заМВА. Может, 10 000 звучит дорого, ново-первых, все курсы умеют принимать оплату врассрочку, аво-вторых: это инвестиции вбудущее. Ксожалению или счастью, это вынужденная мера, мир стал слишком быстрый.

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

Что Роман советует изучить

• FYI For Your Improvement, Michael M. Lombardo &Robert W. Eichinger
  
• Самая большая подборка попрокачке soft skills. Хватит навсю жизнь (VC.ru)
  
• 70книг для развития soft skills (VC.ru)
  
• Soft Skills for Hard Times (Skillbox)
  
• Бесплатные курсы, вебинары, митапы иматериалы отэкспертов Soft skills (Нетология)
  
• Доклады TeamLeadConf (Youtube)
  

Полная версия вебинара:

<реклама>

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

</реклама>

Пролог

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

Процесс интервью

Никогда не берите тестовое задание, решение которого требует от вас времени больше, чем один-два вечера.

Мне еще не известен ни один случай, чтобы человек, который неделю делал тестовое задание и получил хороший оффер. Работодатель часто готов потратить годы, лишь чтобы найти изумруд (скилового, опытного, и за копейки работающего разработчика), но лишь бы найти. Они собеседуют буквально сотню людей, прежде чем наймут кого-то. И такой критерий как выполненное тестовое задание, длинною в неделю, ставит вас в длинную очередь ожидания, в который вы уже заведомо проиграли. Допустим Вы выполнили блестяще тестовое задание, но оффер так и не получили. Вы потратили НЕДЕЛЮ личного времени. А Сколько потратил работодатель? Максимум 10 килоджоулей, нажимая пальчиком переслать, отправляя Вам задание. Он не потерял ничего, и ему это ничего не стоит. А вот вложить силы на решение задачи которой ушла неделя, и получить отказ это огромная просадка по эмоциональным ресурсам, времени, деньгам и самое главное по мотивации. Простое правило: если у вас есть 20 часов свободного времени, вы можете пройти целых 10 собеседований по 2 часа, или решить 1 тестовую задачу и понятия не иметь получите оффер или нет, а в случае отказа эмоциональный откат неизбежен, потому что ресурсов было вложено много, а результата никакого. Не делайте так, следуйте зову здравого смысла!

Основательно подготавливайтесь.

На самом деле это не лежит на поверхности. Гуглите все самые популярные вопросы, которые спрашивают на собеседованиях, запоминайте то, что чаще встречается. Делайте шпоры. Записывайте всё, на чём посыпались при собеседовании и старыйтесь выучить это к следующему. Так или иначе, около 40-50% вопросов всегда повторяются.

Обговаривайте всё на берегу.

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

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

1. Вас сразу собеседует тех. специалист

Это прекрасно, и это значит, что люди не хотят тратить время на лишнюю бюрократию, у них нет большого потока и отсева людей. Более того, чаще всего если собеседование ведёт один технический специалист, то это идеальные шансы на успех. Если их уже двое или трое (а иногда и больше) это плохо. Угодить сразу всем очень сложно. К тому же, почему один человек не в состоянии оценить вашу компетенцию? Зачем для этого целая делегация. Люди часто имитируют работу, а поиск кандидата это тоже работа. Если на ваше собеседование пришло 5 человек, то что-то тут не так

2. Вас спрашивают только то, что имеет отношение к делу

Вы .NET разработчик? ответье, что такое классы\интерфейсы\наследование. Вы Front-End разработчик? Тогда пожалуйста скажите, что такое анонимная функция и отличия const от let.

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

Что подскажет, что это проходимцы, с которыми не стоит связываться

1. Мы ищем и джуна и мидла и тим-лида (с)
Это означает только то, что вопросы будут 99% на тим-лида, а значит они не ищут джунов и мидлов.

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

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

Любое собеседование в разработке это лотерея.

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

Мы просто хотим понять, насколько глубоко ты разбираешься (с)

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



Люди любят доминировать

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

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

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

Эпилог

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

ВЕвропе иСША менторство икоучинг давно стали частью жизни. ВроссийскомIT наставничество только набирает обороты. Обсудили сГеоргием Могелашвили glamcoder, Lead Developer изBooking.com, как менторство влияет накарьеру разработчика, действительноли ментор нужен каждому истоитли возлагать нанего надежды.

Георгий преподаёт вонлайн-школе Otus.ru, входит впрограммный комитет конференции TeamLeadConf ипрограммирует уже более 15лет. Заэто время нераз совершал путешествие вменеджеры иобратно, менял фокус между кодом икомандой. Также занимается коучингом именторством. Мыпоговорили сним ивыяснили, почему менторство так популярно, алюди готовы помогать другим бесплатно или почти бесплатно. Ссылка назапись вебинара вконце статьи.

Менторствоvs. коучинг

Для начала разберемся спонятиями. Есть два способа (ну, кроме психотерапии) помощи другим вформате разговора один наодин: коучинг именторство.

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

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

Согласно статистике, представленной National Mentoring Day, 93% малого исреднего бизнеса считает, что менторство помогает импреуспеть, 67% компаний увеличили продуктивность засчет наставничества.97% опрошенных сотрудников считают менторов полезными, нотолько 25% респондентов имели ментора намомент опроса.

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

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

Ануженли ментор?

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

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

Когда ментор точноНЕ нужен?

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

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

Когда ментор НУЖЕН?

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

Выбирать нужно ментора, который обладает необходимыми вам скиллами или находится напозиции, которую выхотите получить. Например, стать senior-разработчиком вBooking.com ивЯндексе это разные вещи: разные требования икультура компаний. Поэтому именторы нужны разные.

Основной запрос, скоторым приходят кГеоргию, развитие soft skills ирост. Часто приходят снепониманием, куда или как двигаться покарьерной лестнице. Бывают ситуации, когда вкоманде появляется сотрудник, скоторым неудается построить коммуникацию. Еще снаставником можно проработать какую-то неудачную ситуацию. Онпоможет разобрать, что можно было сделать иначе. Если ментор находится втойже компании или команде, онможет давать прямую обратную связь поситуации или помогать налаживать отношения внутри.

Куда расти senior-разработчику?

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

Если есть склонность кбизнесу, можно рассмотреть продакт-менеджмент. Кроме архитекторов может быть много ступеней технического развития сразличной зоной итехнологиями ответственности. Одна итаже должность сильно отличается откомпании ккомпании. Где-то позиция техлида может подразумевать архитектурную работу икоординацию разных сервисов, агде-то разработку наболее серьезном уровне. Можно подумать опереходе всмежные области: вData Science, скрам-мастера, agile-коуча или, например, сбэкенда намобайл.

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

Когда человек неможет выбрать направление самостоятельно, ему нужно задавать открытые вопросы врежиме коучинга: Что тебе важно? Что нравится вработе? Почему?. Взависимости отответов, переходить квсё более конкретным вопросам, пока сотруднику нестанет очевидно, куда ему расти.

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

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

Что плохого, если человек попал влиды неосознанно?

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

Почему технические качества неважны для роста

ВBooking.com четко описаны иерархии ироли: что требуется отMiddle-разработчика, что отsenior-разработчика, кто такой тимлид. Ичем выше выподнимаетесь потехнической ветке, тем меньше нужны технические качества.

Чтобы Middle-разработчику вBooking.com прокачаться доsenior, нужно приносить больше пользы, наносить больше impact продуктам ицелям компании. Это может быть сложный проект, помощь другой команде, запуск side-проекта, которые улучшат показатели компании. Влияние накоммьюнити ипомощь другим вразвитии также ценится вкомпании. Помимо стандартных квартальных иполугодовых целей, становятся важны soft skills: нетолько что тыделаешь, ноикак. Способность общаться слюдьми, доносить мысль четко, ясно ипонятно, выбирать решения, исходя извлияния набизнес, помогать другим расти. Качественное написание кода важно, ноэтого недостаточно, чтобы стать senior-разработчиком.

Тимлид вBooking человек, продолжающий писать код, иservant leader водном флаконе. Его роль помочь команде стать автономной исамостоятельно распределять задачи, поддерживать ивосстанавливать автономность, если она теряется, изащищать команду отвнешних факторов.

Где искать ментора?

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

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

Нежди, что кто-то придет иначнет тебя менторить. Хочешь расти пробуй, проси опомощи сам.

Сколько это стоит?

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

Деньги невсегда главная мотивация для менторов, которые идут вэту сферу осознанно. Обучая других, человек сам учится новому, вместе сподопечным находит выходы изситуаций, вкоторые ещё непопадал. Также менторство возможно монетизировать наperformance review, приведя фидбэки подопечных, что выльется, например, вбонус. Кроме того, ментор получает удовольствие отуспехов учеников иотосознания собственной пользы.

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

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

Рекомендации Георгия: что почитать ипосмотреть

• Коучинг-лидерство. Говори меньше, спрашивай больше инавсегда измени свой стиль управления, Майкл Бенгей Стеньер
• Коучинг инаставничество. Практические методы обучения иразвития, Мелвилл Лидхем, Эрик Парслоу
• Курс покоучингу (Coursera)
• Плейлист свыступлениями Георгия (Youtube)
• Канал Мужик сбабочкой, который ведёт Георгий (Telegram)
• Сайт Георгия, где можно записаться накоучинг кнему: coaching.dev

Cсылки наменторские сервисы для разных целевых аудиторий, окоторых мыслышали: IT(LAMPOVOE IT, Emergentum, Solvery), для студентов (МГИМО, МГУ, РЭШ, НИУ ВШЭ ), для бизнеса (United Mentors, Experum).

Полная версия вебинара

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

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

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

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

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

Сегодня расскажу, как мы с коллегой Александрой искали лучших инженеров на расстоянии и, самое главное, нашли.

Что было до: групповой отбор, экскурсии, экзамен

Раньше все дежурные инженеры перед подписанием договора проходили отбор в 2 этапа: групповое собеседование и вводное обучение.

На групповое собеседование мы приглашали 1215 человек. Кандидаты знакомились с компанией и будущими коллегами, а потом решали несколько кейсов. В мире ИТ многие скептически относятся к таким собеседованиям. Но для нас формат полезен по трем причинам:

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

Собеседование занимало 6 часов почти целый рабочий день. Но в результате сразу набиралась готовая группа на обучение.

Вводное обучение длилось 3 дня. Мы проводили экскурсию по дата-центру, знакомили с обязанностями дежурного инженера и давали практические задания, например, подключить оборудование. Будущие инженеры могли проявить себя в деле и проверить мое-не мое.
В конце кандидаты сдавали экзамен по теории и практике. Если результат не менее 70% от максимального количества баллов добро пожаловать на оплачиваемую стажировку. К обучению подключали руководителей отделов: так можно сразу найти интересных кандидатов в одну из смежных технических групп.

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

Какие сюрпризы принес 2020

Долгий режим ожидания

После введения локдауна мы приостановили набор в дежурку и ждали, пока ситуация не прояснится. Но строить новые ЦОДы мы не перестали, так что летом понадобилось уже 15 дежурных инженеров для новых площадок. Стало понятно, что нам не избежать собеседований в режиме социальной дистанции.
Чтобы не потерять в эффективности, нужно было решить несколько непростых задач в новом формате:

• оставить кейсы, чтобы кандидаты могли продемонстрировать взаимодействие в команде;
  
• показать наши ЦОДы, где предстоит работать;
  
• познакомить будущих инженеров с руководителями, которые находятся на разных площадках;
  

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

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

Первый онлайн-набор: неразбериха вместо кейсов

В июне мы объявили новый набор дежурных инженеров в онлайне. Собеседование запланировали в Cisco Webex: мы используем эту систему для удаленных совещаний внутри компании. Как это выглядело в нашей голове:

1. Приглашаем от 20 до 30 человек на групповое собеседование. Всем кандидатам уходит письмо со ссылкой на виртуальную комнату Webex.
   
2. Проводим презентацию компании и знакомимся с участниками.
   
3. Просим кандидатов разделиться по виртуальным комнатам коллег и решаем кейсы в группах по 4-6 человек.
   

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

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

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

Чат пригодился и на вводном обучении. Преподаватель проводил занятие в Webex и отправлял в Telegram записи лекций и дополнительные материалы, отвечал на вопросы. Экскурсию по ЦОДу заменили на видеотур и сэкономили день обучения. Конечно, получилось не так живо, как на экскурсии. Зато можно перейти по ссылкам и посмотреть в удобное время.

Финальный экзамен проводили в Webex. Старший инженер площадки оставался в своей персональной комнате, а 15 человек подключались по очереди. Без накладок тоже не обошлось. У всех новичков была одна и та же ссылка если перепутаешь время, попадешь на чужой экзамен. Для экзаменатора нагрузка была высокой. В какой-то момент наш Антон даже стал радоваться прогульщикам.

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

Второй онлайн-набор: безличные квадратики

В июле мы проанализировали наш опыт и кое-что улучшили:

• подключили к набору больше наших сотрудников, чтобы сделать несколько потоков на собеседовании и обучении.
  
• сменили площадку и перешли на корпоративный аккаунт в Zoom. Там было удобнее одной кнопкой делить кандидатов на 4-5 сессионных залов.
  

Так мы сразу сократили время онлайн-собеседования с 4 часов до 2.

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

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

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

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

Во второй раз все прошло быстрее: мы объявили набор 10 июля, а уже 27 июля к нам на стажировку вышли пятеро инженеров. В третий набор за 2 недели удалось принять уже 15 дежурных инженеров.

Что из этого получилось

1. Меньше времени на отбор. Время собеседования мы сократили с 6 часов в офлайне до 2 часов в Zoome. Сроки обучения уменьшились с 3 дней до 2.
   
2. Формат удобнее для кандидатов. Не нужно тратить время на дорогу и освобождать несколько дней на прохождение всех этапов. Стало проще вписывать собеседования и занятия в расписание. Особенно были довольны те, кто уже работал и хотел перейти к нам.
   
3. Больше людей доходят до конца обучения. Если раньше на курс приходило 13 человек из 20 приглашенных, то в онлайне не приходит всего пара человек. Даже если время обучения неудобное, можно посмотреть в записи, подготовиться за выходные и сдать экзамен.
   

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


Ответ на оффер от кандидата.

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

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

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

Выбор компании

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

Формируем портрет желаемой компании, я сделала 3 колонки:

• Цели в работе
• Желания на ближайшие годы
• Рекомендации (советы друзей о выборе компании)

Поиск вакансий и требований

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

План подготовки

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

Для составления тем и вопросов, использовала:

• Гайд Хочу работать в Google (взяла темы за основу)
• Требования из вакансий
• Вопросы с собеседований, которыми поделились мои знакомые (нашла много интересных и сложных вопросов)

Для решения задач:

• Leetcode (здесь есть задачи с собеседований Yandex, Alibaba, Google, а с подпиской доступны решения)
• HackerRank

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

Получился общий план:



Пример одной из тем:



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

Резюме

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

Опыт работы описать:

• Кратко основной продукт и количество пользователей
• Мое влияние на продукт: задача -> результат для компании
• Стек технологий

Что рассказать о себе:

• Опиши качества, которые помогут в работе, прикрепите ссылки на свои публикации и расскажите о себе, как личности
• Прикрепи ссылки на свои публикации
• Расскажи о себе, как личности

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

Тренировочные технические собеседования

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

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

Собеседования в production

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

Для поиска компаний: я открыла HeadHunter, посмотрела участников технических конференций и поспрашивала мнение друзей об их местах работы. Так я отобрала компании, которые мне интересны.

Чтобы получить приглашение на собеседование:

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

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

Офферы

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

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

За время работы в IT-рекрутинге у нас накопилось много историй о смешных, нелепых и странных собеседованиях как от разработчиков, так и от HR. Поэтому решили запустить рубрику Трэш-собеседования, где будем делиться подобным контентом. В этой статье собрали 13 историй: страшных, глупых и криповых. Авторы не указаны, но такое мы точно не сможем придумать сами. Расслабьтесь, заварите чай и наслаждайтесь. Если будет интересно делитесь своим опытом в странных собеседованиях, а мы продолжим выпускать похожие статьи дальше.



Начнем с историй от разработчиков. Авторская стилистика частично сохранена.

#1. Украл, скопипастил, в резюме

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

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

#2. Уважительная причина

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

Ты уже знаешь, что мы тебя приглашаем?
Круто! Нет, еще не знаю
Странно, пойду проверю, должны были уже отправить приглашение.

Через 10 минут возвращается:

Я перепутала тебя с другим похожим внешне кандидатом. Тебя мы не берем, сорян.

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

#3. Шиворот-навыворот

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

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

#4. Что?...

...Всё шло хорошо, но тут прилетел вопрос сколько раз в неделю вы ходите в церковь?

#5. Ландан из зе кэпитал...

Однажды я проходил собеседование в Google. Он нашел меня через GitHub я там участвовал в проекте по созданию распределенных хранилищ.

На собеседовании спрашивали о том, какие структуры я использовал, какая часть кода была написана мной и что из алгоритмов применял. Но все это на английском, поэтому собеседование прошло на уровне Ландан из зэ кэпитал оф Грейт Британ. Google посоветовал мне сперва выучить английский.

#6. Крипота в Кемерово

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

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

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

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

А куда это он?
Вы что, не видите? Он вышел.
Куда?
В Кемерово.

Я какое-то время осмысляю происходящее, понимаю, что как-то оно всё не так.

А это вообще нормально? А если я встану и выйду в Кемерово?..
Вам в Кемерово нельзя.

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

#7. Это стресс-интервью, детка

Однажды пришла устраиваться в компанию, а HR вздумала провести со мной стресс-интервью: опоздал на 30 минут и начал кричать на меня: Чего пришла? Таких как вы знаете сколько у нас?

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

А теперь истории от HR.

#8. Чесоточный кандидат

Это была моя первая вакансия в IT iOS-разработчик. Я ничего не понимал не только в iOS-разработке, но и вообще в IT! (прим.: речь про HR, а не разработчике)

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

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

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

#9. Сам с собой веду беседу

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

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

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

#10. Рвусь на работе

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

#11. Рыг

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

#12. Незваный кандидат

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

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

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

#13. Бальтазар, я призываю тебя!

Сидим мы в рекрутерской и вдруг заходит кандидат, которого никто не приглашал. Мы спрашиваем вы к кому а он нам: Меня призвали

#14. Просто было жарко

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

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

За время работы в IT-рекрутинге у нас накопилось много историй о смешных, нелепых и странных собеседованиях как от разработчиков, так и от HR. Поэтому решили запустить рубрику Трэш-собеседования, где будем делиться подобным контентом. В этой статье собрали 13 историй: страшных, глупых и криповых. Авторы не указаны, но такое мы точно не сможем придумать сами. Если будет интересно делитесь своим опытом в странных собеседованиях, а мы продолжим выпускать похожие статьи дальше.



Начнем с историй от разработчиков. Авторская стилистика частично сохранена.

#1. Украл, скопипастил, в резюме

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

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

#2. Уважительная причина

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

Ты уже знаешь, что мы тебя приглашаем?
Круто! Нет, еще не знаю
Странно, пойду проверю, должны были уже отправить приглашение.

Через 10 минут возвращается:

Я перепутала тебя с другим похожим внешне кандидатом. Тебя мы не берем, сорян.

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

#3. Шиворот-навыворот

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

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

#4. Что?...

...Всё шло хорошо, но тут прилетел вопрос сколько раз в неделю вы ходите в церковь?

#5. Ландан из зе кэпитал...

Однажды я проходил собеседование в Google. Он нашел меня через GitHub я там участвовал в проекте по созданию распределенных хранилищ.

На собеседовании спрашивали о том, какие структуры я использовал, какая часть кода была написана мной и что из алгоритмов применял. Но все это на английском, поэтому собеседование прошло на уровне Ландан из зэ кэпитал оф Грейт Британ. Google посоветовал мне сперва выучить английский.

#6. Крипота в Кемерово

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

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

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

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

А куда это он?
Вы что, не видите? Он вышел.
Куда?
В Кемерово.

Я какое-то время осмысляю происходящее, понимаю, что как-то оно всё не так.

А это вообще нормально? А если я встану и выйду в Кемерово?..
Вам в Кемерово нельзя.

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

#7. Это стресс-интервью, детка

Однажды пришла устраиваться в компанию, а HR вздумала провести со мной стресс-интервью: опоздал на 30 минут и начал кричать на меня: Чего пришла? Таких как вы знаете сколько у нас?

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

А теперь истории от HR.

#8. Чесоточный кандидат

Это была моя первая вакансия в IT iOS-разработчик. Я ничего не понимал не только в iOS-разработке, но и вообще в IT! (прим.: речь про HR, а не разработчике)

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

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

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

#9. Сам с собой веду беседу

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

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

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

#10. Рвусь на работе

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

#11. Рыг

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

#12. Незваный кандидат

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

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

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

#13. Бальтазар, я призываю тебя!

Сидим мы в рекрутерской и вдруг заходит кандидат, которого никто не приглашал. Мы спрашиваем вы к кому а он нам: Меня призвали

#14. Просто было жарко

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

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

Собеседование сениор-разработчика это тайна; собеседование джуна это триллер.

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

Существует миллион веб-сайтов для практики алгоритмов, YouTube-каналов для подготовки к собеседованиям и постов в блогах, рассказывающих, как устроиться в Google. Разумеется, подготовка к таким собеседованиям требует времени, но с ними вполне можно справиться.

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

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

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

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

Как устроены собеседования сениор-разработчиков

Десяток лет назад многие материалы для собеседований сениоров состояли из двух частей:

• Знание соответствующих API
• Знание процесса поставки и разработки ПО

Честно говоря, они были гораздо проще, чем собеседования джунов. Часто даже не проверялось знание алгоритмов!

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

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

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

Фактор, присутствующий в каждом собеседовании сениор-разработчика

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

Если у вас болит горло, то вы чувствуете, что заболели. Но вы не знаете, грипп у вас или коронавирус. Больное горло это симптом, а не заболевание. Сама болезнь ещё не диагностирована. Однако вы понимаете, что с телом что-то не так и вам нужно сдать тесты.

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

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


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

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

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

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

Сигналы, а не содержание ответов.

С точки зрения программирования эта концепция была рассмотрена в книге Cracking the Coding Interview знаменитого тренера по собеседованиям Гейл Лакманн Макдауэлл, работавшей в Google, Microsoft и Apple. Так как подаваемые на собеседованиях сигналы настолько важны, она на крайне рекомендует кандидатам сообщать о процессе продумывания состояния задачи на whiteboard-собеседованиях.

Подведём итог

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

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

Чем сильнее положительные сигналы, тем выше ваши шансы на успех.

Какие же сигналы они ищут?

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

Вопросы собеседований сениор-разработчиков можно обобщённо разбить на три категории:


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

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

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

Когда я читал книгу Cracking the Coding Interview, то заметил, что она здорово объясняет, как разбивать технические вопросы на подгруппы: жадные алгоритмы, двоичный поиск и т.д. Они достаточно популярны на собеседованиях FAAMG+, где первостепенную важность имеет знание computer science.

Что важнее всего запомнить

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

Именно этот образ и является сигналом, о котором я говорил.

Шокирующее и обманчивое открытие

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

Это означает, что большинство кандидатов ошибочно относят вопросы к одной из трёх описанных категорий!

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

Вас это не убедило? Вот обоснование этой теории:

• Посмотрите на количество претендентов в постах о вакансиях в области разработки ПО на LinkedIn.
• Даже в мелких и средних компаниях на одну вакансию программиста приходится почти 60100 кандидатов.
• Реклама крутится по три-шесть месяцев, то есть должность остаётся незанятой в течение долгого времени.

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

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

Очень маловероятно, что такое количество опытных кандидатов недостаточно подходит из-за технических знаний. Тем не менее, подходящий кандидат не находится.

Так происходит, потому что во время собеседования на должность сениор-разработчика:

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

Мой последний провал на собеседовании

Спустя почти 55 минут напряжённого собеседования организаторы уже начинали тепло мне улыбаться.

В качестве последнего вопроса они задали мне такой:

Если клиент спросит вас о разработке фуллстек-системы с мобильными клиентами, то каким будет ваш ответ?

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

Поэтому я ответил так:

Я узнаю у него требования.

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

Тем не менее, меня не приняли. Но ещё больше меня поразила причина отказа:

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

Я ошибочно отнёс технический вопрос к категории вопросов о процессах!

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

Намеренная мышеловка

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

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

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

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

В конечном итоге, неважно, прошли ли вы собеседование. Если вы не подходите компании, то и она, скорее всего, не подошла бы вам.

Заключение

Из-за роста популярности Agile и lean в стартапах работодатели больше не воспринимают новых сотрудников как ресурсы. Они рассматривают их как долговременных партнёров и ответственных лиц.

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

Тем не менее, нужно относиться к собеседованиям больше как к свиданиям, а не к тестам.

---

На правах рекламы

Мощные VDS с защитой от DDoS-атак и новейшим железом. Всё это про наши эпичные серверы. Создайте собственный тариф в пару кликов, максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe.

Подписывайтесь на наш чат в Telegram.

В июле и августе 2020 года я, с подачи Григория Петрова, проводил для компании Evrone технические интервью на позицию Senior Golang Backend developer. И, видимо, буду вынужден продолжать проводить, о чём ниже.

Задача формулировалась как найти человека, который сможет задать и поддерживать высокий уровень профессионализма в применении языка Go. То есть, сформулирована она была по-человечески, перевод на канцелярит мой. Под эту задачу я сформировал новый опросник вместо того, которым пользовался несколько лет старый был с жестким закосом под DevOps. Методику, которой я пользуюсь для создания опросников и количественной оценки соответствия кандидатов, я излагал в своем докладе Техническое интервью как инженерная задача на конференции Saint TeamLead 2019.

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



Благодаря усилиям хэдхантеров Evrone Екатерины Тхоржевской и Анны Кудряшовой спасибо им! до меня добираются только резюме интересных кандидатов. Я их читаю и вижу вполне релевантный, а зачастую интересный профессиональный путь. Сложные и интересные проекты, ответственные должности. Слушая обязательный Расскажите о себе этап интервью, я вижу упорную и плодотворную работу. Прям бери и нанимай!

Но когда дело доходит до технической части и опросника, перспективы найма начинают выглядеть уже не так радужно. Кисло они начинают выглядеть, честно говоря! Смотрите: средний балл по опроснику 3.3 по шкале 0-9. 3.3, Карл! 3.3 это, с моей точки зрения, уровень junior. Middle должен набирать, я считаю, 5+. Senior 8+.

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

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

Итак, опросник:
1. Go императивный или декларативный? А в чем разница?

• Что я хочу оценить: знакомство с разными подходами к реализации бизнес-логики.
• Самый популярный неправильный ответ: Я не силен в теории. Очень жаль, что ты не силен в этой теории, %USERNAME%. Если бы ты был в ней силен, ты бы знал, почему некоторые вещи на Go получаются очень легко и хорошо, а некоторые надо прям вымучивать.
• Наводящие вопросы: SQL императивный или декларативный? А Dockerfile? А файл настройки github actions?

2. Что такое type switch?

• Что я хочу оценить: знакомство с нашим (скудным) инструментарием работы с системой типов в runtime.
• Самый популярный неправильный ответ: Я не знаю. Очень странно информация о type switch есть даже в Go tour.
• Наводящие вопросы: как реализовать в Go тип-сумму, который может содержать в себе значения int64|float64|complex? Как реализовать для такого типа метод Add(int64)?

3. Как сообщить компилятору, что наш тип реализует интерфейс?

• Что я хочу оценить: хорошо ли кандидат понимает, на чем основана концепция интерфейсов в Go.
• Самый популярный неправильный ответ: Я не знаю. Справедливости ради, именно этот вопрос редко вызывает затруднения. А когда вызывает, сам кандидат весьма этим удивлен: Я же миллион интерфейсов написал. Как компилятор понимает, что именно я реализовал?... Ну он умный, компилятор. И внимательный.
• Наводящие вопросы: что такое duck typing? К чему он применяется в Go?

4. Как работает append?

• Что я хочу оценить: знаком ли кандидат с базовыми концепциями управления памятью в Go. Самыми базовыми.
• Самый популярный неправильный ответ: Он увеличивает capacity. Если продолжать настойчиво спрашивать: Как он это делает?, кандидат довольно быстро приходит к правильному ответу. Видимо, эти подробности настолько шокирующие, что забыть их трудно.
• Наводящие вопросы: как бы вы реализовали разреженный массив в Go? А без использования map?

5. Какое у slice zero value? Какие операции над ним возможны?

• Что я хочу оценить: помнит ли кандидат, что вообще можно делать со слайсом, и как ведут себя операции на граничных значениях. Почему это важно? Почему это важно? был бы отличный вопрос для интервью, если бы я придумал, как его корректно задавать.
• Самый популярный неправильный ответ: Можно делать len () и cap () наверное Операций со слайсами существенно меньше 10. И мы все 100% применяем их в своей повседневной работе. Надо просто пересчитать их в уме...
• Наводящие вопросы: каков будет результат append([]string(nil), "")? А append([]string(nil), []string(nil)...)? А почему? А range append([]string(nil), []string(nil)...) как отработает?

6. Как устроен тип map?

• Что я хочу оценить: насколько интересно кандидату, как именно ложатся в память наши байтики. Map, возможно, самая важная из стандартных структур данных, и весьма замысловато устроенная. Она сложная, она эффективная, она обладает встроенным race condition детектором Неужели не любопытно?!
• Самый популярный неправильный ответ: то хеш-таблица. Да, это хеш-таблица. Как устроена хеш-таблица?
• Наводящие вопросы: какая hash-функция используется в map в Go? Что такое bucket?

7. Каков порядок перебора map?

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

8. Что будет, если читать из закрытого канала?

• Что я хочу оценить: читал ли кандидат документацию или сразу бросился кодить. Если читал запомнил ли очевидно-важное.
• Самый популярный неправильный ответ: Вернется ошибка. Ну да, ну да Вы помните синтаксис чтения из канала? Интересно, что синтаксис помнят почти все, но вопрос: И как вернется ошибка?, зачастую вводит кандидата в ступор.
• Наводящие вопросы: сколько значений возвращает одно чтение из канала? А почему range-чтение из канала возвращает одно?

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

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

10. Как вы отсортируете массив структур по алфавиту по полю Name?

• Что я хочу оценить: насколько кандидат склонен к написанию велосипедов.
• Самый популярный неправильный ответ: Методом пузырька. Пузырек прекрасный алгоритм, но есть сегодня и поэффективнее. Например quicksort. Не можете с ходу имплементировать quicksort? Так ведь и не надо!
• Наводящие вопросы: какой стандартный пакет предназначен для сортировки любых слайсов? И заодно как сделать из массива слайс? Отсортируется ли массив при сортировке слайса?

11. Что такое сериализация? Зачем она нужна?

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

12. Сколько времени в минутах займет у вас написание процедуры обращения односвязного списка?

• Что я хочу оценить: помнит ли кандидат институтский курс информатики. А если серьезно это золотой вопрос программистского собеседования. Если бы мне позволили, я бы задавал его первым, и 70% интервью можно было бы на этом месте заканчивать. Один мой друг, который работает в JetBrains, так и поступает, кстати. Так вот, связанный список это один из базовых элементов computer science, и один раз узнав, как он устроен, забыть это невозможно. Если программист не может развернуть односвязанный список, это свидетельствует о серьёзных пробелах в базовых знаниях. И это повод насторожиться а что еще из базового он пропустил?.
• Самый популярный неправильный ответ: А что такое односвязанный список?. Это такая структура данных...
• Наводящие вопросы: какие тесты вы бы написали для своей процедуры разворачивания односвязного списка?

13. Где следует поместить описание интерфейса: в пакете с реализацией или в пакете, где этот интерфейс используется? Почему?

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

14. Предположим, ваша функция должна возвращать детализированные Recoverable и Fatal ошибки. Как это реализовано в пакете net? Как это надо делать в современном Go?

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

15. Главный недостаток стандартного логгера?

• Что я хочу оценить: критерии выбора кандидатом 3-party зависимостей для проекта. Логгер просто самый одиозный случай, когда стандартная библиотека не предоставляет нам необходимой функциональности.
• Самый популярный неправильный ответ: Я не пользуюсь стандартным логгером. И никто не пользуется, сюрприз! Но почему?
• Наводящие вопросы: каково основное применение информации из логов?

16. Есть ли для Go хороший orm? Ответ обоснуйте.

• Что я хочу оценить: количество и качество усилий, которые кандидат приложил к выбору инструментов, ускоряющих и облегчающих повседневную деятельность.
• Самый популярный неправильный ответ: Gorm, вроде, неплох. Конкурирует с ответом Я всё пишу руками. Я даже согласен с обоими ответами, но давайте обсудим подробнее как устроен gorm, и почему вдруг руками.
• Наводящие вопросы: что означает буква M в аббревиатуре ORM? Что на эту букву M есть в gorm? А что такое DAL и зачем он нужен?

17. Какой у вас любимый линтер?

• Что я хочу оценить: уровень знакомства с современными практиками поддержки разработки.
• Самый популярный неправильный ответ: Встроенный в Goland. Come on!, там нет линтера, там тривиальный syntax checker!
• Наводящие вопросы: какое отношение линтеры имеют к CI? Зачем нужен CI в процессе разработки?

18. Можно ли использовать один и тот же буфер []byte в нескольких горутинах?

• Что я хочу оценить: понимает ли кандидат принципы, по которым мы выбираем использовать общую структуру данных или локальную для горутин.
• Самый популярный неправильный ответ: Можно, если защитить его мьютексом. Я признаю, это плохой вопрос, недостаточно показательный. Но зачем же давать на него хоть и формально правильный, но бесполезный ответ? К сожалению, в рабочей обстановке нам тоже прилетают плохие задачи, но надо уметь адекватно на них реагировать. Адекватно это не Что за чушь?!, а Сформулируйте, пожалуйста, цель, кстати.
• Наводящие вопросы: а зачем и правда может понадобиться использовать один и тот же буфер []byte в нескольких горутинах параллельно? Что именно мы будем в нем защищать мьютексом?

19. Какие типы мьютексов предоставляет stdlib?

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

20. Что такое lock-free структуры данных, и есть ли в Go такие?

• Что я хочу оценить: насколько глубоко кандидат разобрался в теме конкурентного доступа к данным.
• Самый популярный неправильный ответ: Нет.
• Наводящие вопросы: что такое atomic? А что такое sync.Map? Sync.Map lockfree или нет?

21. Способы поиска проблем производительности на проде?

• Что я хочу оценить: степень знакомства с этой малоприятной, но постоянно возникающей задачей.
• Самый популярный неправильный ответ: Пишу в логи. Коллеги, да такие логи сами по себе создают проблемы производительности!
• Наводящие вопросы: какие проблемы производительности вы знаете? Может ли быть так, что потребление ресурсов (CPU, RAM, disk/net bandwidth) вполне умеренное, а пользователи жалуются на тормоза? А на что, собственно, жалуются пользователи, и как это связано с тем, что вы видите в системе?

22. Стандартный набор метрик prometheus в Go -программе?

• Что я хочу оценить: степень готовности использовать лучшие практики современной разработки. И дело тут не столько в самом прометее, сколько в готовности следовать за тенденциями в индустрии. Это, как ни странно, важно сохранять тесную связь с мейнстримом.
• Самый популярный неправильный ответ: Я не пользуюсь прометеем. А пора бы, уже несколько лет как пора!
• Наводящие вопросы: оставив прометей в стороне что вообще Go-программа способна о себе рассказать? Метрики runtime что это, и откуда берется?

23. Как встроить стандартный профайлер в свое приложение?

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

24. Overhead от стандартного профайлера?

• Что я хочу оценить: тупо читал ли кандидат документацию. И, если читал, что понял?
• Самый популярный неправильный ответ: Ну, заметный.
• Наводящие вопросы: что такое семплирующий профайлер и почему это хорошо?

25. Почему встраивание не наследование?

• Что я хочу оценить: общее знакомство с ООП-парадигмой и границами ее применения в Go.
• Самый популярный неправильный ответ: Наследование позволяет переопределять методы. Но, коллеги, встраивание тоже, тоже!
• Наводящие вопросы: Что означает буква L в аббревиатуре SOLID?

26. Какие средства обобщенного программирования есть в Go?

• Что я хочу оценить: знакомство с основными парадигмами современного программирования и границами их применимости в Go.
• Самый популярный неправильный ответ: Интерфейсы. Коллеги, интерфейсы ничего не обобщают (внезапно). Однако программисты, пришедшие в Go с других языков, имеющих развитые средства обобщенного программирования, сильно тоскуют по ним и пытаются эмулировать эти самые средства с помощью интерфейсов. Создают при этом, простите за правду, кошмарных уродцев.
• Наводящие вопросы: что такое map-reduce? Как его реализовать в Go? А без interface{}? А что такое кодогенерация и как ее можно использовать в этой задаче?

27. Какие технологические преимущества языка Go вы можете назвать?

• Что я хочу оценить: глубину осознания кандидатом места языка Go в современной разработке. Для каких задач Go подходит идеально? Для каких не очень, но будет полезен? Преимущества существуют не сами по себе, а только в контексте задачи!
• Самый популярный неправильный ответ: Читабельность. Коллеги, читабельность субъективная категория, она не может быть технологическим преимуществом. Это раз. Два читабельность Go довольно относительна. Килотонны boilerplate обработки ошибок и ручной раскрутки стека читабельность ни в коем разе не увеличивают!
• Наводящие вопросы: чем отличается goroutine от OS thread? Как устроен сетевой ввод-вывод в Go?

28. Какие технологические недостатки языка Go вы можете назвать?

• Что я хочу оценить: глубину осознания кандидатом места языка Go в современной разработке. Для каких задач Go совершенно не подходит?
• Самый популярный неправильный ответ: Отсутствие generic types. Я пробовал спрашивать на этом месте: Для каких ваших текущих задач были бы полезны генерики?, и ни разу не услышал ничего внятного. И не услышу генерики критически важны для функциональных языков, а Go Об этом ниже.
• Наводящие вопросы: их миллион, но я задам один. Как превратить []io.ReadWriter в []io.Reader?

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

Напоследок обещанное предположение о том, как и почему сложилась эта печальная ситуация. Наша индустрия, как бы мы это ни оценивали, уже давно живет по закону fail early, fail often, but always fail forward. Для нас это означает, что мы должны делать свою работу как можно хуже! Мы должны потратить как можно меньше сил, средств и времени, особенно времени! на предложенную задачу, ибо никто не знает, имеет ли текущая задача практический смысл. Собственно, большую часть задач мы решаем в режиме разведки, проверяя чужие смелые бизнес-гипотезы.

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

Моё скромное мнение так нельзя! Образование это игра в долгую, и подходить к нему надо с другими критериями, нежели к очередному Проверим идейку MVP.

Конференция Golang Live 2020 пройдёт онлайн 1417 октября. И в этом есть свои плюсы: нам не придётся вводить ограничения на количество гостей, и участником сможет стать каждый желающий. Забронировать билеты можно на все дни конференции, а благодаря генеральному партнеру компании Юла, первый день открыт для всех желающих. Смотрите расписание здесь.

Программа конференции раскроет главную тему Продуктовая разработка на Gо. Так вы сможете увидеть цельную картину и понять, как Gо работает на реальных (часто высоконагруженных) проектах. А тестирование в случае Go становится ещё интереснее. Сложную бизнес-логику, как правило, нам приходится реализовывать нетривиальным способом, поэтому и писать интеграционные тесты для неё сложно. Что с этим можно сделать и нужно ли все обкладывать интерфейсами и моками, мы и поговорим при встрече.

Пообщаться, задать вопросы (и ответить на вопросы других) вы можете в этом telegram-канале. Посмотреть новости о конференции в другом, или на выбор: Facebook, VKontakte, Twitter, Youtube, если вы предпочитаете именно их.

До встречи на Golang Live 2020!

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

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

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

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

---

Сперва я быстро просматриваю все резюме

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

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

В быстром отборе резюме помогает правило: чем больше технологий я встречаю, тем лучше. Если у человека в резюме написано MySQL, Linux, Postgres, Apache и так далее шансы есть. Человек по крайней мере слышал о технологиях и, кто знает, возможно, даже сам с ними работал. Хотя будем честны в резюме можно написать все, что угодно.

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

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

Я не требую особых знаний, я не прошу настроить мне MPLS. Но что такое маска подсети, что такое IP-адрес в 21 веке должны знать все IT-специалисты. Я понятия не имею, что у человека в голове происходит, когда он не понимает, что такое 127.0.0.1. Он сидит на локальной машине, у него запущен сервис на виртуалке. У сервиса прописан эндпоинт 127.0.0.1, коннект к базе. От незнания наш герой вхреначивает то же самое. Как результат: у меня не коннектится к базе. Конечно, блин, не коннектится!

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

---

Вот, например, стандартная задачка из CCNA, на понимание того, как работают сети

Есть два свича из разных сетей, между ними стоит роутер. Компьютер А хочет отправить данные в компьютер Б.

Что происходит в этот момент?

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

---

Затем я спрашиваю по всем уровням модели OSI

Слышал ли что-нибудь человек про Spanning Tree протокол? Про корневой протокол, про IP-уровень? Хорошо, а как это все работает? Понимает ли он, как происходит роутинг? Ну и скопом: таблицы маршрутизации, динамический протокол маршрутизации, транспортный уровень TCP. И так далее, и так далее.

Я хочу услышать, чем отличаются TCP и UDP. Хороший спец ответит мне, почему критичные системы (например, Domain Name System) используют протокол без гарантированной доставки сообщений (UDP).

Ответ простой так быстрее. Пока устраиваешь TCP-сессию, ты можешь 3 раза отправить UDP пакетик туда и получить его обратно. И никакого оверхеда.

Задаю вопросы про DNS

Какие бывают типы записи? Знает ли мой собеседник, что такое MX-запись, как работает spf или как работает DKIM.

Да, в работе эти знания могут и не пригодиться. Но мне важно знать, понимает ли человек суть технологии, было ли ему интересно прочитать про это. Вот добавлял он какие-то записи в DNS и загуглил, что такое spf-запись, или не загуглил?

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

Я начинаю со стандартных вопросов об отличиях http-версий 1.0, 1.1 и второй версии. Интересуюсь, что такое headers и зачем они нужны. Как веб-сервер понимает, что ему пришел запрос на определенный virtual host, а не на любой другой. И всегда задаю пару вопросов по Nginx.

Дальше плавно переключаю внимание на TLS-протокол

Как работает SSL\TLS? Инженеру нужно понимать это хотя бы на базовом уровне есть корневой центр сертификации, он подписал сертификат, и сертификат где-то используется.

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

Ответ под спойлером

Дело в том, что сначала устанавливается TLS-соединение, а потом уже следом идет HTTP-протокол, а веб-сервер может определить, к какому сайту обращается клиент только по HTTP-протоколу, по хедеру хоста. Nginx еще не знает, к какому сайту обратились, но он уже должен отдать сертификат клиенту. Есть расширения для TLS-протокола, которые позволяют клиенту передать хостнейм серверу, к которому он обращается при попытке установить TLS-соединение. И таким образом выбирать нужный сертификат. Когда этого расширения не было, на одном IP-шнике можно было держать только один сайт с включенным SSL.

Перехожу к Linux и BASH

Надо знать все юниксовое, все Unix-like системы. Нужно уметь работать с Shell и Bash, знать основные команды. ls-ы всякие, mkdir и т.д.

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

По Linux спрошу, как заменить в файле строчки другими строчками. Или как распарсить какой-нибудь access.log в Nginx средствами BASH. Чтобы человек рассказал про awk, про cat, про sort, про все, что помогает быстрой работе.

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

Потом надо выяснить, как дела с виртуализацией

Обычная виртуализация, виртуализация через гипервизор. Если кандидат заводит разговор про паравиртуализацию значит, что-то знает.

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

Перемещаемся к контейнерам

Узнаю, работал ли собеседник с Docker? Собирал ли он образы, писал ли Docker-файлы, использовал ли Docker compose, деплоил ли с его помощью. Зачем вообще нужны эти контейнеры и как они работают? Поднимал ли наш соискатель систему оркестрации контейнеров Swarm или Kubernetes? Можно задать целый блок вопросов, но главное понять, делал человек работу своими руками с контейнерами или нет?

Спрашиваю про CI/CD deployment

Меня интересует огромный список вещей: как он настраивает автоматический deployment, как настраивает Continuous Integration? Как у него собираются приложения, использует ли он системы анализа кода (PVS-Studio, SonarQube). Как он пишет тесты или как интегрирует тесты, написанные разработчиками.

Делает ли он какое-то интеграционное тестирование этих сборок? Что дальше происходит с тем, что он собрал? Это как-то складывается в артфекаты или это упаковывается в docker-контейнеры, пушится в registry? Пусть расскажет, какие системы использовал для настройки CI/CD-процесса. Это могут быть и GitLab CI, и Circle CI, и какие-то облачные решения. А может быть, Jenkins, ну и про самописные скрипты на PowerShell не стоит забывать.

Скажи мне, как человек деплоит, и я все пойму. Он может деплоиться с помощью Helm в Kubernetes, Ansible, скриптами или чем-то еще самописным.

Про систему управления конфигурациями

Говорим чаще всего по Ansible. Поскольку его знают большинство. Итак, зачем нужны роли, как зашифровать и хранить секретные данные, как закидывать пароли на Git-репозиторий? И все в таком духе.

Узнаю про умение писать код

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

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

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

SQL, NoSQL в чем различия, с чем работали? Чаще встречаю людей с опытом работы в PostgreSQL, реже MySQL. Задаю вопросы про индексы, может ли соискатель настроить реплику, может ли настроить логическую репликацию между табличками или просто данными. А что он будет мониторить в этом случае? А как ускорить базу?

---

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

Просто...

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

Подытожу

• сети
• API-уровень
• транспортный уровень TCP\UDP
• протоколы DNS и HTTP
• Linux
• контейнерная и гипервизорная виртуализация
• CI/CD
• система управления конфигурациями
• контейнеры
• базы данных

Все это позволяет составить полную картину о человеке

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

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

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

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

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

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

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

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

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

Создайте условия

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

Проверьте динамики и микрофон

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

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

Включите веб-камеру

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

Держите под рукой блокнот и ручку

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

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

Подглядывайте в резюме

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

Не курите вейп во время собеседования

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

Не гуглите ответы

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

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

Предупреждайте о форс-мажорах

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

Помните о преимуществах онлайн-собеседований

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

Если вы работаете в области автоматизации тестирования и готовы к карьерным переменам участвуйте в Hiring Day от DINS. С вас тестовое задание и 3 часа свободного времени на онлайн-встречи 31 июля, с нас знакомство с HR и командой, обратная связь или оффер в тот же день. Узнать подробности и подать заявку можно здесь.