Pull to refresh

Что такое I в ACID или взгляд с другой стороны

Reading time 8 min
Views 12K
Прочитав этот пост, написанный farwayer, сначала хотел просто оставить комментарий, но, подумав пару десятков минут, решил, что тема глубокая, и мне есть что сказать на целый пост. Все таки, с одной стороны, я один из тех, кто на собеседованиях не смотрит на код и кого разочаровывает незнание оценки сложности поиска по индексу в реляционных СУБД, с другой, считаю, что могу дать понимание того, как мыслит достаточно большой кластер интервьюверов, зачем они поступают (на первый взгляд) нелогично и деструктивно, и какие проблемы сами хотят этим решить. Есть надежда, что понимание картины мира «врага» само по себе ответит на множество вопросов.

Для начала расскажу о себе. Надеюсь, что это лучше поможет осознать описанное ниже. В разработке ПО 9 лет, некоторое время работал на себя (создавал биржевых роботов и торговал на собственные деньги), основное время был наемным разработчиком (в том числе lead developer). С недавнего времени занимаю продуктовую должность. Собрал 2 команды senior уровня. Провел несколько десятков (хотя и меньше 100) технических собеседований на позиции middle2senior, senior, lead. В аутсорсе не работал ни дня за всю жизнь провел 18 дней. Поэтому, могу сказать, что весь опыт связан с продуктом (собственным или нанимателя), и все собеседования проводил с мотивацией «найти человека, который принесет максимальную пользу продукту». Признаю, что опыт автора исходной статьи больше моего, но цель, — не рассказать, как правильно, или дать совет, как надо поступать, а рассказать, как можно на те же вещи посмотреть с другой, альтернативной, и не факт, что правильной, точки зрения.

Поехали по пунктам (названия взяты из оригинального поста).

Никому нет дела до твоего кода


Прежде всего вопрос в том, а что такое хороший код и какие ожидания от кода, который производит опытный программист. Для меня хороший код — это функция от задачи, условий, в которых эта задача поставлена, принятых в команде (компании) гайдлайнов, ожиданий техлида (архитектора), менеджера по продукту, лид QA. К примеру, рассмотрим несколько задач:

  1. Разработать API для последующей выдачи его всем пятистам B2B клиентам компании для интеграции продукта в их решения, — ожидается продуманное и хорошо документированное решение с максимально понятной структурой, соответствием принятым на рынке стандартам, максимально строгой валидацией данных, полным покрытием тестами, расширяемостью, продуманным логгированием, соблюдением всех требований безопасности, масштабируемостью по производительности, устойчивостью к хотя бы примитивным примерам DoS и DDoS;
  2. Реализовать соответствие продукта требованию регулятора, которое вступает в силу через месяц, и может привести к остановке всего бизнеса, — ожидается надежное решение с упором на тестирование;
  3. Пофиксить баг на проде, связанный с кешированием, о котором стало известно за час до наступления Черной Пятницы, — ожидается, что решение будет написано и развернуто на проде за 30 минут и ничего не поломает. Другие требования уходят на второй план;
  4. Проверить гипотезу, для которой надо разово спарсить 250 страниц сайта конкурента, после чего на их основании сформировать для бизнес-аналитика документ в google spreadsheet, — ожидается, что программист не будет делать лишней работы и напишет write-only код, не затратив на это много времени;
  5. Проверить производительность Aerospike на задаче, для которой традиционно в компании используется PostgreSQL, и наблюдаются проблемы с производительностью, — ожидается, что будут учтены алгоритмические нюансы и профиль нагрузки, но при этом весь код пойдет на выброс вне зависимости от результатов эксперимента.

Согласитесь, что неправильно оценивать код, закрывающий все эти задачи по одним лекалам. А ведь, от хорошего программиста в продуктовой разработке часто ожидают эффективного решения всех вышеупомянутых задач. Практика показывает, что эффективность программиста во всех этих кейсах проще определить кейсовыми вопросами и обсуждением опыта, чем рассматриванием кода, написанного при неизвестных для интервьювера переменных. Плюс, код, который собеседуемый хочет показать != код, который он пишет, решая коммерческие задачи.

Торжество бесполезных знаний


