Программисты не могут написать алгоритмы без помощи: ещё раз про интервью
Его поддержали многочисленные коллеги:
Эта тема, которая периодически поднимается на разных площадках, как нельзя кстати легла на мой собственный опыт: на этой неделе и паре прошлых я прошёл несколько технических интервью в компаниях, и вопрос о том, как готовиться, является сейчас самым важным для меня.
Не секрет, довольно часто интервьюеры спрашивают т.н. Основы языка (в моём случае, это JavaScript), которые в том числе включают в себя алгоритмы. И тут любой нормальный (вокруг этого определения возможна дискуссия, но я настаиваю именно на нормальности, без кавычек) инженер сталкивается с двумя трудностями. Только сначала маленькое пояснение к «нормальности»: обычный разработчик обязан использовать в коммерческой разработке передовые технические решения, принятые в его области. Например, лучшие алгоритмы. Однако обязан ли рядовой, нормальный программист помнить конкретные реализации лучших алгоритмов в коде, это вопрос.
Итак, две трудности:
1) Зачастую на интервью перед тобой лист бумаги и карандаш. Либо доска и маркер. В реальной разработке мы пользуемся многочисленными инструментами, снимающими некоторые рутинные задачи: например, выполняющими автодополнение кода. И поэтому, к тому же учитывая несколько стрессовую обстановку на собеседовании, с лёту написать правильный, синтаксически верный код не всегда удаётся.
2) Вторая трудность является следствием фундаментальной особенности цифровой эры. Поясню на маленьком примере.
Последние пару лет я изучаю китайский язык. Основная трудность в изучении китайского — запомнить написание слов, выраженных иероглифами. В отличие от европейских, привычных нам алфавитных языков, в китайском, даже если ты хорошо помнишь произношение слова, это вряд ли поможет тебе вспомнить его точное написание. Делу помогают современные электронные помощники — приложения для телефона, вводя в которые фонетическую запись слова на латинице (пхинь инь), можно быстро получить искомые иероглифы.
Периодически я думаю, как люди обходились раньше. Ведь в лучшем случае нужно было каждый раз лезть в толстый словарь, чтобы подсмотреть правильное написание искомого слова. Это предъявляло совершенно другие требования к способности запоминать иероглифы, времени на их повторение при изучении и так далее.
Короче, если говорить грубо, часть функций нашего мозга невольно выносится во внешние интерфейсы. Нет, не сама память, но, скажем так, хэш-таблица к ней, по которой мы можем быстро восстановить все те многочисленные знания, которые получаем во всё убыстряющемся потоке профессиональной жизни.
Ровно о же самое можно сказать и о знаниях в программировании. Положа руку на сердце, каждый может признаться: он рано или поздно подзабывает какие-то вещи, принятые относить к Основам. Например, любой хороший курс по JavaScript включает себя понятие ООП, раскрытие темы наследования, создания «классов» и так далее. Однако в современных проектах, особенно основанных на фреймворках, программист напрямую использует ООП-парадигмы в написании своего кода не так часто. Не так часто, как спрашивают ООП на интервью при приёме на работу (а его любят спрашивать практически всегда). Естественно, возникают коллизии между тем, что есть на самом деле, и тем, что ты, как тебе кажется, твёрдо запомнил (и успешно забыл).
Другими словами, успешно работающий программист, который знает где и как быстро восстановить знания по текущей теме, выдающий каждый день код и даже способный на решение весьма нетривильных задач (например, придумать RoR), на интервью вдруг с треском проваливается, мыча что-то не очень внятное, глядя на, казалось бы, «детскую» задачу. Тогда вопрос —, а что на самом деле определяет такое интервью?
По этой теме у буржуев, кстати, есть исследования. Например, вот это: blog.interviewing.io/you-cant-fix-diversity-in-tech-without-fixing-the-technical-interview
Вывод: «там не всё так однозначно». Конечно же, любой нормальный наниматель в первую очередь желает видеть перед собой человека, знающего элементарные вещи. Поскольку вся наша культура является прежде всего письменной культурой, наниматель в праве требовать, чтобы свои знания кандидат мог изложить на бумаге. Однако с программированием (и, вероятно, с некоторыми другими областями напряжённого умственного труда) всё очевиднее простой факт: человек уже не в состоянии воспроизвести все свои знания без специальных ключиков, подсказок. Скорее на интервью было бы продуктивнее предлагать соискателю решать ту или иную практическую задачу, интегрально оценивая его способности и умения находить решение, а не только вспоминать отдельные куски кода.
По материалам theoutline.com/post/1166/programmers-are-confessing-their-coding-sins-to-protest-a-broken-job-interview-process,
русский перевод частично здесь: tproger.ru/news/programmers-are-confessing-their-sins-to-protest-against-whiteboard-interview
Комментарии (4)
4 марта 2017 в 01:27
0↑
↓
На собеседованиях не требую синтаксической правильности, сразу говорю, что пишите псевдокод похожий на целевой язык. И не требую проверки всех граничных условий. Но прошу назвать некоторые, которые кодом не предусмотрены. В общем, относитесь к людям так, как хотите, чтобы они относились к вам. Гуглом пользоваться запрещаю.4 марта 2017 в 02:04
–1↑
↓
даже способный на решение весьма нетривильных задач (например, придумать RoR), на интервью вдруг с треском проваливается, мыча что-то не очень внятное, глядя на, казалось бы, «детскую» задачу
Я в это не верю, а DHH, мне кажется, просто троллит тупых, но очень самонадеянных «программистов на рельсах».
LexS007
4 марта 2017 в 05:19 (комментарий был изменён)
0↑
↓
Специалист умеет пользоваться всеми доступными инструментами для решения задачи. Что плохого в поиске описания алгоритма? Все же знать нереально. Ну на счет пузырка он, скорее всего, просто преувеличил)
4 марта 2017 в 05:42
0↑
↓
Умею писать алгоритмы на листе так как учился в такие времена и таких местах что даже олимпиада по программированию проходила на листочках с карандашем)) Первые свои программы на С++ писал в тетрадке
