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

40

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

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

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

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

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

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

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

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

stackoverflowuser2010
источник
12
Я собираюсь сделать дикое предположение и сказать, что вы дали интервью в Google?
Пемдас,
2
@ Этель: Если вы посмотрите на glassdoor.com, где люди публикуют свои зарплаты анонимно, вы можете видеть, что должность исследователя платит примерно на 10–20 тыс. Долл. США в год больше, чем сопоставимый инженер ПО (то же место, то же поле). Как ни странно, я знаю, что моя зарплата примерно на 25 тысяч долларов в год больше, чем у других моих друзей, которые закончили со степенью магистра в области CS из моей аспирантуры примерно в то же время. И это не только зарплата; Я видел, что у кандидатов наук более высокие карьерные траектории, чем у тех, у кого нет. У меня нет прямых доказательств, но я видел, что докторов наук легче нанимать на уровни CTO / VP.
stackoverflowuser2010
3
Это безумие, но, очевидно, не распространяется на «настоящие» инженерные профессии. Я знаю тонну инженеров-строителей, и они шокированы тем, что я рассказал им о некоторых из моих прошлых интервью ... многие говорили только то, что вы сделали: "почему вы с этим мирились?"
красная грязь
3
@el fuser - Это зависит от работодателя. Все собеседования по электротехнике, которые у меня были, либо попросили меня посмотреть код ПЛК, написать код ПЛК и / или сделать что-нибудь с электрическими схемами. На первом вопрос был: «Что такое закон Ома?» Это был эквивалент теста fizzbuzz ... если вы только что взяли 4 года электротехники и не можете сделать это правильно, собеседование окончено.
Скотт Уитлок
1
Скотт: «Если вы только что взяли 4 года электротехники и не можете сделать это правильно, собеседование окончено». Я боюсь, что, возможно, завалил пару из них, потому что я смеялся или был оскорблен. Я думаю, исходя из исследовательской среды, вы принимаете базовые знания как должное.
Омега Центавра

Ответы:

45

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

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

Уайетт Барнетт
источник
2
К счастью, такие вещи, как github и bitbucket, помогают увидеть, что сделал этот человек. это может облегчить (или значительно уменьшить) необходимость задавать вопросы должной осмотрительности.
Привет,
3
точно в точку. очень трудно отделить добро от подражателей-программистов. даже с кодом, который нужно показать, потребуется много времени, чтобы прочитать и понять его до уровня, позволяющего судить об авторе. исследовательские работы, OTOH, написаны для читателей, самое большее, всего несколько часов, чтобы действительно понять одну, обычно плохую можно узнать за несколько минут.
Хавьер
3
Код для показа - хитрость. Откуда вы знаете, что Джо Интервью на самом деле написал этот код, если не заставить его написать код?
Уайетт Барнетт
У меня есть опубликованная статья и книга в пути. Обычно технические экраны замыкаются накоротко, потому что мои знания хорошо задокументированы, они хотят убедиться, что я - тот Майк Браун
Майкл Браун,
1
Кроме того, технические менеджеры боятся нанимать по-настоящему умных и опытных специалистов - тех, кто может знать что-то лучше, чем они, и поэтому может спорить за и против решения, а не просто как роботы для написания кода. В конечном итоге, найм кого-то, кто может перевернуть связанный список за минуту вместо найма действительно умных инженеров, - это потеря всех тех, кто получает финансовую прибыль от продукта. Как сказал Бьярн Страуструп: «В организации, которая рассматривает своих программистов как дебилов, скоро появятся программисты, которые хотят и могут действовать только как дебилы».
Лев Хейнсаар
30

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

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

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

Райан Микела
источник
17

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

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

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

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

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

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

С. Лотт
источник
Я понимаю, что вы говорите. Правильный вид собеседования должен соответствовать правильной работе? Это правильная интерпретация?
stackoverflowuser2010
5
@ stackoverflowuser2010: Нет. Я просто жалуюсь, что академический мир намного сложнее, чем мир разработки программного обеспечения. Вы получили интервью как SE. Я не мог даже войти в дверь в академии. Ваша точка зрения настолько искажена, что вы не видите различий. Академия намного, намного сложнее.
S.Lott
6

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

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

Скотт Уитлок
источник
4
+1 Фактически, деньги, потраченные на исследования, оправданы опубликованными работами, поэтому, если у кандидата есть хороший список тех из прошлого, есть вероятность, что он (-ы) может произвести еще немного, что, скорее всего, удовлетворит любого, кто окажется проверка, на что был потрачен исследовательский грант.
Петер Тёрёк
@ Петер Тёрёк: Да !!! Фонды, которые предоставляют гранты, затем должны подать отчет, и главное, на что они обращают внимание - это количество опубликованных работ.
sharptooth
5

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

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

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

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

Sharptooth
источник
Это справедливо, но вы применяете достаточно широкую сеть, когда выполняете технический компонент или концентрируетесь на определенной области?
rjzii
@Rob Z: Мы пытаемся задать очень простые вопросы о C ++ - в основном, об указателях и рекурсии, мы предоставляем фрагменты, содержащие около пяти строк хорошо отформатированного кода, и спрашиваем, что и как они делают. Конечно , мы не всегда спрашивать о нескольких виртуальных наследовании и порядке базовых классов инициализации в случае виртуального наследования.
sharptooth
Почему вопросы виртуальных функций так популярны? Иногда кажется, что это все, что нужно изучать ...
Jé Queue
@Xepoch: я думаю, потому что они очень просты, и знание их внутренней работы хорошо показывает, заботишься ли ты, что происходит внутри, или просто вставляешь строки кода вместе.
sharptooth
Я думаю, что мне повезло в моей карьере. Редко я когда-либо видел кодер для вырезания и вставки. Я знал плохих практиков (включая меня), но, по крайней мере, это был их собственный дизайн :)
Jé Queue
5

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

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

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

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

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

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

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

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

rjzii
источник
3

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

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

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

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

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

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

гость
источник
2

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

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

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

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

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

красно-грязь
источник