Тебе нужен тест по программированию. Но это должно быть 5-10 минут. 30 минут максимум. Нет 2-х часового теста, который точно скажет, насколько хорош программист. Вы не сможете сказать, постоянно ли они пишут сопровождаемый код, всегда ли они правильно комментируют, или придумывают нечитаемые путаницы с “умными” решениями проблем и т.д. За 2 часа, единственное, что Вы сделаете - узнаете, кто лжет о том, что знает язык/программирование.

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

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

“Либо эти люди думают, что это имеет ценность, что означает, что они понятия не имеют, что они делают, ИЛИ, они знают, что это пустая трата времени, но по каким-то причинам (вероятно, слепо следя за волокитой HR), они готовы тратить время кандидатов еще до того, как кандидат будет принят на работу”. Представьте себе, что они будут думать, что они могут уйти, как только они платят мне.

В любом случае, я не хочу работать там.

Там еще одна вещь, которая может быть отгонять кандидатов: Продолжительность процесса собеседования. У вас есть люди, которые проводят собеседование по телефону. Затем берёте домашний тест, который у них есть неделя, чтобы закончить. Потом вы проходите тесты. Потом организуешь собеседование с руководством. Потом (я полагаю) вы проводите пару личных собеседований. Потом ты возвращаешь парня, которого хочешь нанять. И что для этого нужно? 2 недели? Дольше?

За это время я уже получил 3 предложения. Я принял одно и начинаю на следующей неделе. Думаешь, я пойду делать твой двухчасовой тест?

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

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

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

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

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

Я могу сказать вам прямо сейчас, что если я получу проект, который займет более 8 часов, я скажу им спасибо, но мне это не интересно. У меня хорошая работа и жизнь. Если менеджер видит в этом проблему, это говорит мне, что его не волнует мой баланс работы и жизни на работе (особенно, если их не волнует перед мной). Ни одна компания, за исключением, возможно, Google, Apple или Facebook, не сможет избежать этого.

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

Подумайте об этом так. Хороший шифровальщик может легко получить телефонные и личные интервью. Каждый дополнительный обруч они должны прыгать через будет означать, что они будут принимать более легкий маршрут и собеседование (и получить наем) кем-то другим, кто будет платить столько же. Если вы заставляете людей прыгать через обручи, убедитесь, что они видят, что это стоит их время от get-go.

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

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

Что, я думаю, мы должны были сделать вместо этого

Вместо того, чтобы давать людям задание на дому, которое заняло 15-20 минут, мы должны были сделать 15-20 минутное Skype-интервью, где мы задавали такие вопросы, как Fizzz buzz. Это заняло бы столько же времени, но я бы, скорее всего, отсеял плохих программистов перед двухчасовым очным интервью.

FYI -> Вот очень подробная статья о Fizz-buzz и общей практике проведения интервью.

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

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

Обратите внимание, что я сказал “короткий ”. Мы даем кандидатам ноутбук с правильно установленным Eclipse (наш выбранный IDE), когда они приходят на собеседование. Правильно настроенный означает, что у них есть доступ к источнику jdk, но у него нет интернета, и их просят не использовать мобильные телефоны во время теста. Они получают час, чтобы решить от нуля до пяти проблем, начиная от “FizzBuzz”, и подняться в сложности к чему-то по порядку простой многопоточной системы производитель / многопользовательский-потребитель.

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

Кстати, у нас были якобы опытные программисты Fil, чтобы получить FizzBuzz право. Позвольте мне повторить: у нас было горстка кандидатов не в состоянии завершить FizzBuzz правильно. Обычно не следуя инструкциям, но чтение спецификации является существенной частью быть разработчиком.

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

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

У нас однажды был один кандидат жаловался на тест, потому что он думал, что он слишком старше, чтобы доказать себя (это не спекуляции - он так сказал). И он хорошо справился с испытаниями, и у него был весь тот опыт, который мы хотели. Но он был terrible сотрудником: он также, очевидно, думал, что он был слишком старшим, чтобы руководить или учиться, и в конечном счете мы должны были отпустить его.

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

