Пʼятниця, 17 вересня 2010 р.

про собеседования 2

или мой метод

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

составлено в форме письма другу (собственно является частью комментария к посту)
  1. всегда помни, что для соискателя собеседование стресс (даже если это не так, все равно помни об этом). поэтому улыбаемся, шутим, начинаем собеседование не с технических вопросов, а с разговоров о последнем проекте, целях и желаниях кандидата. даем человеку поговорить о себе и своих достижениях. пусть расслабится. если HR уже говорил на эту тему, а ты не присутствовал, все-равно даем кандидату поговорить. но лучше, чтобы ты присутсвовал с самого начала. или ты спрашивал про это, а не HR. пусть соискатель расслабится, забудет, что это СТРАШНОЕ И УЖАСНОЕ СОБЕСЕДОВАНИЕ, ОТ КОТОРОГО ЗАВИСИТ ЕГО КАРЬЕРА И ЖИЗНЬ (С)
  2. к техническим вопросам переходим плавно, например фразой "а теперь давайте поговорим о Java, Вы же понимаете, от меня требуют отчета". попробуй убедить кандидата в том, что тебе не особенно интересно здесь устраивать экзамен, просто тебя начальство назначило (даже если это не так). вовлеки его в игру, пусть делает тебе одолжение. пусть с самого начала почувствует себя ПОЛЕЗНЫМ ТЕБЕ, ВАЖНЫМ ДЛЯ ТЕБЯ
  3. заведи себе чеклисты. Basic и Advanced. начинай с простого, если кандидат бодро отвечает на простые впросы, сразу переходи к расширенному листу. так быстрее, проще и спокойнее тебе. так лучше для кандидата - он видит стандартную процедуру. не импровизацию направленную на завалить его
  4. заведи себе Impossible or Just Known чеклист. вопросы, ответы на которые нужно просто ЗНАТЬ. очень сильно помогает в работе со "звездами". если кандидат зарывается, можно начать именно с этих вопросов. пусть его попустит
  5. помимо всего прочего, в процессе разговора прислушивайся к человеку, пытайся его понять. помни, перед тобой ВСЕГДА прежде всего ЧЕЛОВЕК и уже потом специалист, программист, сотрудник, соискатель. поступай с другими так, как хочешь, чтобы поступали с тобой. и потом, поняв что за человек к тебе пришел, ты сможешь определить, сработаетесь вы или нет
  6. всегда пытайся понять, чем данный человек может быть ПОЛЕЗЕН команде, не важно чего он не знает, важно, чем он будет ПОЛЕЗЕН
  7. никогда, слышишь, НИКОГДА не унижай человека, не устраивай ему стресс-интервью, не обсужай его с коллегами непосредственно на собеседовании. не верь книжкам и статьям, где пишут, что это поможет понять, как человек работает в стрессовой ситуации - это ложь. все эти практики всего-лишь попытка самоутвердится за чужой счет. сходи в спортзал, попинай грушу
  8. попроси прислать кусочки кода, которые соискатель считает достойными публикации. если таковых нет, пусть напишет и пришлет. код не обязательно должен быть связным или рабочим. вообще это хорошее правило для начала разговора. пусть HRы просят приложить образцы к резюме. "программирование на бумажке" - зло и ересь, программирование на выделеном компьютере - бессмысленная трата времени и ресурсов. СОБЕСЕДОВАНИЕ НЕ ДОЛЖНО занимать больше ЧАСА-ДВУХ времени кандидата. да-да, именно ВРЕМЕНИ КАНДИДАТА, количество твоего времени исключительно проблемы менеджера, проекта и твои

