Технические интервью имеют тенденцию быть субъективными? [закрыто]

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

В одном из недавних интервью я сказал кое-что об использовании алгоритма дерева AVL для решения конкретной поставленной задачи. Интервьюер ответил: «Что такое дерево AVL?». Другой пример - что-нибудь вокруг синтаксиса; Я сталкивался с этим в основном в интервью, где требуется код на Ruby, потому что есть много способов реализовать решение данной проблемы. Очень распространенными являются проблемы вокруг объектно-ориентированных проектов.

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

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

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

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

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

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

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

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

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

Но вообще говоря: да, технические интервью всегда субъективны. И они должны быть. Если вы собираетесь проводить 8 часов + каждый день с человеком, было бы неразумно выбрать кого-то, кому удастся свести вас с ума в 60-минутном интервью.

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

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

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

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

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

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

Один простой пример, как вы упоминаете, заключается в том, что интервьюер хочет получить ответ, очень близкий к его собственному ответу. Другой пример: когда интервьюеру интереснее исследовать, он знает больше, чем кандидат. И еще один простой случай, когда интервьюер хочет, чтобы кандидат знал конкретное расположение меню для работы программной IDE (Visual Studio, Eclipse, NetBeans).

Я был на нескольких таких, и это очень расстраивает.

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

Самое странное, что, будучи выпускником CS, я знаю некоторую психологию (собирался изучать эту профессию), а иногда обнаруживаю множество субъективных «помех». Или, когда интервьюер идет в офис по соседству и явно говорит своим коллегам, он / она не хочет нанимать кандидата по субъективной причине.

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

Вот как я это делаю:

• Сначала я прошу кандидата решить реальную проблему. Обычно это проблема, которую я могу легко решить; обычно намного меньше, чем выделенное время.

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

Вот что я ищу.

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

• Мне также интересно, насколько хорошо они слушают и общаются. Смогли ли они понять и выполнить все начальные требования? Насколько хорошо они объяснили, как работает их решение?

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

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

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

Вот как я знаю, что кандидат - плохой выбор:

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

Считаете ли вы, что в качестве собеседника ваше согласие на работу не является в определенной степени субъективным? Набор персонала - это двусторонний процесс.

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

В вопросе о дереве AVL меня заинтересовало бы объяснение кандидата, как оно работает, и предоставление информации о свойствах и использовании. Чтобы сделать лучше, чем объяснение в Википедии. Имейте в виду, что ваша аудитория может быть кем-то в корпоративной корпоративной среде, где последняя ссылка на O (log n) в техническом обсуждении была в основном ... никогда.

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

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

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

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

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

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