Какую помощь я должен оказать во время технических интервью? [закрыто]

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

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

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

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

В одном вопросе респонденты должны были иметь возможность определить объем цилиндра, поэтому я не возражал, если бы кто-то сказал: «Мне бы пришлось обратиться в Google за формулой объема цилиндра». Мне было интересно узнать, знают ли они, как решить проблему, а не запомнить ли они формулы. Для работы они должны были иметь приличное представление о том, как перевести реальный мир в программное обеспечение, поэтому это была важная концепция.

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

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

У вас есть два подхода, которые подходят как для решения проблем, так и для коротких технических вопросов:

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

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

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

Пример:

- Можете ли вы сказать мне, как вы создаете свойства только для чтения в C #, то есть свойства со значением, которое может быть инициализировано только внутри конструктора и не может быть изменено позже?
- Конечно. Я просто использую ключевое слово readonly.
- Ты уверен? Можете ли вы объяснить мне разницу между собственностью и полем?
Хм. Свойство ... вы видите ... получить и установить ...
- Хорошо. Таким образом, поле - это переменная, объявленная внутри класса или структуры и действительная в области действия класса / структуры, в то время как свойство похоже на поле, но также предоставляет механизм для чтения, записи или вычисления значения. Теперь о чем readonly? Это используется со свойствами?
- Я считаю, что он используется только для полей ...
- Верно. Так что насчет свойств?
- Их нельзя только читать.
- Ты уверен? Как насчет свойств, которые имеют только добытчики?
- Они только для чтения.
- Значит ли это, что их стоимость всегда останется неизменной?
- Да.
- Нет, не совсем. Тот факт, что у вас есть свойство с геттером, не означает, что его значение не изменяется в течение срока службы экземпляра класса. Если получатель ссылается на поле, которое увеличивается каждый раз, когда вы обращаетесь к свойству, возвращаемое значение будет непрерывно увеличиваться.
- Правильно.
- Так? У вас есть идея, как вы можете реализовать свойство со значением, которое никогда не меняется?
- Нет.
- Ну, вы можете использовать поле только для чтения. Знаете ли вы, что такое поле поддержки?
[...]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иногда предоставление minor hintsво время устного собеседования помогает понять, насколько хорошо кандидат понимает тему (и). Тем не менее, должны быть no hintsстандартные тесты, которые каждый кандидат должен пройти.

По сути, two main thingsвы можете узнать о потенциальном кандидате:

а) Личные качества - хорошо ли он вписывается в вашу компанию или команду

б) технические навыки - обладает ли он хорошим техническим опытом и заинтересован в подборе новых вещей

Чтобы узнать об этих упомянутых моментах, вы должны вовлечь потенциального кандидата в разговор. Также важно удостовериться, что кандидат comfortable during the interviewдля того, чтобы получить максимальное понимание его текущих навыков (как программных, так и технических), а также его потенциала для выполнения работы.

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

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

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

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

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

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

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

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

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

Зависит от того, какой программист вы хотите. Интроверт, который может написать на бумаге великолепные 20 строк кода, будет хорошо выглядеть для вас, босс. Разработчик программного обеспечения, который может работать на основе миллионов строк кода в команде для эффективного производства хорошего программного обеспечения, вероятно, не очень хорошо. Мне нравятся такие интервью в качестве кандидата - они много говорят мне о том, как начальник относится к своему персоналу и какова культура работы. В таком случае, когда я покинул интервью, я сказал: «Спасибо, давайте сэкономим нам немного времени, если не позвоните мне, я вам не позвоню». Когда меня спросили, почему, я указал, что не хочу работать в компании, которая подставила меня, чтобы потерпеть неудачу.

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

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

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

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

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

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

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