11 коментарі:

  1. моё имхо - при собеседовании на должности сениора\эксперта "программирование на бумажке" is a must.

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

    ВідповістиВидалити
  2. @COTOHA, Сереж, хочешь по честному? но только без обид, да? ты наверняка представляешь должности, на которые я собеседуюсь? так вот, у меня появилось правило - на вопрос о написании кода, отвечать "я пришлю". если потенциальный работодатель настаивает - наверное здесь собседование закончится. я не буду хамить, не буду скандалить, я просто вежливо попрощаюсь и уйду.
    исключением из правила "программирование на бумажке - ересь" может быть только какие-то кусочки кода, которые иллюстрируют вопрос. например
    - вот такая конструкция, каков будет порядок вызовов
    - вот такая функция, как она будет работать
    - вот такой фрагмет, чем мы его дополним
    все. никакого кода на бумаге, никакого кода на компьютерах компании. на ноуте кандидата? теоретически возможно, но будь УВЕРЕН - он НИЧЕГО не напишет. во всяком случае ничего внятного.

    пресловутое правило "сделай это за 20 минут" заставляет тебя думать не о "сделай", не о "это", а только о "20 минут".
    можно попросить кандидата оценить время на задачу и посмотреть, как он вложится в рамки. а если это будет 1 из 10 случаев, когда он промахнется?
    можно дать кандидату бесконечное количество времени, но это будет означать, что тебе тупо нечего делать
    короче, мое мнение остается прежним - программирование на бумажке показывает только то, как человек умеет программировать на бумажке. и больше ничего. как и математические задачки ala Microsoft.

    ВідповістиВидалити
  3. Мне кажется что очень важно доводить человека до правильного ответа в разумных приделах. То есть если он не может ответить на вопрос, то надо задать наводящий, проверить как он думает. Или задать вопрос который не имеет решения и попросить предложить варианты кандидату. Так можно понять будет ли человек бороться с сложными taska-ами или просто забьёт и испугается. Всегда надо доводить то что начал до конца. А насчёт кода, то мне тоже кажется что написать кусочек это важно (is must), но это дело каждого уйти с собеседования если ему что-то не понравилось...

    ВідповістиВидалити
  4. вы так рассуждаете, как-будто тест на бумажке однозначно отвечает брать\не брать. на собеседовании же много чего ещё.

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

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

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

    что там будет накорябано дело десятое, важно как.

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

    ВідповістиВидалити
  5. Прежде всего, спасибо за пост!
    По поводу п. 2. С одной стороны это очень разумный ход. Но есть подозрения, что это будет работать на 100% только с новичками. Мид и синьер наверняка знают эту кухню, и фраза 'Да, собственно, мне пофиг, но т.к. начальство требует...' ну, мягко говоря, настораживает :)
    По поводу п. 3. Как не прискорбно, но примерно в 50% случаев это забывают/не успевают сделать.
    По поводу п.7. Как по мне, я согласен со всем, кроме 'не устраивай стресс тестирование'. Почему? Потому, что вопросы из Impossible листа можно воспринимать как частный случай стресс тестирования.
    Попутный вопрос: а что, были прецеденты 'обсуждения кандидата с коллегами прямо на собеседовании'?
    По поводу п.8. (программирования на бумажке) – честно говоря это явление вызывает устойчивый рвотный рефлекс, который выработался в универе тупоголовыми 'преподами' по программированию и невозможностью на практических занятиях предложить что нить лучше чем доска с мелом. Хотя в случаях пояснения алгоритмов это лучший вариант (псевдокод, диаграммы и т.д.).
    А вообще понравилась идея с 'присыланием кода вместе с резюме'. Скорее всего ее можно расширить до дальнейшего объяснения/обсуждения.

    ВідповістиВидалити
  6. @All, друзья, давайте разберемся с понятиями. под "программированием на бумажке" я подразумеваю НЕ иллюстарцию знаний примерами, НЕ диграммы классов, наследования и прочее, НЕ отрывки кода (ну например с последоватльностью вызовов). нет, нет, нет и нет. я подразумеваю прозьбу к кандидату создать кусок кода (высшая степень маразма - работающий), используя ТОЛЬКО ручку и бумагу. реализовать законченный функционал, решить задачу... программировать.
    и самое главное, если СОИСКАТЕЛЬ ХОЧЕТ написать код - НИКОГДА ЕМУ НЕ МЕШАЙТЕ. но ткаже НИКОГДА не делайте это ОБЯЗАТЕЛЬНЫМ пунктом интервью. почему - я объяснил
    @Макс, комметировать буду тоже по пунктам
    п. 2. ну совершенно не обязательно произносить фразу буквально. просто соискатель должен понимать, что валить его сегодня не будут
    п. 3. я напечатал себе два листочка в 2 колонки после третьего собеседования в Тим. они достались по наследству нашему общему другу. это не долго
    п. 7. если человек ведет себя снисходительно, хорошее к нему отношение ничего не даст. нужно даеть ему понять, что он не звезда. но это не стресс-интевью. настоящее стресс-интевью - это крики, унижения, оскорбления и т.п.
    а что до обсуждений, так это было мое первое в жизни собеседование. контора CS Ltd. так что имею опыт, когда пять бородадых дядек не стесняются обсуждать студента в его присутсвии. очень не приятно, я скажу

    ВідповістиВидалити
  7. Антон, "математические задачки ala Microsoft" нужны... при приеме на работу в IT-компанию, занимающуюся ДЕЙСТВИТЕЛЬНО инновационными разработками. Разумеется, MS и Google попадают в эту категорию, но подавляющее большинство аутсорсинговых компаний - не попадают по самой сути этого бизнеса.

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

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

    ВідповістиВидалити
  8. @Dmytro Lapshyn, я тибе сичас адын вещ скажу, ти толко нэ абижайся (с)
    вот все-равно аутсорс-не аутсорс. задачи типо МС/Гугл показывают, как человек умеет решать эти задачи. хотя нет, Гугловые иногда думать заставляют и это показывают. МСовские... я понимаю, что если ты заканчивал 27 матлицей тебе все-равно. но я не заканчивал. и масса других хороших и очень грамотных разработчиков тоже его не заканчивали - не все ЗНАЮТ КАК нужно решать такие задачи. вот я например не умею их решать. т.е. логически я дошел до того, что в задаче про 100 этажей и 2 шарика вопрос только в том, каково минимальное число шагов. то, что их 13 я узнал у Гугла. внимание вопрос, это что означает? и нужно ли хранить в голове формулы, когда их можно за 10 минут посмотреть? я думаю - нет.
    а про программирование на листочке я уже писал. все, что требуется для того, чтобы проходить такие задачи - запредельное количество написанного кода, чтобы не ошибаться в синтаксисе и наплевательское отношение к результату. иначе либо скобочку забудешь, либо будешь думать про время, про оптимизацию до кода, про что угодно, только не про решение задачи.

    ВідповістиВидалити
  9. Угу, сразу как то вспомнилась шутка "опыт вождения болидов формулы 1 приветствуется" (Если бы водителей принимали на работу так же, как и программистов...)

    ВідповістиВидалити
  10. О да, как же я ненавижу писать код на бумажке... Хотя увидеть код человека до приёма на работу это очень полезно. Да, хорошая практика попросить прислать, но вдобавок мы практикуем удалённую сессию. Даём человеку очень простую задачу, где почти не нужно думать. Делаем это с целью - посмотреть на владение IDE, общий стиль (скорее непередаваемое ощущение, профи сразу видно), скорость набора (если она заметная - это просто небольшой плюс) и всё это в "домашних условиях". Неплохо работает и кандидатам интересно.

    ВідповістиВидалити
  11. @Restuta, а цель какова? Узнать, насколько хорошо человек знает IDE? А если он в emacs с custom-настройками привык программировать? И скорость набора тоже мне не совсем понятно зачем мерять? Человек может кодировать 100500 знаков в секунду, от этого меньше брака не будет получаться, скорее наоборот. Как показывает практика существенные деньги платят за месяц исследований и правку одной строчки. Очень существенные за полгода исследований и отчет о том, что именно нужно поправить в архитектуре, коде, команде, управлении.
    А общий стиль - попросите прислать код. А потом попросите объяснить что этот код делает - в подробностях. Последнее для того, если есть сомнения, что это именно код кандидата. Это существенно сократит время. ИМХО.
    Но в любом случае, Ваше интервью - Ваши правила.

    ВідповістиВидалити