Следовательно, что you делать? Вы должны делать то, что работает для вашей организации, но мой совет - продолжать тесты, но делать их на месте, в рамках собеседования. Скажите им заранее, что это часть процесса, и сделайте это до того, как они встретятся с высшим руководством (но Вы должны сначала встретиться с ними, чтобы помочь им успокоиться). И действительно: пропустите собеседование с высшим руководством, если у них не получится. Не беспокойтесь о популярности среди кандидатов или плакатов в интернете. Стоимость плохой аренды намного хуже, чем стоимость задержки до тех пор, пока вы не сделаете хороший наем.

Почему нет дома тесты?

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

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

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

Как протестировать вместо этого?

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

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

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

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

1. Во время технического интервью они усадили меня за компьютер, у которого была убогая версия их кодовой базы, и заставили меня решить три относительно короткие проблемы, связанные с ней (найти и исправить ошибку, которую они целенаправленно добавили, добавить новое поле в информационную таблицу и т.д.). Они дали мне ровно час, чтобы я это сделал, и через час они просмотрели мое решение, а также то, как я подошел к решению проблемы. Это дало им больше понимания обо мне как о программисте, уважая при этом моё время и сохраняя его кратким и точным.
2. Во время технического собеседования они попросили меня поработать над проблемой, с которой они столкнулись во время разработки на доске, и при этом иметь возможность отбросить от них идеи. Это был самый короткий вариант, который дал им возможность увидеть, как я справляюсь с проблемами и как много я могу сделать на самом деле.
3. Во время технического собеседования (на должность младшего специалиста по веб-разработке Ruby on Rails Web Development) они поручили мне построить веб-приложение с нуля, которое бы осуществляло навигацию по сайту, заполняло несколько форм по мере их представления, извлекало данные из полученной страницы и представляло их пользователю. Они сказали, что это должно быть быстрым упражнением, и, возможно, это было для веб-разработчика старшего уровня, но, имея на тот момент всего год профессионального опыта, я потратил четыре часа, пытаясь заставить все это работать, прежде чем сдаться и уйти домой (все интервьюеры ушли за несколько часов до меня, потому что это было послеобеденное собеседование, они сказали, что я должен просто сохранить готовую программу, когда я закончу). Это нелепое задание на указанную должность, не давало им представления о моих способностях к кодированию, и мне казалось, что они просто пытаются получить свободную работу от сделки. Нет нужды говорить, что к тому времени, как я ушел в тот день, я даже не хотел эту работу.
4. Еще до технического собеседования они дали мне задание создать веб-приложение, которое бы использовало API, который их компания использовала, чтобы “сделать что-нибудь интересное”. Это было в точности так же широко, как это звучит. Это потребовало от меня сделать следующее еще до того, как я попытался создать приложение: создать учетную запись разработчика для API, загрузить набор для разработки API, создать общедоступное веб-приложение (с другой учетной записью разработчика), изучить API и создать хранилище данных для доступа к нему с помощью API. Конечно, это заняло много часов, и вскоре после того, как я начал работать с самим веб-приложением, я получил другое собеседование и вскоре после этого предложение о работе, поэтому я прекратил работу над заданием. Это безумие, которое нужно иметь в процессе собеседования, потому что кто хочет потратить все это время и усилия на разработку программы только для того, чтобы иметь небольшой шанс двигаться дальше в процессе собеседования?

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

Позвольте мне начать с:

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

• мне задали вопрос о квадратных и круглых крышках люков.

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

• Перед тем, как выставить объявление о вакансии, вы должны сесть и пройти через то, что именно вы пытаетесь нанять, а “разработчик” - это не ответ, по крайней мере, не правильный ответ. Хорошим ответом на этот вопрос было бы что-то вроде “эксперта по ипотечному домену”.

Найти кого-то, кто может написать немного кода или поискать в Google, как применить тот или иной шаблон, тривиально по сравнению с поиском кого-то, кто занимался бы бизнесом, в котором вы находитесь, и может использовать эти знания. Другими словами, если бы я нанимал компанию, занимающуюся ипотечной документацией, я бы взял кого-нибудь, кто мог бы рассказать о разнице между фиксированным и ARM займом на 15 лет, и кем-нибудь, кто мог бы написать алгоритм сортировки пузырьков за 2 минуты. Причина в том, что “нормальные” бизнесмены выдвигают всевозможные странные требования, а эксперты по домену могут легче добраться до сути того, что нужно, в то время как тот, кто ничего не знает, с радостью добавит бесполезные вещи или сделает приложение действительно плохим.

