Почему собеседования с инженерами SW непропорционально трудны (по сравнению с научными собеседованиями)? [закрыто]

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

Мое наблюдение: собеседования на работу с SW-специалистами гораздо сложнее, чем собеседования с CS-исследователями, но работа для исследователей более оплачиваемая, более конкурентоспособная, более полезная, более интересная и имеет более высокий потенциал.

Вот типичный цикл интервью для исследователя:

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

Вот типичный цикл интервью для инженера SW:

• Телефонное интервью, где мне задают вопросы об алгоритме и, возможно, я занимаюсь кодированием Довольно стандартный.
• Личные собеседования на доске, где они изучают F *** из вас по эзотерическим мелочам C ++ (например, как работает вызов полиморфной виртуальной функции), алгоритмам (заставляют алгоритм всех пар кратчайшего пути работать для вершин 1B) проектирование системы (разработка балансировщика нагрузки базы данных) и т. д. Это продолжается шесть или семь интервью. Смешной.

Зачем кому-то с этим мириться? Какой смысл спрашивать о пустяках C ++ или писать код, чтобы доказать себя? Почему бы не сделать интервью SE больше похожим на интервью исследователя, где вы рассказываете о том, что вы сделали?

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

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

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

Выходить на конечности здесь.

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

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

Задумайтесь об этом на мгновение.

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

У меня такие вопросы: «Почему так сложно получить докторскую степень?» И "Зачем мне доктор философии, чтобы быть исследователем CS?" "Почему так много барьеров и препятствий?"

Зачем кому-то с этим мириться?

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

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

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

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

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

Вместо этого нам все равно, потому что нам нужно знать, как быстро вы можете выучить фундаментальные вещи. Вы претендуете на X лет опыта? Хорошо, мы зададим сложные вопросы, чтобы выяснить, есть ли у вас твердые знания.

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

Вы заявляете о своем X-летнем опыте «разработки, отладки и исправления кода C ++» и не можете объяснить простыми словами, как указатель указывает на объект? Извините, мы не можем нанять вас - если вы не можете сделать это, как вы объясните более сложные проблемы, когда нам нужно принимать сложные технические решения?

Короткий ответ: на рынке есть множество людей, которые утверждают, что знают программирование, но не умеют программировать.

Дополнительное замечание: я удивлен, что никто не разместил ссылку на эссе FizzBuzz .

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

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

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

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

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

Я разработчик программного обеспечения (c / c ++) с более чем 20-летним опытом работы в этой области. Типы интервью, которые мы обычно видим сейчас (дразнилки мозга, реализации структур данных, алгоритмы поиска и т. Д. На доске), обычно не проводились, за исключением новичков. Если человек работал в уважаемой компании в течение разумного периода времени, это считалось доказательством его способности писать код. Теперь это стало очень школьным, и я не уверен почему. Действительно, типичные вещи, которые они просят вас написать, МОГУТ запомнить, поэтому выполнение этого на доске действительно ничего не доказывает. В рабочем проекте вы будете использовать Интернет для исследования чего-либо, и вы не будете писать btrees или связанные списки с нуля.

Я думаю, что это еще одно увлечение менеджмента - точно так же, как scrum - с этим, вероятно, началось Google, Amazon и Microsoft. Все остальные копировали точно так же, как они делали с Джеком Уэлчем и званием ... помните GE?

Если вы, менеджер по найму, читаете мои комментарии, вы ДОЛЖНЫ спрашивать кандидатов, КАК они будут решать определенные проблемы. Вместо того, чтобы просить их кодировать хеш-таблицу, предложите им проблему с хеш-таблицей и спросите, как они ее решат.

Я также согласен с разработчиком над этим постом, который сказал: «Дайте им реальную проблему, которую должна была решить компания»!

«Но я склонен бомбить вопросы ООП / Наследование. Почему? Потому что, как только была добавлена ​​поддержка шаблонов, я почти полностью использовал C ++ для общего программирования».

Я также согласен с вышеизложенным. Когда ты работаешь на компанию, ты пишешь код ИХ способом. Я до сих пор испытываю трудности, когда вспоминаю синтаксис вызовов C ++ по ссылкам из головы, потому что старший архитектор в компании, в которой я работал 15 лет, предпочитал использовать указатели, а не ссылки. Видите ли, он был старым программистом на Си. Так вот что мы все использовали.

Опять же, техническое интервьюирование является произвольным и капризным.

Есть большая разница между тем, чтобы жарить человека на мелочах, и видеть, знают ли они их CS. Как я уже говорил выше, я имею более чем десятилетний опыт работы с C ++, но я склонен бомбить вопросы ООП / Наследования. Зачем? Поскольку, как только была добавлена ​​поддержка шаблонов, я использовал C ++ почти исключительно для общего программирования .

Я взял интервью у нескольких компаний BigHouseHoldNameTech в районе Бэй и в Сиэтле, и одно из лучших интервью касалось реальных вопросов, с которыми им приходилось сталкиваться на работе, включая структуры данных и алгоритмы [то есть: у вас есть 300 миллиардов точек данных состоящий из XYZ. Как эффективно хранить и искать? ].

Это в значительной степени позволяет вам узнать, как кандидат может вмешаться и помочь решить реальные проблемы, с которыми вы сталкиваетесь. Абсолютно хуже было и с другой компанией BigHouseHoldNameTech, но они задали часы невероятно таинственных вопросов, которые вы действительно должны просто посмотреть в руководстве [ то есть описать основные различия между печатной платой в Windows и Linux - и это не было ' т для позиции уровня ядра ]

Хедж-фонды причудливы с их намерением пытать ... ожидайте 8 часов решения проблем типа ранца на доске.