ИНТЕРВЬЮ ГЛАЗАМИ ПОСТРАДАВШЕГО

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

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

Дальше про программистов. В игровой индустрии. Тупо по опыту. Как это всё применимо вне игровой индустрии – я не знаю. Как это всё работает там, где меня не было – я не знаю. Там, где я был, работало (когда работало) – только так. По-другому не работало. Некоторым такое «не работало» стоило всякого, окончательно.

Нанимать нехороших кадров просто потому, что не получается нанять никаких других – плохая, глупая идея. Мифический «средний» программист тоже не нужен. Вообще. Деление здесь практически бинарное – может писать код или не может писать код. Бывает, что может студент. Бывает, что не может эксперт с мировым именем. У интервью две задачи; первая – выяснить, «может» или «не может»; вторая – выяснить, «нравится» или «не нравится».

Если может, но не нравится – можно попробовать несколько разных команд, внутри большой конторы. А можно не пробовать. Если не может – то нанимать не надо вообще. Нельзя. Никак. Менеджером тоже нельзя. И скриптером тоже. С не нравится в общем-то тоже жить тяжело, но тут хоть как-то можно решать. Отсадить. Работать по удалёнке. В ночную смену. С не может жить нельзя, научить не получится.

Время собственных правильных кадров надо жалеть и экономить. Будем экономить. Начнём с отбора резюме. Собирает HR+рекрутер (можно в одном лице), по ключевым словам или как угодно ещё (хоть бы и медитацией). Может давать вопросник. Шлёт вакансии, пробует сманивать, постоянно общается со своими кошерными кадрами – чтобы хорошо понимать и чувствовать формальные признаки. Полученную папку резюме просматривает уже лид, или тот, кому лид поручил. Аналогично вакансии пишет лид. Если есть сомнения – резюме выкидывается. Если есть непонятки – их выясняет HR.

Пишите простые вакансии. «Нужен хороший программист делать всё». «Нужен хороший программист программить сетку». «Нужен написатель графики». «Нужен написатель звука». «Нужно заскриптить пол игры». Плясать надо от нужен.

По кошерным резюме проводится отписывание/отзвон. На предмет «телефонного» интервью. Короткого. 5-30 минут, в зависимости от успешности. После такого интервью даётся домашнее задание, которое надо будет сделать за 1 час. Кадру заранее сообщается, сколько надо будет времени, и на что его надо будет тратить. Пусть готовит комп с компилятором. Гугль пусть не готовит для разговорной части.

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

Сперва даю первую секцию вопросов. Плохо отвечавшим (прощёлкано 2 и более вопроса) вежливо говорю спасибо, и дальше с ними общается HR. Если я не понимаю ответ – то я уточняю. Если я долго не понимаю ответ – считаю, что он не ответил. На его уточняющие вопросы я отвечаю. Внятные уточняющие вопросы – это сразу бонус.

Секция «с миру по нитке»

  • 2^8 (проебавших конкретно этот, обычно шлю лесом сразу).
  • 2^16, битовое представление.
  • -1, битовое представление.
  • Скалярное произведение.
  • Векторное произведение.
  • Наследование и виртуальные функции в C++.
  • new супротив malloc в C++.
  • Tree супротив list, как структуры данных.
  • Hash как структура данных.
  • Производительность, что такое и про что O(N).
  • N*log(N) в дереве, и почему оно так.

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

Можно показывать условно слабые знания в каждой конкретной секции. Совсем «никакие» знания показывать нельзя. Конкретно проваливших две секции вежливо отправляю прощаться с HR. Замечу, здесь всё ещё телефонные вопросы.

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

Прощаться и здороваться крайне важно. Когда здороваемся – говорим кто, откуда зачем. Когда прощаемся – интересуемся, какие есть вопросы. Если планируется продолжение банкета – обговариваем. Если не планируется – говорим, что HR с вами свяжется. HR и так знает, как прощаться насовсем; программисту это делать совсем не обязательно.

Секция «биты это вам не байты»

  • -2, битовое представление.
  • Как реализовать neg.
  • Как реализовать abs.
  • Как можно больше способов реализовать x/2 (бонус за методы, которые работают с отрицательными x).
  • Как можно больше способов реализовать x*3.
  • 1.0f, битовое представление. Бонус за «нормализованные» float-ы, бонус за double супротив float.
  • Как реализовать fabs.
  • Как реализовать float->int, «быстрый» float->int если знаем range.
  • Сравнительные характеристики разных битовых операций (по производительности).

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

