Так вышло, что наша компания искала разработчиков. В работе мы используем стандартный набор веб-технологий: HTML, CSS, Javascript, PHP, SQL. Во время проведения собеседований я был не то чтобы расстроен, а скорее обескуражен. Вопросы, на которые не могли ответить кандидаты, а именно разработчики с тремя и более годами опыта, были тривиальными. Они практически не касались специфики фреймворков или сложных алгоритмов, это просто скрининговые вопросы на знание языка и программирования в целом.
Не задачи, подчеркну, именно вопросы. От соискателей никто не требовал написать на доске программу для парсинга обратной польской нотации. Более того, не требовалось даже давать какие-то академические определения — просто как-то объяснить что такое Х и для чего его можно применять.
Особо меня впечатлили навыки JS и я бы хотел предоставить вашему вниманию список вопросов, которые вызывали затруднение у опытных разработчиков.
Я обычно задавал этот вопрос в качестве разогрева, чтобы дать понять кандидату, что жести не будет. Однако же кандидата это отнюдь не успокаивало… Люди реально не понимают зачем вообще эти все тонкости. Для многих let и var равносильны, просто var устарело. У большинства кандидатов вызывал полное непонимание вопрос «со звёздочкой», почему в «константном» массиве можно изменять значения элементов а в «константной» строке нельзя изменять текст.
Разные вариации на тему того, как повлияет выполнение функции на переданные в неё аргументы разных типов. Достаточно понимать разницу в передаче по ссылке и по значению. Легко запомнить, что массивы и объекты передаются по ссылке. Как правило, проблем незнание этой особенности не создаёт, просто приводит к написанию неэффективного кода. Зато, уж если проблемы появляются, то устранять их оказывается очень сложно.
Известная особенность языка, например:
С одной стороны рождает массу способов выстрелить в ногу себе и ни в чём неповинным коллегам, с другой позволяет писать лаконичный код.
Надо заметить что === избавляет от большинства таких проблем, но сильно усложняет код в некоторых ситуациях. С учётом того, что JS это всё-таки язык логики интерфейсов, пытаться писать на нём сложные вычисления как минимум странно. Разумным кажется использовать язык именно по назначению, а не пытаться с маниакальным упорством побороть его кажущиеся недостатки чтобы применять в финансовых расчётах или умном доме.
Отдельно хочу уточнить, что вопросы были не надуманные ребусы, а вполне рабочие ситуации вида 'Abc' > 'abc' или 0.1 + 0.2 == 0.3
Большинство разработчиков как правило понимают эту концепцию, но далеко не все. Обычно проблемы возникают на вложенных функциях.
Что выведется в консоль? А если так?
По каким-то таинственным причинам, многих людей ставят в тупик вопросы на знание таких конструкций. Единственное моё предположение заключается в том, что они просто не работали с достаточно низким уровнем языка и использовали исключительно фреймворки и библиотеки. Как можно не знать базовый for я вообще не представляю, однако же встречался и такой самородок.
Как правило, for (… in ..), for (… of ..) требуются для написания обходов сложных структур и сборки данных из нескольких разнотипных источников.
Тоже весьма страный случай. Хотя в современных фреймворках обработку исключений напрямую проводить практически не приходится, но знать принцип работы механизма исключений крайне важно. Это базовый синтаксис языка и, зачастую, необходимое средство написания нужного алгоритма.
Базовый функционал, на котором строится большинство типовых операций с массивами. Сохранение копии исходных данных, сортировка таблицы, фильтрация результата, поиск по пунктам меню, форматирование… Мало кто может себе позволить их не знать, но как правило только из-за применения Underscore или другого специфичного инструмента.
Нормальным я считаю помнить сигнатуру первых трёх из них и знать что гуглить, чтобы найти остальные.
К сожалению, сейчас это жизненно важное знание. Типовой проект устроен в виде API, данные из которого подтягиваются во фронт через запросы. Такая архитектура позволяет практически полностью отвязать фронт от бэка, но в замен заставляет строить кучу логики на промисах. Вопросы были несложными, например как гарантировать выполнение запроса B только после успешного выполнения запроса A.
Это были вопросы с собеседования мидла с зарплатой в районе 2к$ на руки. На них не могли ответить соискатели с годами опыта. Что же пошло не так?..
Я бы не хотел показаться излишне заносчивым или высокомерным. Я не выдумывал абстрактных задач с нелепыми требованиями, брал только практические вещи, с которыми сталкиваешься постоянно. Более того, Javascript соискатели указывали своим ключевым навыком и указывали в резюме годы опыта, то есть должны были отвечать с лёгким недоумением — когда же начнутся сложные вопросы?
Многие из нас просто невероятно самоуверены. Не скрою я и сам весьма самодовольный тип, хотя меня легко подловить на какой-то специфичной теме, например я давно забыл как использовать Canvas и не смогу из головы написать код для проксирования объекта. Однако, незнание базового синтаксиса языка нельзя объяснить никак. Вообще. Ну просто нельзя быть разработчиком не зная язык.
В JS около 20 реально применяемых ключевых слов(мало кто применяет в реальных задачах экзотику типа void или with). Это на вечер изучения.
Не указывайте JS своей специализацией если вы не можете дать ответы на простые вопросы по синтаксису языка. Будьте себе на здоровье Seneor React Developer или Fellow Angular Evangelist, но не утверждайте, пожалуйста, что вы знаете Javascript.
Не задачи, подчеркну, именно вопросы. От соискателей никто не требовал написать на доске программу для парсинга обратной польской нотации. Более того, не требовалось даже давать какие-то академические определения — просто как-то объяснить что такое Х и для чего его можно применять.
Особо меня впечатлили навыки JS и я бы хотел предоставить вашему вниманию список вопросов, которые вызывали затруднение у опытных разработчиков.
Вопросы
Ключевые слова объявления переменных (var, let, const)
Я обычно задавал этот вопрос в качестве разогрева, чтобы дать понять кандидату, что жести не будет. Однако же кандидата это отнюдь не успокаивало… Люди реально не понимают зачем вообще эти все тонкости. Для многих let и var равносильны, просто var устарело. У большинства кандидатов вызывал полное непонимание вопрос «со звёздочкой», почему в «константном» массиве можно изменять значения элементов а в «константной» строке нельзя изменять текст.
Поведение разных типов данных при передаче их в качестве аргументов функции
Разные вариации на тему того, как повлияет выполнение функции на переданные в неё аргументы разных типов. Достаточно понимать разницу в передаче по ссылке и по значению. Легко запомнить, что массивы и объекты передаются по ссылке. Как правило, проблем незнание этой особенности не создаёт, просто приводит к написанию неэффективного кода. Зато, уж если проблемы появляются, то устранять их оказывается очень сложно.
Преобразование и сравнение разных типов данных
Известная особенность языка, например:
(0 == "0") == (0 == "")
("123" == " 123 ") != (123 == " 123 ")
С одной стороны рождает массу способов выстрелить в ногу себе и ни в чём неповинным коллегам, с другой позволяет писать лаконичный код.
Надо заметить что === избавляет от большинства таких проблем, но сильно усложняет код в некоторых ситуациях. С учётом того, что JS это всё-таки язык логики интерфейсов, пытаться писать на нём сложные вычисления как минимум странно. Разумным кажется использовать язык именно по назначению, а не пытаться с маниакальным упорством побороть его кажущиеся недостатки чтобы применять в финансовых расчётах или умном доме.
Отдельно хочу уточнить, что вопросы были не надуманные ребусы, а вполне рабочие ситуации вида 'Abc' > 'abc' или 0.1 + 0.2 == 0.3
Замыкания и this
Большинство разработчиков как правило понимают эту концепцию, но далеко не все. Обычно проблемы возникают на вложенных функциях.
function a(){
this.counter = 1;
function b(){
this.counter = 2;
}
b();
console.log(this.counter);
}
a();Что выведется в консоль? А если так?
const b = {a: a};
b.a();for(.., .., ..), for (… in ..), for (… of ..)
По каким-то таинственным причинам, многих людей ставят в тупик вопросы на знание таких конструкций. Единственное моё предположение заключается в том, что они просто не работали с достаточно низким уровнем языка и использовали исключительно фреймворки и библиотеки. Как можно не знать базовый for я вообще не представляю, однако же встречался и такой самородок.
Как правило, for (… in ..), for (… of ..) требуются для написания обходов сложных структур и сборки данных из нескольких разнотипных источников.
Обработка исключений (try, catch, finally, throw)
Тоже весьма страный случай. Хотя в современных фреймворках обработку исключений напрямую проводить практически не приходится, но знать принцип работы механизма исключений крайне важно. Это базовый синтаксис языка и, зачастую, необходимое средство написания нужного алгоритма.
Методы работы с массивами — map, reduce, forEach, filter, every, some, indexOf, includes, splice
Базовый функционал, на котором строится большинство типовых операций с массивами. Сохранение копии исходных данных, сортировка таблицы, фильтрация результата, поиск по пунктам меню, форматирование… Мало кто может себе позволить их не знать, но как правило только из-за применения Underscore или другого специфичного инструмента.
Нормальным я считаю помнить сигнатуру первых трёх из них и знать что гуглить, чтобы найти остальные.
Асинхронное/синхронное выполнение кода
К сожалению, сейчас это жизненно важное знание. Типовой проект устроен в виде API, данные из которого подтягиваются во фронт через запросы. Такая архитектура позволяет практически полностью отвязать фронт от бэка, но в замен заставляет строить кучу логики на промисах. Вопросы были несложными, например как гарантировать выполнение запроса B только после успешного выполнения запроса A.
Заключение
Это были вопросы с собеседования мидла с зарплатой в районе 2к$ на руки. На них не могли ответить соискатели с годами опыта. Что же пошло не так?..
Я бы не хотел показаться излишне заносчивым или высокомерным. Я не выдумывал абстрактных задач с нелепыми требованиями, брал только практические вещи, с которыми сталкиваешься постоянно. Более того, Javascript соискатели указывали своим ключевым навыком и указывали в резюме годы опыта, то есть должны были отвечать с лёгким недоумением — когда же начнутся сложные вопросы?
Многие из нас просто невероятно самоуверены. Не скрою я и сам весьма самодовольный тип, хотя меня легко подловить на какой-то специфичной теме, например я давно забыл как использовать Canvas и не смогу из головы написать код для проксирования объекта. Однако, незнание базового синтаксиса языка нельзя объяснить никак. Вообще. Ну просто нельзя быть разработчиком не зная язык.
В JS около 20 реально применяемых ключевых слов(мало кто применяет в реальных задачах экзотику типа void или with). Это на вечер изучения.
Не указывайте JS своей специализацией если вы не можете дать ответы на простые вопросы по синтаксису языка. Будьте себе на здоровье Seneor React Developer или Fellow Angular Evangelist, но не утверждайте, пожалуйста, что вы знаете Javascript.
