[Перевод] Почему сениор-разработчики чаще получают отказ на собеседованиях?
Собеседование сениор-разработчика — это тайна; собеседование джуна — это триллер.
Собеседования на позицию джуниор-разработчика высасывают из кандидата всю алгоритмическую энергию. Даже для участия в тренировочном собеседовании нужна большая доза сахара и кофеина. Но надо признать: они слишком предсказуемы.
Существует миллион веб-сайтов для практики алгоритмов, YouTube-каналов для подготовки к собеседованиям и постов в блогах, рассказывающих, как устроиться в Google. Разумеется, подготовка к таким собеседованиям требует времени, но с ними вполне можно справиться.
Самое важное для прохождения собеседования на должность сениор-разработчика — понять, что такая же стратегия не подойдёт для него.
(Примечание: это утверждение не относится к собеседованиям сениоров в FAAMG+, в которых неизбежно требуется намного больше тестов знаний алгоритмов, чем на собеседованиях в других компаниях, однако у меня нет личного опыта собеседования в них.)
Подчеркну цель этой статьи: в среднестатистических компаниях, занимающихся разработкой ПО, уровень отказов при проведении собеседований на должность сениор-разработчика чрезвычайно высок.
Тот факт, что не все сениоры собеседуются одновременно (на одной и той же задаче), показывает, что это не проблема спроса и потребления.
Десяток лет назад многие материалы для собеседований сениоров состояли из двух частей:
- Знание соответствующих API
- Знание процесса поставки и разработки ПО
Честно говоря, они были гораздо проще, чем собеседования джунов. Часто даже не проверялось знание алгоритмов!
Сегодня ожидается, что сениор-разработчик знает только одно. Но ожидания слишком высоки, у вас нет шанса на манёвр. Не стоит ходить вокруг да около. Чтобы пройти собеседование, недостаточно простого накопления знаний, требуется гораздо больше.
Собеседования сениор-разработчиков имеют структуру, пусть даже не все собеседующие и кандидаты об этом знают.
Чтобы справиться с собеседованием, нам нужно разобраться в этой структуре.
Фактор, присутствующий в каждом собеседовании сениор-разработчика
Прежде чем приступать, давайте рассмотрим актуальный сегодня пример.
Если у вас болит горло, то вы чувствуете, что заболели. Но вы не знаете, грипп у вас или коронавирус. Больное горло — это симптом, а не заболевание. Сама болезнь ещё не диагностирована. Однако вы понимаете, что с телом что-то не так и вам нужно сдать тесты.
Лабораторные тесты ищут конкретные параметры, а не просто симптомы. Наличие или отсутствие этих параметров в конкретном количестве определяет, заразились ли вы, и какой именно болезнью.
Проводящие собеседование ищут болезни (то есть первопричины) определённого типа. Как и лаборатории, они игнорируют симптомы. Если вы вывалите на них мешанину из технического жаргона и модных словечек про API, то вероятность успешного собеседования сильно снизится. Любой может сымитировать подобное всезнайство, погуглив во время пути на собеседование.
Но если вы продемонстрируете свою методичность, то завоюете их внимание. Как и специалисты из биолаборатории, они полагаются на методы, строго демонстрирующие пригодность или непригодность кандидата.
Эти методы называются сигналами. Это очень старая физиологическая концепция, используемая, когда дело касается любого вида взаимодействий между людьми. В брачный период животные и птицы демонстрируют и ищут сигналы от наиболее подходящего партнёра.
Пары на свиданиях в кафе постоянно считывают настроение друг друга. И проводящие собеседования ничем от них не отличаются, только для них существует очень мало инструкций. Зато в материалах о подготовке к интервью недостатка нет.
Тем не менее, в безумии собеседований есть своя логика. Собеседующим смотрят не на правильные/ошибочные ответы. Сквозь ваши ответы они ищут сигналы.
Сигналы, а не содержание ответов.
С точки зрения программирования эта концепция была рассмотрена в книге Cracking the Coding Interview знаменитого тренера по собеседованиям Гейл Лакманн Макдауэлл, работавшей в Google, Microsoft и Apple. Так как подаваемые на собеседованиях сигналы настолько важны, она на крайне рекомендует кандидатам сообщать о процессе продумывания состояния задачи на whiteboard-собеседованиях.
Подведём итог
Важно не содержание ваших ответов, а передаваемые через них сигналы, определяющие ваш выбор.
Может случиться так, что вы с вашим другом пойдёте на одно интервью и совершите одну и ту же ошибку, но ваши рассуждения, которые привели к ней, могут убедить проводящего собеседование, а другу этого сделать не удастся.
Чем сильнее положительные сигналы, тем выше ваши шансы на успех.
Так как технологии по своей природе несопоставимы друг с другом, сложно чётко выделить конкретные аспекты для каждой должности сениор-разработчика. Тем не менее, всегда можно провести общую классификацию вопросов на собеседовании.
Вопросы собеседований сениор-разработчиков можно обобщённо разбить на три категории:
Если рассмотреть каждую из категорий, то становятся очевидными два фактора:
- Технические знания специфичны для каждой отрасли. Вы нарабатываете их в течение многих лет опыта. Когда появляется возможность собеседования, вы вряд ли что-то сможете с ними сделать, кроме как освежить знания. В своей статье, ссылка на которую приведена выше, я уже говорил о том, на чём конкретно нужно сосредоточиться.
- Вопросы на знание процессов + управление людьми обычно бывают общими. Вы должны вспомнить о примерах из своего опыта и показать, как успешно справились с ними благодаря собственному подходу или рассказать, чему научились из своих провалов, как любой рациональный человек. Они являются общим знаменателем, но их пропорция может варьироваться. Например, если проводящий собеседование не посчитает вас технически компетентным, то он может сократить эти вопросы или полностью пропустить их. Но если вы показали себя многообещающим кандидатом, то он может углубиться в эту часть, чтобы решить, попадёте ли вы в шортлист.
Каждый вопрос, задаваемый на собеседовании, более-менее можно отнести к одной из приведённых выше категорий. В области технических вопросов (огромной, 50-процентной части диаграммы) вопросы могут разветвляться на более мелкие подкатегории.
Когда я читал книгу «Cracking the Coding Interview», то заметил, что она здорово объясняет, как разбивать технические вопросы на подгруппы: «жадные» алгоритмы, двоичный поиск и т.д. Они достаточно популярны на собеседованиях FAAMG+, где первостепенную важность имеет знание computer science.
Что важнее всего запомнить
Обратите внимание, что ответы на эти вопросы демонстрируют ваши знания. С другой стороны, обоснование ответа, ваш тон и всё остальное, что представляет ваше мнение, образует ваш образ в сознании проводящих собеседование.
Именно этот образ и является сигналом, о котором я говорил.
Шокирующее и обманчивое открытие
Определение категории вопроса на собеседованиях сениор-разработчиков является проблемой и для большинства мелких и средних компаний. Единственное отличие в том, что разница в категориях размыта, как и сказано выше.
Это означает, что большинство кандидатов ошибочно относят вопросы к одной из трёх описанных категорий!
Этот вывод удивителен, но всё-таки правдив. Я совершал такую ошибку более пятидесяти раз. И я уверен, что именно эта ошибка виновата в большинстве отказов.
Вас это не убедило? Вот обоснование этой теории:
- Посмотрите на количество претендентов в постах о вакансиях в области разработки ПО на LinkedIn.
- Даже в мелких и средних компаниях на одну вакансию программиста приходится почти 60–100 кандидатов.
- Реклама крутится по три-шесть месяцев, то есть должность остаётся незанятой в течение долгого времени.
Разумеется, LinkedIn очень часто не отражает ситуацию с вакансиями, но я подтвердил свою догадку, заглянув в разделы «Карьера» соответствующих компаний. Вы можете сделать это самостоятельно.
Это чётко даёт понять, что собеседования проводятся, но подходящий кандидат не находится. Почему? По требованиям портфолио они подходят, и это подтверждается процессом проведения собеседований (рекрутёры часто публикуют вакансии в своих лентах).
Очень маловероятно, что такое количество опытных кандидатов недостаточно подходит из-за технических знаний. Тем не менее, подходящий кандидат не находится.
Так происходит, потому что во время собеседования на должность сениор-разработчика:
- Кандидат не демонстрирует вовремя сигналы. (Ответы типа «я не знаю» — это честно, зато очков вам не добавит!)
- От кандидата не ощущается положительного настроя, когда его ожидают. (Молчание вместо стратегии проявления инцициативы.)
- И даже когда они проявляются, их величины недостаточно. (Инициатива демонстрируется, но очень расплывчато, не в конкретной форме. (Короткие предложения типа: «для обеспечения обмена знаниями я настрою Google-документ».)
- Иногда кто-то ждёт фальшивых сигналов. Или правильных, но изложенных неправильно
(вина проводящего собеседование, отсутствие комментариев).
Спустя почти 55 минут напряжённого собеседования организаторы уже начинали тепло мне улыбаться.
В качестве последнего вопроса они задали мне такой:
Если клиент спросит вас о разработке фуллстек-системы с мобильными клиентами, то каким будет ваш ответ?
Так как большинство технических вопросов уже было задано, я решил, что это вопрос о процессе и/или о способности взять инициативу.
Поэтому я ответил так:
Я узнаю у него требования.
Затем я, очевидно, подробно рассказал, как буду это делать, задавая конкретные вопросы об используемой клиентом системе управления проектом, и так далее.
Тем не менее, меня не приняли. Но ещё больше меня поразила причина отказа:
Нам нужен человек, способный представить варианты выбора с их плюсами и минусами, чтобы клиент мог принять обоснованное решение. К сожалению, даже если вы обладаете такими умениями, вы их не продемонстрировали. Удачи в следующий раз!
Я ошибочно отнёс технический вопрос к категории вопросов о процессах!
Я утешал себя тем, что мне не хватило контекста. Но это было просто оправдание, потому что я не попытался определить категорию вопроса. Я проиграл в уже выигранной игре.
Собеседования с сениор-разработчиками — это загадка. Они устроены подобно мышеловкам, и на то есть причина.
В продуктовой компании сениор-разработчик должен активно взаимодействовать с ответственными лицами. В консультационных фирмах всё ещё сложнее, потому что ответственные лица относятся к сторонам с конфликтующими интересами — конкурентам и клиентам.
Нечёткие вопросы на собеседованиях специально придумываются для проверки способности кандидата ориентироваться в реальной ситуации. В мире, управляемом жадными владельцами Agile-продуктов, незадачливого разработчика сразу же съедят.
И всё сводится к одному: правильно определить категорию задачи и продемонстрировать максимально конкретный позитивный настрой относительно заданного вопроса. Никакой краткости, никаких противоречивых сигналов.
В конечном итоге, неважно, прошли ли вы собеседование. Если вы не подходите компании, то и она, скорее всего, не подошла бы вам.
Из-за роста популярности Agile и lean в стартапах работодатели больше не воспринимают новых сотрудников как ресурсы. Они рассматривают их как долговременных партнёров и ответственных лиц.
Собеседования на должность сениор-разработчика стали гораздо более гуманистичными по своим целям, однако они не всегда проводятся столь же гуманно.
Тем не менее, нужно относиться к собеседованиям больше как к свиданиям, а не к тестам.
На правах рекламы
Мощные VDS с защитой от DDoS-атак и новейшим железом. Всё это про наши эпичные серверы. Создайте собственный тариф в пару кликов, максимальная конфигурация — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe.
Подписывайтесь на наш чат в Telegram.
