Каков наилучший способ оценить новых программистов? [закрыто]

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

Больше вещей, которые я должен отметить:

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

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

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

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

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

Я надеюсь, что я не говорю слишком агрессивно в своем вопросе; и кстати я сам программист

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

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

• Регулярное тестирование с FizzBuzz-подобными вопросами кодирования и многими вопросами знаний, где они должны давать кодированные примеры. В зависимости от позиции это могут быть принципы ОО, принципы разработки SQL и т. Д. Я увеличиваю сложность вопросов по всему тесту, чтобы понять, насколько далеко они могут зайти. Идея состоит не в том, чтобы получить ответы на все вопросы (если они это сделают, тем лучше), а в том, чтобы узнать, могут ли они признать, когда они чего-то не знают. Доверие важно, и я не хочу, чтобы кто-то лгал мне в моей команде.

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

• Последняя часть, но не в последнюю очередь, The Code Review . Я прошу кандидата принести кусок кода (я обычно делю несколько предыдущих тестов / обсуждений и этот обзор на несколько дней, чтобы они могли написать и отполировать один фрагмент кода). Затем мы регулярно проводим анализ кода с двумя людьми: одним человеком, который будет непосредственно работать с кандидатом, и человеком, который ранее проверял тест с кандидатом. Относительно обзора кода вы можете прочитать эту статью от JohnFX .

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

Начните с предоставления им FizzBuzz для решения. Это должно отсеять худшее из них.

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

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

Просто ищите страсть к работе.

Чтобы процитировать Джоэла, ищите людей, которые « умны, и добиваются цели ».

Остальное не имеет значения

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

Положительные показатели:

• Страстный о технологии

• Программы как хобби

• Буду отговаривать вас на техническую тему

• Значительные (и часто многочисленные) личные сайд-проекты на протяжении многих лет

• Изучает новые технологии самостоятельно

• Мнение о том, какие технологии лучше для различного использования

• Очень неудобно из-за идеи работать с технологией, которую он не считает «правильной»

• Очевидно умный, может иметь отличные разговоры на различные темы

• Начал программировать задолго до университета / работы

• Имеет несколько скрытых «айсбергов», большие личные проекты под радаром CV

• Знание большого разнообразия несвязанных технологий (не может быть в резюме)

Отрицательные показатели:

• Программирование - это работа дня

• На самом деле не хочу разговаривать по магазинам, даже когда

• Изучает новые технологии на курсах, спонсируемых компанией

• Рад работать с любой выбранной вами технологией, «все технологии хороши»

• Не кажется слишком умным

• Начал программировать в университете

• Весь опыт программирования есть в резюме

• Ориентирован в основном на один или два технологических стека (например, все, что связано с разработкой Java-приложения), без опыта работы за его пределами

Кроме того, я бы предложил:

• Тест FizzBuzz (или что-то подобное, чтобы проверить базовую способность написать алгоритм.
• Более сложная версия теста FizzBuzz (чтобы привести их к точке сбоя или почти сбоя).
• Обсудите их код и посмотрите, не хотят ли они быть самокритичными и искать улучшения (которые они, вероятно, не успели сделать в краткой версии на месте), такие как:
  • хорошие имена переменных (у меня были очень опытные опытные программисты, использующие переменные в производстве, такие как "flag" (WTF ??)
  • модульность.
  • Предвидеть проблемы и делать «защитное кодирование»
• Готовность видеть «недостатки» как возможности для улучшения. Я думаю, что лучшие программисты всегда смотрят на недостатки в своем предыдущем коде. Они не настолько эгоцентричны, чтобы думать, что обнаружение недостатка - это личное оскорбление. Они видят в этом возможность добиться большего. (Те, кто не может смотреть на недостатки непоколебимо, либо ошеломлены, увидев недостаток (и становятся неуверенными в себе или, чтобы избежать этого, они игнорируют недостатки).
• Могут ли они отладить?
• Могут ли они юнит-тест? (Я говорил со слишком многими программистами, которые говорят: «QC делает это». Я не говорю о тестировании, я говорю о тестировании: вы пишете функцию, она работает? Прилагает ли она разумные усилия, чтобы справиться с вероятные проблемы (нулевой ввод и т. д.)? Если вы не можете этого сделать, как вы узнаете, когда закончите?
• Есть ли у них хорошие навыки общения? (как минимум: хорошее понимание и самопознание того, когда они понимают и не понимают, и готовность сказать: «Я не понимаю, пожалуйста, объясните это снова».

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

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

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

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

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

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

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

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

Нечетные практики найма при найме разработчиков программного обеспечения

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

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

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

Тем не менее, вы решаете провести собеседование, не задавайте вопросы об этой «загадочной мысли» .

Я предлагаю вам ответить на вопрос FizzBuzz и нанять первого, который пройдет. Дальнейшие тесты, как правило, ошибочны, так как не каждый хороший программист подойдет к такой проблеме, как вы, или проведет собеседование без заикания, или знает языки, которые вам нужны или интересуются, или глупость, как обмен целыми числами без третьей переменной (кому это все равно нужно? значит, объем ОЗУ превысил 128 байт?).

Думаю об этом. Если вопрос FizzBuzz исключает 199 из 200, то он просто исключает сотни интервью. Вы действительно собирались взять интервью у сотен потенциальных?

Просто кажется, что убывающая отдача после FizzBuzz. Это предполагает, что 199/200 даже близко. И я полагаю, ВАШЕ время тоже ценно ...

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

Такие примеры глупого простого вопроса - это вопрос о рекурсии, такой как у вас есть список, и вы должны напечатать его в обратном порядке без использования цикла. Простой вопрос регулярных выражений, если регулярное выражение обычно делается в вашей разработке. Вопрос о битах и ​​байтах при использовании C ++ (напишите шаблон, который принимает char в long и распечатывает двоичное представление. Специализация не требуется, просто используйте sizeof () для определения длины в битах)

Это займет у вас <= 3 минуты на вопрос

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

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

1. Могут ли они защитить то, что утверждают, что знают? Они помещают это в резюме / CV как навык или что-то, что они сделали в другом проекте. Посмотрите, как глубоко они могут пойти по этому вопросу.

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

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

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

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

Первая прополка - это резюме. Одна вещь, которую я ищу, это много заявленного языкового опыта и ничего, чтобы описать то, что они делали на этом языке. Я видел резюме, которые в значительной степени утверждают, что они знают каждый когда-либо придуманный язык, и все же их опыт показывает, что они фактически работали только с Access и Visual Basic. Те идут прямо в мусор. Резюме на 10 страниц попадает прямо в корзину (особенно резюме на 10 страниц от людей с опытом работы менее 2 лет, которые я получил). Из недавних выпускников колледжа с небольшим опытом, вы должны быть очень разборчивы в том, как они себя представляют. Лучшие кандидаты осторожны со своими резюме, они не имеют ошибок. Вы действительно ищете кого-то, кто так мало заботится, что он не потрудился вычитать свое резюме?

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

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

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

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

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

Если она выйдет в ярких цветах, она в игре!