Ну привет". Честно говоря, эта статья была не для вас, а для моей хорошей подруги, которая должна была пройти первое собеседование, но раз уж вы здесь…
Эта статья посвящена собеседованию по коду, поэтому мы не рассматриваем некоторые собеседования на уровне архитектора и уделяем меньше внимания решению проблем (что, возможно, даже более важно), а больше — коду.
В любом случае, давайте сначала проясним основы:
Будь профессионалом или GTFO
Чтобы успешно пройти техническое собеседование, вы должны хорошо разбираться в стеке технологий или, по крайней мере, быть более опытными, чем кандидат. Обойти это невозможно, никакое количество «Топ-69 вопросов для интервью по JavaScript» не поможет HR или генеральному директору начинающего стартапа с нулевым техническим опытом успешно пройти техническое собеседование.
И вот почему:
Причина 1: выигрывают все, никого не берут на работу
Вы хотите определить уровень знаний кандидата. Почему? Потому что после собеседования вы хотите сказать одно из двух: «Это потолок для этого парня» или «Я приветствую их, они настолько хороши, насколько может быть кандидат».
Дело не в том, что невозможно выбрать между 50 «наиболее хорошими кандидатами» (желаемая зарплата, насколько они хороши, насколько красива их улыбка), но, особенно для менее высоких должностей, вы хотите сравнить «потолки» кандидатов.
Причина 2: Они знают, что вы не знаете
Если кандидат хорош (а вы хотите, чтобы он был таким), он легко заметит недостаток знаний у интервьюера. Это может быть нормально, если инженер среднего уровня возьмет интервью у какого-нибудь системного архитектора — они оба (надеюсь) понимают, что это формальность.
Но чем больше разрыв в знаниях, тем уродливее он становится.
Я знаю парня, которого так разозлил тот факт, что весь процесс «технического собеседования» был одной девушкой из отдела кадров, которая задавала ему вопросы, напечатанные на листе бумаги, и сравнивала его ответы с правильными, что он просто встал и ушел. .
Кто-то более предприимчивый может просто воспользоваться бедной девушкой из отдела кадров или каким-нибудь самопровозглашенным гуру Java (боже, люди все еще называют себя гуру и рок-звездами?).
Даже если ничего из этого не произойдет, у кандидата останется ощущение, что процессы в вашей компании — мусор и ими управляют непрофессиональные люди. Если это так, обычно вы хотите, чтобы они узнали об этом по крайней мере через три месяца после заключения контракта, а не после 10 минут собеседования.
Теперь вы можете спросить: но Алекс, а что, если я не являюсь техническим основателем и ищу потенциального соучредителя? Какие еще у меня есть вопросы, кроме топ-69 JavaScript-интервью? Ну, у вас, вероятно, есть ваша сеть. Попросите кого-нибудь из вашей сети взять у них интервью или получить рекомендации. Как мы узнаем позже, годы опыта не всегда являются решением.
Прочтите 69 лучших вопросов на собеседовании по JavaScript
Разве я не проигнорировал их полностью в последнем разделе? Неа. Видите ли, они похожи на сывороточный протеин. Сывороточный протеин не должен быть вашим единственным источником белка, точно так же, как Топ-69 не должны быть вашим единственным источником вопросов. Буду ли я лично ожидать советов по здоровью в статье об интервьюировании людей? Я так не думаю (если вы этого не ожидали, сделайте перерыв в чтении и нажмите кнопку «Хлопать»).
Но я ожидаю, что кандидат либо знает ответы на них, либо, по крайней мере, удосужился проверить эти списки.
Когда я проходил собеседование для одного из своих крупнейших клиентов (приложение на основе Angularjs — да, не самый свежий стек, и, в конце концов, он будет обновлен), мой любимый вопрос был «Как данные Angularjs связующая работа», которая позже трансформируется в «что такое грязная проверка» и некоторые вопросы по коду по теме. Если бы вашим лучшим ответом было что-то вроде «ну, вы вводите {{field}} в свой шаблон, да… и… вот и все», мне было бы очень грустно.
Меня не волнует, что вы в последний раз работали с Angular в 2015 году. Вы приходите на собеседование, и я ожидаю, что вы либо знаете ответ, либо показываете, что вы хотя бы удосужились погуглить вопросы для собеседования по Angularjs. Ваша работа как интервьюера состоит в том, чтобы выяснить, знают ли они технологию/принципы или гуглили ли вопросы.
Я хочу сказать, гуглите сами вопросы. Вы можете не только найти несколько хороших идей, но и лучше понять, к чему потенциальный кандидат должен быть готов.
Тесты для школьников
Спросите кандидата, «что будет на выходе этой функции», и вы можете услышать правильный ответ. Спросите их, почему они так ответили, и вы поймете.
Когда я учился в школе, учитель, готовивший команду к олимпиаде по математике, называл тесты «игрой в угадайку» (у нас в Беларуси есть что-то похожее на SAT). Можно дать кандидатам своего рода тест в качестве фильтра, но никогда не стоит основывать свои решения о найме исключительно на них. Или не задавать вопросы как о неправильных, так и о правильных ответах.
Говоря о младших разработчиках, вы не представляете (и я в то время тоже не представлял), сколько людей ответят правильно, но не смогут объяснить почему.
Опыт в собачьих годах
Есть поговорка: «Возраст — это всего лишь число, а тюрьма — это всего лишь комната». Шутка о возрасте согласия должна быть где-то здесь, но это не имеет значения. 1 год в агентстве веб-разработки, которое создает веб-сайты электронной коммерции на WooCommerce ≠ 1 год в крупной аутсорсинговой компании ≠ 1 год в стартапе.
Есть некоторые вещи, которые люди могут получить только с опытом, и, вопреки утверждениям многих аутсорсинговых компаний, как у нас, так и по всему миру, 3 года опыта ≠ Старший разработчик (может быть, когда-нибудь я даже напишу статью об одном человеке 6 месяцев после их первой работы в iTe**art, когда они продаются клиенту в качестве старшего разработчика). Так что не ждите, что через 2 года в индустрии придет горячее шоу и спроектирует архитектуру вашего корпоративного приложения, это плохая идея.
С другой стороны, как насчет людей с 2 годами работы системным архитектором, 1 годом работы руководителем группы и общим опытом работы в отрасли более 7 лет?
Проверить каждую компанию, указанную кандидатом, особенно сложно, когда кандидат находится в другой стране. Учитывая мой опыт проведения собеседований с удаленными разработчиками, я был бы очень, очень осторожен с людьми, которые должны иметь соответствующий опыт, но вы не чувствуете, что они делают.
Никогда не доверяйте записям Linkedin больше, чем своему мнению.
Доверьтесь своей интуиции.
Если вы принимаете решение самостоятельно, доверяйте своей интуиции. Если нет, расскажите HR/менеджеру, что вы думаете о кандидате. Не держите это в себе.
Самозванцев или неквалифицированных старших архитекторов системных решений больше, чем можно ожидать. Это применимо не только к ИТ, но и ко всем отраслям. Я настоятельно рекомендую вам приобрести экземпляр этой книги, в ней есть несколько разделов, посвященных самозванцам.
Не бери дерьмо вообще
Вы должны проявлять уважение там, где это необходимо. Павел Шабалин — человек, который научил меня не принимать никаких абсурдных объяснений и всегда докапываться до сути проблемы. Это касается как встреч/стендапов, так и интервью.
Если вы чего-то не понимаете, может быть, из-за акцента или просто потому, что непонятно, что имеет в виду кандидат (или у вас есть хоть малейшая тень сомнения), спросите. Если вопрос неясен, повторите.
Если вы чувствуете, что кандидат становится хитрым или уклоняется от вопросов, задайте ему вопрос «Да/Нет» и попросите его дать определенный ответ. Следующий диалог основан на реальном интервью, которое я провел для этого проекта Angularjs.
– Будет ли работать этот фрагмент кода?
– *минутный ответ, который не дает точного ответа на вопрос*
– Итак, будет ли работать этот фрагмент кода ?
- *10 секунд тишины* Это не сработает, потому чтото-то и то-то
- Вот мы делаем это и это, ну и что вы говорите, что это неверно. Этот фрагмент будет работать?
– Да, верно, я говорил, что он будет работать.
- Нет, не будет. Мы неправильно привязываем контекст.
– Да, я говорил, что это не сработает.
Если вы боитесь выглядеть плохо, повторяя некоторые вещи или задавая этому системному архитектору несколько простых вопросов,просто представьте, как глупо вы будете выглядеть, если не спросите их + они не смогут ответить + их наймут .
Если у вас есть хотя бы тень сомнения, повторите итерацию.
Я знаю, как это странно, особенно когда вы берете интервью у людей с большим стажем, чем у вас, которые старше вас. Не забывайте, однако, что предполагать, что они знают ответ на ваш вопрос (если только речь не идет о том, как вывести «Hello world» в консоль), — плохая идея.
Спросите концепции
Я могу открыть некоторые js wtfs и начать задавать людям вопросы, есть ли typeof null === "object" или какие-то вопросы о наследовании прототипов, которые больше никто не использует в эпоху Вавилона и которые я бы сам озадачил. Будет ли это полезно? Нет.
Несколько раз я пытался убедить кандидата в том, что в React вместо использования Redux или GraphQL нужно просто загружать данные из бэкенда через axios и передавать их через реквизиты, потому что весь Redux — это заговор с целью сделать веб разработка усложняется, чтобы разработчикам платили больше.
Вы редко выигрываете этот спор, но это весело.
Записывать
В отличие от этой статьи, которую вы можете открыть в любое время (надеюсь), ваш интервьюер не будет рядом, чтобы вы могли повторить все его ответы. Это было бы особенно серьезно, если бы у вас было 6 интервью подряд (кстати, это как бы выжигает вас). Так что делайте заметки. Запишите и хорошее. К концу интервью у вас должно получиться что-то вроде этого:
Хорошо начал с тестов, провалил вопрос о чистой функции, не знает, как работает Redux, потребовалось 40 минут, чтобы решить вопрос о кодировании. Жесткий проход.
or:
В некоторой степени разбирается в связывании, хорошо разбирается в вопросе о запахе кода, но имеет небольшой опыт в этой области. 8/10, лучше предыдущих
Они понадобятся вам либо сами, если выбор найма — это ваш звонок, либо вы сможете предоставить их менеджеру по персоналу/менеджеру. Такой краткий отчет намного лучше, чем «Ну, я думаю, что он не идеален, но он в порядке».
Вопрос о запахе кода
Я посвятил 50% своей блогерской карьеры разговорам о качестве кода. В каждом отдельном интервью я на 100% добавляю вопрос плохой код, варьирующийся от что не так с этой глупо раздутой функцией из 600-loc с 12 аргументами до что-то не так со следующим подходом. И вы тоже должны. Я настоятельно рекомендую видеокурс Боба Мартина по качеству кода — вы можете сформулировать свои вопросы так же просто, как просто взять все худшие практики и запихнуть их все в один фрагмент кода, а затем попросить кандидатов найти их все. Не забывайте говорить и спрашивать почему всякий раз, когда вы чувствуете, что кандидат может не ответить, особенно при собеседовании с младшими/средними разработчиками. Всякий раз, когда вы чувствуете, что они могут не знать, вы мягко нажимаете, пока не получите четкий ответ.
Вопрос кодирования
Это обязательно при собеседовании с младшими разработчиками, и становится менее важным, когда кандидат обладает более высокими навыками. Я предпочитаю Codewars для этого. Найдите несколько относительно сложных ката, ничего особенного, расслабьтесь и наслаждайтесь шоу.
Стресс, сэндвич и суд Соломона
Убедитесь, что всем удобно. Никто не хочет допроса. Улыбнитесь, предложите им кофе, если вы проводите интервью на месте. Если вы толкаете, делайте это мягко и вежливо. Не ведите себя придурком, если только кандидат не попросил вас вести себя придурком, например: «Да, верно, я говорил, что это сработает».
Из 50 с лишним интервью, которые я провел в прошлом году, в двух было заметно, что кандидат опечален своей неспособностью ответить. Одна девушка вместо ответа просто промолчала. Если это так, не давите. К тому времени становится совершенно ясно, что это собеседование не закончится наймом, так что не нужно давить.
Всегда начинайте с положительной ноты и всегда заканчивайте на единице, особенно с младшими разработчиками, которые ищут свою первую позицию. Они могут быть недостаточно компетентны, но не нужно говорить об этом им в лицо.
Не говорите им: «Мы свяжемся с вами позже», если вы не планируете этого делать.
«А как насчет стресса? То, что вы здесь описали, звучит очень напряжно! Это нехорошо и нехорошо».
Обычно, если кандидат действительно хорош, вам вообще не нужно давить. Если они сразу плохие, тоже не давите. Вы нажимаете, когда не уверены. Компания, в которой вы работаете (или даже ваша компания), бизнес ваших клиентов и благополучие сотрудников вашей компании и, конечно же, ваше собственное благополучие и карьера — все зависит от того, как вы сделаете правильный выбор при найме.
Если кандидат не может пройти собеседование из-за стресса, рассмотрите возможность переноса собеседования или, если работа в вашей компании достаточно напряженная, сразу же откажитесь от него. Это суждение Соломона: если вы находитесь в стартапе, торопитесь выпускать функции и одновременно пытаетесь угодить своим клиентам и инвесторам, вам, вероятно, не нужны люди, которые не могут работать под давлением. Итак, если кто-то провалил ваше собеседование, потому что оно было несколько напряженным, он провалил его.
ПРОФЕССИОНАЛЬНЫЙ СОВЕТ №1. Если у вас есть 10 минут, но вы уже четко понимаете, что продолжение этого собеседования будет пустой тратой времени, пусть кандидат так и скажет. Спросите кандидата, что он думает о том, как прошло интервью, и если бы это были вы, продолжили бы они.
Вывод
Если вы интервьюер, вашему суждению доверяют. Поймите, что вы можете быть неправы, но никогда не позволяйте фразам «Вероятно, они имели в виду это», «Мне кажется, что если я задам больше вопросов, это может разочаровать кандидата» и «Они не могут не знать, что у меня есть подозрения, что они не знаю» мешают правильно выполнять свою работу.
Если вы хотите, чтобы я работал с вами, напишите мне на Linkedin или напишите мне на [email protected]. Или подписывайтесь на меня в Instagram.
