четверг, 26 июня 2014 г.

Как проводить технические собеседования?

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

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

clip_image002

При этом «модели» используются самые разные. В гугле когда-то считали, что человек, который сможет ответить на вопрос: сколько шариков для гольфа влезет в багажник Lexus LS470 является хорошим программистом и сможет успешно решать их задачи. Майкрософт когда-то использовал похожий подход (вспомните «Чтобы сделал мистер Фейнман» Эрика Липперта), а сейчас они садят кандидата за стол и просят его покодить. Очевидно, что эта модель также не совершенна, ведь она не соответствует реальному миру, ведь мы никогда не кодим на работе, когда от этого зависит наша судьба, а наш начальник при этом заглядывает в код через наше левое плечо.

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

ПРИМЕЧАНИЕ
Помимо отечественного аутсорса подобные тип собеседований активно используется и в некоторых компаниях в США. Например, в Нью Йорке большинство собеседований очень напоминают киевские;)

Кого мы хотим найти?

Прежде чем решить, как же нам подобрать правильных людей (и отсеять «неправильных») нужно определиться с тем, кого же мы ищем.

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

Так что планка в наши компании несколько ниже, ключевые критерии совпадают: нам нужно найти человека, который умеет думать, решать задачи и доводить дело до конца (кстати, именно умение довести дело до конца Бертран Мейер считает самой полезной чертой разработчика, о чем он поведал в своем недавнем интервью).

ПРИМЕЧАНИЕ
Я тут здорово все упростил, поскольку процесс отбора существенно сложнее. Как минимум нужно учитывать человеческие качества, ведь даже rock star разработчику стоит отказать, если из-за него развалится вся команда.

Техническое собеседование

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

Отечественный аутсорс при отборе уделяют максимальное внимание конкретным техническим навыкам: знаниям языков программирования, технологий и платформ. Можно сколько угодно спорить, насколько коррелируют знания языка C# с умением решать рабочие задачи и насколько этот подход лучше/хуже альтернативных вариантов. Как по мне, значительно важнее не то, какие вопросы вы задаете и какие знания проверяете, а то, как вы слушаете ответы и каким образом их анализируете.

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

Узнайте, как человек думает

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

Например, вполне нормальным попросить реализовать StringBuilder самостоятельно или спросить о том, как он реализован в .NET. При этом значительно интереснее обсуждать этот вопрос, когда кандидат не знает решения. Тут можно затронуть компромиссы между эффективностью реализации методов Append и ToString, подумать о выборе структуры данных и т.п..

СОВЕТ
Очень полезно обсуждать задачи, суть которых хорошо известна кандидату, но которые он не решал на практике. Это немного выведет кандидата из зоны комфорта и будет показывать не его способность запоминать факты, а его способность думать и принимать решения.

Никаких вопросов из "тестов"

Из первого совета вытекает второй совет о том, чего делать никогда не нужно. Не нужно задавать вопросы, ответы на которые легко гуглятся, и главное, нельзя трактовать ответы по принципу тестов: "ответил/не ответил", без продолжения обсуждения.

Меня всегда очень беспокоит, когда на собеседовании задается вопрос следующего вида: "Скажите, а какой тип возвращаемого значения должен быть у перегруженного оператора = в С++? Ссылка или константная ссылка?". Особенно печально, когда ответ на этот вопрос просто записывается на бумажке и интервьюер переходит к следующему подобному вопросу.

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

Сосредоточьтесь на фундаментальных вещах

Есть некоторые позиции, которые требуют очень глубокой экспертизы в определенной области. Бывает, что команде нужен эксперт по WCF, WPF или ASP.NET, который должен знать технологию очень глубоко и тогда на собеседовании придется гонять кандидата по всем дебрям. Во всех других случаях значительно полезнее сосредоточиться на фундаментальных вопросах, даже если они и привязаны к конкретной технологии.

Обычно под фундаментальными вещами я понимаю ключевые концепции: основы типов в .NET, основы сборки мусора и проблемы управления ресурсами; основы языка C# типа делегатов, событий, замыканий. Фундаментальные вещи из области проектирования, типа cohesion & coupling, проблемы наследования/агрегации, опасностей изменяемости и т.п; паттерны проектирования, отношение к ним и их роль в арсенале разработчика. Основы алгоритмов, можно в привязке к платформе ("Что будет если метод GetHashCode будет всегда возвращать 42?") и т.п.

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

Определите свой уровень по шкале от 1 до 10