Секция «матемачиха и линейное щастье»

  • Всё, что знаете про векторное произведение, за 3 минуты.
  • Как посчитать нормаль треугольника по 3 точкам.
  • Векторы, операции над ними, нормализация вектора.
  • Матрицы, операции над ними, умножение вектора на матрицу.
  • Единичная матрица, обратная матрица, как быстро инвертировать ортонормированную матрицу.
  • Базисы, не ортонормированные базисы, зачем нужны, расстояние между двумя точками в таком базисе.
  • Сферические координаты (зачем нужны)
  • Кватернионы, операции для кватернионов, зачем нужны, slerp
  • Сравнительные харрактеристики производительности операций над векторами, матрицами, кватернионами, конверсии из и в.

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

Секция «езыг врагов наших, С++»

  • Всё о наследовании за 3 минуты (зачем нужно, множественное, виртуальное, публичность).
  • Что такое pure virtual function (зачем надо). «Контракты» в качестве бонуса.
  • Vtbl, vptr, и прочие детали реализации. Бонус за множественное наследование. Бонус за виртуальное наследование.
  • Конструкторы, деструкторы, порядок создания и удаления.
  • Виртуальные функции в конструкторах.
  • Шаблоны (зачем нужны, что такое специализация, что с производительностью).
  • Исключения (зачем нужны, производительность, особенности реализации).
  • new супротив new[] – зачем нужны, особенности реализации.
  • STL (зачем). Бонус за историческую справку. За 3 минуты о производительности основных типов.
  • Для любого (вставить «нужное») описать сайд-эффекты, когда не работает и почему. Бонус про «без сайдэффектов».

Задавать некорректные вопросы «с подманкой» вполне можно. Вполне можно, например, спрашивать почему умножение быстрее маски, или почему у дерева O(N^2) при поиске. Особенно можно по телефону – от телефона всегда можно убежать и не получить по ушам. Хорошо чувствовать собеседника – и вместе посмеяться подманке.

Секция «современная археология через призму ассемблера»

  • Зачем нужен в «вставить сегодняшний год» году.
  • Latency и throughput – что? где? когда?
  • Всякий доступ к памяти, L1 и L2. Бонус за iCache, бонус за DMA.
  • Сравнительные характеристики скорости доступа к памяти.
  • Сравнительные характеристики цены операций. Madd супротив битов супротив деления супротив степени. Jump prediction как бонус.
  • Почему float умножение быстрее чем целочисленное.
  • SIMD, зачем нужен.
  • SIMD, сравнительные характеристики производительности основных операций. Выравнивание. Разное.
  • Как работают прерывания? Зачем они работают?
  • Loop roll супротив loop unroll. Бонус за переименование регистров.

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

Секция «Ящики. Большие серые ящики. Контейнеры. Структуры данных. Разное»

  • Linear access супротив random access. Бонусы за кеш.
  • Hash (insert, delete). Многовходный. Бонус за идеальную хеш-функцию.
  • Дерево. Поиск, характеристики производительности. Бонус за красно-чёрное дерево. Бонус за «где в STL используется красно-чёрное дерево».
  • String, детали реализации, как оптимизировать. Типичный хеш для строчки.
  • Что такое lazy evaluation и как его можно реализовать на С++. Зачем он нужен.
  • std::vector и эквиваленты. Зачем нужен. Производительность.
  • std::map и эквиваленты. Зачем нужен. Производительность.
  • Как выделять память. Аллокаторы. Стратегии аллокации. Реализация. Производительность.
  • Lifetime, сборка мусора.

Всякие дополнительные секции пишутся по специфике конторы. Если игра сетевая – пишется секция по сетевым протоколам. Если используем много скриптинга – спрошаем за LUA, Python, Perl, другие страшные слова. Такие секции безусловно «специальные». Спрашивать про них осмысленно, если они есть в резюме. Если нет – можно поинтересоваться.

Для очень специальных специалистов можно опускать секцию про ассемблер. Т.е. если нанимать специального программиста на C# делать всякое к редактору, то без ассемблера он переживёт. Вместо ассемблера осмысленно вставить обязательную специализированную секцию по дисциплине; в нашем примере C#.

По окончании такого интервью даётся «домашнее задание». На 1 час. Получил – прочитай; спроси что не понял. Как понял – напиши. Как дописал – отладь. Как отладил – присылай обратно, и сразу звони. Если не звонит через час – то звоним мы. Еще минут 10 мы можем простить.

Обычно «домашнее задание» – задача, которую можно легко и качественно с чистого листа без использования стандартных библиотек запрограммировать и отладить за пол часа. 30 минут. Толковый уже нанятый кадр. И до часу самый бестолковый. Такое задание посылается по email-у, по получению (и после всех уточняющих вопросов) начинается отсчёт.

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