Возвращаясь к вопросам, only ask go / no go questions.

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

Критично ли определять, когда запрос открыт для sql инъекции? Для позиции Sr - абсолютно, для позиции Jr - нет. Это то, что легко обучить и обработать через просмотр кода. Отсюда и причина, по которой вы хотите, чтобы sr. знал это изнутри и снаружи - чтобы они могли тренировать юниоров.

Критично ли то, что они знают точное максимальное значение типа данных Int32? Обычно нет - этот уровень банальных знаний - для чего нужен Google; но, может быть, ваше требование - кодирование на устройствах с ограниченной памятью - в этом случае: абсолютно.

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

Что я делаю, чтобы взять интервью у людей:

• я прошу их описать предыдущий проект или два. Все, что меня волнует на данном этапе - это сделать так, чтобы им было удобно и чтобы они могли говорить. Это “go/no go”, потому что если я не могу понять, что они говорят, то я не могу с ними работать.

• я задаю им несколько конкретных вопросов в техниках, которые мне нужны. Если это SQL сервер, то я спрошу об обновлении на соединении. Если это HTML, я передам им 10-строчный html-файл с парой css-классов и спрошу, что на выходе. Это тривиальные вопросы для людей с опытом работы в этих областях и быстро отсеивают претендентов.

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

• Если я ищу младшего девчонку, то спрошу о домашних животных проектах. все, что я хочу знать, это тип используемой технологии. Это должно помочь вам понять, что они на самом деле хотят делать. Другими словами, разработчик на C# вряд ли будет заниматься домашними проектами на php. Честно говоря, я не ожидаю слишком многого от младших, кроме того, чтобы быть обучаемым. Если они активно работают над домашним проектом, то я могу их обучить. Если они из тех, кому нужны люди, чтобы сказать им, что делать, есть гораздо более крупные компании, в которых эти ребята могут работать.

Я не выдумываю эти вопросы на лету, потенциальные ответы рассматриваются заранее и подходят по шаблону “go/no go”. Если вопрос не подходит, то это не относится к делу. Я также задаю каждому кандидату те же самые вопросы, если я не на 100% уверен, что не нанимаю их, и на этом собеседование прекращается.

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

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

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

Что вы тестируете?

Тест для белой доски, или короткий тест на программирование, дает вам некоторое представление об отдельном человеке, но на самом деле не так уж и много. Если только вы не планируете, чтобы кто-то тратил свое время на написание кода на доске или код в стиле FizzBuzz.

Что вы want?

Вы хотите кого-то, кто:

• страстный
• готов учиться
• способен решить problems*
• резонансно технические
• собирается помочь вашей команде improve

* Заметка, большинство разработчиков решают свои проблемы, зная, какие термины искать в Google.

• Вы хотите нанять кого-то, кто не подходит для вашей команды, потому что они будут тянуть его вниз.

• Как вы можете протестировать на это?

• Спросите их о проекте, который им понравился. Если им кажется, что они не хотят говорить об этом, попробуйте выразить нежное недоверие, например: “Вы не можете сделать X, не так ли?”. Если это что-то, что им нравится, они вас поправят. Это также поможет вам узнать, являются ли они техническими или нет.

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

• Спросите их о том, когда в последний раз (или когда) им не хватало знаний. Как они получили необходимую информацию? Пошли ли они к товарищу по команде? Искали ли они в интернете?

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

• Спросите их, какая технология их волнует и почему.

Если у вас есть кто-то, кто технически подходит к этому разговору, будет проще всего сказать, будет ли этот человек худшим в мире. Пример: к нам пришел ребенок и взял интервью - он сказал, что по шкале от 1 до 10, его навыки работы на Java равны 7-8. Не думаю, что он даже знал, что Java была скомпилирована в jar-файл, который позже был скомпилирован на машинном языке JVM. Я бы поставил себя на 2 или 3 и I знаю это.

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

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

Этот парень не был нанят.