Я уже несколько лет пользуюсь подходом, подсмотренным когда-то у Эрика Липперта и в качестве первого вопроса собеседования задаю следующий: "Определите, пожалуйста свой уровень знания языка C# по шкале от 1 до 10, где 1 – это уровень моей мамы, преподавателя математики, а 10 – уровень автора языка C# – Андерса Хейлсберга.".

Это довольно распространенный вопрос, но для меня он не самодостаточен (хотя бывает любопытно услышать от синьера, что его уровень ниже 6 или выше 8). После этого вопроса я всегда задаю второй: "Ок, ваш уровень 8, а какие именно знания перевели вас с уровня 7 на уровень 8?".

Польза такого подхода в том, что можно узнать следующее: (1) чем человек интересуется и интересуется ли чем-то вообще, и (2) можно пропустить ряд простых тем, если кандидат говорит о недавнем изучении каких-то продвинутых вещей. Так, если кандидат говорит, что он узнал о сегментах в GC и Card Table, о реализации обобщений, деревьях выражений, о проблемах изменяемых значимых типах или о генерации IL-кода, то вполне можно пропустить базовые вопросы, типа разницы между ссылочными и значимыми типами и углубиться в более серьезные подробности.

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

ПРИМЕЧАНИЕ
Не так давно на rsdn было обсуждение этого вопроса: "Как вы оцениваете ... по 10ти бальной шкале?", в котором я также принял участие.

Тяните за ниточку

Я очень редко провожу собеседование по бумажке. Обычно происходит следующее: берется несколько ключевых вопросов (таких себе "якорей"), на основе которых строится все обсуждение. Ответ на вопрос n зачастую дает почву для вопроса n+1, который в свою очередь дает почву для следующих вопросов.

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

Аналогично, невинный вопрос, типа "А атомарна ли операция i++, где i – это System.Int32?" может послужить хорошим началом разговора, поскольку наверняка даст почву к другим темам, таким как неизменяемость и многопоточность, проблеме гонок, вопросам об атомик операциях и многим другим.

Именно поэтому мне нравится сверх простая задача следующего вида:

class Foo
{
   
public event EventHandler
MyEvent;
   
private readonly int _syncRoot = 42
;

   
public void
RaiseMyEvent()
    {
       
Monitor.
Enter(_syncRoot);
       
try
        {
           
if (MyEvent != null
)
                MyEvent(
this, new EventArgs
());
        }
       
finally
        {
           
Monitor.Exit(_syncRoot);
        }
    }
}

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

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

Насколько "технологическое" интервью эффективно?

Есть ли связь между знанием языка C# и умением решать производственные задачи? Тут все не так просто. Можно выделить две крайние ситуации.

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

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

В целом, разумный подход на основе технологических интервью показал вполне хорошие результаты. Полноценный синьер не обязан знать про Card Table, но сможет относительно легко ответить о пользе поколений в сборке мусора, и даже не зная о SOLID принципах мы наверняка сможем пообщаться на предмет cohesion и coupling, о роле тестов и паттернах проектирования.

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

Интервью – это двусторонний процесс

Для любого специалиста собеседование является двусторонним процессом: интервьюер оценивает кандидата, а кандидат оценивает компанию посредством оценки интервьюера.

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

Можно подумать, что это лишь мое личное наблюдение, и не каждый интервьюер готов спрашивать C# MVP о языке C# (хотя лично я не вижу в этом ни каких проблем). Но ведь такую же картину видят и многие мои коллеги, которые проходят собеседования на Senior или даже Middle позиции.

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

З.Ы. Если так уж случилось, что вы были на моих собеседованиях (Земля ведь квадратная;), будет интересно услышать ваше мнение о нем.

З.Ы.Ы. Понравился пост? Поделись с друзьями! Вам не сложно, а мне приятно;)

