Рассекая просторы vc.ru, уже несколько раз натыкался на материалы о найме программистов и не без интереса читал их, ведь я сам программист, и мне любопытно было узнать, как нас оценивают на собеседованиях.
Мои впечатления? Я в печали... Почти все материалы, на мой взгляд, напоминают «вредные советы».
В особенности «порадовала» последняя прочитанная статья: «25 классических вопросов, которые HR-ы задают программистам на собеседованиях» ( ссылка ), после прочтения которой и возникло желание написать данный материал.
Сразу оговорюсь, вся статья — это сугубо личное мнение, однако нашедшее поддержку в лице друзей и коллег программистов.
Итак...
Первая встреча, собеседование без тех специалиста
HR-ы, не обманывайте себя. Вы никогда не поймёте на сколько хорош программист…
Разве что только когда сможете воткнуть электроды ему в ухо и запустить end-to-end теститрование. Но пока таких технологий нет, всё что Вы можете оценить — это адекватность и, хотя бы отчасти, мотивацию человека сидящего перед Вами.
И поверьте, этого достаточно.
Ведь Ваша задача найти человека, который сможет влиться в коллектив, плодотворно в нём работать и чтобы его работа вознаграждалась тем способом, который он ожидает, и который может обеспечить Ваша компания(деньги, признание, интересные проекты и т.д.).
Все попытки спрашивать какие то технические нюансы будут выглядеть неуместно и беспомощно. Лично меня очень сильно раздражает, когда меня спрашиваю о том, в чем сами не разбираются. Хочется просто встать и уйти.
Что ещё можно спросить на первом этапе? Зависит от специфики вакансии.
Если Вам нужен опытный человек — спрашивайте об опыте, узнавайте какие задачи он решал, какие трудности преодолевал.
Если Вам нужен человек, которого можно обучить, дайте ему пару логических задачек, проверьте живость ума.
Собранной на первом этапе информации хватит чтобы отсеять 80% - 90% кандидатов.
Часть вторая. Собеседование с тех специалистом
НЕ НАДО СПРАШИВАТЬ ТЕОРИЮ!
Пожалуйста, великие гуру найма и технари, любящие спрашивать теорию, объясните мне в комментариях в чем смысл Ваших вопросов?
По моему, если ответ на Ваш вопрос лежит по первой ссылке в гугле, то спрашивать его не имеет смысла. Разве что Вы ищите человека на закрытый объект, где нет доступа в интернет. Но в остальных случая — Я считаю теоретические вопросы пустой тратой времени, которая ничем Вам, как работодателю, не поможет.
Я лично знаю несколько человек, которые учились со мной на программистов. У них от зубов отскакивали все теоретические выкладки, но когда дело доходило до реального программирования — ничего путного они сделать не могли.
Также негодование вызывают вопросы, которые возможно и касаются будущей работы, но разобраться в которых не составляет труда. Например «юнит-тесты». Чтобы научиться писать юнит-тесты уйдёт от силы минут 10.
Прошу обратить внимание, более сложные тесты уже относятся к вопросам об опыте, о которых далее.
Что же, по моему, нужно спрашивать у кандидата?
Спрашивайте технические нюансы из их предыдущего опыта, особенно те, которые пересекаются с будущей работой.
По тому, как человек рассказывает, будет понятно:
- Реально ли он разбирается в вопросе или просто придумал эти пункты для набивания себе цены.
- На сколько его опыт и знания подходят для текущей вакансии.
- Сможет ли он справиться с будущей работой.
- Сможет ли он научиться, если не имеет подобного опыта.
И, как мне кажется, этого достаточно, чтобы сделать финальный выбор.
Больше о человеке Вы сможете узнать только на испытательном сроке.
Для дискуссий приглашаю в комментарии.
Надеюсь данный материал будет хоть кому-то полезен, спасибо за внимание.
Комментарий удален модератором
Мудаком будет уже априори из-за написания велосипеда.
Комментарий удален модератором
Golang используют активно в гугле. Сомневаюсь что они пишут что-то отличное от
https://golang.org/pkg/sort/
Комментарий удален модератором
Если бы у гугла всё падало из-за криворукости отдельного кодера, то его бы уже давно не существовало.
Есть тесты от юнит до end-toend, есть DevOps, есть CI/CD, dev и test сервера, есть всякие докера с кубернетсами. Там при всём желании трудно будет всё положить разом.
откуда такая инфа?
уверен что пишут. нет одного алгоритма подходящего на все случаи жизни. от размера массиа, потребности в устойчивости, уровня упорядоченности входных данных, размера элемента и особенно ключа, возможности использовать много ядер и т.д. - зависит конкретный оптимальный алгоритм
Невероятно, правда? Особенно при том, что и сам язык и библиотечную реализацию сделал разработчик из Гугла.
а вы бы такой на собесодовании - ИЗИ! - sort($array);
Ну как минимум std::sort.
Для остальных алгоритмов сортировки есть 100500 библиотек покрытых тестами и проверенных на продах.
Это если речь о сортировке идет.
А вдруг они хотел проверить твою алгоритмическое решение, а не знание api языков
Достаточно на собеседовании спросить про отличия и преимущества известных соискателю методов сортировки.
Как вы заебали с этой сортировкой. Ни разу за 5 лет разработки сначала под мобайл, потом бэкенд мне не потребовалась никакая сортировка, кроме стандартной дотнетовской linq. Ну знаю я, что есть пузырьковая, быстрая, вставкой и ещё какие-то, но хули толку от этого? Важнее для современной разработки знать лучшие практики типа DI, mvc, mvvm и т.п., чем всю эту шелуху, которая при надобности гуглится и изучается за 5 минут.
Про сортировку начали писать противники теоретических вопросов. Речь изначально была про теорию в целом. Вопросы DI, MVC, MVVM это тоже теория. Например, мало кто понимает, что такое DI и приравнивает концепцию к DI container. С MVC тоже не все просто, мало кто может правильно распределить код между M, V и C, и на практике получаются толстые контроллеры или вью с логикой модели.
Про сортировку в этом обсуждении вроде бы первым написал я, но я не противник теоретических вопросов. Я противник упрощенного подхода к интервью, при котором человек или целиком уходит в дроч кандидата по теории, или же забивает на теорию целиком, потому что главное чтобы человек был хороший.
Выше по треду юноша с пламенным взором написал что все, кто пишут не идеальные алгоритмы - мудаки. Ну хорошо, проверим мы, что человек знает теорию графов, пишет все кейсы удаления из красно-черного дерева на доске по памяти, и может долго рассуждать о плюсах и минусах разных классификаторов в задачах машинного обучения. Возьмем его на работу, и поймем, что это неадекват, который уходит в себя на месяц и выжимает все до последней капли производительности на задаче, которую можно написать не идеально за неделю, и она будет покрывать 99% случаев (и даже в этой ситуации клиенты будут на нас молиться, потому что до этой автоматизации они вообще все руками делали).
Человека нужно оценивать в комплексе, если он просто дрочит на паттерны-алгоритмы-архитектуры и вообще не интересуется как это все ложится на продукт и в каких условиях это будет использоваться - нафиг такой человек нужен.
Это вроде бы очевидно. Человек должен быть не только специалистом, но и адекватным, уметь работать в коллективе и т.д - обычные человеческие качества. Но это никак не относится к значимости знания теории. При этом нужно понимать, что в разных специализациях нужно спрашивать про разную теория. Где-то важно ручное управление памятью, а где-то это в принципе невозможно, а гораздо важнее читаемость и, например, отсутствие лапши из колбэков.
Да вот не всегда очевидно, к сожалению. Видал я людей, которые искренне считают, что то, что они отлично знают теорию сразу же делает их желанными в глазах любого работодателя, а необходимость иногда написать неоптимальное решение вызывала у них ярость, потому что как же так, они же не про своевременное решение задач пользователей, они про то, чтобы писать абстрактные алгоритмы в вакууме.
Ну на собеседованиях реально о сортировках спрашивают... В чём и заключается весь абсурд. Начитаются всяких "25 классических вопросов, которые HR-ы задают программистам на собеседованиях" и начинают...
Но ведь это не проблема вопросов про теорию в целом, а проблема выбора правильных вопросов.
Воооот, вот она боль коллег по цеху.
Разработал такой крутой портал с микросервисами, блокчейном и ш#юхами, приходишь на собеседование, а тебя про сортировки спрашивают...
Это как?
Ну например golos.io - блокчейн блог платформа.
Я не знаю как это работает, но если там нет пиров, то и блокчейн там бесполезен. А если есть, то это не портал, а просто веб-клиент.
Давайте не будем холиварить по поводу блокчейна =) У меня есть статейка на хабре про алгоритмы консенсуса, можем там подискутировать, оживим так сказать тему.
Где вы тут холивар увидели? Вы привели странный пример на странное заявление.
Странные примеры на странные заявления - это и есть черта холивара :D
А они утверждают что полезен. Кто прав?
А, то есть вы просто верите их словам? Ок, тогда я лучше не буду влезать.
При чем тут Я? Я всего лишь привел пример.
Ваше второе предложение отвечает на первое. Вы привели пример - вы за него отвечаете.
И правильно делают.
Олимпиадников Вам в команду =)
Их тут хватает, всё хорошо.
Чтоб в ограниченных условиях выбрать наиболее эффективный алгоритм.
Ну за 5 лет в энтерпрайзе и стартапах у меня не возникло такой потребности. У вас она часто возникает? Именно когда сортировка из стандартной библиотеки не подходит.
постоянно. грубо говоря, алгоритм сжатия - это как раз моя реализация всяких сортировк, хешей и т.п., и от того что и как я для этого конкретного алгоритма реализую, зависит весь конечный результат
ну и выбор идёт скажем так: hashtable c hash chains - 10 обращений к памяти при lookup. вычёркиваем. кукушка - 2 обращения. уже лучше. робин гуд - одно, но реализовать гораздо сложнее. берём!!!
А можно ссылку на ваш алгоритм? Статья есть? Правда интересно.
сжатие: https://web.archive.org/web/20170205090944/http://freearc.org:80/Research.aspx
здесь были и статьи но часть из них протухла
Рид-Соломон: https://github.com/Bulat-Ziganshin/FastECC/blob/master/ReedSolomonFFT-ru.md
это ссылка на статю
Сортировка: https://cs.stackexchange.com/questions/93563/fast-stable-almost-in-place-radix-and-merge-sorts
это тоже по сути статья
а у тебя её спрашивают? я вот собственный алгоритм сортировки разработал, свой алгоритм рида-соломона, кучу алгоритмов сжатия. а вот твоих аббревиатур не знаю. каждому своё :)
А это не вопрос про теорию?
Я лично за вопросы про теорию, но против вопросов реализации.
Соискателю достаточно знать о минусах и плюсах того или иного способа решения задачи.
ИМХО, вопрос реализации самый важный. В случае словесного обсуждения можно заучить ключевые слова, и пройти собеседование как "китайская комната". В случае вопросов реализации можно увидеть :
- понимает ли человек концепцию
- каковы его навыки реализации теоретических концепций в коде
- каковы его навыки написания кода в целом
А вдруг нет? Меня вот на быстрый тест попросили сделать вроде сортировки и выдачи неповторяющихся символов, я за 5 минут написал .distinct()+.sort(), и собеседующий возрадовался:"сколько мне тут циклов лепили, сколько строк бесполезного кода писали!". Не угадаешь.
есть такая порфессия - писать эти алгоритмы. не всем дано быть кодерами )))