Выясните, какие атрибуты вы ищете, а затем выясните, как протестировать на those

Но мне really нужно посмотреть, как она кодирует!

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

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

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

С точки зрения человека, ищущего работу, я, как правило, избегаю мест, где на кодирование уходит более 1 часа. Однажды я побывал в этом месте, где требовалось почти 3 дня java-проекта по кодированию. Я все это сделал, и парень даже был впечатлен, но мне сказали, что наняли кого-то другого после второго этапа собеседования. Так что после этого, если я приду в компанию, я проигнорирую/перейду любой проект, для завершения которого требуется более пары часов. Мое время так же ценно, как и их, и я предпочитаю не тратить его на вещи, которые никуда меня не приведут.

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

Как отметили другие, некоторые разработчики могут быть отстранены на 1-2 часа программирования, чтобы подать заявление о приеме на работу. Что может сработать лучше, так это сеанс белой доски, где кандидат решает проблему на белой доске во время собеседования. Это дает вам возможность пройти собеседование, а также убедиться, что у них есть технические отбивные.

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

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

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

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

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

Хотите нанять программистов, которые не могут программировать?

Я собираюсь рискнуть, что вы этого не сделаете.

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

**Готовы ли вы снизить свои стандарты, потому что все пытаются нанять программистов?

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

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

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

**И отпугивает кандидатов проблема?

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

Это good отпугнуть этих кандидатов. Вы хотите нанять способных, мотивированных кандидатов. До тех пор, пока вы не отпугиваете тех, кто тоже, вы хороши.

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

Как я могу улучшить наш процесс найма?

Проверьте содержание вашего упражнения программирования. Является ли оно разумным и подходящим для контекста собеседования?

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

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

А также рассмотреть, как вы управляете упражнением. Если вы просто дать им некоторую документацию и сказать “здесь, сделать это в течение следующей недели и отправить мне по электронной почте”, это, вероятно, только будет минимально эффективным.

Лучше может быть, если вы можете запустить упражнение через веб-портал, который кандидаты могут проверить и начать упражнение, и как только они запустят таймер начинает отсчет от 1 часа. Тогда они либо представить что-то в течение этого часа, или нет. Это менее открытые, лучше удержать внимание кандидата, и обеспечивает четкий крайний срок / коробку времени, так что 1) вы не останетесь ждать всю неделю, чтобы результат, который никогда не придет, и 2) неквалифицированные кандидаты не выбрасывают неделю своего времени, пытаясь завершить свое упражнение по программированию. Они получают 1 час, они либо решают проблему, либо нет, и вы знаете результат немедленно.

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

В итоге

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

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

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

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

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

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

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

Звучит ли это как много работы? Это должно быть… Одна из причин, по которой наем кажется таким “трудным”, заключается в том, что вы пытаетесь сделать это как можно эффективнее. Чем больше времени, мозговых сил и ресурсов вы отвлекаете на это, тем легче. Будет ли лучше потратить эти ресурсы на доставку товара - вопрос вечного управления. Но если вы тратите много времени на “дерьмовую программистскую фильтрацию”, то это сжигание денег. По крайней мере, вышеописанные этапы имеют внутреннюю ценность вне процесса приема на работу.

(*): Hell, hire them.

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

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

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

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

Я думаю, что вы сформулировали свой вопрос немного неправильно, но то, как вы его сформулировали, отражает распространенное заблуждение о найме программистов. Кандидаты “отпугиваются” заданием по программированию, или они отфильтровывают Вашу компанию из собственного рассмотрения из-за задания?

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

Я кликнул на объявление о работе, и меня сразу же попросили написать сопроводительное письмо. Ох. Я думаю, что каждый кандидат ненавидит сопроводительные письма. Я не знал эту компанию и не пользовался их продукцией, так что я мог бы сказать о них? Я погуглил их, прочитал их сайт и товарные предложения, выяснил, где я мог бы поместиться в их организационной структуре, если бы меня наняли, и придумал несколько абзацев “продавать” сам.

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

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

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

1. Дистанционная работа.

2. Бесплатные компьютеры/мониторы в качестве бонуса за подпись.

3. Компания вносит свой вклад в уважаемые проекты с открытым исходным кодом.

