Итак, у меня было техническое собеседование, и интервьюер задал мне вопрос, на который может быть несколько ответов. Я придумал решение и объяснил его ему, но он имел в виду другое решение и не принял мое решение, даже если я логически обосновал свой подход. Я не был уверен на 100%, потому что я только что придумал подход, и у меня не было предыстории данной проблемы.
После интервью я подтвердил, что решение, которое я придумал, вполне приемлемо и является одним из многих решений. Так должен ли я отправить ему письмо с надлежащими ссылками, что мое решение было правильным? Это хорошая практика?
Если я этого не сделаю, я боюсь, что меня из-за этого могут отвергнуть, а после отказа нет смысла писать ему по почте.
Шансы на то, что это поможет в вашей ситуации, ничтожно малы. В зависимости от того, как будет сформулировано электронное письмо, оно может даже значительно снизить ваши шансы.
Если бы это был только один из многих вопросов, я бы не слишком беспокоился об этом. Если остальная часть интервью прошла нормально, и вы продемонстрировали общие знания в других ситуациях, я был бы несколько удивлен, если бы они отказали вам только в одном вопросе.
Из-за того, что у меня мало знаний о найме людей. Даже на техническом собеседовании меня больше интересуют ваши коммуникативные навыки и то, как вы пытаетесь решить проблему, а не то, знаете ли вы ответ или нет.
В этом случае лучше просто подождать и посмотреть, что произойдет.
Это, кажется, малоизвестный факт в обществе, но многие проблемы имеют более одного решения. Может быть, сказать тебе, что твой ответ был неправильным, было тестом. Иногда работодатели ждут, чтобы вы оттолкнули и сказали: «Послушай. Мой ответ тоже правильный, и вот почему…» или, может быть, они искали тебя, чтобы развлечь возможность ответа интервьюера и подумать, что это может быть лучше. идти.
Они оценивают вашу реакцию на определенный раздражитель. Они хотят увидеть, как вы справляетесь с ситуацией, потому что подобные ситуации, вероятно, регулярно возникают на их рабочем месте, и вам нужно будет уметь справляться с ними эффективно. Во многих случаях для этого необходимо быть исключительным художником-импровизатором, чтобы изящно справляться с неожиданными ситуациями.
Это просто зависит от того, что они ищут, и поэтому полезно заранее как можно больше изучить работодателя или иметь опыт работы в отрасли. Если вы понятия не имеете, что они ищут, почти невозможно придумать приемлемый ответ. Вы должны спросить себя, как кто-то в этой роли справится с ситуацией, и исследования/опыт, безусловно, помогут вам понять это.
К сожалению, это тот случай, когда «просто забудьте об этом».
( ЕСЛИ это был кто-то, кого вы очень хорошо знали и с которым много разговаривали, вы могли бы написать по электронной почте и сказать: «Я думал о X, и…». Но это звучит так, как будто это просто еще один корпоративный интервьюер.)
Так должен ли я отправить ему письмо с надлежащими ссылками, что мое решение было правильным?
К сожалению, в 99,99% случаев они просто удалили письмо.
Точно так же, как резюме просматривают всего 2 секунды, интервьюеры просто бегают по техническим собеседованиям и вычеркивают людей из списков.
Это хорошая практика?
Я бы сказал, что это безвредно . Это не будет, скажем так, раздражать человека. Но, к сожалению, в 99,99% случаев они просто удаляли письмо.
К сожалению, общий ответ на ваш вопрос: «В 99,99% случаев совершенно бессмысленно отвечать на вопрос технического интервью».
Имейте в виду, что интервьюеры не идеальны. В частности, в вашем случае интервьюеры не всегда являются сильными кодерами. Не исключено, что они просто не поняли вашего решения.
В том же духе часть работы по программированию заключается в оправдании вашего решения перед другими. Если вы не можете сделать это во время встречи, ваше решение действительно должно быть лучше, чтобы оправдать его повторное обсуждение.
Если ваш интервьюер хорошо разбирается в коде, имейте в виду, что «правильное» решение может оказаться недостаточно хорошим. Они предпочитают что-то читабельное, проверяемое, эффективное и идиоматичное. Еще одна вещь, которую я видел, как сильные интервьюеры-кодировщики делали, — это показывали альтернативное решение, чтобы увидеть, можете ли вы указать на компромиссы между ним и вашим.
В любом случае, от того, что вы поднимаете этот вопрос сейчас, мало пользы. Воспринимайте это как опыт обучения и подумайте, как вы могли бы справиться с этим лучше в следующий раз.
Должны ли вы отправить продолжение об этом? Да. Нет. Может быть.
Я бы не ожидал, что это будет иметь огромное значение (если это имеет какое-либо значение) в их решении в любом случае, но давайте рассмотрим варианты.
Если вы достаточно хорошо объяснили это во время интервью , а он все еще не принял это, есть большая вероятность, что он не ответит положительно, если вы продолжите дальнейшие действия.
Некоторые люди менее открыты для обратной связи, чем другие. Может быть и так, что он это прекрасно понимал, но с этим была какая-то другая проблема.
Вы на 100% уверены, что вы правы? Если вы продолжите, и вы на самом деле были неправы, это пошлет сообщение о том, что вы тот, кто не так уж открыт для обратной связи (если, возможно, вы не сформулируете это очень, очень изящно).
Если вы, возможно, пропустили какое-то скрытое ограничение или могла быть какая-то другая веская причина, по которой он не принял ваш подход, также не было бы хорошей идеей продолжить. Конечно, вы, по-видимому, этого не знаете, но, возможно, вы можете сделать разумное предположение о том, насколько это вероятно.
Если вы плохо объяснили это во время интервью или это объяснение было бы очень полезным, если бы вы использовали некоторые ссылки, это может помочь в дальнейшем.
Некоторые люди были бы очень признательны, если бы кандидат подумал о проблеме после собеседования и потратил на нее некоторое время. Это показывает, что вы действительно заботитесь о работе.
Другие, возможно, не очень оценят это, или он, возможно, уже принял решение, но в таких случаях это, вероятно, все равно не повредит.
Я бы, вероятно, попытался включить какой-нибудь исполняемый рабочий код или ссылку или две на авторитетный сайт, если это применимо.
Не делайте свой ответ слишком длинным, не включайте слишком много ссылок и старайтесь свести код к минимуму.
Не делайте вид, что «вы не правы». Если вы сомневаетесь, просто полностью избегайте обсуждения того, как он ответил. Вы можете пойти с чем-то вроде:
Я еще немного подумал о проблеме и придумал этот код, чтобы показать, что он работает.
(Это довольно рудиментарный ответ, чтобы дать основную идею. Добавьте изюминку и откорректируйте формулировку по своему вкусу).
Если собеседование прошло хорошо, независимо от этого вопроса , вам нужно будет сделать выбор самостоятельно, исходя из вашей ситуации, того, как именно прошло собеседование, насколько важным был этот вопрос, как, по вашему мнению, они воспримут ваши последующие действия. и на какого работодателя вы хотите работать (и на какого работодателя вы не хотите работать, хотя также стоит иметь в виду, что один интервьюер не всегда будет представлять общую культуру компании).
Если собеседование прошло хорошо, но недостаточно хорошо для того, чтобы вы получили предложение, нет большого риска в дальнейших действиях. Тебе нечего терять.
Однако, если собеседование прошло ужасно, это крайне маловероятно, чтобы его спасти, поэтому дальнейшие действия, вероятно, просто тратят ваше время впустую. Хотя вам по-прежнему нечего терять, и вы, вероятно, потратите больше своего времени, чем их (поскольку они, скорее всего, просто проигнорируют это).
Хотя вы, возможно, также недооценили то, как все прошло, что может случиться, поэтому я был бы осторожен, не делая поспешных выводов.
Не пишите ему, это время прошло, а вы уже объяснили. Если он серьезный профессионал, он, возможно, сам искал его, чтобы проверить ваш ответ. Я, конечно, делаю, если кто-то оспаривает то, что я считаю правильным.
Сказав, что если есть несколько возможных ответов, и я ищу конкретный, то не имеет значения, является ли ваше решение жизнеспособным, это не то решение, которое я ищу по какой-либо причине. В вашем конкретном сценарии вероятность того, что он искал самое простое решение.
В любом случае существует потенциальный риск при ничтожно малом шансе на благоприятный исход от рассылки по электронной почте.
Нет, и не принимайте предложение от этой компании.
Существует выражение, используемое при найме людей: люди с качеством «А» нанимают людей с качеством «А», люди с качеством «В» нанимают людей с качеством «С». Объяснение этому заключается в том, что люди, которые действительно хороши, хотят продолжать учиться и нанимать людей, у которых они могут учиться, в то время как люди, которые не уверены в своих позициях, перейдут к кому-то лучше, чем они.
Интервьюер не стремился выяснить, насколько вы хороши на собеседовании — он хотел узнать, насколько хорош он сам. Он не заинтересован в найме для разнообразия мыслей, он заинтересован только в найме людей, которые думают о проблемах, смотрят на проблемы и решают проблемы точно так же, как и он, не лучше.
После такого собеседования, если он и рекомендует вас нанять, то только потому, что считает вас хуже, чем он, и вы попадаете в и без того токсичную рабочую среду, которая позволяет людям ранжировать себя, и где иерархия явно имеет значение ( или кто-то не будет брать интервью таким образом).
Интервью — улица с двусторонним движением
Дело не только в том, что они узнают вас, это в том, что вы узнаете их и узнаете, подходит ли вам это место для работы. То, как они проходят собеседование и как они относятся к вашим ответам, многое говорит о том, что важно в компании. Из этого интервью вы можете понять, что нестандартное мышление, вероятно, не приветствуется.
Фактор в этом положение интервьюеров в компании. Если бы это был технический руководитель команды, перед которой вы будете отчитываться, вы можете ожидать, что любое другое мнение будет подавлено, если вы согласитесь на эту работу. Он не ищет предложений или новых идей, просто кодовая обезьяна, чтобы рабски возиться за компьютером весь день.
Проблема с вопросами Gotcha
Большинство профессий (и вы конкретно упомянули о технологиях, а я работаю в сфере технологий почти 20 лет, и это особенно актуально) полностью ситуативны. В ходе карьеры вы обнаружите, что люди будут использовать одни и те же технологии, одни и те же технологические стеки и одни и те же инструменты совершенно по-разному. Знакомство с как можно большим количеством этих вещей является ключом к хорошей карьере.
Тем не менее, большинство вопросов на собеседовании в равной степени ситуативны и основаны на опыте интервьюеров. (Вот почему я настоятельно рекомендую провести «исследование оппозиции» вашего интервьюера, если у вас есть имя и время — понимание их биографии может помочь вашей подготовке к интервью, чтобы соответствовать их вероятным вопросам).
Такого рода ситуационные вопросы полезны ТОЛЬКО в том случае, если вы имеете дело с редкой, уникальной и специфической частью (обычно устаревшей) технологии, в которой кандидат предложил обладать набором навыков. Задавать вопросы только с одним решением или с циклом дыра, превращающая вопрос в ловушку, не поможет вам оценить, насколько умен кандидат. Кандидата это раздражает, а вы производите впечатление крайне высокомерного человека. Это буквально привратник в ИТ-индустрии.
Если ваш ответ на это: «Все, кто работал в сфере технологий, должны это знать». вы являетесь частью проблемы, как и любой вопрос, который вы задаете. Если вы слышите это на собеседовании, это огромный красный флаг.
Телеграфировать чувства на собеседовании — плохая идея
При собеседовании с кандидатом вы никогда не должны давать какую-либо обратную связь во время собеседования. Это изменит настроение кандидата и изменит его реакцию на вас. Нервным собеседникам будет трудно отвечать на вопросы, и если они думают, что вы ищете что-то конкретное, они попытаются дать вам ответ, который, по их мнению, вы хотите получить на работу. Это плохо, потому что не дает вам возможности должным образом провести собеседование с кандидатом.
Один из самых верных способов рассказать кандидату, как у него дела на собеседовании, — это сказать ему, какой ответ «правильный» (я использую этот термин в широком смысле). Сообщение кандидату о том, что он вряд ли получит работу, в лучшем случае бессознательно заставит его работать хуже, а в худшем — намеренно заставит его уйти. То, что кто-то сделал бы это на собеседовании, показывает, что ему не хватает навыков работы с людьми, необходимых для оценки кандидатов с самого начала.
Что должно было произойти
В этом случае, если предположить, что ваш ответ был технически правильным (и, возможно, интервьюер обоснованно полагал, что это не так), он должен был задать дополнительные вопросы. «Почему вы выбрали такой подход?» «Какие преимущества дает это решение, чего нет у других решений?» «Какова потенциальная слабость этого подхода?»
Если действительно есть только один правильный ответ, ответ следует представить, а не спрашивать, а затем вопрос следует сформулировать следующим образом: «Какие проблемы вы видите с этим подходом и какой подход вы бы выбрали вместо этого?»
Однако, как я упоминал ранее, это требует от кандидата отстраниться от своего каверзного вопроса «попался», который он придумал сам, и большинству людей трудно это сделать.
Пример на практике
Недавно во время собеседования я задал кому-то вопрос (Как бы вы переименовали файл в Git?). На этот вопрос есть много ответов, и ни один из них не является правильным или неправильным по своей сути, но некоторые из них имеют больше преимуществ, чем другие (использование команды перемещения в Git сохраняет историю, прикрепленную к этому файлу, по сравнению с переименованием файла и его повторной фиксацией). Этот вопрос был разработан, чтобы выявить уровень квалификации человека, проходящего собеседование в компании. Опытный пользователь поймет связанные с этим тонкости, а кто-то на более среднем этапе не поймет недостатки подхода, который они выбрали.
Когда кандидат ответил «неправильным» (для целей этого разговора) ответом, я затем спросил их о ловушке их решения по сравнению с другим (в этом случае «Вы потеряете историю файла если бы вы сделали это, не так ли?»).
Это не говорит им, что такое правильный ответ или что они обязательно ошиблись, просто расширяет разговор, чтобы сообщить мне, как они думают о проблеме, которая, как другие ответы лучше намекают и объясняются, является целью интервью:
Цель собеседования - оценить уровень навыков кандидатов, чтобы оценить, могут ли они выполнять описанные обязанности.
Gotcha Вопросы не должны применяться.
git mv
«сохранения истории» точно так же. Вы можете подумать о git log --follow
том, что необходимо для просмотра истории переименованного файла по переименованиям (даже если вы используете git mv
). Если этот вопрос был разработан, чтобы выявить навыки кандидатов, убедитесь, что вы понимаете его, иначе вы станете интервьюером, на которого жалуется OP. Вы можете проверить это, создав файл с текстом, переместив его с и без git mv
и увидев, что оба «теряют историю» с git log -- file
, но «сохраняют историю», если вы используете git log --follow -- file
.Это случилось со мной однажды во время интервью с компанией FAANG. Я был очень расстроен. Однако на самом деле оно того не стоит. Считается непрофессиональным поведением связываться с кем-либо, участвующим в процессе найма, кроме вашего рекрутера напрямую, если не указано иное, по любой причине, и в этом случае это выглядит как спор и граничит с запугиванием (даже если вы правы).
Пройдя обучение по собеседованию FAANG (в компании FAANG), интервьюерам (по крайней мере, в этих компаниях) специально говорят не предвзято относиться к одному или небольшому подмножеству «приемлемых» ответов и честно слушать все, что говорит кандидат. ; как и вы, иногда ответ, данный кандидатом, правильный, но не ожидаемый. Однако, к сожалению, как и в моей ситуации, иногда интервьюеры не соблюдают эту подготовку. Хреново, но бывает.
Если вы чувствуете себя очень расстроенным из-за этого, вы можете рассказать об этом своему рекрутеру. Маловероятно, что они сделают что-нибудь, чтобы помочь вам, но это возможно, и это не повредит.
Примечательно, что еще один момент в тренинге по собеседованию FAANG, который я проходил, заключается в том, что тот факт, дает ли кандидат рабочий ответ, на самом деле не так важен, как вы думаете. Я бы сказал, что 20% вашей «оценки» за собеседование (как она есть) зависит от того, правильный ли ваш ответ на самом деле. Важнее то, как вы подошли к проблеме. Вы задавали уточняющие вопросы и/или высказывали свои предположения? Вы разбили проблему на части или просто пытались решить все сразу? Когда интервьюер давал вам намеки и направляющие комментарии, применяли ли вы их и реагировали ли они так, как ожидал интервьюер? Эти вещи гораздо важнее (по крайней мере, в компании, где я обучался собеседованию), чем то, действительно ли вы получили «правильный» ответ.
Нет:
Я придумал решение и объяснил его ему, но он имел в виду другое решение и не принял мое решение, даже если я логически обосновал свой подход.
Вы можете написать ему по электронной почте, если хотите, но если вы это сделаете, я рекомендую вам указать временную и пространственную сложность желаемого вами подхода по сравнению с временной и пространственной сложностью предложенного им подхода.
Я не говорю, что ваше выступление на собеседовании должно быть идеальным. Это не обязательно, но если вы собираетесь возразить и, возможно, написать интервьюеру по электронной почте о потенциальной ошибке, которую он совершил, вы действительно должны быть уверены, что ваше решение является наиболее оптимальным как с точки зрения эффективности времени, так и с точки зрения космической эффективности.
После интервью я подтвердил, что решение, которое я придумал, вполне приемлемо и является одним из многих решений.
Сомневаюсь. Чтобы дать вам пример, взгляните на то, что сделал этот человек:
Он нашел ответ на HackerRank и подумал, что его решение вполне подходит для задачи на собеседовании по кодированию , которую кто-то опубликовал.
Его ответ: https://codereview.stackexchange.com/a/212530/7219
Оригинальный вопрос: https://codereview.stackexchange.com/questions/212492/bracket-matcher-in-python
К сожалению, он не осознавал, что одна и та же проблема может иметь множество небольших вариаций и что решение, которое он нашел, могло быть оптимальным для проблемы, которую он нашел на HackerRank, но уж точно не было оптимальным для задачи собеседования по программированию, которую должен был решить ОП. решать.
Пожалуйста, не будь тем парнем.
По сей день он не понимает, что сделал не так, и все еще отрицает это, несмотря на то, что два старших инженера указали ему на его ошибку.
Килиси
станри
WernerCD
Джек
WernerCD
Джеффри
Джакомо1968