Я использовал «посчитать, сколько раз встречается каждое слово в текстовом файле». Можно брать практически любое аналогичной сложности. Смотреть надо на

  • Готовность и время. Те, кто не сделал – провалили. Те, кто не настроил компьютер, компилятор итп к интервью – провалили. Те, кто не сделал вовремя – провалили. Бонус за 45 мин. Бонус за 30 мин.
  • Соответствие заданию. Написавший «не тот» код не нужен. Не осилил прочитать, понять, задать вопросы итп – не нужен.
  • Баги. 2 больших бага – это значит, провалил. Один большой баг можно просить починить (по-быстрому), и провалил, если не осилил починить. Провалил, если починил так, что сломал что-то ещё.
  • Комментарии, тесты.
  • Эффективность.
  • Использование стандартных либ.
  • Остальное.

Стандартные либы не надо запрещать. Кандидат может быстро написать со стандартными, либо медленно без. Реже – быстро без. Медленно и со стандартными либами – это некошерное решение; надо глядеть больше на результаты разговора.

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

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

Бывает (редко) – повезло, не отсеяли лишнего. Чаще мало лишнего отсеивается. Хуже нанять лишнего. Уволить морально тяжело. Лечить последствия. Переписывать код. Менять планы. Или смириться. Лучше сразу не нанять. Лучше не донанять. Лишний кадр – это ещё и овертайм. Не только себе, но как минимум ещё и лиду. Нафиг лишний кадр.

После интервью с кошерным кандидатом по телефону 5-10 минут общается, скажем, продюсер, или какой-нибудь иной менеджмент – спрашивает за «как привык работать», «как будешь работать субботы перед релизом», «как работаешь с расписанием», «как предсказываешь сроки» – и прочие сложные вопросы. Если не возникает идиосинкразия – кадра привозят пообщаться в контору. Бывает, что и возникает. Если продюсер говорит нефиг – оно реально нефиг. Ибо.

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

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

Интервью «в конторе» занимает от 3 часов, до почти полного дня. Подходить надо ответственно. Быть готовым. Планировать. Сразу иметь настроенный комп. Заранее иметь помещение с «доской, мелом и тряпкой». Чтобы все были и знали заранее. Иначе будет грустно. И пусть никто не уйдёт обиженный.

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

Интервьюировать надо сложившимися группами, по 2-3 человека. Групп нужно 2-3 разных. Состав групп не менять без причин. Пусть каждая группа тренируется. Если групп много – делать ротацию групп. Ротацию членов групп не делать.

У каждой группы сложатся свои вопросы, неплохо заранее обсудить, «кто что спрашивает». Разные группы не спрашивают одинаковое – не надо.

Целей у такого развлечения строго две: выяснить, не помог ли на телефонном интервью и домашнем задании друг, гугль, и т.п.; выяснить, на каком уровне выступает деятель, в сравнении с остальными членами группы.

Вопросы у групп могут быть самые разные – как за компьютером, так и у доски. Типичные это «калькулятор», «рейтрейсер», «целочисленное деление». Фактически любые могут быть типичные. Смотреть надо, как кадр решает задачи. Какие спрашивает вопросы. Как понимает на слух и при чтении. Полезно чуть отвлекаться, если кадру есть чего рассказать о предмете – бывает, что есть сильно больше рассказать, чем собственно группе.

Иногда при групповом общении наступает идиосинкразия. Интервью при таком раскладе осмысленно быстро свернуть, персонажа попрощать вежливо с HR.

В середине группового общения устраивается самый важный тест – совместный обед. Себя надо строго спрашивать – будем ещё жрать совместно с этим кренделем, или ну его нафиг. Если нафиг – то после обеда вежливо попрощать с HR. Жрать надо вкусно – платит контора.

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

Решение для каждого участнега каждой группы выглядит «Да, нанимать» и «Нет, не нанимать». Общее решение – на какую/какие из имеющихся должностей. Продюсер участвует. За деньги продюсер решает сам, с техдиректором, без остальных. Впрочем, есть и конторы с открытой инфой о зарплатах. Мне лично всё равно.

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

Если есть сомнения, расхождение мнений, метания и терзания – лучше не нанимать. Предлагать в другие команды тоже не надо. Надо вежливо прощать с HR и жить до следующего интервью. Обсуждать на форумах с кадром на предмет «почему не наняли» не надо. Указывать причины «почему не наняли» не надо. Ругаться тоже ни с кем нельзя; кто кого будет интервьюировать через год в этой маленькой индустрии – большой вопрос.

Пострадавшая при «не наняли» – контора. Хотели нанять, но не наняли. Нужны – а не срослось. Не вышло. Кадровый кризис. А кадр работу найдёт – на любой товар есть покупатель, вопрос только в цене.