35 комментариев:

  1. Прочитал. Немого показалось сумбурны.
    Наверное от имхо добавил бы, что инт. все таки стресс. и надо и это учитывать, бес сомнения должно быть открытая беседа.
    Наверное спросил бы: - Выразите кодом шутку, гнев, наслаждение...
    Про Рос.. рынок не знаю, но посоветовал бы уважение к соискателям ( 99 процентов даже
    не откликаются на закид резюме, такое ощущение что уходят в спам по фильтру)

    ОтветитьУдалить
    Ответы
    1. Да коммент тоже немного сумбурный:))), но замечания валидны:)

      Удалить
  2. Как-то раз, технически собеседуя человека, я попросил его задать подобные вопросы мне. Ну т.е. как бы поменяться местами :) Это сразу как-то разрядило ситуацию ))) Ну и понятно, что джуниор скорее всего на такую встречную просьбу просто стушуется, а вот парни поскилластее вполне могут что-то и спросить. И опять же - по характеру вопросов с их стороны можно попытаться понять, что их волнует/интересует. Ну и оценить чувство юмора :)

    ОтветитьУдалить
    Ответы
    1. Антон, идея неплохая. Хотя обычно на собеседовании очень мало времени, но если выделить 5 минут, и, возможно, совместить с обсуждением технологической стороны проекта на который идет кандидат, то может вполне получиться хороший результат.

      Удалить
  3. Где записываться на собеседоние ? :)))

    Можно какие-то примеры вопросов, которые вы задаете на собеседонии ?

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

    ОтветитьУдалить
    Ответы
    1. О, можно сделать рубрику:)) и проводить собеседования за деньги:)

      Несколько примеров я привел в статье. Другие я приводить не могу, поскольку их все еще использует команда при подборе кандидатов:)

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

      Удалить
  4. Ну было бы странно, если бы человек, проводящий тех. собеседование не владел вопросом. Хотя один раз меня действительно собеседовал по тех. вопросам человек с распечатанным опросником ))) ЖЕСТЬ :)

    ОтветитьУдалить
    Ответы
    1. Владение вопросом - это относительная величина:) Поэтому вполне нормальная ситуация, когда кандидат в определенных вопросах знает что-то лучше интервьюера.

      У меня были и обратные ситуации: когда на мой вопрос о взаимодействии управляемого/неуправляемого кода, кандидат отвечал: "А что нам об этом говорить, я все равно лучше вас эту тему знаю":)

      Удалить
  5. В целом согласен. Но, для меня кроме таких составляющих, как умение думать и знание технологии (языка), важно ещё и знание инструментов, с которыми человек работает. Это показывает насколько эффективно он может работать. Если человек ни разу не слышал об SQL Server Profiler или, что стандартная кнопка переименования есть F2 в VS (это конечно если что-то не установлено или изменено) или, что можно поставить условную точку останова и приатачиться к двум процессам сразу, то грош цена тому, что он знает про обобщённую вариантность в C#.

    ОтветитьУдалить
    Ответы
    1. Мысль интересная. Я тоже считаю базовые знания инструментов полезным, хотя никогда не спрашивал об этом на интервью (и у меня никогда не спрашивали об этом).

      Удалить
  6. Хочу поделиться опытом.

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

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

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

    Еще лично мне понравился ряд статей некоего Joel Spolsky на данную тематику, позже переросшую в книжку. Главная мысль в том, что Вам не так уж много нужно узнать о кандидате. На самом деле, самое важное что нужно успеть узнать на собеседовании - это что он: 1) smart; 2) gets things done;

    Итак, чего я хочу узнать на собеседовании (обычно хватает минут 60-90, в зависимости от скорости кандидата):
    1. Соответствие skillset кандидата позиции
    2. Общий технический уровень И знание основ
    3. Мышление кандидата
    4. Как он решает проблемы

    5. Смогу ли я с ним работать, впишется ли он в команду
    6. Чего он хочет, его приоритеты

    Что мне безразлично:
    Любой вопрос, на который есть ответ в индусских сборниках "Как пройти собеседование по C#". В крайнем случае - после правильный ответ засчитывается только после объяснений "почему так".

    ОтветитьУдалить
    Ответы
    1. Итак, я предлагаю:

      Необязательно:
      1. Проведите прескрининг по телефону (до 15 минут). При большом потоке кандидатов это вам ОЧЕНЬ поможет сэкономить время и силы. При маленьком

      тоже, в целом. Расскажет гораздо больше того, что написано в CV. Задайте несколько общих вопросов и несколько самых простых по основам. Ну и,

      возможно, один сложный
      2. Дайте кандидату тестовое задание до интервью. Часто мы этого не делаем, и всем лень (кандидату писать а нам потом читать), но это один из

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

      сразу после интервью

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

      на будущее, карьерные амбиции и т.д. Я понимаю, что подобные вещи должны делать HR. Но лично мне никогда это не помогало. Вам с ним работать и

      эти 10 минут могут сэкономить месяцы возможных последствий
      1.1 Решает вопросы 5-6
      1.2 Дает кандидату 10 минут расслабиться и выйти из "ступора". Даже очень хорошие кандидаты, длительное время не проходившие интервью, могут

      "тупить" пока вы не наладите с ними контакт
      2 (!) Дайте ему задачу из тех, с которыми Вы сами столкнулись (желательно недавно) на работе. Посмотрите как он будет ее решать. Обсуждайте и

      выдавайте проблемы, с которыми столкнулись сами
      2.1 Это позволит быстро и нешаблонно увидеть ответы на 1-4
      2.2 Обычно хватает 2-3 таких задач для покрытия большинства областей знаний, о которых вы хотели узнать (1)
      2.3 Обсуждение позволяет выявить не только (возможно "заученные") знания, но и то, насколько кандидат может ими оперировать и насколько они

      востребованы в его работе
      2.4 Для того чтобы увидеть мышление кандидата и то, как он отвечает на те вопросы, на которые не знает ответов, постарайтесь выбрать

      действительно интересные задачи. Я искренне надеюсь, что такие встречаются в вашей работе
      3. Если вы сомневаетесь подходит ли кандидат или нет - значит он не подходит
      3.1 Есть мнение, что решение о приеме кандидата вы принимаете в первые 5 минут интервью. Остальное время тратиться на то, чтобы убедить себя в

      правильности этого решения. Ну да это лирика :)


      Недостатки:

      Использование предложенного подхода лучше подходит для отбора кандидатов в свой проект. Довольно трудно по результату дать более объективный

      критерий оценки уровня кандидата, чем "да" или "нет"

      Фуххх.... хотел написать комментарий, а вышло так многа букаф, что в один пост не влезло %)

      Удалить
    2. Костя, огромное спасибо! Отличные дополнения, которые, по сути, тянут на самостоятельную статью:))

      Удалить
  7. После собеседования кандидата выбирать так: http://youtu.be/ZWib5olGbQ0
    (пропускаем первые 37%, после этого выбираем первого, который лучше всех предыдущих).

    ОтветитьУдалить
  8. Кстати, вот тут кто-то заметил, а я расширю - умение применять и знания инструментария tracing'а и debugging'а. Позволит в реальных проектах сэкономить кучу времени.

    ОтветитьУдалить
    Ответы
    1. Тут интересно, что даже технические сильные кандидаты могут провалиться на этом вопросе.
      Удивительно, но разработчики в среднем знают свои инструменты очень посредственным образом (хотя может быть это у меня выборка не репрезентативная).

      Удалить
  9. "умение применять и знания инструментария tracing'а и debugging'а. Позволит в реальных проектах сэкономить кучу времени" - абсолютно согласен с вами. Именно и это, в том числе я подразумевал, просто лень было писать длинный коммент :) Лично я считаю это одним из самых эффективных способов фильтрации теоретиков-гуру. Ведь подобные знания бывают у тех людей, у которых за плечами реальный боевой опыт.

    ОтветитьУдалить
    Ответы
    1. "умение применять и знания инструментария tracing'а и debugging'а. Позволит в реальных проектах сэкономить кучу времени"
      Мне интересно каким образом вы будете проверять наличие этих знаний?:)
      Мне кажется (возможно из-за небольшого количества реального боевого опыта), что наличие таких знаний должно определяться реалиями проекта. Если проект сплошной багфикс и допиливание очередного легаси монстра, то да, эти навыки будут даже более важны чем "теоретика". Но если проект скорее жив чем мертв, то это не должно быть основным критериям при оценке кандидата.

      Удалить
    2. Да очень просто. От самого простого вопроса, типа: слышали ли вы про пространство System.Diagnostics и всё что с этим связано? Или: допустим вы пишите кастомный сериалайзер в XML (а он естественно использует очень глубокую рекурсию), как можно используя Visual Studio просмотреть процесс построения дерева XML не записывая вывод в файл. Или слыхали ли вы про такой термин как инструментирование или выборка. А знаети ли вы, что такое SOS для отладчика? Да, на самом деле примеров много.

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

      "Если проект сплошной багфикс и допиливание очередного легаси монстра, то да, эти навыки будут даже более важны чем "теоретика"." – по моему мнению, большинство проектов являются таковыми. И шанс, что вам попадётся очень хорошо написанный проект и с хорошей командой – весьма мал.

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

    Подскажите, в каких источниках можно ознакомиться с проблемами вызова события из под блокировки?

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

      Удалить
  11. В свое время работы в аутсорсинговой фирме я проводил собеседования так http://habrahabr.ru/post/199136/ . Большой статистики не накопилось, но по результатам общения было развернуто несколько 'сеньоров' и взята студентка с которой в последствии было очень приятно работать. Почемуто часто слышу что негоже вопрошать старших разработчиков о том как писать или читать код, но мой личный опыт говорит что многи навешивают себе звание исключительно за выслугу лет....дескать с тех пор как открылпервоеиздание Троелсена прошло больше 5 лет, значит уже старший.....

    ОтветитьУдалить
    Ответы
    1. Павел, спасибо за отличное дополнение.
      Ревью кода - очень годный подход для оценки кандидатов!

      Удалить
  12. Сергей, а насколько ты оцениваешь свои знания от 0 до 10? очень интересно

    ОтветитьУдалить
  13. Да, о C#. 9? хм, я почему-то думал, что у тебя 8. Ведь есть такие люди как Эрик Липперт скажем, мне кажется он где-то 9, и то не 10, потому что он ведь не Андерс Хейлсберг, хотя я могу не корректно оценивать их уровень. У меня такие мысли по поводу этого вопроса, что чем выше уровни, тем сложнее переход от уровня к уровню и соответственно тем больше времени потребуется для перехода, и наверно для перехода на 10 нужно не меньше 20-30 лет, если вообще получится его достичь. Или не все так грустно?)

    У меня почему-то такие мысли сложились, что уровень 0 - человек вообще не знающий ничего. 1,2,3 - junior 4 - middle, 5,6,7 - senior, 8,9,10 - expert. Конечно я могу не правильно представлять себе всю цепочку просто потому что могу не правильно представлять весь путь (особенно верхние и близкие к ним уровни).

    Что думаешь по этому поводу?

    ОтветитьУдалить
    Ответы
    1. Уровень Эрика Липперта я бы оценил в 10.5-11. Все верно, он скорее всего знает C# лучше Андерса, просто потому что он знает его лучше изнутри.

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

      И ты прав в том, что переход на каждый новый уровень сложнее предыдущего. При этом сложность перехода обусловлена не только временными трудозатратами, но и уровнем человека, и его задачами. Это значит, что все еще грустнее, и многим из нас (мне, в частности), не попасть даже на уровень 9. С другой стороны: а плохо ли это?

      Эрик, Андерс и тот же nikov - это люди с уникальными способностями, которые нашли свое место. Они любят и умеют разрабатывать языки программирования. 9+ уровень нужен именно для этого. В простой работе - мало вероятно.

      Так что я бы по этому поводу особенно не заморачивался. У каждого из нас есть свои положительные и отрицательные стороны. И если мы не перейдем на 9-й уровень владения языком C#, это не значит, что мы не можем стать хорошими, по настоящему хорошими разрабтчиками.

      Удалить
  14. Собственно твой уровень я тоже могу не правильно оценивать, во-первых мы в принципе не знакомы, во-вторых у меня довольно смутные представления о верхних уровнях. Поэтому хотел бы узнать правильно ли я представляю себе картину?

    ОтветитьУдалить
    Ответы
    1. Ответил на коммент выше: картину ты представляешь себе правильно:)

      Удалить
    2. Прочитал, огромное спасибо за комментарий =) На самом деле я тоже осознаю, что возможно я за всю жизнь какого-то уровня не достигну, но это не важно, если я сделаю все возможное, что мог, то достигну вполне хорошего и высокого уровня, ведь даже люди с уровнем 6-7 это уже очень хорошие и квалифицированные специалисты, которых не так уж много. Еще раз огромное спасибо за ответы, мне было важно понять правильно ли я представляю картину )

      Удалить
  15. p.s. я пока что свой уровень оцениваю как 4.9 и нацелен в ближайший месяц-2 перейти на 5.0, для этого нужно дочитать Рихтера =) Осталось добить сериализацию и на десерт многопоточность)

    ОтветитьУдалить
    Ответы
    1. Это верно. Главное - двигаться. А там не успеешь оглянуться, как поймешь, что ты уже очень даже неплох:)

      Удалить
  16. Сергей, как считаешь, есть ли разница при выборе кандидата на вакансию в офис и на удаленку? Как мне кажется, для удаленки больше приоритетно знание предметной области, а вот для работы в офисе наоборот, личностные качества

    ОтветитьУдалить
    Ответы
    1. Иван, это хороший вопрос.

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

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

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

      Удалить