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

Шахматы - очень старая игра, но и там бывает что-то новое.
Шахматы - очень старая игра, но и там бывает что-то новое.

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

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

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

Вверху - самое ценное
Вверху - самое ценное

Начнем, как и положено, с самого важного. Базовые ценности.

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

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

Во вторую очередь неплохо определить рабочие обстоятельства, то есть как кандидат привык работать повседневно. Нужен ли ему жесткий контроль сверху (и иногда локтем поддых чувство локтя сбоку), или может быть его нужно отпустить в свободное одиночное плавание? Хочет он начинать рабочий день в 9:00 в офисе, или предпочитает днем спать, а работать ночью под звон сверчков на даче? Планирует ли он свой график на неделю, или делает всё в последний день? Опять же, тут нет ни одного правильного или хорошего ответа, главное, чтобы ответы были честными.

Въедливый читатель сразу спросит – а как же может быть полезным свойство оставлять всё на последний день? А я отвечу практическим кейсом – часто иногда бывает так, что правки и баги прилетают внезапно в большом объеме, и их надо делать вчера. Именно тут полезны люди, способные на короткое время (до двух суток) мобилизовать волю и сделать дело, потом двое суток отсыпаться. У людей же четко планирующих такое развитие событий вызывает недоумение – у них семьи, запланирован отдых с детьми и тёщей, нельзя ли положить задачи в бэклог следующего спринта?

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

Поэтому вопрос «Как вы справились со сложной задачей на прежнем месте работы?» плохой, кандидат очень навряд ли ответит, что не справился, истерил, разбил в приступе ярости корпоративный ноутбук, и его вобщем-то за этот провал и выгнали. Он придумает что-то типа «у них ничего не работало, но как только я переступил порог, сразу всё наладилось, взлетело, пошли коммиты и релизы, и проект вышел в ПРОД на 2 месяца раньше срока».

А вот вопрос «Чему вы научились за последний год?» хороший, так как показывает, осваивает ли кандидат что-то новое. Тут открывается целый ряд продолжений, из которых будет ясно, что именно кандидата интересует, в какие темы он хочет углубиться, в какие попробовал – и не понравилось. Это всё легко сопоставимо с требованиями к кандидату.

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

Наши привычки с нами надолго
Наши привычки с нами надолго

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

В конце можно поспрашивать про вещи, которые нужно именно знать – понимание паттернов проектирования, принципов SOLID, KISS и DRY, и вот это вот всё. Так как эта часть самая малозначимая, то уже примерно понятно, годится кандидат на позицию или нет, и можно просто поговорить на тему.

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

Ну и на сладкое – избегайте вопросов-головоломок «а что будет в этом кусочке кода», особенно если при наборе этого кода в IDE он засверкает красненьким. Никто кроме Яндекса не пишет код на листочке и не компилирует его в уме.

На сегодня всё. Задавайте вопросы с умом, и помните, что

Жизнь - сложная штука.
Жизнь - сложная штука.

Комментарии (13)


  1. Fexele
    21.05.2024 15:53
    +3

    "Собеседование на работу – это разговор двух лжецов"

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

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


    1. Trihlorid Автор
      21.05.2024 15:53

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

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


      1. syschel
        21.05.2024 15:53

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


    1. ruslan_sverchkov
      21.05.2024 15:53

      А так, интервьювер тот же лгун

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


  1. MinimumLaw
    21.05.2024 15:53

    Никто кроме Яндекса не пишет код на листочке и не компилирует его в уме.

    Не работали вы в embedded... Там это чуть ли не основной навык. А вот зачем этот навык зачеркнутым - вопрос очень открытый.

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

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


    1. Trihlorid Автор
      21.05.2024 15:53

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


      1. MinimumLaw
        21.05.2024 15:53

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

        В общем случае одним из самых ключевых свойств кода, работающего на этом уровне будет скорость. Коду драйвера или планировщика непозволительно "отбирать" процессорное время у прикладных программ. Идут жаркие битвы по поводу границ этого утверждения, и я, если честно, долго думал стоит ли отвечать. Рискую разжечь очередную ветку священной войны, но... Пусть будет. Единственное, что я обязан обговорить - так это вопросы безопасности. Как той, которая "safety", так и той, которая "security". К сожалению русское "безопасность" не передает нюансов, а синонимы "взломостойкость" и "отказоустойчивость" тоже не вполне применимы. И тем не менее, даже с учетом этих ограничений скорость критически важна. А поскольку код работает непосредственно на аппаратуре, скорость его работы непосредственно зависит от того через какие именно цепи потекут электроны в процессоре и окружающей его периферии. И становится критически важно понимать, как тот или иной код, написанный как правило на том самом "кроссплатформенном ассемблере с элементами структурного синтаксиса" (т.е. языка C, опять же как правило без всяких плюсов) преобразуется в машинные инструкции и каким именно путем они в свою очередь заставят бежать электроны по самому процессору и окружающей его схеме.

        У нас очень простой код. Ну правда - у нас нет каких-то предсказаний поведения чего бы то не было, как правило нет серьезной математики с плавающей точкой. Есть только довольно линейные алгоритмы - если произошло событие "a", то делай "бэ". Но делай максимально быстро и не мешая другому коду (не останавливай выполнение соседних потоков без реальной на то необходимости). Ну и адекватно реагируй на асинхронные события. Выдрал пользователь USB-устройство, а у тебя кто-то с ним работает. Изволь сам не упасть, и не задержать остальных впав в бесконечное чтение из отсутствующего устройства, ну и этому самому кому-то работающему нормально завершиться позволь. В первом приближении абсолютно ничего сложного. Ровно до тех пор, пока за реализацию не возьмешься. И еще неизвестно где сложнее - в составе операционной системы, где есть какие-то программные средства IPC и управления временем выполнения или на контроллере, где реально только железки и твой код, пасущий табун электронов.

        Да, конечно, код "на листочке" мало кто пишет (разве что в учебных или трепологических целях, вспоминая в очередной раз те самые UB - неопределенное поведение или гораздо чаще избыточно умные оптимизаторы компиляторов), Но тем не менее - навык работы компилятором реально важен. Более того - именно в embedded среде главной проблемой является не UB, а именно излишнее "оптимизаторство" компиляторов. Я руками развернул цикл ради скорости, а излишне умный компилятор увидел и завернул все назад в цикл - практически типовая проблема, особенно если применяется типичная для нашего мира опция -Osize (т.е. оптимизировать под минимизацию размера). Так что мы, наверное, остаемся теми немногими, кто просто регулярно проверяет что именно там наделал с нашим кодом компилятор, и не стоит ли его поправить.


  1. N4N
    21.05.2024 15:53

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


    1. Trihlorid Автор
      21.05.2024 15:53

      Спасибо!


  1. Bynthgjkzwbz
    21.05.2024 15:53

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


  1. Stauroman
    21.05.2024 15:53
    +3

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

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


  1. vregose
    21.05.2024 15:53

    С интересом бы посмотрела на результаты опроса «рекрутерам на собеседовании приходилось»... Потому что там, по идее, тоже самое, только хуже. Особенно на первом каком-нибудь этапе.


  1. GaDzik
    21.05.2024 15:53

    Мне нравиться. Стал еще увереннее в своих силах и мотивации. Много раз читал статьи автора из других источников. Всегда в тему и по делу. Узнал по "тяжелый вздох".