Updated: поправил некоторые неполиткорректные ашипки.

  • Hy-u-Hy

    Diam0nd

    >“Указывать причины «почему не наняли» не надо”
    Я понял так, что это относится к программисту, проводящему техническое интервью. И это правильно, “посылать” – не его работа, (как и не его работа – _принимать решение_ о посыле/найме), его работа “протестировать и доложить результат”. Даже если результат “не брать ни в коем случае”, решение (может быть формально) принимает не программист.

    Программисту-интервьюеру лучше до конца интервью сохранять вежливую благожелательность. И ничего определённо не говорить, ни “да”, ни “нет”. Иначе это свидетельствует о бардаке в конторе.

  • Safrin71

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

  • Pingback: Интересные ссылки: C#, бизнес, программирование, смех, ПО… « Блог Серёжи Борзова()

  • Pingback: highly professional scums » Blog Archive » Coffee break()

  • http://www.vogster.com raskolnikov

    я бы на такое собеседование не пошел :)

  • int32

    нуу

    Постера можно понять, ему деньги платить, он обжигался
    на кривых руках и теперь дует на воду… Я разных команд
    насмотрелся, и разгильдяйских и военных, и успех их по
    моим наблюдениям не особо коррелирует с начальным уровнем
    набираемых. Единственное, с чем я соглашусь, это с бинарным делением
    умеет-не умеет кодить. Это видимо в мозжечке, или есть
    или нет. В остальном – мне кажется что его компания это
    военно-командная структура, могущая конкурировать за счет
    работы вширь, а не вглубь. По моим личным наблюдениям
    людям, которые любят самоорганизовываться в такие структуры,
    очень трудно придумывать что-то новое, и трудно адекватно
    оценивать людей “на глаз”. Первое приводит к специализации по конъюктурным,
    неглубоким и скучным (зато стабильно планируемым) проектам. Второе
    к именно такому подбору людей, акценту на “что умеешь” а не
    “как учишься новому”. Мне лично удобнее жить со свободными художниками,
    когда важны не столько знания, сколько способность быстро
    переориентрироваться в неизвестной области. Я сам такой, и
    мне с такими людьми легче; раньше встречая такой тип оценки
    “по одежке” я дергался, сейчас я понял что это просто не мое.
    Так что, все что я щас пишу, это совет всем тем кто почувствовал
    себя неуютно по прочтению этой инструкции по найму (кстати,
    в таких организациях очень любят инструкции, а я их игнорирую) -
    так вот собственно, совет: забейте. Если вас туда не взяли,
    значит вы туда не хотели, и значит оно вам было не надо.
    Ищите место где вы будете свой с первого слова на интервью,
    где на вас не будут смотреть как на винтик, и где вы
    будете не бояться делать ошибки. Поверьте моему опыту, такие
    места есть, они просто себя не афишируют ;)

  • http://www.netbee.ua/ King_Artes

    “raskolnikov:

    я бы на такое собеседование не пошел :)”
    А я бы пошёл, ибо мге всё равно какое собеседование главное что б меня вакансия устраивала

  • Pingback: “Проводить интервью крайне полезно. Тот… « Avdenago.com/LIVE()

  • Pingback: C++: Вопросы на собеседовании - Rikki Mongoose()

  • Алексей Пушкарев

    Как-то всё негативно… “В середине группового общения устраивается самый важный тест – совместный обед. Себя надо строго спрашивать – будем ещё жрать совместно с этим кренделем, или ну его нафиг. Если нафиг – то после обеда вежливо попрощать с HR. Жрать надо вкусно – платит контора.” Как это “Жрать вкусно” ? Как говорится на вкус и цвет…. Что для кого является “вкусно” довольно субъективно. По тому кто что ест я думаю не повод судить о человеке. По требованиям похоже вы ищете гуру, senior’ов и т д, т.е. junior’ы не люди и они не имеют шансов вырасти в вашей компании? А зарплаты у вас соответствуют?

  • Pont

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

  • btnc

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

  • truthfinder

    Вот вроде толково написано. Непонятно правда, почему забыты вопросы многопоточности, и маненечько темплейтов хотя бы. Современный геймдев без этого уже немыслим. Человек должен как минимум представление иметь. Но на протяжении статьи не покидал вопрос, а кого собственно хотят найти? Написателя чего? Вспоминая про забытую многопоточность, и учитывая специфику вопросов, мне приходит на ум, это программист кустарной математической библиотеки. Сколько человекочасов в геймдев конторе на это тратят? По мне так обычно её украл/написал и забыл. Про вопросы 2^8 даже говорить не хочется. (Вот прям так всё плохо с кадрами?)

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

  • truthfinder

    Я понимаю, что со времён написани статьт прошла уйма времени. Да вот ситуация изменилась мало. Где сейчас учат архитектуре современного игрового движка? Даже сейчас реально полезных трудов на эту тему катострофически мало. Один из немногих действительно полезных трудов на тему современного Game Engine был написан разработчиком из Naughty Dog. В целом же ситуация за последнее время не улучшилась, а вопрос про 2^8 стал ещё более актуален (увы).