Дэвид Хэнссон, создатель Ruby on Rails, признался в своём твиттере, что не написал бы сортировку пузырьком на доске. Дэвид подсматривает код в интернете всё время:
Его поддержали многочисленные коллеги:
Эта тема, которая периодически поднимается на разных площадках, как нельзя кстати легла на мой собственный опыт: на этой неделе и паре прошлых я прошёл несколько технических интервью в компаниях, и вопрос о том, как готовиться, является сейчас самым важным для меня.
Не секрет, довольно часто интервьюеры спрашивают т.н. Основы языка (в моём случае, это JavaScript), которые в том числе включают в себя алгоритмы. И тут любой нормальный (вокруг этого определения возможна дискуссия, но я настаиваю именно на нормальности, без кавычек) инженер сталкивается с двумя трудностями. Только сначала маленькое пояснение к «нормальности»: обычный разработчик обязан использовать в коммерческой разработке передовые технические решения, принятые в его области. Например, лучшие алгоритмы. Однако обязан ли рядовой, нормальный программист помнить конкретные реализации лучших алгоритмов в коде, это вопрос.
Итак, две трудности:
1) Зачастую на интервью перед тобой лист бумаги и карандаш. Либо доска и маркер. В реальной разработке мы пользуемся многочисленными инструментами, снимающими некоторые рутинные задачи: например, выполняющими автодополнение кода. И поэтому, к тому же учитывая несколько стрессовую обстановку на собеседовании, с лёту написать правильный, синтаксически верный код не всегда удаётся.
2) Вторая трудность является следствием фундаментальной особенности цифровой эры. Поясню на маленьком примере.
Последние пару лет я изучаю китайский язык. Основная трудность в изучении китайского — запомнить написание слов, выраженных иероглифами. В отличие от европейских, привычных нам алфавитных языков, в китайском, даже если ты хорошо помнишь произношение слова, это вряд ли поможет тебе вспомнить его точное написание. Делу помогают современные электронные помощники — приложения для телефона, вводя в которые фонетическую запись слова на латинице (пхинь инь), можно быстро получить искомые иероглифы.
Периодически я думаю, как люди обходились раньше. Ведь в лучшем случае нужно было каждый раз лезть в толстый словарь, чтобы подсмотреть правильное написание искомого слова. Это предъявляло совершенно другие требования к способности запоминать иероглифы, времени на их повторение при изучении и так далее.
Короче, если говорить грубо, часть функций нашего мозга невольно выносится во внешние интерфейсы. Нет, не сама память, но, скажем так, хэш-таблица к ней, по которой мы можем быстро восстановить все те многочисленные знания, которые получаем во всё убыстряющемся потоке профессиональной жизни.
Ровно о же самое можно сказать и о знаниях в программировании. Положа руку на сердце, каждый может признаться: он рано или поздно подзабывает какие-то вещи, принятые относить к Основам. Например, любой хороший курс по JavaScript включает себя понятие ООП, раскрытие темы наследования, создания «классов» и так далее. Однако в современных проектах, особенно основанных на фреймворках, программист напрямую использует ООП-парадигмы в написании своего кода не так часто. Не так част��, как спрашивают ООП на интервью при приёме на работу (а его любят спрашивать практически всегда). Естественно, возникают коллизии между тем, что есть на самом деле, и тем, что ты, как тебе кажется, твёрдо запомнил (и успешно забыл).
Другими словами, успешно работающий программист, который знает где и как быстро восстановить знания по текущей теме, выдающий каждый день код и даже способный на решение весьма нетривильных задач (например, придумать RoR), на интервью вдруг с треском проваливается, мыча что-то не очень внятное, глядя на, казалось бы, «детскую» задачу. Тогда вопрос — а что на самом деле определяет такое интервью?
По этой теме у буржуев, кстати, есть исследования. Например, вот это.
Вывод: «там не всё так однозначно». Конечно же, любой нормальный наниматель в первую очередь желает видеть перед собой человека, знающего элементарные вещи. Поскольку вся наша культура является прежде всего письменной культурой, наниматель в праве требовать, чтобы свои знания кандидат мог изложить на бумаге. Однако с программированием (и, вероятно, с некоторыми другими областями напряжённого умственного труда) всё очевиднее простой факт: человек уже не в состоянии воспроизвести все свои знания без специальных ключиков, подсказок. Скорее на интервью было бы продуктивнее предлагать соискателю решать ту или иную практическую задачу, интегрально оценивая его способности и умения находить решение, а не только вспоминать отдельные куски кода.
По материалам статьи, русский перевод частично здесь.
Его поддержали многочисленные коллеги:
Эта тема, которая периодически поднимается на разных площадках, как нельзя кстати легла на мой собственный опыт: на этой неделе и паре прошлых я прошёл несколько технических интервью в компаниях, и вопрос о том, как готовиться, является сейчас самым важным для меня.
Не секрет, довольно часто интервьюеры спрашивают т.н. Основы языка (в моём случае, это JavaScript), которые в том числе включают в себя алгоритмы. И тут любой нормальный (вокруг этого определения возможна дискуссия, но я настаиваю именно на нормальности, без кавычек) инженер сталкивается с двумя трудностями. Только сначала маленькое пояснение к «нормальности»: обычный разработчик обязан использовать в коммерческой разработке передовые технические решения, принятые в его области. Например, лучшие алгоритмы. Однако обязан ли рядовой, нормальный программист помнить конкретные реализации лучших алгоритмов в коде, это вопрос.
Итак, две трудности:
1) Зачастую на интервью перед тобой лист бумаги и карандаш. Либо доска и маркер. В реальной разработке мы пользуемся многочисленными инструментами, снимающими некоторые рутинные задачи: например, выполняющими автодополнение кода. И поэтому, к тому же учитывая несколько стрессовую обстановку на собеседовании, с лёту написать правильный, синтаксически верный код не всегда удаётся.
2) Вторая трудность является следствием фундаментальной особенности цифровой эры. Поясню на маленьком примере.
Последние пару лет я изучаю китайский язык. Основная трудность в изучении китайского — запомнить написание слов, выраженных иероглифами. В отличие от европейских, привычных нам алфавитных языков, в китайском, даже если ты хорошо помнишь произношение слова, это вряд ли поможет тебе вспомнить его точное написание. Делу помогают современные электронные помощники — приложения для телефона, вводя в которые фонетическую запись слова на латинице (пхинь инь), можно быстро получить искомые иероглифы.
Периодически я думаю, как люди обходились раньше. Ведь в лучшем случае нужно было каждый раз лезть в толстый словарь, чтобы подсмотреть правильное написание искомого слова. Это предъявляло совершенно другие требования к способности запоминать иероглифы, времени на их повторение при изучении и так далее.
Короче, если говорить грубо, часть функций нашего мозга невольно выносится во внешние интерфейсы. Нет, не сама память, но, скажем так, хэш-таблица к ней, по которой мы можем быстро восстановить все те многочисленные знания, которые получаем во всё убыстряющемся потоке профессиональной жизни.
Ровно о же самое можно сказать и о знаниях в программировании. Положа руку на сердце, каждый может признаться: он рано или поздно подзабывает какие-то вещи, принятые относить к Основам. Например, любой хороший курс по JavaScript включает себя понятие ООП, раскрытие темы наследования, создания «классов» и так далее. Однако в современных проектах, особенно основанных на фреймворках, программист напрямую использует ООП-парадигмы в написании своего кода не так часто. Не так част��, как спрашивают ООП на интервью при приёме на работу (а его любят спрашивать практически всегда). Естественно, возникают коллизии между тем, что есть на самом деле, и тем, что ты, как тебе кажется, твёрдо запомнил (и успешно забыл).
Другими словами, успешно работающий программист, который знает где и как быстро восстановить знания по текущей теме, выдающий каждый день код и даже способный на решение весьма нетривильных задач (например, придумать RoR), на интервью вдруг с треском проваливается, мыча что-то не очень внятное, глядя на, казалось бы, «детскую» задачу. Тогда вопрос — а что на самом деле определяет такое интервью?
По этой теме у буржуев, кстати, есть исследования. Например, вот это.
Вывод: «там не всё так однозначно». Конечно же, любой нормальный наниматель в первую очередь желает видеть перед собой человека, знающего элементарные вещи. Поскольку вся наша культура является прежде всего письменной культурой, наниматель в праве требовать, чтобы свои знания кандидат мог изложить на бумаге. Однако с программированием (и, вероятно, с некоторыми другими областями напряжённого умственного труда) всё очевиднее простой факт: человек уже не в состоянии воспроизвести все свои знания без специальных ключиков, подсказок. Скорее на интервью было бы продуктивнее предлагать соискателю решать ту или иную практическую задачу, интегрально оценивая его способности и умения находить решение, а не только вспоминать отдельные куски кода.
По материалам статьи, русский перевод частично здесь.