4. Возмещение расходов на профессиональное обучение и/или конференции.

5. Обеды с обслуживанием.

6. Гибкий график работы.

7. Возможность работы с новыми или незнакомыми технологиями.

8. “Культура стартапа” - т.е. отсутствие политики/бюрократии.

9. Узнавание названия: ваша компания или ваш продукт хорошо известны. Кандидаты любят упоминать, где они работают, и слышать, как люди отвечают “О, круто! Мне нравится их продукция”

10. Благотворительные или революционные цели/видение компании. Людям нравится писать код, который делает жизнь людей лучше.

11. Зарплата выше среднего. Деньги покрывают множество организационных грехов.

12. Ежегодные выездные семинары компании в прохладные места.

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

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

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

Альтернатива #2 - Вероятно, они уже написали код бесплатно, который они вам покажут, если вы просто спросите. У большинства программистов есть код на сайтах Github, Bitbucket, Q&A, например Stack Overflow, или они могли бы предоставить вам какой-нибудь код, который они еще не опубликовали.

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

В качестве прямого ответа на ответ Бобо (который является принятым ответом, потому что парень написал его и принял его сам, что, честно говоря, я чувствую себя немного жалко):

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

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

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

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

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

Если это действительно ваша цель, я бы рассмотрел другой подход. Как было указано в других ответах, ДА, у Вас всегда должен быть вопрос по кодировке, но вопросы по кодировке редко вникают в подробности языка. Некоторые вопросы, которые я видел, полезны для тестирования:

1. Сравните и сравните Java и C (или любые другие языки, указанные в резюме кандидата и т.д.)
2. Какие функции, по вашему мнению, должны быть добавлены к языку (или еще лучше, что вы думаете об этом конкретном предложенном/предложенном изменении языка?)

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

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

Все сводится к рассмотрению вашей бизнес ситуации, а не к общей практике.

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

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

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

В ИМХО существует почти нулевая вероятность того, что новый выпускник колледжа сможет выполнить сложный программный код на начальном уровне. Если для прохождения теста по кодированию требуется одна неделя, то в требовании следует четко указать, что вы ищете программистов с опытом работы не менее 2+ лет, так как я считаю, что для выполнения работы по кодированию, для которой требуется одна неделя, необходимо иметь большой опыт. И я думаю, что если вы ищете свежих выпускников, то спроектируйте свой тест соответствующим образом, и вы можете найти много идей в интернете, или вы можете попросить старших программистов, работающих на вас, спроектировать подходящий тест для свежих выпускников.

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

FINDINGS

Позитивы подхода

1) Возьмите домой тест сорняков из демотивированных кандидатов, и заменяет их с кандидатами, которые действительно хотят работать на вас. Это само по себе делает это стоит того, чтобы сделать, так как мотивированные люди = продуктивные сотрудники. Если они не могут беспокоиться, чтобы сделать 1 час задания, то это говорит об их отношении к получению работы.

2) Я согласен с другими, что взять домой тест не должен быть дольше, чем час - мой очень просто. У меня были следующие результаты от добавления его в процесс набора

а) Некоторые кандидаты не завершить его. Не стоит нанимать.

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

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

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

д) Некоторые кандидаты делают очень хорошо, прокомментировать свой код и в одном или двух случаях предоставить документацию. Зачет найма.

Негативы подхода

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

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

Приветствие этого подхода

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

Незнакомая мышь или неожиданная раскладка клавиатуры (особенно Mac vs PC) или другой IDE могут значительно замедлить производительность без какой-либо разницы в компетентности. Кроме того, полноценное приложение часто требует большого количества кода шаблона, который разработчик может не успеть ввести или даже не запомнить. Запуск нового приложения полностью с нуля на самом деле очень редкая задача; большая часть работы сосредоточена на расширении или улучшении существующего кода.

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

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

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

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

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

Я хотел бы изучить XMLreader и XMLwriter.

Сначала я думал, что забыть об этом. Но потом я увидел в этом шанс доказать, на что я способен. У меня нет степени CS, поэтому я скучаю по некоторым теоретическим вещам. Они спросили, что такое 3 столпа ООП и хотели сказать, кому какое дело.

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