После негативной реакции хабровчан на мою прошлую заметку про собеседование программистов, пришлось хорошенько порефлексировать, чтобы переосмыслить и скорректировать некоторые свои представления о программировании, программистах и себе. Да и, кроме откуда-то взявшейся заносчивости, неработающих примеров (не протестил — не деплой, ага), я совершенно не выразил того, что изначально хотел: главное — это умение писать код, решающий задачу.
За прошедшее время обязанность участвовать в технических собеседованиях разработчиков от меня никуда не делась. Формат собеседования остался прежним: это работа с кодом в онлайн-блокноте, но задач осталось всего две и они стали намного проще.
Вот пример одной из них:
/* Простое число — целое положительное число, имеющее только два делителя: 1 и само себя */
function isPrimeNumber(number) {
/* необходимо реализовать функцию, возвращающую true в случае, если number является простым числом и false в противном случае */
}
Вынесенный в заголовок этой статьи вопрос отнюдь не риторический и обязан своим появлением страстям, которые крутятся вокруг этой задачи на собеседованиях.
Немного вводных данных: мы ищем фуллстеков, пишущих на JavaScript/TypeScript. Спектр задач, в зависимости от пожеланий самого разработчика, может быть очень широким: от разработки биллинговой системы, до десктоп-приложения для рисования на скриншотах и загрузки в облако. Соответственно, базовые знания математики (плюс-минус, разделить-умножить, найти среднее арифметическое, максимум-минимум в ряде) нужны, равно как и умение решать прикладные задачи, решения которых может и не быть на stackoverflow. По резюме мы отбираем кандидатов уровня не ниже middle, с соответствующим опытом работы. Разработка — совсем не профильный вид деятельности компании, поэтому нам трудно привлечь мощных разрабов и таких кандидатов очень мало.
Задача, подобная этой, должна была стать примитивным фильтром, показывающим, что собеседник умеет создавать алгоритмы. Знание каких-либо конкретных алгоритмов не требуется. Вычислительная сложность решения не особо важна, главное — задачу нужно решить.
Помню как я первый раз удивился, когда парень с трёхлетним опытом работы в крупных проектах, сказал что для решения этой задачи нужен какой-то «алгоритмист». И он объяснил почему: у него опыт разработки сервисов, где, в основном, работаешь с данными из базы, очередями — получаешь/передаёшь, вот это вот всё. Тогда я и задумался, что современное программирование — это, наверное, больше про опыт работы с RabbitMQ, MongoDB, чем про вычисление/нахождение чего-то.
Часто кандидаты говорят «я не математик», «у меня с математикой не очень». Первое время я терялся и не знал что ответить, потому что я не вижу тут математики, это задача на поиск. Да и трудно ожидать таких слов от программиста, метящего на зарплату в тысячи долларов. Теперь-то я предлагаю кандидатам поразмышлять: «поскольку любое положительное целое число делится без остатка на единицу и само себя, достаточно найти хотя бы ещё одно число, на которое аргумент можно поделить нацело и вернуть false, а если не нашли, то вернуть true». Но и это не всегда помогает.
Понимаю, что в это может быть трудно поверить, но я хочу сказать, что написанное мной правда и представляет в моей работе определённую проблему. Добавлю, что такие случаи актуальны для программистов с небольшим опытом работы (до пяти лет). Я предполагаю, что этому есть несколько причин:
1. Клиповое мышление
Современное клиповое мышление как-то отразилось на программировании и новоиспечённым разработчикам проще (а может и интереснее) искать решения даже простейших задач на stackoverflow, из-за чего способность «придумывать» алгоритм для решения задачи не прокачивается даже с годами.
Не знаю как происходит процесс программирования у других, может, теперь действительно принято обращаться к stackoverflow не тогда, когда ты не можешь что-то решить, а сразу же, без самой попытки решения? Ни в коем случае не говорю, что это плохой подход, вероятно даже хороший: за счёт такой мемоизации решений, в перспективе, можно создать ИИ, который по ответам на stackoverflow будет кодить без участия человека.
2. Простота и массовость языка
Я уверен, что если бы мы искали Си-разработчика, то такой проблемы не было бы. Но случая проверить эту гипотезу пока не представилось.
Тренд «войти в айти», куча онлайн школ с программами аля «Интенсив по Python», «Стань React-разработчиком за месяц» породили массу людей, которых в программировании изначально привлекала оплата (возможно, только она) труда. Но и эти разработчики очень востребованы. Например, фронтендеров появляется сейчас очень много, но их всё равно не хватает: без работы не останется никто, главное уметь в React. Нужны ли тут алгоритмы? Я скажу «да, конечно», и, вероятно, ошибусь.
Раньше программирование изучали из любопытства и за годы до того, как оно начинало приносить программисту деньги. Многие так и не начали этим зарабатывать, программируя для себя, но работая по смежным специальностям. А теперь программированию учат с гарантией трудоустройства и пост-оплатой за курсы с первой зарплаты. И я только за, как человек заинтересованный в полной комплектации команды, в которой я работаю.
Но, как программист, я не понимаю, почему задача из школьного курса информатики способна вызвать затруднения у дипломированных профессионалов.
Возможно, в наших требованиях к кандидату что-то не то. Может, нам действительно не нужно, чтобы разработчик умел придумывать решение задачи, и такое требование — это старпёрство. Мне уже начинает так казаться.
Я работаю в одном помещении с инженерами, занимающимися интеграцией, поддержкой облачной инфраструктуры. Сегодня я пожаловался коллегам на эту проблему и они тоже удивились. Удивились и сказали как бы они решили эту задачу, причём разговор сразу пошёл про оптимизацию вычислений. Это не профессиональные программисты, возможно, последний раз они прогали что-то ещё в институте, но они умеют составлять алгоритмы для решения задачи.
Aquahawk
Чем больше на рынке людей кто не умет в математику и алгоритмы, тем больше платят тем кто умеет.
Grigorenkovic
Больше востребованы и больше платят — совсем разные вещи
Calm12
Но ведь спрос и ограниченность предложения должны поднимать стоимость.
arheops
Да, они поднимают стоимость тому человеку, который найдет нужного.
YuriiSig
>>Вычислительная сложность решения не особо важна, главное — задачу нужно решить.
Еще лет 10 назад, когда работали русскоязычные сайты Intel'а (конкретно — Intel MKL), я предлагал 10000$ за разработку алгоритма трехдиагонализации вещественных симметричных упакованных матриц, который в разы (сейчас в 2 раза, а тогда почти в 3 раза) был бы быстрей соответствующего алгоритма из пакета Intel MKL. Но никто за эту задачу не взялся, хотя мне удалось ее решить, но его я не публиковал (по причине, указанной ниже). Хотя Intel MKL воспользовался моей статьей (Ю. Ф. Сиголаев, Б. И. Ионин, О модификации алгоритмов диагонализации, связанных с квантовохимическими расчетами. Журнал общей химии. – 2010. – 80, № 11. – С. 1928-1929.) для улучшения другого алгоритма, связанного с диагонализацией, при этом на меня не сославшись. После этого отпало всякое желание что-либо публиковать. А теперь вопрос: а кто умеет? Ведь Intel MKL рекламирует свой продукт как лучший в мире в части, касающейся алгоритмов линейной алгебры.
nikolayv81
У Интел есть разработчики а есть "продавцы" разработчики разрабатывают как могут (и на самом деле нет уверенности что ваш алгоритм в общем случае даёт лучший с т.з. целей библиотеки результат), но их задача разработать "комплексное решение" и вполне возможно что если один из их крупных клиентов укажет на проблему производительности именно в этом месте они для их частного случая (а может, если повезёт и для всех) доработают алгоритм, но сумма с риска должна быть такой, чтобы выдернуть специалистов из других задач и это не 10000 и вероятно даже не 100000$.
Есть пример к примеру Oracle, который отдаёт индивидуальные патчи крупным клиентам, но не всем а только тем кто пожаловался на конкретную проблему и дело тут в том что патчи могут создать больше проблем у основной массы потребителей.