Рассекая просторы vc.ru, уже несколько раз натыкался на материалы о найме программистов и не без интереса читал их, ведь я сам программист, и мне любопытно было узнать, как нас оценивают на собеседованиях.
Мои впечатления? Я в печали... Почти все материалы, на мой взгляд, напоминают «вредные советы».
В особенности «порадовала» последняя прочитанная статья: «25 классических вопросов, которые HR-ы задают программистам на собеседованиях» ( ссылка ), после прочтения которой и возникло желание написать данный материал.
Сразу оговорюсь, вся статья — это сугубо личное мнение, однако нашедшее поддержку в лице друзей и коллег программистов.
Итак...
Первая встреча, собеседование без тех специалиста
HR-ы, не обманывайте себя. Вы никогда не поймёте на сколько хорош программист…
Разве что только когда сможете воткнуть электроды ему в ухо и запустить end-to-end теститрование. Но пока таких технологий нет, всё что Вы можете оценить — это адекватность и, хотя бы отчасти, мотивацию человека сидящего перед Вами.
И поверьте, этого достаточно.
Ведь Ваша задача найти человека, который сможет влиться в коллектив, плодотворно в нём работать и чтобы его работа вознаграждалась тем способом, который он ожидает, и который может обеспечить Ваша компания(деньги, признание, интересные проекты и т.д.).
Все попытки спрашивать какие то технические нюансы будут выглядеть неуместно и беспомощно. Лично меня очень сильно раздражает, когда меня спрашиваю о том, в чем сами не разбираются. Хочется просто встать и уйти.
Что ещё можно спросить на первом этапе? Зависит от специфики вакансии.
Если Вам нужен опытный человек — спрашивайте об опыте, узнавайте какие задачи он решал, какие трудности преодолевал.
Если Вам нужен человек, которого можно обучить, дайте ему пару логических задачек, проверьте живость ума.
Собранной на первом этапе информации хватит чтобы отсеять 80% - 90% кандидатов.
Часть вторая. Собеседование с тех специалистом
НЕ НАДО СПРАШИВАТЬ ТЕОРИЮ!
Пожалуйста, великие гуру найма и технари, любящие спрашивать теорию, объясните мне в комментариях в чем смысл Ваших вопросов?
По моему, если ответ на Ваш вопрос лежит по первой ссылке в гугле, то спрашивать его не имеет смысла. Разве что Вы ищите человека на закрытый объект, где нет доступа в интернет. Но в остальных случая — Я считаю теоретические вопросы пустой тратой времени, которая ничем Вам, как работодателю, не поможет.
Я лично знаю несколько человек, которые учились со мной на программистов. У них от зубов отскакивали все теоретические выкладки, но когда дело доходило до реального программирования — ничего путного они сделать не могли.
Также негодование вызывают вопросы, которые возможно и касаются будущей работы, но разобраться в которых не составляет труда. Например «юнит-тесты». Чтобы научиться писать юнит-тесты уйдёт от силы минут 10.
Прошу обратить внимание, более сложные тесты уже относятся к вопросам об опыте, о которых далее.
Что же, по моему, нужно спрашивать у кандидата?
Спрашивайте технические нюансы из их предыдущего опыта, особенно те, которые пересекаются с будущей работой.
По тому, как человек рассказывает, будет понятно:
- Реально ли он разбирается в вопросе или просто придумал эти пункты для набивания себе цены.
- На сколько его опыт и знания подходят для текущей вакансии.
- Сможет ли он справиться с будущей работой.
- Сможет ли он научиться, если не имеет подобного опыта.
И, как мне кажется, этого достаточно, чтобы сделать финальный выбор.
Больше о человеке Вы сможете узнать только на испытательном сроке.
Для дискуссий приглашаю в комментарии.
Надеюсь данный материал будет хоть кому-то полезен, спасибо за внимание.
Автор очень ловко подменяет тезис "бездумно задавать вопросы по теории из топчика поисковой выдачи - отстой" на "теория не нужна".
Не уверен, специально или из-за непонимания разницы.
Можно ли писать код и деливерить в прод без знаний теории CS? Можно. И можно даже при этом выдавать оптимальное решение имеющихся задач в определенном проценте случаев.
Проблема только в том, что без понимания того, как работает используемый тобой код и платформа ты не можешь оценить ни оптимальность этого решения, ни возможные проблемы\последствия его использования.
Суровая правда такова, что понимание принципов работы целевой платформы и используемых инструментов довольно сильно увеличивает понимание того, что будет происходить с твоим кодом после того, как ты нажмешь кнопочку Run в своей модненькой IDE.
Это понимание позволяет избегать в долгосрочной перспективе довольно многих проблем, которые ты, конечно, потом решил бы (с помощью гугла и стэковерфлоу).
Но избежать проблем - значительно лучше, чем их решить.
Понимание структур данных, алгоритмов и всяких там паттернов-хуяттернов очень хорошо помогает декомпозировать задачи на логические компоненты и видеть разные варианты решения оных.
Значит ли это, что на работку надо брать только олимпиадников? Нет, не значит.
Это значит, что люди задумывающиеся о том, как их код будет работать будут писать код более вдумчиво, чем люди, которые "скомпилировалось - значит работает".
Ну и дальше по накатанной, вплоть до "тесты можно научиться писать за 10 минут".
кек.
Понимание структур данных, алгоритмов и всяких там паттернов-хуяттернов очень хорошо помогает декомпозировать задачи на логические компоненты и видеть разные варианты решения оных.
Живой пример, сколько раз на практике у Вас такое происходило?
Абстрактно можно говорить много и долго. Живые примеры показывайте, обосновывайте свою точку зрения.
Я свою могу обосновать и подкрепить примером.
Простите, но их всех ваших ответов я вынес только одно: до серьезных задач вы еще не добирались.
Если хотите простой пример, то проведите эксперимент: за сколько времени вы сможете реализовать ukkonen's algorithm (ссылка на описание первая же в гугле).
Искал применение этого алгоритма в жизни. Вот что нашёл:
Первая, и возможно самая распространённая, практическая задача, связанная с суффиксными деревьями, это нахождение включения одной строки в текст.Зачем мне тратить время на реализацию этого алгоритма, если есть готовые модули реализующие данный функционал?
Простите, но их всех ваших ответов я вынес только одно: до серьезных задач вы еще не добирались.Серьезных задач реализации которых уже есть в огромных количествах? Нет, мне такое не интересно. Хотите делать велосипеды, Ваше право.
Если говорить о моей точки зрения - не знание ядра линукса не мешает мне его эффективно использовать.
Вы видимо от конечного бизнеса далеко и уж тем более от найма персонала, очередной диванный аналитик, который свои 5 копеек хочет вставить.
А как вы можете оценить эффективность использования ядра линукса, если не знаете, что именно вы используете и как оно работает?
Какие метрики и критерии эффективности вы используете?