Собеседование сениор-разработчика — это тайна; собеседование джуна — это триллер.
Собеседования на позицию джуниор-разработчика высасывают из кандидата всю алгоритмическую энергию. Даже для участия в тренировочном собеседовании нужна большая доза сахара и кофеина. Но надо признать: они слишком предсказуемы.
Существует миллион веб-сайтов для практики алгоритмов, 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.
Kwisatz
Вы извините, но это ересь какаято. После статьи у меня прямо перед глазами встал образ очереди сеньоров которые не могут найти работу, но на самом деле в очереди стоят работодатели.
Далее: общение с клиентами, от синьера, серьезно? Если мне нужно будет чтобы синьор (ну вдруг) общался с кем то я его буду брать на встречи и следить за тем что и как он говорит и обучать, все. При найме я уж точно не ищу это качество, мне без разницы, мне нужен «бородач», я выдаю ему проблему, он мне обоснованное решение с комментариями.
JustDont
Исключая некоторые бредовые аспекты статьи (про общение с клиентами разработчика, пусть и сеньора - я тоже не очень понял), вообще центральная мысль о том, что в собеседованиях для человека с опытом "правильные ответы" это зачастую не главное - она хорошая. Потому что ну да, не главное, экзаменовать сеньора алгоритмическими задачками или другими "вопросами из учебника" - не очень интересно, в первом море ложноположительных срабатываний из-за популяризации алгоритмов силами FAANG, во втором - большинство специалистов с опытом на вопросы за пределами своей конкретной текущей области скажут "я это посмотрю в гугле" (и будут правы).
И вот тут становится важным не то, что человек говорит, а как он это делает, в каком направлении мыслит, и тому подобное. То есть, "сигналы".
Kwisatz
— Вы можете нам рассказать про интересные задачи которые вам доводилось решать?
— (а) Не рассказывает, тут странно, усомнюсь в том что написано в резюме.
— (б) Рассказывает, как правило с упоением, задаем уточняющие вопросы, обсуждаем детали, причем делаем это искренне, как будто соискатель знает больше вас, разговор двух специалистов на очень высоком уровне.
— (в) я просто делал свою работу, тоже точка зрения и с этим можно работать.
— Знаете мы бы хотели нанять вас на проект М, вам предстоит решать задачи Н, М, О, вы можете рассказать как бы вы ее решали? Есть ли мысли по проекту? Расскажите пожалуйста, поподробней про пути решения проблемы П в задаче О.
Почти везде мне интересно «что» скажет, а «как» я пожалуй оставлю для мест где я не хочу работать, у меня нет времени на эти сантименты.
Зы хотя мне интересны люди увлеченные, посему это «как» может быть плюсом, но не более того.
JustDont
Ну вот у вас в (б) уже кругом "как", а не "что".
Kwisatz
Только для красного словца, я ниже на эту тему уточнение описал.
Schavelev
Я думаю, тут речь про «консультационные фирмы» (они же out-staff, видимо). Из конца статьи — «ответственные лица относятся к сторонам с конфликтующими интересами — конкурентам и клиентам». В out-staff компаниях очень часто смешанные команды (сотрудники заказчика, контракторы, люди из других компаний). В таком контексте это по крайней мере логично. Но в таком случае (out-staff) общаться с клиентами (с сотрудниками огранизации-клиента) надо всем, а не только синьорам (ну если не исключительно синьоры в штате).
LARII
А я если честно не понял про People Management у программиста-исполнителя.
avost
да, стоят. Но очень часто сеньорская вакансия всё равно висит месяцами. И вовсе не потому, что кандидаты не идут. Идут. Об этом в статье написано. Но если на мидловые и джуновые вакансии охотно берут кандидатов не полностью матчащихся под требования, то сеньора очень часто подбирают чтобы он конкретно подходил под все требования и имел опыт работы со всем целевым стеком (видимо, мысль такая — нефиг за сеньорские деньги ещё и доучивать чувака). Поэтому, да, проблема на обеих сторонах.
Да, такое бывает. Процессы бывают построены сильно по-разному.
Это вы не ищите. Это ваш частный случай. Кто-то может искать. Проблема со стороны сеньора как раз понять к кому он попал :). В статье как раз описан ваш вариант, который кандидат неверно интерпретировал. А я, вот, как-то попадал в ситуацию строго обратную — ВСЕ вопросы интерпретировал как технические/архитектурные, а, как потом донесла разведка, меня готовы были взять и отменить собеседования с остальными кандидатами, если бы я хоть немного обозначил иные способности :). Но меня как замкнуло на техничке — ну, меня так сориентировали изначально, что не разомкнуло до конца и я даже не задумался о том почему на собеседовании не только чувак из московского офиса (а мы далеко в Сибири), но и представитель головняка из Японии (из речи которого я распознал только "конишуа" и просил москвича переводить с японского английского на русский английский)). Впрочем, хорошо, что я туда не прошёл — что-то потом они быстро свернули подразделение.
Сеньор — о-о-очень сильно размытое понятие. В этом и проблема. Автору — респект за то, что сформулировал. Я, например, догадывался, но понять не мог, теперь всё стало очевидно!
Kwisatz
Правда? Вотн е создается такое ощущение ни с одной из сторон этих чудных баррикад.
Я обычно такому радуюсь, потому что если вас на собеседовании этого не спросили, прямо или не очень, а потом это явилось решающим фактором, то вывод напрашивается простой и очевидный — идиоты.
А вы представляете какие там тараканы могут быть если даже в таких важных вещах они кошки-мышки устраивают?
avost
Так они всё правильно спрашивали! Идиотом тут был я, поскольку был в другом контексте :). Классический пример — фильм с Пьером Ришаром — Укол зонтиком.
Они не устраивают специально. Автор же привёл отличный пример. Вопрос полностью корректен в обоих контекстах и спрашивающий абсолютно уверен, что вы понимаете о каком контексте идёт речь — ну, мой собеседник ведь думает также, как я, а я у себя в уме только что сформировал логическую цепочку почему я сейчас задаю именно этот вопрос (и собеседник тоже). И вы так считаете (ну, он же думает также, как я...). Никто не предполагает, что вы должны угадать. Это просто когнитивное искажение. Надо просто знать о нём и пытаться распознать проблему. А когда распознал — задать уточняющий вопрос. Всё просто.
Kwisatz
Хм, такая точка зрения любопытна, но тем не менее, я считаю что чтобы комфортно работать лучше как раз для инженера, чтобы руководитель подобные шарады не устраивал, искажение или нет.
dimkrayan
имхо, не надо путать «собеседование сеньора» и «собеседование на должность сеньора».
Вполне возможно, что потому и не берут, что есть куча резюме от тех, кто сеньором только хочет быть, но пока не является.
А в тему, как интерпретировать вопросы — почему-то вот вообще никогда не возникало такой проблемы. Если были сомнения — либо я спрашивал, какой именно ответ от меня ждут, либо интервьювер поправлял меня.
avost
Значит вы умнее, чем, к примеру, я :).
Если есть сомнения, то тут понятно что делать. Проблема в том, что бывают ситуации, когда нет сомнения о чём вопрос, а он, на самом деле, не об этом. (см "Укол зонтиком").
Но когда знаешь куда смотреть, решение уже тривиальное.
dimkrayan
Если интервьювер в этой ситуации вас не поправил — имхо, он поступил не как профессионал. Как будто ему надо не вакансию закрыть, а найти повод, почему вы не подходите. К сожалению, такие собеседования тоже бывают, но у меня они все-таки были в основном, когда я был джуном.
victor_1212
конечно ересь, типа фантазии на тему, чтобы быть в теме автор (некто PenMagnet) должен иметь собственный достаточный опыт проведения интервью, imho senior positions элементарно меньше в разы, поэтому более тщательный отбор, плюс networking имеет гораздо большое значение, часто все уже решено после телефонного разговора, и интервью есть формальность, чем выше senior position тем чаще
RomanArzumanyan
Почему же нет?
Менеджеры обсудили условия сотрудничества, пришли сеньоры и начали собирать технические требования к проекту. Кто-то называет таких сеньоров технологами и т. п., но многие из них помимо всего прочего ещё пишут код как для внутренних нужд, так и для клиентов.
Ваш покорный слуга работает таким сеньором в продуктовой ИТ компании.
SAWER
Если платят хорошо для региона и не в рублях, то у работодателя будет хороший выбор хоть лидов, хоть сеньоров. И в такие компании действительно очередь. Настоящий опыт тут мало влияет(хотя без него никуда), а умение себя подать, вести разговор на технические темы, приводят к положительному результату. За собеседование нужно успеть показать, что ты подходишь компании. При этом, не редко компания сама не знает, что ей нужно, а если и знает, то напрямую обычно не говорит.
И это работает в обе стороны, если представитель компании хорош, то он на много чаще будет выявлять полезных для компании людей. Бывают, что собеседование не задаётся, хотя почти на всё есть ответ, но вот обратной связи нет, человек теряется, сухо отвечает, но стоит немного повернуть разговор, как уже раскрывается довольно много информации.
PS: Не так часто компании берут людей на должность сразу. Я такого не видел давно. Была бы действительно очень острая нехватка, то брали бы почти любых, хоть как-то подходящих, без очень длительных 3+ этапных собеседований, ТЗ и прочих фильтров. Так что ситуация далеко с кадрами не настолько плоха, деньгами откупаться всё ещё выгоднее, чем обучать.