Техническое интервью и навыки программиста [закрыто]

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

У меня только что было собеседование с крупной технологической фирмой на стажировку, где мне задавали много типичных вопросов, ориентированных на алгоритмы. Теперь, учитывая мое прошлое, я считаю себя сильным в алгоритмах (у меня также есть хорошие оценки в алгоритмах уровня выпускника - материал с NP-полнотой и выше (аппроксимация и рандомизированные алгоритмы), но, к сожалению, я провалил интервью. Я не смог Подумайте об очень эффективном методе решения струнной проблемы примерно за ~ 10 минут. Когда интервью закончилось, у меня был стакан воды, я съел банан и немного расслабился и попытался снова. И вот! Ответ, который я мог бы получить менее чем за 5 минут. И самое худшее из всего - я был на самом деле на этом треке, и интервьюер намекнул на это, но слишком сильное давление приготовило меня. Весь мой опыт заставил меня задуматься о технических интервью. У меня были некоторые вопросы, и я хотел задать их на этом форуме -

1. Разве можно за полчаса судить о чьих-то технических способностях? Честно? Или это просто бросок костей?

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

3. Люди, которые выходят с летающими красками в этом интервью, становятся великими программистами? Они продолжают разрабатывать изящные игровые движки, графические библиотеки, писать быстрые фреймворки с форк-объединением? Есть ли какие-либо доказательства, указывающие на положительную взаимосвязь между успехами в технических интервью и фактическими способностями программирования? Или эти интервью в большей степени направлены на то, чтобы найти человека, который «добивается цели» (Спольский)?

Могу поспорить, что многие академики, публикующие новаторские идеи - ICML, VLDB, Mobicom, - проваливают эти интервью. Но я могу заверить вас, что они одни из самых умных людей, которых вы найдете на этой планете.

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

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

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

Имейте в виду, что...

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

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

Разве можно за полчаса судить о чьих-то технических способностях?

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

Измеряют ли технические вопросы интервью способность решать проблемы?

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

Люди, которые выходят с летающими красками в этом интервью, становятся великими программистами? Или эти интервью в большей степени направлены на то, чтобы найти человека, который «добивается цели» (Спольский)?

Вот и все. Величие редко. Я счастлив найти кого-то компетентного.

1. Да. Да честно. Это не значит, что 30 минут достаточно, чтобы получить полную картину того, на что способен человек. Работа интервьюера состоит в том, чтобы сделать все возможное, чтобы понять, кто является интервьюируемым и что они могут сделать. Найти людей, которые поместили в свое резюме что-то, чего они на самом деле не знали, просто. Точно выяснить, что может сделать собеседник, включая все его навыки и сильные стороны, - нет.

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

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

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

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

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

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

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

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

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

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

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

Что касается ваших вопросов:

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

2. Смотрите № 1. Часть шума происходит от различий в том, видели ли люди проблему раньше.

3. Смотрите № 1. Вероятно, существует небольшая положительная корреляция между этими тестами и становлением великим программистом.

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