- PVSM.RU - https://www.pvsm.ru -
Прочитав этот пост [1], написанный farwayer [2], сначала хотел просто оставить комментарий, но, подумав пару десятков минут, решил, что тема глубокая, и мне есть что сказать на целый пост. Все таки, с одной стороны, я один из тех, кто на собеседованиях не смотрит на код и кого разочаровывает незнание оценки сложности поиска по индексу в реляционных СУБД, с другой, считаю, что могу дать понимание того, как мыслит достаточно большой кластер интервьюверов, зачем они поступают (на первый взгляд) нелогично и деструктивно, и какие проблемы сами хотят этим решить. Есть надежда, что понимание картины мира «врага» само по себе ответит на множество вопросов.
Для начала расскажу о себе. Надеюсь, что это лучше поможет осознать описанное ниже. В разработке ПО 9 лет, некоторое время работал на себя (создавал биржевых роботов и торговал на собственные деньги), основное время был наемным разработчиком (в том числе lead developer). С недавнего времени занимаю продуктовую должность. Собрал 2 команды senior уровня. Провел несколько десятков (хотя и меньше 100) технических собеседований на позиции middle2senior, senior, lead. В аутсорсе не работал ни дня за всю жизнь провел 18 дней. Поэтому, могу сказать, что весь опыт связан с продуктом (собственным или нанимателя), и все собеседования проводил с мотивацией «найти человека, который принесет максимальную пользу продукту». Признаю, что опыт автора исходной статьи больше моего, но цель, — не рассказать, как правильно, или дать совет, как надо поступать, а рассказать, как можно на те же вещи посмотреть с другой, альтернативной, и не факт, что правильной, точки зрения.
Поехали по пунктам (названия взяты из оригинального поста).
Прежде всего вопрос в том, а что такое хороший код и какие ожидания от кода, который производит опытный программист. Для меня хороший код — это функция от задачи, условий, в которых эта задача поставлена, принятых в команде (компании) гайдлайнов, ожиданий техлида (архитектора), менеджера по продукту, лид QA. К примеру, рассмотрим несколько задач:
Согласитесь, что неправильно оценивать код, закрывающий все эти задачи по одним лекалам. А ведь, от хорошего программиста в продуктовой разработке часто ожидают эффективного решения всех вышеупомянутых задач. Практика показывает, что эффективность программиста во всех этих кейсах проще определить кейсовыми вопросами и обсуждением опыта, чем рассматриванием кода, написанного при неизвестных для интервьювера переменных. Плюс, код, который собеседуемый хочет показать != код, который он пишет, решая коммерческие задачи.
Отлично пониманию негодование, связанное с
А то, что поиск по B-tree индексам в PostgreSQL имеет логарифмическую сложность? Я вчера узнал, вот теперь и вы
Но что с другой стороны? Баги, связанные с алгоритмической сложностью, одни из самых неприятных для бизнеса. Они не покрываются юнит тестами (O(N^2) при тестовом запуске, где N=10, это реально быстро), они не покрываются автоматическими, интеграционными, регрессионными и ручными тестами по той же причине. Они не всплывают на dbe, uat, sit (ведь для N=1000 это все еще быстро). Они могут ждать своего часа годами, не напоминая о себе, пока один покупатель не добавит себе в корзину 250 продуктов, или пока не появится клиент брокерской компании, решивший собрать себе HFT-робота на коленке. Но, когда они проявляются, поплохеть может всему бизнесу.
Сюда же относятся и вопросы про ACID. Баги, связанные с блокировками в СУБД, race condition, транзакциями в СУБД, — это тоже самая мякотка для бизнеса. Они точно так же, как и баги, связанные с алгоритмической сложностью, могут сидеть тихо годами и ударить очень больно. Когда основная оперативная СУБД компании, развернутая на монструозном сервере с максимальным резервированием всего, просто останавливается с нулевой нагрузкой на CPU и IO в момент максимальной активности клиентов, поверьте, это крайне неприятно и, да, это может стоить годовой зарплаты команды программистов. Поэтому, знать наизусть каждую букву ACID не нужно (по крайней мере, я никогда не спрашиваю знания расшифровки аббревиатур да и сам не помню их наизусть), но вот незнание сути каждой из букв — это уже серьезная заявка на внедрение в код подобных багов. Если программистов с таким незнанием в команде двое, то code review тоже не станет лечением.
А тут вот это. И ребята вроде адекватные. Фиг пойми. А потом видишь, что вакансия полгода открытой висит. Ну-ну.
То, что на сайте компании (или на аггрегаторе вакансий) доступна вакансия, не означает, что компания ищет одного человека в одну команду. Реальность продуктовых компаний в период роста — это вечный кадровый голод. Или масштабируешься, захватываешь рынок, выдавливаешь конкурентов, или умираешь. И у менеджера по продукту вечная головная боль — «что выкинуть». Не «а чего бы крутого такого придумать, чтобы 100 программистов загрузить на месяцок, чтобы не скучали», а что бы из крутого, нужного, запланированного и ожидаемого (и обещанного) клиентами выкинуть из планов, чтобы не затянуть очередной релиз на год. Поэтому, нет лишних рук, и тот факт, что вакансия полгода висит, не отменяет факта, что 10 человек по ней уже нашли и взяли на работу, и с удовольствием возьмут еще столько же. Снова таки, не везде и не всегда, но описанная мною ситуация нормальна и допустима для продуктовой разработки.
Я всегда спрашиваю. Так что, тут полностью согласен с автором. Но точка зрения части тех, кто не спрашивает, мне ясна тоже. Эти люди часто не понимают, как сравнивать разный опыт различных кандидатов между собой. Ответы на закрытые вопросы им сравнивать проще.
Тут есть важный момент. Что, да, опытный и сообразительный разраб быстро вникает. Но если уж человек заявляет что много работал с условным OAuth на нескольких проектах (важно, именно так, а не «как-то разок использовал в прототипе»), а интервьювер тоже работал с OAuth, то почему бы и не поспрашивать? Глубина ответов покажет, насколько человек будет глубоко вникать в новые, встретившиеся на пути технологии, понимает ли подкапотные принципы, или копирует с SO, пытается ли предвосхитить грабли.
Но и тут можно выкрутиться, дав небольшое тестовое на час-два (только не на месте: для многих собеседование это всё-таки стресс).
Тут могут быть разные мысли на этот счет, но лично я считаю тестовое задание оскорбительным даже для middle уровня. Все таки, тестовое задание, — это очень сильная диспропорция по затраченному времени компании и соискателя. Условно, соискатель тратит 3 часа на написание кода + еще 5 на вылизывание и поиск лучших практик в гугле, а представитель компании за 1 минуту дает вердикт. Для этого соискателю нужна мотивация. Поэтому, хорошая практика, но не для оценки опытных и востребованных программистов, которых готовы брать и без тестового.
И мысли по интересному комментарию [5] от loppi [6]
А если есть проблема, для которой я не знаю сходу решения — всегда можно изучить вопрос и найти это решение.
Интервьюверу важно не просто факт, что соискатель изучит вопрос и найдет решение. Важно, как он это сделает, — рассмотрит ли все варианты, или найдет первый попавшийся, как отреагирует на столкновение с фактом, что избранный вариант решения несостоятелен, и надо искать новый, и так далее. Для разных обстоятельств могут быть различные ожидания.
Только одно собеседование кардинально выделялось из общей массы, разговор шел тет-а-тет с техдиром, он распросил с какими технологиями я работал, а потом мы разговаривали про различные проблемы на их проекте и на моих прошлых проектах, и как эти проблемы решались или можно решить.
Да, отличный способ собеседования (сам так считаю и использую), который хорошо дополняет другие вопросы. И, что странно, есть огромный % senior разработчиков, которые отлично знают теорию и имеют реальный многолетний опыт, но при этом крайне слабо себя показывают при попытке решить задачу с большим количеством степеней свободы. Из минусов этого способа собеседования, что он требует длительной подготовки (из реальных кейсов надо извлечь суть, опустив ненужные детали и обобщив) и может быть неэффективным, если ключевые вызовы как соискателя, так и собеседователя были специфичными.
Автор: algotrader2013
Источник [7]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sobesedovanie/344212
Ссылки в тексте:
[1] этот пост: https://habr.com/ru/post/484944/
[2] farwayer: https://habr.com/ru/users/farwayer/
[3] write-only код: https://www.techopedia.com/definition/24383/write-only-code
[4] умных книг: https://www.mann-ivanov-ferber.ru/books/kto/
[5] комментарию: https://habr.com/ru/post/484944/#comment_21170990
[6] loppi: https://habr.com/ru/users/loppi/
[7] Источник: https://habr.com/ru/post/485160/?utm_campaign=485160&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.