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

Прочитав этот пост, написанный 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 разработчиков, которые отлично знают теорию и имеют реальный многолетний опыт, но при этом крайне слабо себя показывают при попытке решить задачу с большим количеством степеней свободы. Из минусов этого способа собеседования, что он требует длительной подготовки (из реальных кейсов надо извлечь суть, опустив ненужные детали и обобщив) и может быть неэффективным, если ключевые вызовы как соискателя, так и собеседователя были специфичными.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 49

    0

    ИМХО один из самых главных скилов разработчика — умение поставить себя на место другого. В чем проблема ставить себя на место работодателя? Не так хорошо развит навык?

      +1
      Тороговцев специально учат: «Не пытайтесь выдумывать за человека, чего он хочет — наверняка ошибётесь».
      В психологии есть понятие "проекции".

      Если разработчик не имеет соответствующего опыта другой стороны, то предсказать её поведение у него хорошо не получится. И эта статья как раз проясняет дела для автора той статьи и других людей.
        0

        99% людей не понимаю что и как может компьютер, поэтому конкретно для разработчика выдумывать нормально (смотря на работу человека). Возможно я не прав насчет работодателя.

          0
          Если бы я спросил у покупателей, что им нужно, они бы сказали: „Более быструю лошадь“

          Вопрос не в том, чтобы принять решение за работодателя. А втом, чтобы предложить решение, которое могло бы быть лучше (или потом согласиться с решением).
          Из личного опыта, есть программисты, которые будут тупо кодить что написано в требованиях, даже не подумав что это полная ерунда. Ведь бывает, что аналитик просто ошибся, или не до конца знает детали,… ИМХО — это не очень хорошие программисты.
            0
            Все от критериев и бизнес-модели зависит, увы. Если менеджер отвечает за делание разовых аутсорс проектов на фикс прайсе, которые получены по субподряду от более успешных аутсорсеров, то для него это не то, чтобы очень хороший программист, а просто лучший. Да, могут вопросы к менеджеру, почему он так себя не уважвет, что таким занимается, но это уже выходит за рамки поста и обсуждения.
            0
            Человек «хочет» и «у человека есть потребность» — это разное. Из классики, собственно. Пользователи упорно «хотят», что бы форма загружалась быстрее. Она не может загружаться быстрее по объективным причинам, но пользователи ХОТЯТ. После общения и выяснения причины этой хотелки выясняется, что на этой форме, среди всего прочего тяжеловесного хлама, есть очень маленький, но очень часто нужный чекбокс. То есть «потребность» вовсе не в быстрой загрузке формы, а в быстром доступе к чекбоксу. Продублировали чекбокс на другой более легковесной форме, и хотелка исчезла сама-собой.
          +1
          Но что с другой стороны? Баги, связанные с алгоритмической сложностью, одни из самых неприятных для бизнеса.

          Вы делаете всё ту же ошибку, что и яростные защитники big O в комментариях к прошлой статье: низкая производительность != высокая алгоритмическая сложность.
          Для бизнеса проблемой является первое, но никак не второе. Иногда низкая производительность вызвана именно алгоритмами с плохой сложностью, а иногда — совсем даже не ими. Иногда проблема в законах физики (задержки в 300-400ms при передаче данных в противоположную точку земного шара неизбежны), иногда в железе (можно сказать, что алгоритмы виноваты уже и тут, но так глубоко копать вы скорее всего не захотите), иногда — в данных (формирование XML и JSON с точки зрения алгоритмической сложности примерно одинаково, а вот итоговый размер данных может быть очень сильно разным), иногда — в применении инструментов не по назначению (это исследуется с точки зрения big O, но более продуктивно будет всё-таки использовать инструмент по назначению).
            +1
            Я думаю, посыл автора был в том, что именно низкую производительность можно отловить тестами, условно, вида «нам надо обрабатывать Х операций в секунду, тест на Х проходит, у нас все ОК». В то же время, если ожидается рост, особенно взрывной, нужно понимать, как будет расти функция необходимых ресурсов в зависимости от функции роста Х
            0

            Ага и пофиксить баг на проде за 30 минут мы конечно же доверим человеку, который пришел в проект вчера.

              +8

              А что остаётся делать, если все остальные уволились?

                +4

                Действительно

                0
                вы будете смеяться, но это бывает гораздо чаще именно там, где этот проект не имеет не только тестов и тестового сервера, но еще и никого из разработчиков кроме вас, а в особо запущенных случаях — вообще без системы версионирования (т.е. вы все ваши изменения сразу в проде и делаете, возможно — предварительно заархивировав текущую рабочую структуру файлов, если на диске есть еще свободное место).

                PS: однажды был у меня случай, когда уволили со скандалом одного «бизнес аналитика» — код на проде отличался от кода в репозитории (скрипты tcl\tk), никого из разрабов больше нет, вот это был интересный проект!
                  +1
                  А у нас такое вчера было… Но дивные разработчики (предыдущие) положили весь гит репозиторий в… образ, чем спасли клиента нашими руками ))
                  +4
                  Был у мужика огромный алмаз, и захотел он его огранить, но ни в одной ювелирной мастерской за это не брались, уж очень велика была цена ошибки. Мужик уже совсем отчаялся, но тут ему посоветовали обратится к старому Рабиновичу — если и он не возьмется, значит никто. Пришел мужик в мастерскую к Рабиновичу, показал старому еврею камень, объяснил проблему. Рабинович покивал, мол да, работа сложная, потом позвал подмастерье:
                  — Изя, сделай дяде камушек.
                  Мужик в шоке, как так, такой камень за который не взялись лучшие ювелиры, и — подмастерью! Рабинович в ответ:
                  — Это ви знаете, что камушек сложный, это я знаю, что камушек сложный. А Изя не знает, он сделает.
                  +1
                  от хорошего программиста в продуктовой разработке часто ожидают эффективного решения всех вышеупомянутых задач.

                  ну наверное кто-то ожидает, но во-первых, это не значит что это так должно быть, а во-вторых, первые три требования они на самом деле про одно и то же — про читаемый и поддерживаемый код, который как раз и нужно увидеть на собесе (3-й пункт реализуем иммено в том случае когда код нормальный, иначе это лотерея), 4-й пункт это про адекватность, а не про код — нормальный человек понимает что такое разовая задача, хотя давать такие задачи стоит только джуниорам если не хотите терять спецов. 5-й — опять же разовая задача, но для опытного и толкового, который может также не помнить ничего про сложность конкретных алгоритмов, нагалит и решит.
                  Баги, связанные с алгоритмической сложностью, одни из самых неприятных для бизнеса.

                  но это не значит что человек должен поняить наизусть сложность всего и вся, он должен знать о самом понятии сложности.
                  Сюда же относятся и вопросы про ACID

                  точно также нет нужны помнить расшифровку, надо значить что уровня изорляции бывают разные (не нужно помнить наизусть) и что из этого следует.
                    0
                    Они могут ждать своего часа годами, не напоминая о себе,

                    Вот когда появятся, тогда их и нужно будет решать, разве нет? Это же пресловутая преждевременная оптимизация.
                      +2

                      когда ТАКОЕ появляется, решать уже обычно поздно.

                        +1
                        Скорее дорого, чем поздно. Присутствовал на проекте, который в один прекрасный день начал загибаться по базе. Вроде и нагрузка не выросла, и не менялось ничего, но видимо количество данных перешло какую-то грань. В итоге клиент нанял ребят из Percona (консультанты по вопросам БД, часть из которых являются разработчиками MySQL), у которых на тот момент был рейт по 800 американских президентов в час. За пару дней они всё разрулили, база стала шелестеть как новенькая. Но вышло крайне не дёшево.
                      +4
                      Ну, вообще говоря, про букву I в ACID вполне есть о чем поговорить на собеседовании.
                      По пониманию того, как происходит конкурентный доступ в базе данных люди делятся примерно на 3 уровня:
                      1. «Оно происходит как-то само магически и повлиять на это мы не можем». Если начать допытываться: «А как вы думаете, все-таки как там это сделано?», то можно услышать много интересного. Например «Так а на уровне базы данных нет никакого конкурентного доступа, там все запросы выстраиваются в очередь и выполняются друг за другом» или «Ну, наверное там внутри есть большой мьютекс, который предохраняет данные от порчи». Хотелось бы сказать, что это уровень джуниоров, но, к сожалению…
                      2. «Оно происходит как-то само магически, но мы можем на это повлиять, если будем использовать правильные заклинания и не будем использовать запретные слова». В категорию запретных слов периодически попадают: триггеры, внешние ключи, джойны. В категорию добрых заклинаний: конечно же «Добавить индексов», но и иногда что-нибудь типа «Отключить транзакции». Тут, в зависимости от набора заклинаний человек может некоторое время мимикрировать под грамотного разработчика, но иногда заклинания устаревают или бывают абсурдными с самого начала.
                      3. «Я понимаю на высоком уровне, что там происходит и знаю как на это повлиять». Это уже системный подход и сложно себе представить, чтобы человек на этом уровне не смог рассказать о такой базовой вещи, как ACID

                      В идеальном мире, мне бы хотелось, чтобы с моими деньгами/заказами/данными работали только специалисты 3-его уровня…
                        +2

                        Да дело в формулировке вопроса.


                        Я могу про уровни изоляции много что рассказать, но как там этот самый ACID расшифровывается — давно уже забыл, проще у гугла спросить. :)

                        +1

                        Требование экстенсивного расширения противоречит требованию собирания команд senior уровня. Разработчики такого уровня, как правило, уже хорошо трудоустроены, меняют работу редко, и их реально надо хантить. Надо или смириться, что набор будет идти медленно, или «пылесосить рынок», заваливая деньгами (если они у вас, конечно, есть).


                        Если у вас в команде уже есть спецы, то почему бы не взять способных кандидатов, даже если они подходят по-вашему подо все требования? Идеальных кандидатов можно ждать долго, а чтобы они приняли именно ваше предложение, надо постараться.


                        Подозреваю, что если вакансии висят, а соискателя не берут, то проблемы всё же в чём-то другом. Ну, и не зря говорят, что «не боги горшки обжигают». Можно конечно как Гугл нанимать после почти экзамена, а потом ставить в основном на поддержку и легаси, но люди после этого обнаруживают, что занимаются не тем, чем хотели бы и уходят.

                          0
                          Требование экстенсивного расширения противоречит требованию собирания команд senior уровня.

                          Все так. Экстенсивное расширение исключительно синиорами — это идеальная картина. В реальности надо идти на компромиссы. Увы, даже пылесос не всегда работает, — многие из тех, на кого он направлен, уже давно уехали в Европу или США.
                          Если у вас в команде уже есть спецы, то почему бы не взять способных кандидатов, даже если они подходят по-вашему подо все требования?

                          Если крупными мазками, то мое видение в плане набора программистов очень близко с видением, описанным тут. Перспективных и сообразительных тоже растил, и успешно. Но, сейчас понимаю, что, увы, вариант «медленно задорого и с диким скрипом искать лучших» в долгосроке оказывается даже более быстрым, ведь, при выходе на работу человек сразу начинает выдавать почти пиковый для себя велью без отвлечения коллег (в альтернативных стратегиях до достижения пикового результата надо значительно инвестировать ресурс более опытных коллег + принудительно понижать сложность кода всего репозитория, что можно читать, как использовать мозги членов всей команды на меньший %).
                          +1
                          Только одно собеседование кардинально выделялось из общей массы, разговор шел тет-а-тет с техдиром, он распросил с какими технологиями я работал, а потом мы разговаривали про различные проблемы на их проекте и на моих прошлых проектах, и как эти проблемы решались или можно решить.

                          Из опыта, крайне редко соискатель в состоянии что-то внятно рассказать о предыдущих проектах. Но если получается — да, бывает что сразу видно «надо брать».
                          То, что на сайте компании (или на аггрегаторе вакансий) доступна вакансия, не означает, что компания ищет одного человека в одну команду.

                          +1. Пару десятков человек наняли по одному описанию вакансии уже. Технологии и требования одинаковые, проекты похожие.
                          Глубина и детали

                          Есть ощущение, не подтверждённое экспериментально, но всё же, что человек который с одной стороны может а с другой хочет разобраться глубоко, будет лучшим программистом, чем тот, который не может и/или не хочет. Не обязательно в произвольно выбранном вопросе, но в какой-нибудь теме — можно взять то, что чаще всего указано в резюме.
                            0
                            Однажды мне коллега пожаловался что завалил собес из всего 3х вопросов. Один из которых «что такое fpie ?»
                            Меня эта история смутила. Но решив попробовать, оказалось что вопрос весьма репрезентативный. Если на вопрос кандидат четко знает и умеет рассказать, то и на все остальные он тоже ответит, да и работать будет эффективно (статистически доказано).

                            Если не отвечает, то собеседующему нужно оценивать множество других факторов или же просто подождать кандидата который ответит.

                            Т.е. я бы это назвал подобный отбор не по «необходимому», а по «достаточному» критерию. Иногда (если воронка кандидатов большая), такой отбор имеет смысл.
                              0
                              Real-world decision tree classifier, однако. Да ещё и с эффективным прунингом
                                0

                                Загуглил, теперь знаю, потратил 10 секунд. Так бы и сказали, что ASLR :)

                                  0
                                  Один из ключиков компилятора для генерации кода нечувствительного к адресу загрузки.
                                  Нужен был еще со времен ДОСа для резидентных программ, кодогенерации для эксплойтов до сборки шаред библиотек, а так же необходим для работы некоторых санитайзеров. Может оказывать незначительное замедление кода.

                                  Фактически ответ на этот вопрос показывает пересечение больших кластеров знаний, а именно:
                                  — что бывает машинный код чувствительный и нечувствительный к перемещению
                                  — как работает загрузчик операционной системы
                                  — имел ли разработчик опыт работы с GNU тулчейном
                                  — имел ли разработчик опыт сборки библиотек под GNU
                                  — пользовался ли санитайзером для которого этот ключ необходим
                                  — настраивал ли CI для всего этого
                                  — насколько часто он это делал, что запомнил ключи компилятора

                                  отсюда же можно сделать высоковероятные предположения что кандидат знает также другие ключи которые часто приходится знать, calling conversions, name mangling, несколько систем сборок, с десяток+ *никс программ командной строки…

                                  PS когда то давно подобными вопросами были вопросы про многопоточность. Вроде как, если человек дорос до многопоточного кода, то и фундамент знаний у него серьезный. Но после того, как их начали спрашивать на каждом собеседовании, то ценность ответа — сильно девальвировала до «Обольшого».
                                    0
                                    сильно девальвировала до «Обольшого»

                                    И почему «Обольшое» не уважаете?) Да, сейчас его знает каждый второй, но вот держать его в голове в момент придумывания алгоритма, увы, могут не многие. Условно, я никогда не спрошу у кандидата «Что означает О большое?», но часто спрашиваю оценку сложности задачи после того, как обсудили решение. Или во время, если кандидат пошел ложным путем.
                                      +1
                                      Хотя бы потому что О(1) для листа и О(1) для вектора это величины отличиющиеся на 2 и более порядка. И если поразмышлять «правильно» на тему О может 9 из 10 разработчиков, то ответить почему последовательный проход по листу оказался в 250 раз медленнее чем по вектору может 1 из 20.

                                      т.е. я не знаю как можно собеседующему интерпретировать то, что человек может оценить сложность быстрой сортировки для лучшего и худшего случая в О нотации. Или как интерпретировать то, что он не знает или не вспомнит вообще эту сортировку (кроме того что недавно читал про неё или вчерашний студент)
                                        0
                                        Условно, я никогда не спрошу у кандидата «Что означает О большое?»

                                        Эээм… Не понимая, что оно значит довольно проблематично оценивать сложность и понимать, что эта оценка значит.
                                        0

                                        В принципе, справедливо: вот я про position [in]dependent code и загрузчики знаю, но на C/C++ не писал уже лет 15 и ключики не помню (детали вообще быстро забываются, а вот основные принципы помнишь всегда). Так что если бы я решил тряхнуть стариной и переквалифицироваться обратно, меня бы сразу спалили, да :)

                                          0
                                          пользовался ли санитайзером для которого этот ключ необходим

                                          Я довольно часто юзаю asan, но не помню, чтобы ему был нужен -fPIE.

                                            0
                                            clang.llvm.org/docs/ThreadSanitizer.html

                                            «Non-position-independent executables are not supported. Therefore, the fsanitize=thread flag will cause Clang to act as though the -fPIE flag had been supplied if compiling without -fPIC, and as though the -pie flag had been supplied if linking an executable.»

                                            Пользовался ли «именно тем самым нечасто используемым» санитайзером для которого этот ключ необходим.
                                              0

                                              И который его сам добавляет.


                                              tsan, кстати, по моему опыту очень плохо работает с атомиками.

                                                0
                                                И который его сам добавляет.

                                                Когда очень много зависимостей, прийдется во время линковки лезть в каждую либу и смотреть на флажки что бы ничего не конфликтовало.

                                                Да и не везде CMAKE последней версии. Да и не везде CMAKE. Ручками часто приходится флажками жонглировать.

                                                Он у меня тоже плохо работал… Много было false positive.
                                      +1
                                      Все таки, тестовое задание, — это очень сильная диспропорция по затраченному времени компании и соискателя. Условно, соискатель тратит 3 часа на написание кода + еще 5 на вылизывание и поиск лучших практик в гугле, а представитель компании за 1 минуту дает вердикт.
                                      Как я уже писал под прошлой статьёй, прийти к вам в офис на очное собеседование — это тоже дело далеко не 5 минут. В Москве, например, если «повезёт», одна только дорога туда-обратно может занять те же 3 часа.

                                      Да и сам подход какой-то странный. Я не хочу, чтобы компания тратила на меня столько же времени, сколько и я на них. Мне нужно за минимальное время получить максимально релевантный ответ.
                                        0

                                        Смотрите, тот факт, что собеседование одного кандидата стоит для компании дорого (надо на 2 часа вырвать из процессов лида и ПМа), заставляет как-то оптимизировать процесс, и не приглашать кандидатов с низкой вероятностью прохождения (и тем самым экономить и их время тоже). Для этого часто используют 15-ти минутный телефонный прескрин, например. И от этого выигрывают обе стороны. А в случае тестового относятся так, что "не жалко", пусть тестовое хоть человек с вероятностью в 1% пройти собес делает. Там более, если к тому времени уже закроют позицию, то можно просто все ответы на тестовые выкинуть и не смотреть. Именно из-за этого диспропорция это плохо.


                                        И да, тестовое это ж не вместо, а в дополнение

                                          0
                                          заставляет как-то оптимизировать процесс, и не приглашать кандидатов с низкой вероятностью прохождения (и тем самым экономить и их время тоже). Для этого часто используют 15-ти минутный телефонный прескрин, например.
                                          Гораздо чаще для этого используют зарекомендовавший себя метод «гадания по резюме».
                                          Да и «15-ти минутный телефонный прескрин» — тоже не сильно лучше, за 15 минут вы сможете подтвердить только существование соискателя и актуальность его заявки.

                                          И да, тестовое это ж не вместо, а в дополнение
                                          Тестовое (в нормальных местах) идёт, как минимум, вместо загадок про люки и зачёта по сортировке пиломатериалов. То есть, тестовое прошёл — значит по скилам уже подходишь, и остаётся только «поговорить за жизнь» и поторговаться за зарплату.
                                            0
                                            Да и «15-ти минутный телефонный прескрин» — тоже не сильно лучше, за 15 минут вы сможете подтвердить только существование соискателя и актуальность его заявки.

                                            Мой опыт показывает обратное. Есть ряд вопросов, аналогичных fpie из комментария выше, но для других стеков технологий. Когда таких закрытых вопросов 15 (45 секунд на 1 вопрос + остальное время на возможность кандидату спросить о проекте и команде), то предварительная оценка выходит весьма неплохой.
                                            То есть, тестовое прошёл — значит по скилам уже подходишь

                                            Тут у разных людей разное видение. Но, как минимум, тестовое без последующей перепроверки хард скиллов = возможность сделать его совместно с более опытным товарищем. И на возражение «так через 3 дня реальной работы и так станет все понятно», преждевременно отвечу, что далеко не всегда и не везде. А проваленный испытательный срок — это огромный убыток для компании, ведь потрачено внимание коллег, расширение ресурса затянуто на лишние 2-3 месяца, необходимо двигать обязательства перед клиентами и другими командами, ведь планы считались исходя из непрошедшего тоже.
                                              0
                                              Кажется это называется «лучше не нанять хорошего, чем нанять плохого». Такой себе фильтр Блума по кандидатам. Хорошие тоже отпадают, но плохие уже точно не пройдут.
                                                0

                                                Фильтр Гугла :)

                                        0
                                        Del
                                          0
                                          Условно, соискатель тратит 3 часа на написание кода + еще 5 на вылизывание и поиск лучших практик в гугле, а представитель компании за 1 минуту дает вердикт.

                                          Тут смотря что Вы хотите увидеть в выполненном тестовом задании. Обычно в Интернете встречаю упоминания тестовых заданий в которых соискателю предлагалось изобрести какое-либо алгоритмическое ноу-хау (тянущее на научную работу) или супер вызубренное владение каким-то конкретным инструментом/библиотекой/фреймворком.


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


                                          На составления ТЗ я потратил около 3-х дней, на выполнение соискателю давался 1 день, на проверку я тратил не менее 1 часа. Задание не было большим и сложным, так почему же я потратил так много времени на подготовку ТЗ?


                                          ТЗ было составлено так, что бы соискатель смог продемонстрировать такие свои навыки:


                                          • внимательно читать ТЗ
                                          • вникать в предметную область
                                          • абстрагироваться на разных уровнях детализации (система/приложение/класс)
                                          • банальное понимание клиент-серверной архитектуры (особенно когда на разных уровнях взаимодействия клиент и сервер могут меняться местами)
                                          • структурировать дизайн приложения
                                          • структурировать код приложения
                                          • переиспользовать код
                                          • работать с чёрными ящиками (есть детальное описание API другого приложения, но нет его реализации что бы к нему подключиться и интегрироваться последовательностью проб и ошибок)
                                          • прочее

                                          При этом в самом же ТЗ и в сопроводительном письме указывалось что код не будет даже компилироваться и запускаться, было описано что это одно из приложений в микросервисной системе, что это "прототип" но подобию которого будут строится и все другие приложения системы, и прочие "намёки".


                                          Так вот на разработку такого тестового задания и на интерпретацию того что нам присылали соискатели тратиться достаточно много времени, понятно что если соискателей много то суммарно их потраченного времени больше чем нашего, но если сравнивать с временем 1 соискателя, то мы потратили на тестовое задание в разы больше времени и сил.


                                          P.S.: рассматривались соискатели именовавшие себя Junior и Middle — все показывали примерно равные уровни компетенции по тем параметрам что мы оценивали.


                                          P.P.S.: и да, то что соискатель делал в тестовом задании было реально схоже с тем что мы делаем на самом деле, т.е. нужно было написать мини игрушечную версию того что у нас имеется.

                                            0
                                            Есть же еще вариант дать соискателю реальную задачу из рабочего проекта. И оплатить, если все будет выполнено. Разумеется, нужен предварительный отбор по резюме и подписание NDA
                                              0
                                              Зачем?
                                                0
                                                Что именно зачем?
                                                Дать реальное тестовое задание — чтобы нанимать людей, которые готовы выполнить тестовое задание, причем не абстрактное, а реальное, получить за него деньги. А работодатель сразу видит подходит ли ему такой разработчик. Плюс отсев тех, кто не хочет или не может.
                                                Оплатить — чтобы разработчик был заинтересован делать задачи работодателя.
                                                NDA — чтобы не ушел код.
                                                  +2
                                                  Зачем это соискателю, который ищет работу, а не подработку?
                                                    +3

                                                    Это сработает только если у вас работа мечты.


                                                    Поставьте себя на место соискателя, у которого 10 собеседований, и на каждом предложат такой вариант.

                                                      0
                                                      Поставьте себя на место соискателя, у которого 10 собеседований

                                                      Представил. Как апворк, только репутация при этом не фармится)

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое