У меня дилемма. У меня есть кандидат на должность старшего разработчика программного обеспечения.

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

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

РЕДАКТИРОВАТЬ:

Против лучшего суждения я дал тест. Лучшие оценки почти по всем вопросам, даже по темам, которыми он не хвастался. Но я так поддержал его иронию, когда он увидел вопросы теста - которые явно не для старшего.

Итак, мы сделали предложение.

Спасибо всем за идеи.

Как обычно...

Это зависит

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

Насколько вы уверены в техническом тестировании? Вы взяли это? Как вы думаете, это справедливо?

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

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

Будут ли результаты технического теста влиять на ваше решение о найме? Достаточно ли сильна ваша беседа с ним и рекомендации коллег, которым вы доверяете, чтобы какие-либо результаты технического теста не имели значения?

Если тест не поможет, пропустите его.

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

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

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

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

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

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

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

В-третьих, если у вас есть ноющий голос, говорящий: «Я боюсь, что, несмотря ни на что, он может не пройти тест», тогда слушайте этот голос - не пропустите тест. Это не может быть правильный прокат.

И, наконец, если кандидат хорош, то он не только не будет оскорблен техническим экзаменом, но, скорее всего, это будет хорошим знаком для вашей организации. Это пункт 11 в широко цитируемом тесте Джоэла . В конце концов, им не нравилось работать с разработчиками, которые не прошли бы технический тест и, вероятно, не хотят повторять этот опыт.

По всем этим причинам вы должны дать тест, если (и это важно, если) тест не является очевидной частью BS, которую следует заменить полезным техническим тестом.

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

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

Сделайте техническое, прежде чем нанимать кого-либо.

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

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

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

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

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

Поверни это другой стороной.

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

Затем отметьте некоторые ответы на свои вопросы как «технический тест завершен».

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

Кроме того, насколько вы, по вашему мнению, способны выполнять работу, для которой был рассчитан этот тест?

Я работаю в компании, которой требуется около 99% кандидатов для прохождения теста по программированию. 1%, которые не обязаны проходить, попадают в две категории. Первая категория - это «рок-звезды», которые мы активно набирали с самого начала. Вторая, и, возможно, более релевантная категория - это люди, для которых процесс был отменен старшим персоналом, имеющим очень хороший послужной список и способным выполнять работу, для которой они нанимают.

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

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

Учитывая ограничения HR, я думаю, что я бы скачал копию cyber-dojo , установил ее на локальный сервер, разместил вашего кандидата перед веб-браузером, который может получить доступ только к этому серверу, и попросил бы его выполнить несколько ката (по вашему выбору) на языке по своему выбору (в идеале это другой язык для ката).

Тогда посмотрите на последовательность светофоров. Если они хороший разработчик TDD , вы должны получить хорошую повторную красную / зеленую прогрессию.

^{Если вы хотите поиграть в кибер-додзё, у автора есть хорошая онлайн-версия здесь .}

Другой вопрос - насколько вы доверяете своему отделу кадров.

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

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

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

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

Сказав это, вы должны увидеть, какую задержку может вызвать фактический процесс интервьюирования. Если он является очень компетентным кандидатом, который, по вашему мнению, может вмешаться и исправить ваши проблемы со сроками на ходу, то у него не должно быть проблем с проведением пары часов в интервью / парном программировании. Другим фактором, который следует учитывать, будут ваши нынешние сверстники. Вы не хотите, чтобы ваша большая команда чувствовала, что люди входят / уходят в соответствии с вашими прихотями - потому что обычно это плохо отражается, если парень выходит из игры. Это одна из основных причин, почему HR настаивает на нескольких интервью, так что один человек не может повлиять на успех.

Удачи с наймом и проектом!

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

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

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

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