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

Часть кода теста заняла у меня 5 минут, это заняло бы, может быть, 10-15, если бы я набрал все бессмысленные свойства и назначения и реализовал метод (который никогда не вызывается). Удвойте это за потенциально дерьмовую обстановку и нервозность на собеседовании, и время будет в порядке. SQL должен быть таким же простым.

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

Судя по всему, это работает как форма FizzBuzz. Он отсеивает людей без базового понимания языка. Это хорошо . Только представьте, что вы наняли одного из них!

Тот факт, что люди не проходят ваш тест, показывает, что ваш процесс вплоть до собеседования несовершенен.

Вы должны спросить себя, как получилось, что вы берете интервью у людей, которые не проходят такой простой тест. Они солгали в своем резюме? Это распространено в вашем регионе? Есть ли способ узнать раньше? Может быть, вы найдете несколько простых вопросов, которые можно задать по телефону? Или вы пригласили не тех людей? Они на самом деле сказали, что знают C#, или вы так предположили? Боюсь, здесь я не могу вам помочь, потому что там, где я живу, люди обычно не лгут и не преувеличивают таким образом в своих резюме. Если они говорят, что могут кодировать на C#, они могут.

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

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

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

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

Вы слышали о псевдокоде ?

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

пример :

// Place a for loop here, For as long as i < [var].Length then do this other thing. 

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

Кроме того, я бы НАСТОЯТЕЛЬНО рекомендовал разрешить ему использовать Интернет для ссылок на код. Кодирование требует ОГРОМНОГО количества поисковых кодов, чтобы выучить их.

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

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

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

Суть в том, что вам нужно понять, как он думает . Не то, насколько он хорош в кодировании.

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

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

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

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

Наконец, я бы сказал, что «слишком сложно» на самом деле зависит от типа человека, которого вы хотите нанять. Не тупите свои вопросы, потому что вам не нравится, что люди не проходят мимо. Вместо этого устанавливайте разумную планку вопросов, чтобы отсеивать людей, которые не добьются успеха на этой должности. Я уверен, что на должности в Google, на которой соискатель будет разрабатывать расширенные поисковые алгоритмы, не будет простых вопросов вроде «В чем разница между запросами POST и GET?» Вместо этого я уверен, что им задают сложные вопросы по алгоритмам и машинному обучению. Идеально иметь вопросы, которые слишком сложны для людей, которые не собираются добиваться успеха, но демонстрируют понимание принципов, которые им потребуются для достижения успеха.

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

Чего вы хотите достичь этой задачей разработки?

У вас есть небольшое окно на собеседовании, чтобы судить, накормил ли вас кто-то чушью во время интервью.

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

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

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

Например:

У меня есть массив объектов ac#, и я выполняю цикл foreach.

Затем вы ждете, пока кандидат скажет: «О, преобразуйте это в список объектов, и тогда вы сможете использовать linq для поиска по списку.

Вы можете показать им оператор SQL с явной неэффективностью, а затем получить представление об ответе: «О, добавьте индекс к таблице или измените предложение where на что-то еще.

Вы даже можете иметь неправильное соединение в SQL и посмотреть, подберут ли они его, или что-то в этом роде.

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

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

У меня два комментария:

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

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

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

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

Бонус: не забывайте, что некоторые люди ДЕЙСТВИТЕЛЬНО борются на собеседовании. Я знал людей, которым было очень комфортно брать интервью и отвечать на поведенческие вопросы, но они полностью замирали/не обращали внимания на технические вопросы, потому что не ожидали этого или были готовы к чему-то другому.

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

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

Как определить, слишком ли сложные задания или нам просто не повезло с кандидатами?

1. Сколько длится ваше интервью? (Для обсуждения предположим, что это два часа.)
2. Сколько задач по программированию вы собираетесь опросить интервьюируемого? (Допустим, это четыре задачи).
3. Учитывая четыре задания на двухчасовое собеседование, сможете ли вы выполнить каждое задание за 25 минут? Или, если некоторые из них сложнее других, сможете ли вы пройти их все за 100 минут? [Предположим, что вы видите эти вопросы впервые.] Если ответ «Нет», то интервью слишком сложное. Если ответ «Да», то интервью не слишком сложное.
4. В качестве альтернативы вы можете попросить бывшего коллегу или приятеля по программированию сыграть роль потенциального собеседника и посмотреть, смогут ли они пройти ваше техническое собеседование в разумные сроки.

Одна статистика такова: сколько терпит неудачу? Если у вас было более 10 отказов, каков шанс, что вы действительно получили 10 плохих кандидатов?

Они получают ответы неправильно или просто не заканчивают? В незнакомой среде 1 час не очень долго. Я только ожидал, что вы могли бы попросить около 4 основных задач. Через час вы будете тестировать только базовую механику.

Может вопросы непонятные а может вопросов слишком много/сложных для 1 часа.

Не могли бы вы опубликовать некоторые из ваших вопросов?