Отлично пониманию негодование, связанное с
А то, что поиск по B-tree индексам в PostgreSQL имеет логарифмическую сложность? Я вчера узнал, вот теперь и вы
Но что с другой стороны? Баги, связанные с алгоритмической сложностью, одни из самых неприятных для бизнеса. Они не покрываются юнит тестами (O(N^2) при тестовом запуске, где N=10, это реально быстро), они не покрываются автоматическими, интеграционными, регрессионными и ручными тестами по той же причине. Они не всплывают на dbe, uat, sit (ведь для N=1000 это все еще быстро). Они могут ждать своего часа годами, не напоминая о себе, пока один покупатель не добавит себе в корзину 250 продуктов, или пока не появится клиент брокерской компании, решивший собрать себе HFT-робота на коленке. Но, когда они проявляются, поплохеть может всему бизнесу.

Лирическое отступление о Performance Testing
Предвосхищая комментарии о небходимости Performance Testing, отвечу сразу, что далеко не всегда понятно, где именно пресловутый N надо поднять до небес. А, учитывая злонамеренные попытки организовать Application-level DoS, предусмотреть все варианты становится почти невозможным. Поэтому, да, я тоже за Performance Testing, но это не отменяет моего ожидания от разработчика, что он должен интуитивно понимать, где оценка сложности становится критической и опасной для бизнеса.

Сюда же относятся и вопросы про ACID. Баги, связанные с блокировками в СУБД, race condition, транзакциями в СУБД, — это тоже самая мякотка для бизнеса. Они точно так же, как и баги, связанные с алгоритмической сложностью, могут сидеть тихо годами и ударить очень больно. Когда основная оперативная СУБД компании, развернутая на монструозном сервере с максимальным резервированием всего, просто останавливается с нулевой нагрузкой на CPU и IO в момент максимальной активности клиентов, поверьте, это крайне неприятно и, да, это может стоить годовой зарплаты команды программистов. Поэтому, знать наизусть каждую букву ACID не нужно (по крайней мере, я никогда не спрашиваю знания расшифровки аббревиатур да и сам не помню их наизусть), но вот незнание сути каждой из букв — это уже серьезная заявка на внедрение в код подобных багов. Если программистов с таким незнанием в команде двое, то code review тоже не станет лечением.

Лирическое отступление о legacy и NoSQL
Возможно, пример и притянут за уши (хоть и реален для моего опыта), и в основном актуален лишь для старомодных систем и двухзвенок, но современные NoSQL архитектуры с микросервисами имеют свои приколы с рассинхронизацией данных и рассогласованием схемы данных на разных нодах, в разных версиях данных. Не вижу смысла углубляться в это сейчас.

Тебя валят


А тут вот это. И ребята вроде адекватные. Фиг пойми. А потом видишь, что вакансия полгода открытой висит. Ну-ну.
То, что на сайте компании (или на аггрегаторе вакансий) доступна вакансия, не означает, что компания ищет одного человека в одну команду. Реальность продуктовых компаний в период роста — это вечный кадровый голод. Или масштабируешься, захватываешь рынок, выдавливаешь конкурентов, или умираешь. И у менеджера по продукту вечная головная боль — «что выкинуть». Не «а чего бы крутого такого придумать, чтобы 100 программистов загрузить на месяцок, чтобы не скучали», а что бы из крутого, нужного, запланированного и ожидаемого (и обещанного) клиентами выкинуть из планов, чтобы не затянуть очередной релиз на год. Поэтому, нет лишних рук, и тот факт, что вакансия полгода висит, не отменяет факта, что 10 человек по ней уже нашли и взяли на работу, и с удовольствием возьмут еще столько же. Снова таки, не везде и не всегда, но описанная мною ситуация нормальна и допустима для продуктовой разработки.

Мысль об экстенсивном расширении
Практика показывает, что экстенсивное расширение ресурса программистов редко эффективно и часто деструктивно. Но, невзирая на это, современные условия рынка требуют этого от продуктового бизнеса. Ведь, пока скорость роста бизнеса ценится сильнее операционной прибыли (не вижу смысла обсуждать тут, правильно ли это), основатели принимают этот вызов, и (иногда) выигрывают. Вариант «давайте расти органично, не теряя эффективности» тоже рабочий, но, как правило, эффективность каждой стратегии роста зависит от ситуации на рынке, и обсуждение этого потянет мыслей и фактов на огромный пост.

