« Вирт и C/C++
Render state rant »

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

24th October 2007, 02:51 am by look4awhile

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

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: поправил некоторые неполиткорректные ашипки.

Category: casual, life  |  Comment (RSS)  |  Trackback

57 Comments

  1. CEMEH:

    +100

    24 October 2007, 5:28 am

  2. DigiMind:

    Эпохальный труд :)

    24 October 2007, 7:34 am

  3. Dmitry Tyurev:

    Судя по тексту, к вам стоит бесконечная очередь мега-программистов. Нам бы такой кадровый кризис… :)

    24 October 2007, 8:04 am

  4. semka:

    Толково.

    24 October 2007, 8:52 am

  5. neteraser:

    Красивая азбука про большие компании. Пусть кто-то напишет азбуку про маленькие - и будет совсем хорошо. Про маленькие в России намного больше применимо, чем про большие. :)

    24 October 2007, 8:57 am

  6. IronPeter:

    Я бы испугался и убежал от тебя, Боря :)

    24 October 2007, 9:10 am

  7. look4awhile:

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

    я обычно спрашиваю чела, перед тем как дать ему ответ - что он думает, возьмём или нет.
    почти всегда народ может сказать.

    24 October 2007, 9:12 am

  8. dDIMA:

    2 neteraser:
    Почему собеседование в маленькую компанию будет сильно отличаться от этого?

    2 look4awhile:
    Супер. Отличная статья.
    *Пошел думать про «быстрый» float->int если знаем range*

    24 October 2007, 11:21 am

  9. Sergei_am:

    Хороший пост, полезнъй, ++.
    Стоит каждому тут прогнатся через примеръ, посмотреть на себя. Подозреваю, многие ‘нарастили брюшко’… :)

    Вот, про ненравится… разве успевали до такой степени создать хомогенную кантору, чтобъ все всей толпой дружно оценивали кандидата / обедали с ним с интересом / говорили про WoW/MTG/Futurama/South park ?
    Если там 5+ человек, то ето означает что из ‘хороших’ берем ‘себеподобнъх’, что в плане кадрового кризиса немного смущает…
    Я ли недопонял, или мне лиш кажется ето не столь важнъм, а в действительности…?

    24 October 2007, 11:40 am

  10. klk:

    Хм, я бы наверное не прошёл такое собеседование. Хотя даже в таком случае это полезный опыт. На последнем собеседовании мне было действительно интересно и если бы меня не взяли на работу, я бы всё равно не жалел о потраченом времени. Кстати, на WTF сегодня тоже про собеседование: http://ru.worsethanfailure.com/Articles/CHutbchutb-poobschitelbnee.aspx

    24 October 2007, 11:49 am

  11. alll:

    А джуниоров вы вообще нанимаете? :)

    24 October 2007, 2:00 pm

  12. ReJ:

    Охо! - страшно полезно и во многих плоскостях.
    * /ме пошёл работать над личными дырами

    24 October 2007, 3:41 pm

  13. CTpaHHoe:

    Здесь не хватает про финансовую часть. Допустим - “нужен”, а руководство готово выделить “столько”… И что делать? Будут приходить кодеры на “столько” и ниже, в основно ниже :’(
    PS: а можно утащить вопросы в свой вопросник? :)

    24 October 2007, 4:50 pm

  14. anatolix:

    Отличный пост, спасибо. Понял, что меня возможно возьмут в Gamedev, если вспомню про линейное счастье, то даже со всеми бонусными задачами :)

    А если серьезно: технические вопросы просто зачет - на самом деле возможно излишне полные. Например полностью без секции “Ассемблер” я человека возьму(математика мне тоже нужна другая, но если на 3D набирать людей, то наверное она правильная)

    Практика “попрощаться с HR” у нас сейчас не практикуется - возможно от этого и страдаем.
    Практика - в офис вообще приглашать 1 из 10, но им уделять много времени на самом деле наверное рулит. Можно конечно попробовать ее воплотить в жизнь.
    Говорить почему не взяли imho надо - т.к. мучать человека несколько часов и не дать ему фидбека для развития - неправильно.

    24 October 2007, 6:19 pm

  15. lordmaze:

    > Кадр, который завалил – пусть приходит через год.

    skoree cherez god on gde-to eschio rabotat budet :)

    24 October 2007, 8:04 pm

  16. lordmaze:

    Eschio podumal - realno rabotaet mozhet dlya 2-3 kompaniy v industrii. Teh kuda ludi hotyat “luboy tsenoy”. Potomu chto realno proshedshiy takoe interview - on nifiga ne programmer skoree vsego. i uzhe davno work kak lead/manager gde to…

    24 October 2007, 8:08 pm

  17. virtul:

    спасибо, очень хороший пост.
    /me собеседование бы однозначно не прошел :) *ушол работать…

    24 October 2007, 8:26 pm

  18. look4awhile:

    2 Sergei_am: крайне важно чтобы человек «прижился»; иначе будет много лишних и ненужных конфликтов – такое ужасно непродуктивно, выйдет нехорошо.

    2 alll: джуниоров тоже набираем. Им можно не ответить на те вопросы в секциях, которые ближе к концу. Например в битах это представление float-а, в математике кватернионы, итд итп. Азбуку в виде линейной алгебры, понятия о производительности структур данных итп им надо знать – такому должны учить в школе и институте.

    2 CTpaHHoe: руководство сильно больше пострадает, если потом кто-то уволится – а нанять уже будет некого. Осмысленно нанимать всех внятных программистов – по переизбытку можно расширять бизнесс.

    2 anatolix: для геймдева они вообщем-то «насыщенные» - чтобы было что провалить и всё равно произвести хорошее впечатление. Совсем без секции «ассемблер» в геймдев брать страшно – проблемы с производительностью и памятью замучают.
    Говорить «почему не взяли» - по телефону – не надо. Потому что это «не взяли потому, что не знал азбуку» либо «потому что не умеешь писать простой код без багов».
    Говорить «почему не взяли» - в оффисе – не надо. Потому что причины обычно «не понравился», «не умеешь слушать и понимать». Редко возникает ситуация «недостаточно знаний по предметной области» - но такое обычно кандидату более или менее понятно самому.
    Хорошо наоборот спрашивать «как вам понравилось наше интервью». Я ещё спрашиваю «как думаете, мы вас возьмём» - на этот вопрос >90% отвечают правильно.

    24 October 2007, 8:56 pm

  19. Aras Pranckevicius:

    (I’ll write in Engrish because my Russian is even worse…)

    Very good article. Coming from a small company, the first stages of sorting out the candidates might be much smaller (because the incoming stream of them is much smaller than that for naughty dog I imagine).

    Still, not sure what to do with the last stages of the interview (the one that happens on-site). The first stages are too low-level to answer such kinds of very important things:
    * Is there a “get the big picture” trait? Without this, a person is basically useless.
    * How well he/she copes with unknown situations? New game, new engine, new team, new codebase, new hardware, new toolset, new bug and so on.
    * How he/she solves the problems? E.g. how comes up and checks various hypotheses in a face of a new really weird bug. How looks for information when something really new has to be done. And so on.

    The above require spending some real actual time with the candicate. Which is costly, but oh well.

    At this moment I think the best on-site interview would be to sit together with him/her and do some real actual work. E.g. take the candidate and some existing guy(s) and make a game from scratch in 8 hours. With your toolset he has never used before. Split up tasks or do pair programming, or whatever of that sort.

    24 October 2007, 9:06 pm

  20. look4awhile:

    The following article is written based mainly on my experience while working in Midway San Diego. I can’t give any comments on Naughty Dog interview process.

    24 October 2007, 9:10 pm

  21. Aras Pranckevicius:

    Naughty Dog or Midway, does not matter much. real big game companies are much larger than some 10 people code shops, and that would be the main source of difference. Not that there is much difference (if there is any, it would be just in size of the interview, not the approach).

    24 October 2007, 9:14 pm

  22. anatolix:

    > Совсем без секции «ассемблер» в геймдев брать страшно – проблемы с производительностью и памятью замучают

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

    Про низкоуровневые штуки: Мне наоборот хочется, чтобы код был наиболее переносим - начать с того, что у нас Windows, Linux, FreeBSD, Solaris, 32 бита и 64 бита, а вообще фиг знает на каких системах мы будем работать через 5 лет. В серверном мире прогресс идет сильно быстрее.

    Про производительность - у меня наверное другая слегка специфика, на самом деле ассемблером обычно можно выжать проценты производительности, может быть десятки процентов. Это конечно в нашей специфике миллионы долларов - но все равно через год у меня будет тупо вдвое больше машин, а запас по нагрузке все равно иметь надо. Поэтому умение внятно radix-ом обогнать std::sort меня устраивает - остальному научится. (Код который наиболее нагружен кончено у нас оптимизировано по самое нехочу, но что наиболее характерно Андрей Гулин(ты его наверное знаешь) недавно одного из любителей ассемблера ткнул носом в то, что компилятор его пишет быстрее. Если ты в cachegrind или vtune не готов считать cachemiss-ы то лучше в ассемблер не лезть).

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

    24 October 2007, 11:21 pm

  23. look4awhile:

    ты про проблемы “текущей” памятя, я про проблемы latency при доступе к памяти. в gamedev часто делается “вообще никаких new\delete внутри главного цикла. кроме placement new. чуть реже - вообще никаких new\delete никогда, кроме placement new.

    exception часто выключают совсем - давно компиляторы делали совсем плохо, теперь делают условно плохо. вообщем по инерции, от недостатка квалификации, и чтобы не ловить ещё один класс багов. такая религия.

    переносимый код это хорошо. только очень небесплатно. где-то проще после чуть рефакторить. где-то проще заранее. здравый смысл рулит.

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

    25 October 2007, 12:41 am

  24. shodan:

    anatolix,
    > на самом деле ассемблером обычно можно выжать проценты производительности, может быть десятки процентов.

    А в геймдеве, местами, таки сотни.
    На математике, за счет использования SSE.

    25 October 2007, 12:45 am

  25. lordmaze:

    > look4awhile:
    > The following article is written based mainly on my experience while working in Midway San Diego.

    Borya - ya v shocke !
    i chto narod normalno vosprinimal ? V smisle ne junior guys a mid/senior guys ? Te te kto v obschem mozhet bez etih shtuk nayti sebe position…

    25 October 2007, 2:04 am

  26. lordmaze:

    > А в геймдеве, местами, таки сотни.
    > На математике, за счет использования SSE.

    aga a potom lihsniy conversion v float vsio ub’et.

    Nu ili ne conversion - a mega rendering :)

    25 October 2007, 3:11 am

  27. Decay:

    Классная статья!
    Судя по комментам я сейчас нахожусь на уровне крепкого junior’a. :)
    А вообще, все ответы я бы разделил на 3 категории - знаю хорошо, потому что с этим работал/работаю; помню основы, потому что когда-то с этим работал, но сейчас уже начал забывать; по работе с этим не сталкивался, ничего сказать не могу (при необходимости можно составить впечатление за несколько минут через гугл).

    25 October 2007, 9:37 am

  28. Decay:

    Дополение к предыдущему посту: был бы у меня при таком подходе шанс добраться до собеседования в офисе?

    25 October 2007, 11:06 am

  29. shodan:

    > aga a potom lihsniy conversion v float vsio ub’et.

    Тебе убьет, а ты не конвертируй.
    Я на вполне боевой задаче как-то раз выжал около 3-3.5x буст именно из такого ;)

    25 October 2007, 12:37 pm

  30. Блог NunDesign » Blog Archive » Офисное дизайнерское: тщательнéе!:

    [...] замечания о собеседованиях в блоге highly professional scums - “ИНТЕРВЬЮ ГЛАЗАМИ ПОСТРАДАВШЕГО” -речь идёт о найме программеров, но некоторые идеи [...]

    25 October 2007, 1:42 pm

  31. pentagra:

    Сразу оговорюсь, я не из gamedev компании, но C++ программеров нанимаем.
    Мы пол года не могли нанять программера, хотя у нас вопросов на порядок меньше и они проще.
    Человек, подходящий под такие запросы, это безусловно хорошо для команды, но вот реально ли такого найти в разумные сроки …

    26 October 2007, 1:24 pm

  32. kolya:

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

    26 October 2007, 2:48 pm

  33. virtul:

    http://www.dtf.ru/forum/topic.php?id=16076

    26 October 2007, 4:29 pm

  34. joric:

    dDIMA
    > *Пошел думать про «быстрый» float->int если знаем range*
    float2int тут - http://kunaifusu.livejournal.com/221098.html =)

    27 October 2007, 12:36 pm

  35. Vlasov Alexey:

    Вот Борь тебе чтиво, что бы ты понимал насколько далеки “твои” от “наших” пострадавшие:0)

    http://dlight.ru/masterclass/articles/2007/10/24/2838/

    30 October 2007, 5:41 pm

  36. Hy-u-Hy:

    Средний весьма процесс. На четвёрку “с вожжами” :-)

    Из позитивного
    - правильно, что телефонное интревью - “на знания”, ибо не все могут “думать по телефону”
    - правильно, что высылается простое тестовое задание для решения на компе
    - правильно, что “не сделал / не понял задание - провалил”
    - правильно, что интервью on site содержит кроме разговора ещё и решение задачек, и доску с мелом
    - правильно, что надо нанимать “хороших” программистов, а “плохих” - не надо. Как цель, к которой надо стремиться - годится :-)

    Из негативного:
    - я бы не стал спрашивать про минус единицу и 2^8. То, что человек не наврал в резюме, можно вычислить и более деликатным способом. Или смысл вопроса “а не пошлёт ли кандидат нас нах?” :-)
    - я бы убрал почти весь low level. junior должен писать просто, понятно и согласно уставу. senior по оптимизации тестируется глубже и on site, такие вопросы его только обидят.
    - я бы убрал половину математики. Ибо по-хорошему штатники математики не знают (кто знают - в геймдев не идут). А про скалярное-векторное произведение что-то пропоют почти все, хоть выпускники ПТУ от геймдева Full Sail.
    - я бы не стал ограничивать тестовое задание часом. Если это отражает практику на фирме (прибежать с feature request, через час потребовать результат) - лучше такую информацию от кандидата скрыть ;-) Если не отражает - нафиг такое ограничение. Пусть думают сколько влезет, мы же не сидим под дверью.
    - я бы убрал решение задачек on site на компьютере. ибо у интервьюера нет времени, а кандидат волнуется и трясётся, посему отладка должным образом не осуществляется. Причём никакой информации кроме “кандидат трясся на интервью” реально не добывается.
    - следует обязательно спрашивать (не по телефону) про ООД и хоть какое-то понятие о практической отладке. Ибо биты байтами, а ему - код писать.
    - полезно дать почитать код (возможно специально фиговый) и поспрошать комментариев.
    - полезно проводить интервью с художниками-дизайнерами. А то может он с ними (или они с ним) общаться не сможет.

    PS: Сам я последний раз проходил интервью в прошлом тысячелетии. А провожу я интервью регулярно, думаю пару сотен провёл.
    PPS: Что интересно, ни разу за 13+ лет в геймдеве мне не потребовались знание о битах во float’е, как и о деталях реализации КЧ-деревьев. Проекты выходят стабильно и регулярно, платформы самые разные. Вот ведь удивительное дело.

    31 October 2007, 7:25 pm

  37. look4awhile:

    если человек обижается на вопросы на интервью, то не совсем понятно на что ещё он обидится в процессе работы. думаю вполне нормально спрашивать хоть-бы и 2+2. аналогично с senior-ом которого “обидят” вопросы.

    смысл ограничения в 1 час - чтобы человек примерно понимал объём работы. безупречное решение с custom gui не нужно.

    аналогично с on-site задачками. сидеть с ним вместе и решать - милое дело. за одно понятно, как понимает то, что ему говорят. опять-же никто не пугает, не нервирует - обсуждают и решают совместно. если и в такой ситуации “кандидат трясся” - можно ещё раз позвать, другим днём. или экстраполировать. или подумать, а когда он затрясётся ещё.

    отладку обычно спрашиваем on-site. обычно на собственном коде. идея дать почитать плохой код - очень нравится. буду пробовать, когда дойдёт до.

    1 November 2007, 9:49 am

  38. Hy-u-Hy:

    “Обижается” - это фигурально. На самом деле уважающий себя кандидат думает что-то типа:
    - интервьюер не читал резюме => у них брадак
    - интервьюер дурак (”не знает, что такое MIT”) => у них брадак
    - интервьюер упорно не верит резюме => у них принято не верить людям
    - интервьюер всё понял, но не хочет/не может отступить от скрипта => у них произвол/фашизм

    Результат одинаковый - вы (фирма) не продемонстрировали вменяемость. И, возможно, не прошли интервью. С уважающим себя кандидатом.

    Теорема: кандидаты, себя не уважающие, в геймдеве не нужны. Пусть идут туда, где надо копать от забора и обеда.

    >смысл ограничения в 1 час - чтобы человек примерно понимал объём работы.
    >безупречное решение с custom gui не нужно.
    А так и надо сказать - “решение с custom gui не нужно”.

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

    >“кандидат трясся” - можно ещё раз позвать, другим днём. или экстраполировать.
    > или подумать, а когда он затрясётся ещё
    Всё-таки устройство на работу - стрессовое весьма дело. Это как предложение руки и сердца :-) А совместная жизнь потом - она попроще :-)

    1 November 2007, 5:04 pm

  39. look4awhile:

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

    ограничение на время ввели после того как получали отличный результат через 4-6 часов пару раз. смысл того временного ограничения - показать как он будет писать сразу. задача очень простая - т-е час там как раз для неспешного вдумчивого написания. после 4 часов оно уже ничего не показывает.

    если не давать задачки “у доски” или “за компом” - зачем звать? приятно пообщаться? оно тоже полезно, но таки половину мы в итоге отсеивали in-house. усложнять телефонное так, чтобы отсеивать всех - не хватило скила.

    1 November 2007, 9:06 pm

  40. Hy-u-Hy:

    У доски задачки давать-давать, очень показательная вещь. Мне просто не понравилась идея “писать рейтрейсер за компом”. Долго. Лучше правильно поговорить-поспрашивать - больше данных будет.

    Усложнять телефонное не надо, ибо не все умеют “думать по телефону”. И, кстати, не всегда вообще коммуникация по телефону успешно осуществляется - акцент(ы), помехи и просто невозможность видеть собеседника - мешают.

    Мы (не скажу кто) на данный момент от телефонного интервью отказались - такое вот новое веяние. То, которое мы проводили раньше, давало слишком маленький отсев. Усиливать список вопросов никто не захотел. В виде компенсации усилили кодерский тест “на дому”. От “гуманного” перешли к “умеренно-злому”. И вопросы-задачи, и имплементация фичи в учебный проект. Всё практическое.

    >после 4 часов оно уже ничего не показывает.
    Согласен. 4 часа на считало слов - за глаза. Я не согласен, что надо часом ограничивать, непрактично это. И за решение быстрее часа я бы бонуса не давал, никакого. Торопыги-тарабанщики не нужны, нужны солидные практики.

    >на практике был 1 кандидат, который после телефонного не захотел приходить
    Ну, может. Мне раза три в год попадается гуру (10+ лет опыта) - ну не стоит их про минус единицу и 2^8 спрашивать. Видно, что знают :-) А если 10% после такого вопроса попрощается - нам это нафига? Гуру стадами не ходят, они зверь редкий.

    1 November 2007, 9:27 pm

  41. IronPeter:

    Маааленькое замечание - если гуру раз в три года и 10% fail rate - то в среднем гуру фейлится раз в 30 лет :).

    2 November 2007, 8:40 am

  42. DigiMind:

    > Маааленькое замечание - если гуру раз в три года

    Там было три гуру в год. :)

    2 November 2007, 12:18 pm

  43. IronPeter:

    ах, профукал спросонья!

    2 November 2007, 12:48 pm

  44. Hy-u-Hy:

    Интервьюированием гуру (гур, гуров, гурей) занимаются как минимум все senior’ы, а не кто-то один. Оценка, что в команду в год приходит трое гуру - неверна :-) Это было бы слишком грустно.

    3 November 2007, 12:07 am

  45. Software Development Guide:

    Software Development Guide…

    I couldn’t understand some parts of this article, but it sounds interesting…

    8 November 2007, 2:23 pm

  46. То, что я читаю #3 | kraynov.com:

    [...] Gamedeff.com. Интервью глазами пострадавшего. Очень интересная статья по поводу того, как нанимать [...]

    11 November 2007, 6:25 am

  47. evgeniy13:

    Я бы прошел такое собеседование… Но вообще, к столь дотошным интервью отношусь крайне скептически. Мне кажется испытательный срок - вполне нормальное решение для выяснения профессионализма. К тому же, имхо, гораздо важнее обучаемость/вменяемость человека, чем обширные знания. Если его берут не на узкоспециализированную работу, то 90 % вещей из интервью просто не понадобятся на практике.

    11 November 2007, 7:02 am

  48.   Интересно почитать (15.11.2007) by Блог Димка:

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

    15 November 2007, 5:18 pm

  49. Diam0nd:

    “Указывать причины «почему не наняли» не надо”
    Абсолютно не согласен. Интервью feedback это абсолютно стандартная процедура. Вам бы было каково если бы Вам отказали без указания причины? (кроме как “Попробуйте через год конечно”) Или я Вас не так понял? :)

    28 November 2007, 11:10 pm

  50. look4awhile:

    > Абсолютно не согласен. Интервью feedback это абсолютно стандартная процедура.

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

    > Вам бы было каково если бы Вам отказали без указания причины?

    это совершенно не важно.

    аналогично не надо советовать “пробовать через год”.

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

    29 November 2007, 2:38 am

  51. Hy-u-Hy:

    Diam0nd

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

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

    29 November 2007, 8:16 pm

  52. Safrin71:

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

    14 December 2007, 3:59 pm

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

    [...] http://blog.gamedeff.com/?p=64 - полезно кодерам, готовящимся к прохождению собеседования на новую работу [...]

    1 January 2008, 8:29 pm

  54. highly professional scums » Blog Archive » Coffee break:

    [...] Ах как-бы я хотел шутить, но таки нет: вам не нравится интервью имени Баткина? – пишите на С#, конечный результаты и сроки будут [...]

    24 January 2008, 10:12 pm

  55. raskolnikov:

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

    25 January 2008, 12:27 am

  56. int32:

    нуу

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

    29 January 2008, 12:48 am

  57. King_Artes:

    “raskolnikov:

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

    2 July 2008, 4:17 pm

Leave a comment

You must be logged in to post a comment.