Пофигу на прошлые проекты


Я всегда спрашиваю. Так что, тут полностью согласен с автором. Но точка зрения части тех, кто не спрашивает, мне ясна тоже. Эти люди часто не понимают, как сравнивать разный опыт различных кандидатов между собой. Ответы на закрытые вопросы им сравнивать проще.

О сравнении кандидатов между собой
К сожалению, HRы и авторы умных книг, сидящие на нескончаемом потоке отборных синиоров и архитекторов, жаждущих попасть в компанию мечты любой ценой, любят строить различные системы сравнения, позволяющие отранжировать десятки и сотни кандидатов между собой и выбрать наилучшего. Потом эти подходы навязываются техническим собеседователям, и, как следствие, появляются стандартизированные опросники, которые дают god mode на собеседовании при сливе. Но реальная проблема даже не в этом, а в том, что ради сравнения собеседователи затягивают процесс, ждут, пока наберется сравнительная база, и тем самым одновременно создают проблемы со скоростью найма владельцу бизнеса и ставят в неприятное положение соискателей, заставляя ждать ответа неделями. Бонусом еще и принуждают рекрутеров к постоянному вранью, ведь ответ «ты вроде и неплох, но нам бы еще пятерых для сравнения» не катит, и приходится придумывать что-то из разряда «у нашего техлида прабабушка умерла, поэтому он вернется через недельку и что-то решит». Я для себя решил, что сравнение — зло. Подходит — давай оффер (хотя, % офферов у меня и сильно ниже, чем у сравнивающих коллег).

Опытные разрабы


Тут есть важный момент. Что, да, опытный и сообразительный разраб быстро вникает. Но если уж человек заявляет что много работал с условным OAuth на нескольких проектах (важно, именно так, а не «как-то разок использовал в прототипе»), а интервьювер тоже работал с OAuth, то почему бы и не поспрашивать? Глубина ответов покажет, насколько человек будет глубоко вникать в новые, встретившиеся на пути технологии, понимает ли подкапотные принципы, или копирует с SO, пытается ли предвосхитить грабли.

Еще несколько мыслей


Но и тут можно выкрутиться, дав небольшое тестовое на час-два (только не на месте: для многих собеседование это всё-таки стресс).
Тут могут быть разные мысли на этот счет, но лично я считаю тестовое задание оскорбительным даже для middle уровня. Все таки, тестовое задание, — это очень сильная диспропорция по затраченному времени компании и соискателя. Условно, соискатель тратит 3 часа на написание кода + еще 5 на вылизывание и поиск лучших практик в гугле, а представитель компании за 1 минуту дает вердикт. Для этого соискателю нужна мотивация. Поэтому, хорошая практика, но не для оценки опытных и востребованных программистов, которых готовы брать и без тестового.

И мысли по интересному комментарию от loppi
А если есть проблема, для которой я не знаю сходу решения — всегда можно изучить вопрос и найти это решение.
Интервьюверу важно не просто факт, что соискатель изучит вопрос и найдет решение. Важно, как он это сделает, — рассмотрит ли все варианты, или найдет первый попавшийся, как отреагирует на столкновение с фактом, что избранный вариант решения несостоятелен, и надо искать новый, и так далее. Для разных обстоятельств могут быть различные ожидания.
Только одно собеседование кардинально выделялось из общей массы, разговор шел тет-а-тет с техдиром, он распросил с какими технологиями я работал, а потом мы разговаривали про различные проблемы на их проекте и на моих прошлых проектах, и как эти проблемы решались или можно решить.
Да, отличный способ собеседования (сам так считаю и использую), который хорошо дополняет другие вопросы. И, что странно, есть огромный % senior разработчиков, которые отлично знают теорию и имеют реальный многолетний опыт, но при этом крайне слабо себя показывают при попытке решить задачу с большим количеством степеней свободы. Из минусов этого способа собеседования, что он требует длительной подготовки (из реальных кейсов надо извлечь суть, опустив ненужные детали и обобщив) и может быть неэффективным, если ключевые вызовы как соискателя, так и собеседователя были специфичными.
Tags:
Hubs:
+50
Comments 50
Comments Comments 50

Articles