Почему Senior Developer'ы не могут устроиться на работу +128




Сначала о том, как 5 месяцев назад я проходил собеседование на работу. Меня посоветовал друг, и прошло уже немало времени, с момента как я ответил рекрутеру. Я был поражён, как сильно весь процесс изменился за последние 5 лет.


После первичного созвона меня отправили на сторонний сайт (HackerRank), чтобы я решил три небольших задачки за 1 час. Для меня это был первый подобный опыт. Первые две задачки были простыми, но третья оказалась посложней. Когда время подошло к концу, моё решение не проходило все тесты, а только где-то 8 из 10 необходимых.


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


Задачки Повсюду


Мой хороший друг сейчас ищет свою следующую работу, будучи кандидатом наук в Информатике с более чем десятилетним практическим опытом. Почти каждый раз его просят решить какие-нибудь задачки — очно или на стороннем сайте. Он приобрёл Cracking the Coding Interview (в России книга издана как «Карьера программиста» — прим. перев.), чтобы шагать в ногу с рынком труда, но развитие любого навыка занимает время. А несколько отличных вакансий уже прошли мимо.


Проблема всплыла в обсуждении на Megamaker (закрытое англоязычное сообщество для разработчиков и стартаперов — прим. перев.) и один из участников поделился наболевшим:


Скоро мне стукнет 45 и свой стартап (где был CTO) я покинул в декабре. С тех пор я завалил не меньше 10 тестов и интервью на программиста. Пишу код при этом я уже почти 20 лет, включая создание прошивок (по образованию я инженер-электронщик) и полномасштабные распределенные веб-приложения с интеграцией IoT. Я с нуля создавал ПО для крупных специализированных производственных объектов по всему миру. Тем не менее, я просто не могу устроиться программистом, потому что постоянно проваливаю эти тестовые задачки.

А этот твит Макса Хауэлла пошёл в массы несколько лет назад. Это и смешно, и грустно, и одновременно правда.


Создатель доморощенного отклонил google
https://twitter.com/mxcl/status/608682016205344768?lang=en


Факт: для многих Senior Developer'ов, когда они начнут искать другую работу, следующее собеседование может оказаться неприятным сюрпризом.




Разработчики Ненавидят Задачки


Некоторые программисты отвечают…


Я обычно заканчиваю интервью, когда мне предлагают что-то подобное.

или


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

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


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


Рекрутёры почти гарантированно завернут кандидатов, которые могли бы стать ключевыми в компании. Так например, когда Даниэля Бухмюллера не приняли в Netflix…


Твит о Netflix, проходящем над разработчиком rockstar
https://twitter.com/rrubyist/status/1124448304555798529

Компании Любят Задачки


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


Но вместе с ростом пула удалённых разработчиков растёт и количество заявок, которые нужно обработать, чтобы найти подходящего сотрудника. Можете представить себе работу с 500 откликами на одну вакансию?


Компании легко получают 500 приложений
https://twitter.com/ideasasylum/status/1126500299470807046

К тому же я слышал о собеседованиях, где кандидат вообще не умел программировать (не мог написать программу типа hello world). Тратить время десятки таких собеседований не хочет никто.


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


Поэтому я считаю, что задачки на собеседованиях — всерьёз и надолго, и их роль будет только расти.




Потребность в программистах велика как никогда и тем более в Senior Developer'ах. Вот только не рассчитывайте, что годы опыта купят вам беззаботное трудоустройство. Готовьтесь к решению тестовых задачек, пока время не поджимает.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (774):

  1. snuk182
    /#20418777 / +2

    Полтора года назад завалил подобное собеседование. Очень рад был недавно увидеть эту позицию незакрытой до сих пор. Мне даже неинтересны подробности — до сих пор ли они ищут кандидата, умеющего одновременно и олимпиадные задачки на скорость и способного взаимодействовать с ТЗ, либо набрали кого-то из антисанитарных стран до первого бетонного самолета.

    • LeshaVH
      /#20419415

      Большинство крупных компаний просто собирает базу данных)))

      А вообще тому кто предлагает задачки сеньор или лид разработчикам с 15+ годами — надо просто пойти на хер)))
      Ибо они не адекватны)))

      • snuk182
        /#20419487 / +3

        Ну почему же. Я уверен, менеджер искренне хочет найти здравомыслящего сотрудника, который способен реализовывать бизнес задачи соответственно заданиям, реагируя на обязательно возникающие изменения. Однако, автоматизация процесса рекрутинга, решение в пользу которой было принято даже не обязательно этим же менеджером, выдаст в итоге не вполне однозначные результаты. Это в случае компании, которая просто хочет "срезать углы" в процессе поиска специалиста. Есть же еще компании, где программист — заменяемый ресурс. С вытекающими следствиями как рекрутинга, так и отношения в процессе работы. По личному наблюдению — действительно ценных людей туда принимают в обход всего автоматизированно-бюрократического геморроя, чтобы, упаси боже, не спугнуть.

      • Ildar92
        /#20419913 / +1

        я знаю сеньора с 20+ годами опыта, но я бы так не сказал, если бы не знал этого факта. на кого-то между миддлом и сеньором потянул бы

        • depadep
          /#20422021 / +1

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

          • dim2r
            /#20422915

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

            • x67
              /#20423743 / +4

              Тут дело даже не в переобучениях, а в том, что умение решать олимпиадные задачки, хоть и коррелирует с навыками сеньора до какой-то степени, но по сути это две разные области. Можно взять тренированного 10классника, но сеньором от своего умения не станет. Хотя в него будут верить больше, чем в тех, кто эти задачи решать не умеет.

      • dim2r
        /#20420225 / -3

        Если они не использовали инверсию двоичных деревьев последние три года, то можно посылать нахеp.

        Меня недавно спросили теорему Чёрча-Росса о ламбда исчислении. А оно мне надо?

        • sshikov
          /#20420245

          Ну, вообще такой вопрос кое-что говорит о спрашивающем. Вероятно, он не дурак (хотя можно попробовать уточнить, а то вдруг он списал этот вопрос в интернете). Если это правда, то надо ли вам работать с умными людьми? Ну уж во всяком случае ничего явно плохого в этом нет.

          • dim2r
            /#20420295 / +2

            можно быть очень умным, но использовать ум не по назначению

            • sshikov
              /#20420961

              Можно. Но и это вы частично сможете оценить, если вам зададут такой вопрос.

              • dim2r
                /#20421455

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

                • Nalivai
                  /#20423785 / +4

                  Это вы где в России видели НИИ с умными вещами?

                  • dim2r
                    /#20425389 / +2

                    Я пару лет практиковался в новосибирском институте ядерной физики. Там есть очень интересные проекты, в том числе и сотрудничество с ЦЕРНом.

                    • pprometey
                      /#20426191

                      Вот только оплата труда там не очень интересная.

                      • dim2r
                        /#20427345

                        Там как повезет, скорее проблема с жильем. А зарплату можно приличную получать, если крутиться, ездить по командировкам, участвовать в конкурсах.

                        • Mirn
                          /#20431729

                          т.е. мало заниматься или вообще не заниматься наукой?
                          тогда какой смысл?

        • qw1
          /#20424273

          Меня недавно спросили теорему Чёрча-Росса о ламбда исчислении
          Было бы забавно проверить проверить знания рекрутера в этой теме, например, предложив ему выразить какое-нибудь несложное выражение через стандартные комбинаторы )))

      • depadep
        /#20422001

        Мне приходилось и задачки решать, и даже тесты на IQ проходить после 25 лет работы в IT.
        Ощущение двоякое. С одной стороны чувствую, что решение задачи на скорость мало говорит о том, насколько я программист. Я даже в шахматы блиц не играю, хотя классику могу более-менее пристойно для любителя.
        С другой проблема того, как понять кандидата за час действительно есть. Когда сам собеседую, предпочитаю дать несложную задачу на дизайн/рефакторинг без единственно правильного ответа — для того, чтобы понять как кандидат рассуждает и какие у него стиль кодирования.

        • dim2r
          /#20428213

          В некоторых конторах проводят интервью по душам. Вместо 300 вопросов по с++ просто в свободной форме расскажи о себе. Если кандидату дают кредит доверия, то он почему-то проявляет себя лучшим образом и готов вкладываться в развитие.

          • DrunkBear
            /#20428767 / +1

            Наиболее правильный, на мой взгляд, вариант: в процессе рассказа можно уточнять детали и уходить вглубь, спорить и предлагать конкретные минизадачи, которые имеют прямое отношение к работе.
            Ну или услышать «диплом купил, сам ничего не писал, хочу хотя б 100 тыщ» и не тратить время.

          • Tantrido
            /#20428949 / +1

            Да, только почему-то на такие конторы попадаешь редко. Один раз просто написал в cover letter опыт 10+ лет в требуемой технологии — взяли сразу без интервью и собеседований — ВООБЩЕ НИЧЕГО!!! Справился, потом были очень довольны моей работой и оставили хорошие рекомендации.

      • Tantrido
        /#20428839 / +1

        В принципе мне подобные практические собеседования нравятся больше, чем те, что были раньше, когда компании нужен не программист решающий задачи, а ходячий справочник по технологии, например .Net. Но если в 16-м на работу взяли сеньором моментально и без проблем после решения тестовой задачи (на решение дали сутки) + резюме, github и LinkedIn, то сейчас даже решение 3-х задач на отлично на codility за 2.5 часа и успешно пройденное затем техническое интервью не гарантировало получение работы — бред.

        Затем в другой очень известной фирме с высокими зп тоже напрягся и решил эти тестовые задания на codility. На решение дали уже меньше — 1.5 часа, что непонятно: спортсменов по программированию или рабов на галеры нанимают: даже тестовые задания нормально не успеваешь составить на проверку и производительность кода. Но потом этот бред продолжился: тестовые задания дали ещё и на последующем техническом интервью, только решить уже нужно было в присутствии интервьюера за 15-20 мин — решил за 21 мин — отказ. Что происходит?!

        Уже нарешался этих задач на codility массу — аллергия на них уже, если б это ещё получение работы гарантировало. Они могут мои предыдущие тесты посмотреть?! ;)

      • Tantrido
        /#20428873

        А вообще тому кто предлагает задачки сеньор или лид разработчикам с 15+ годами — надо просто пойти на хер))) Ибо они не адекватны)))

        Полностью с тобой согласен, у меня как раз 15+, но приходится смирять гордыню и самомнение и на общих основаниях со всеми проходит, хотя возможно что-то изменится. Возможно в себе нужно что-то менять.

    • Acuna
      /#20420109

      до первого бетонного самолета

      Простите, а можно пояснить для неопытных эту фразу?)

      • sovetnik
        /#20420135

        Не взлетит.

        • Acuna
          /#20420161 / +1

          Оу, ясно, спасибо, а кто в этой ситуации взлететь-то должен, стартап, или человек на должности?

      • snuk182
        /#20420163 / +10

        СЕО моей первой компании рассказывал анекдот, чем отличаются программисты СНГ от программистов повосточней. Действие происходит задолго до моды на аджайл и прочие техники контроля проекта.


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


        • Окей, молодцы. А как он летает?
        • Летает? — спросили разработчики — Этого не было в ТЗ!
        • Блин, чуваки, это САМОЛЕТ. Он должен летать. Перемещаться в воздухе.
        • … многозначительное молчание

        Наши говорят — два месяца, приходите. Заказчик возвращается в назначенный срок. Стоит паровоз. Обычный паровоз, не бетонный, на колесах, на рельсах, пыхтит.


        • Че это?
        • Понимаете, в чем дело. Мы просмотрели ТЗ и пришли к выводу, что самолет — это не то, что Вам надо. Ну бетон, да, дешево, но вы его потом замучаетесь саппортить, кроме того он не взлетит как надо. А Вам же перемещаться. Вот в пределах проектного времени мы запилили вот это средство передвижения. Удобное, поддерживаемое, надежное, предсказуемое.

        • Acuna
          /#20420217

          О, во, благодарю, то, что я и хотел услышать! :)

        • Spaceoddity
          /#20420577 / +3

          Мне вот как-то ближе первый вариант. Нет в ТЗ — идите нахрен! А то понаплодят менеджеров, а задачи никто формулировать толком и не умеет. Постоянно приходится что-то доделывать, переделывать, на будущее потенциальное расширение проекта какой-то резерв оставлять (наверняка будут ещё то-то прикручивать — сделаю выход для него).

          • slonpts
            /#20420655 / +1

            Вообще это часть работы Senior Developer — рассказывать заказчику, что он может упускать из виду.

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

            Если разработчик не пытается выяснить, что именно надо заказчику и объяснить ему последствия его решений, я бы не сказал, что это Senior.

            • Spaceoddity
              /#20420661 / +2

              Как-то вы странно обязанности распределяете… Как по мне, то этими делами должен заниматься менеджер или продюсер.
              Но даже тут постоянно возникают заковыки — когда ты пытаешься менеджеру объяснить даже не какие-то технические аспекты, а просто логические — условное:
              — так нельзя сделать, потому что если юзер введёт имя длиннее 15 символов, то…
              — так сделайте поле в 25 символов!
              — а если в имени будет 30 символов (Характерный момент — обычно технари при проектировании не сходят на конкретику, а закладывают все возможные варианты. Т.е. оперируют алгеброй, а не арифметикой. Гуманитариям же кажется что достаточно поднять лимит и проблема решена)
              — сделайте поле в тысячу символов!
              — тогда это поле не влезет ни в один интерфейс!

              • Zoolander
                /#20421015

                слава богу, что поля ввода на самом деле имеют внутренний скролл и в визуально узкое поле можно вводить хоть все сочинение Льва Толстого

                • snuk182
                  /#20423497 / +2

                  — Когда я копирую в поле логина содержимое третьего тома Войны и Мира, у меня зависает браузер! У вас баг на сайте!

                  • Zoolander
                    /#20427285 / +1

                    пожалуйста, киньте скриншот с полным содержимым Войны и мира

                    вариант:
                    — укажит софт, который позволил вам выделить и скопировать третий том без зависания

                    PS: отмена!
                    обычный браузер позволяет легко выделять и копировать третий том

                    при попытке вставления в разные формы ввода в том же браузере было получено
                    — просто не реагирование формы вообще
                    — Некоторые при вставке из буфера — просто обрезали текст до минимальной величины
                    — зависания получено пока не было, но я не настоящий QA

              • dimm_ddr
                /#20423873

                И этот диалог про поле ввода великолепно объясняет почему формирование ТЗ — это общая работа. Что разработчик хочет от менеджера? Чтобы тот угадал нравящееся разработчику решение? У менеджера есть заказ от клиента в котором есть поле для ввода имени. Он это требование передал разработчику, дальше уже задача разработчика (тестировщика, аналитика, технаря с рандомной должностью созданной специально для таких вещей) определить возможные технические проблемы и пути их решения, описать эти пути с плюсами и минусами и заставить менеджера сделать выбор (либо заставить менеджера пнуть клиента чтобы выбрал он). Эту ситуацию невозможно решить только с одной стороны. Ну то есть возможно конечно, но именно из таких решений и появляются потом анекдоты про бесполезных менеджеров и бесполезных разработчиков.

            • RiseOfDeath
              /#20421865 / -1

              Вообще это часть работы Senior Developer — рассказывать заказчику, что он может упускать из виду.


              Вообще-то это задача аналитика переводить с клиентского на программистский.

              • depadep
                /#20422087

                Это если есть аналитик

                • Xandrmoro
                  /#20422473

                  Даже если его нет, то кто-то же этим занимается. Это задача аналитика как функции, а не как отдельного человека, и условный сеньор может эту функцию как исполнять, так и нет.

                  • depadep
                    /#20422569

                    Верно.Часто это делегируют техлидам или тимлидам (если они программисты). В нашем случае подключают еще и архитекторов.

                  • VolCh
                    /#20427613

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

            • Wesha
              /#20424315

              Вообще это часть работы Senior Developer — рассказывать заказчику, что он может упускать из виду.

              Уточняющие вопросы, говорите? Их есть у меня! Усаживайтесь поудобнее, мы здесь задержимся надолго.

              • slonpts
                /#20431677

                Конечно, надо подходить к вопросу разумно. Текст прекрасен как шутка, но если всерьез, то просто надо сразу спросить, почему нельзя использовать стандартную функцию.


                А иногда заказчик сам не понимает, как ему надо. И тогда разумно предложить "сделаем пока так, а если что — переделаем". Как правило, останется как есть — т.е. заказчика все устраивает.

            • dim2r
              /#20428469

              Если разработчик не пытается выяснить, что именно надо заказчику и объяснить ему последствия его решений, я бы не сказал, что это Senior.


              Иногда можно не выяснять все до конца, а написать самодиагностирующуюся программу. Если все выяснять, то заказчик потеряет терпение.

          • RomanPyr
            /#20435939

            Если вы требуете точно ТЗ, то пишите сразу «без багов». Так не бывает? Вот и «точного ТЗ» не бывает.

      • scruff
        /#20421053

        А по-моему это отсыл к недавней катастрофе Б-777. Там вроде выяснили что ПО писалось через одно место индусами за 2$/час.

        • monah_tuk
          /#20421155

          737 MAX? (MAX имеет значение, т.к. 737 сам по себе уже достаточно старый самолётик)

            • khabib
              /#20421957

              При этом проблем с софтом как раз и не было. Все работало, в соответствии со спецификациями предоставленными, инженерами с зарплатой >200к в год

              • scruff
                /#20422115

                Как раз наоборот — в статье написали что QA делали индусы, нешарящие в авиации.

                • khabib
                  /#20422199

                  Как раз там написано:

                  The coders from HCL were typically designing to specifications set by Boeing.

                  В соответствии со спецификациями, MCAS работал правильно

                  • scruff
                    /#20422811 / -1

                    Тем не менее «грамотно» оттестированный индусами и «работающий» MSAC привел к трагедии. А если бы большие дяди не экономили бы «на спичках» и заказали QA где-нибудь поближе чем Индия то всё обошлось бы.

                    • khabib
                      /#20423589 / +3

                      Попытка переложить ответственность на субподрядчика, который выполнил проект в соответветствии со спецификациями заказчика?
                      Ошибка сделанная Боингом — системная/архитектурная, никакое стороннее тестирование MCAS как отдельного модуля на соответствие спецификации, не выявило бы проблему, что этот модуль полагается на данные только от одного датчика.
                      Это было решение индусов, не распространять информацию о появлении новой системы среди пилотов?
                      Это вина индусов, что пилоты оказались не готовы к «штатному» отказу «самовольная перекладка стабилизатора»?

                      Кроме того, презрительный комментарий по поводу 9$ в час — это 90к рублей в месяц. Какие там зарплаты сейчас у Сухого или Яковлева?

                      • Carburn
                        /#20423843 / -1

                        9$ это цена, которую выставляет компания, а не конечная зарплата разработчика.

                        • khabib
                          /#20423893 / +3

                          Компаний выставляла цену в 20-25 баксов в час и в изначалных статьях фигурировала эта цифра. Это уже позже, пересчитали предполагаемую цифру, которая доходила до разработчика (блумберг, кажется, был этим первым сайтом)

                      • scruff
                        /#20424855

                        Вы внимательно читали мой комментарий? Я индусов винил? Нет. Они возможно сделали всё в рамках своих компетенций и тех «дырявых» спецификаций, что дал заказчик. Плюс еще дело в экономии в ИТ. Там где есть возможность сделать за 9уе вместо 20уе — всегда выберут 9уе (по крайней мере по такой цене продаются индийские гребцы исполнителем, по факту получающие может и меньше 1уе) — даже если на кону жизнь людей. Ведь всегда в случае всего можно спихнуть вину на технарей, не важно кто это будут — индусы, европейцы, китайцы, женщины; большие дяди как были на своих постах — так и остались. Что касаемо Сухого — я не знаю (и не обязан знать) что там у них с QA, но последний пожар на гражданском судне вряд ли заставит адекватного человека подумать, что «новый» Суперджет безопаснее 15-летнего Боинга\Эйрбаса\Эмбраера. Як? Гражданский? Вы серьезно? Кроме Як-40 за последние 10 лет из этого «бренда» я не видел ничего, да и то на задворках аэродрома с демонтированными движками.

                        • khabib
                          /#20425153

                          Вы внимательно читали мой комментарий? Я индусов винил?

                          Определенно, да. Иначе я не знаю, как можно было прочитать этот комментарий:

                          Там вроде выяснили что ПО писалось через одно место индусами за 2$/час.


                          В итоге мы выяснили, что проблема не 9$ баксах в час, не в индусах и не в софте

                          • scruff
                            /#20426151

                            Тогда в чем проблема по вашему? Продолжайте мысль…

                            • pprometey
                              /#20426193

                              Рыба как обычно гниет с головы.

                            • khabib
                              /#20426589 / +1

                              А это как разз не так и сложно:
                              — Топ менеджеры, которые доят бренд 737го слишком долго
                              — Маркетологи, которые продали MAX как «тот же NG, только новый и экономичный». Переход с NG на MAX это 1 день наземного тренинга.
                              — КБ и главный конструктор, который допустил что в самолете есть система без дублирования
                              — Авиаконтролирующие органы (как в Штатах так и международные), которые сертифицировали этот самолет
                              — Авиакомпании, которые заставляют пилотов летать только на автоматике, с минимум практики управления руками. (Сгоревший суперджет, это как раз туда же)
                              — Пилоты, которые молча хавают и соглашаются с этой политикой.

                              Но сми форсят факт «это просто индусы наговнокодили»

                        • Kodiak
                          /#20426027 / +1

                          >… но последний пожар на гражданском судне вряд ли заставит адекватного человека подумать, что «новый» Суперджет безопаснее 15-летнего Боинга\Эйрбаса\Эмбраера.

                          Ну вотт новый Суперджет поимел проблемы при посадке с превышением посадочной массы после удара молнии — ~половина выжила.
                          «Штатная» работа одной систем Боинга — выживших немае.
                          Странная нонче адекватность у людей.

                          • Wesha
                            /#20426053

                            Простите покорно, но "новый Суперджет поимел проблемы при посадке" всё же не "из-за превышения посадочной массы", а потому, что доходяга-пилот его об полосу бил-бил, и на третий раз таки разбил (смотрите сами). Как-то так.

                            • Kodiak
                              /#20426099

                              Ну, тут пишут про перегрузки именно для посадки с превышением, а РТЭ мне, в отличие от РЛЭ (в котором отдельным пунктом посадка с превышением посадочной массы тоже есть), что-то нагуглить сходу не получилось.
                              Так что косяки пилотов косяками, но и помимо этого ИМХО были объективные факторы.

                      • vladkorotnev
                        /#20426073

                        9 баксов в айти за бугром это очень мало для такого ответственного проекта. Я по молодости даже вмордпресс не допиливал на фрилансе меньше чем за 20. При отсутствии менеджмента и прочего бюрократического буллшита, с ним — нужно больше.

            • monah_tuk
              /#20422645

              Моя поправка была относительно модели самолёта, у вас — 777 указан.

      • deemytch
        /#20423173 / -2

        Поищите историю с Боингом, это недавнее. Они наняли индусов для своего ПО с ожидаемым анекдотическим результатом.

        • wataru
          /#20423595 / +1

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


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

    • Igor_O
      /#20420911 / +1

      Странно, что вас в принципе позвали на собеседование. В нескольких компаниях до сих пор висят открытые вакансии по моему профилю, на которые я многократно отправлял резюме. Даже ни одного просмотра резюме. Прошло пять лет уже. Вакансии — до сих пор открыты!
      Почему? А госконтракты. По некоторым из них у исполнителя должно быть X специалистов по специальности Y. «Смотрите! У нас тут открыта вакансия по специальности Y и уже есть 100500 откликов на эту вакансию, мы уже завтра наймем человека!»

      • snuk182
        /#20422135

        Широко известная в узких кругах зарубежная финансовая контора. Там точно не госзаказ.

    • CrushBy
      /#20420985

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

      • Lezenford
        /#20421403 / +1

        Вам это не напоминает грустную тенденцию в школьном образовании последних этак лет 15? Если что, я про ЕГЭ и ГИА, которые точно так же натаскивают на решение задач (тестов), а не на реальные знания)

        • Evgenym
          /#20421485

          Реальность диктует такие требования, поэтому людям приходится под них подстраиваться, чтобы выжить достичь успеха в социуме. Мотивация проста: не сдашь ЕГЭ -> не поступишь -> не получишь диплом -> не устроишься на нормальную работу. Когда я заканчивал школу, цепочка была такая.

          • CrushBy
            /#20421503

            Это в любой системе так, когда ставится KPI. И тогда все начинает сводится к достижению этого KPI любой ценой, даже с ущербом всех остальных показателей. Но проблема в том, что без KPI и оценок многие не могут. Возьмите, например, кол-во лайков и подписчиков в соцсетях. Для многих это превращается в смысл жизни.

            • Xander_Vi
              /#20421715

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

              • Nalivai
                /#20423823 / +2

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

            • VlK
              /#20422923

              С другой стороны, как вы в большой организации будете проверять адекватность работы отделов? Нет KPI — нет оценки, и в этой ситуации часто разводится имитация бурной деятельности.

              • CrushBy
                /#20423231

                Да, так и есть. Без KPI тоже могут быть проблемы. Нужен какой-то баланс.

              • Gar02
                /#20423513 / +5

                Чтобы проверять адекватность работников с помощью KPI, эти KPI сами должны быть адекватными.
                Вот был я в Тунисе. У чистильщика пляжа есть KPI: чистота пляжа. Этот чёрт чистит пляж на тракторе, а потом скидывает весь мусор в море. Зато KPI выполнен: пляж с утра идеально вычесан от мусора. Правда, море превратилось в дерьморе.
                Русские туристы пару раз чуть не побили его, но что ему делать? «Умный» манагер не предусмотрел вывоз мусора. Куда его девать, если за его наличие на берегу тракториста штрафуют?
                А вот найти адекватных составителей KPI — нереально. Эти люди должны знать всё об оцениваемом участке работ, а сегодня начальнички «не любят погружаться». Знакомая фразочка? То-то!

                • RedTalon
                  /#20425221

                  Любой адекватный критерий эффективности перестаёт быть таковым, когда становится известен оцениваемому.

                  • Gar02
                    /#20426377

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

                  • vvbob
                    /#20426453

                    Если человек точит гайки, и эффективность его работы оценивается качеством (размеры и форма в пределах допусков) и количеством выточенных гаек, то никаких проблем в том что он знает критерии нет. Скорее наоборот, лучше до него сразу же их доводить.
                    С разработкой так не работает по той причине что большую часть выполняемых работ невозможно исчерпывающе описать и задать адекватные критерии качества.
                    Разработчики ребята в основном неглупые и ленивые, и всякие KPI часто воспринимают как вызов, сам даже за собой замечаю. Вы мне KPI, а я вот найду способ нихрена не делать и иметь самый высокий из возможных KPI, не потому что так уж хочу ничего не делать, а просто из спортивного интереса :)

                    • pprometey
                      /#20426817

                      Вот есть хорошая статья на Хабре по этому поводу (не в смысле челленджа, а в смысле объективной оценки работы разработчика)
                      Оцениваем разработчика на основе объективных данных

                      • vvbob
                        /#20436341

                        Читал раньше, благодаря вам перечитал еще раз. Статья любопытная, но кмк, это немного более запутанная разновидность оценки качества работы по количеству строк кода, приведшая к знаменитому «индус-кодингу».
                        Единственный нормальный вариант, на мой взгляд — работа относительно небольшими командами, в таких командах все на виду и халявщики особо не побездельничают. Коллеги лучше видят кто чем занимается, кто пашет, а кто фаллосы пинает. Просто руководству надо больше внимания уделять коллективу, общаться и люди сами все расскажут как есть, без всех этих шаманских KPI.

                        • pprometey
                          /#20436657

                          Короче первый принцип agile рулит — люди и их взаимодействия важнее процессов

              • VolCh
                /#20427623

                Перевести их на то, что лет 30 назад в Союзе называли "хозрасчёт".

        • altai2013
          /#20422985

          ЕГЭ — это экзамен, он не может ни на что натаскивать. Знания получают до экзамена, а не во время него. Если человек с «реальными знаниями» не может сдать тест, значит у него банально нет знаний. В тестах спрашивают ровно то, чему учили. Никто не просит в тесте по математике сплясать гопака. В этом и разница с собеседованием на работу, когда знания спрашивают в одной предметной области, а работать потом приходится в совершенно другой.

          • Lezenford
            /#20423039 / +4

            Сразу чувствуется, что вы закончили школу не меньше чем лет 13-15 назад и у вас еще нет детей старшего школьного возраста.
            На самом деле сейчас выпускные классы сводятся именно к натаскиванию на решение определенного шаблона проверки знаний. Зачастую вам не пытаются составить всю структуру знаний, а дают именно подход для корректной сдачи экзамена. При этом в реальности человек может вообще не понимать, как эти знания применять. Точно как в примере с собеседованием — проходить умеют, а работать — нет.
            ЗЫ это субъективный опыт, основанный на собственно сдаче (больше 10 лет назад) и на том, как учатся на текущий момент младшие братья\сестры жены, аккурат возраста сдачи ЕГЭ и ГИА…

            • dimm_ddr
              /#20423913

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

            • rkuvaldin
              /#20424773 / +1

              А вы попробуйте сходить и сдать ЕГЭ. Чисто для себя, чтобы убедиться, что получить там сотню — плёвое дело
              Его ведь может сдать любой человек :-)

              • Lezenford
                /#20426535 / +1

                Уверены что комментарий ко мне? Я то его уже сдавал и знаю, как к нему готовятся и что там спрашивают. Человек с улицы на 100 баллов ЕГЭ не сдаст) даже если у него за спиной красный диплом и отличные знания) У меня много примеров перед глазами было, кто готовился\учился в спец школах для одаренных и прочее, кто в итоге сдавал хуже тех, кто просто зубрили 2 года подряд и монотонно решали тесты)

                • Ametrin
                  /#20427087

                  За 10 лет форма заданий в ЕГЭ поменялась) да даже в те времена зубрежом можно было обеспечить себе не более 50-60 баллов

                  • Lezenford
                    /#20427105

                    Т.е. я могу вас поздравить с 100 баллов который вы получили за экзамен в последние пару лет?) Тогда я за вас рад) Но вы скорее исключение, чем правило. 300 бальников даже на фоне страны не так много)

                    • Ametrin
                      /#20427167

                      Эм, с чего Вы взяли, что у меня 100 баллов?) Как и у многих, у меня баллы посрезались на незазубриваемых задачах в основном (последние задачи С части, и сочинение по русскому подвалил).

                      За все предметы не скажу, но, объективно, ЕГЭ по информатике усложнился за 10 лет.

                      А еще я тоже сдавал ЕГЭ 10 лет назад)

                      • Lezenford
                        /#20427237

                        Тогда вынужден признать, что фразу
                        >А вы попробуйте сходить и сдать ЕГЭ. Чисто для себя, чтобы убедиться, что получить там сотню — плёвое дело
                        Его ведь может сдать любой человек :-)

                        Я до конца не понимаю) И это либо сарказм либо это сильно выше моего понимания)

                        • Ametrin
                          /#20427261

                          я воспринял ее как сарказм..)

        • siziyman
          /#20423025 / +1

          ЕГЭ и ГИА — прекрасная система. Идея и фундамент правильные. Проблемы бывают чисто прикладные (коррупция и низкая квалификация исполнительных органов на разных уровнях, неидеальный набор заданий), но идея однозначно лучше, чем то, что было до этого.
          Кстати, то, что остатки хвалёной советской системы образования с трудом справляются с тем, чтобы подготовить среднего школьника к сдаче довольно простого (пока вы не целитесь в 80+, большинство экзаменов не очень сложные) экзамена без зубрёжки — это больше говорит об этой самой советской системе образования, чем о ЕГЭ и ГИА.

          • Lezenford
            /#20423057 / +1

            а я не говорю, что СИСТЕМА плохая. я говорю о том, что в реальности показатели подгоняются под эту систему проверки, а не на что то практически правильное.
            Т.е. это косяк реализации, а не косяк самой абстрактной модели и ее целей\задач

          • Matisumi
            /#20423573 / +1

            До этого была гораздо более прозрачная система. Абы какие выпускные в школе (потому что ну реально, кому они вообще нужны?), а потом уже подросток сам решает что хочет делать — в армию, в ПТУ, или в институт. Если в институт — то в какой? И от этого уже зависит что он будет сдавать на вступительных и в каком объеме.

            • siziyman
              /#20423799 / +1

              более прозрачная система
              Абы какие выпускные в школе
              Действительно, очень прозрачно и полезно.
              а потом уже подросток сам решает что хочет делать
              Да и сейчас решает.
              И от этого уже зависит что он будет сдавать
              И сейчас зависит, набор предметов и разница между профильной и общей математикой определяется именно тем, куда вы будете поступать.
              и в каком объеме
              Универсальный стандарт, определяющий. что вузы набирают не «кого понравится», а людей, которые по некоторому универсальному показателю показали себя лучше остальных — однозначно вин, это не обсуждается даже.

              • Ctacfs
                /#20424417

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

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

                • siziyman
                  /#20425287

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

                  Государственный вуз, работающий на мои (и, вероятно, ваши — вы же тоже в/из России, как я понимаю) налоги не имеет никакого права набирать «кого понравится», должны быть объективные критерии.

                  • VolCh
                    /#20427673

                    Объективные критерии: результаты вступительных экзаменов. Пускай в той же форме, что ЕГЭ, но вот содержание каждый вуз точно должен иметь право выбирать сам.

                    • dimm_ddr
                      /#20427735

                      Если содержание может быть любым, а не из заранее определенного списка, общего для всей страны, то мы вернемся к платным группам подготовки от института и фактическому ограничению в 1-2 возможных нормальных ВУЗа на выпускника. Потому что подготовится к большему количеству разных экзаменов (а они будут разными — нужно же стимулировать платить за подготовку) у абсолютного большинства выпускников не получится. То есть ровно та ситуация которая была до ЕГЭ. И это именно те причины по которым ЕГЭ вообще был создан — коррупционность зашкаливала просто. И я даже не говорю про взятки (которых тоже стало меньше с вводом ЕГЭ), речь о том что это достигалось совершенно легальными методами — специально подготовленными ВУЗом задачками которые практически нереально решить не узнав способ решения на платных курсах.
                      Ваш вариант работает только в случае если приемом занимаются кристально чистые люди на всех уровнях.

                    • siziyman
                      /#20428425

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

                      Автономный внутренний экзамен — это очень хорошая мотивация делать курсы в ключе «готовься у нас или умри не поступишь». Это, а также банальное количество таких разных экзаменов, лишает умных детей, которым не повезло родиться не там, готовиться к другому вузу, и т.д. поступить в хороший вуз, просто потому что учёному совету надо потешить ЧСВ.

              • Matisumi
                /#20424519

                Абы какие выпускные в школе
                Действительно, очень прозрачно и полезно.


                Можете обосновать необходимость выпускных экзаменов в школе?

                • siziyman
                  /#20430085

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

          • Ctacfs
            /#20424301

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

          • VolCh
            /#20427661

            Система оценки знаний может и хорошаяя, но вот использование её в качестве основного критерия приёма в вузы — нет.

            • siziyman
              /#20428349 / +1

              Знания студентов должны быть единственным критерием приёма в вузы, помимо eligibility (вы закончили 11 классов школы, вы имеете право претендовать на бюджетное обучение, если мы говорим о бюджете, и т.д.). Соответственно покуда ЕГЭ — лучшая из существующих в России систем объективной и комплексной оценки знаний студентов, результаты ЕГЭ — лучший критерий для приёма в вузы, да, именно так.

              • VolCh
                /#20429909 / -1

                Это по вашему мнению это лучшая система оценки знаний.

        • Nalivai
          /#20423837

          Да ладно, я учился до ЕГЭ, и абсолютно та же ситуация была, разве что натаскивали не на ЕГЭ а на контрольные.

          • rkuvaldin
            /#20424783 / +1

            И вступительные.
            Прямо в ВУЗах обычно были подготовительные курсы, которые натаскивали на вступительные конкретного ВУЗа, в которых было грубо говоря три нормальные задачи, и три — с «хитринкой», о которой рассказывали на подготовительных. И не учась там, вступительные экзамены было сдать довольно сложно.

  2. habradante
    /#20418819

    Если компании требуется писать ПО основанное на умении решать подобные задачки, то, может, им и не нужен никакой senior? Если ведущего программиста можно определить по умению решать задачи, то, по логике, любой, кто решит такую задачу — ведущий программист.
    Просто изначально верная задача «отсеивать неподходящих кандидатов» неверно решается. Вводя формальные признаки фильтрации надо понимать, что искомая выборка характеризуется этими признаками. И вот на этом этапе облом, потому что искомая выборка «ведущие программисты» не обладает признаком «умеет решать алгоритмические задачи».

    • masterspline
      /#20419527 / +6

      > задача «отсеивать неподходящих кандидатов» неверно решается

      IMHO, изначально решается задача «найти подходящих кандидатов». И неважно, сколько гениев будет отсеяно вместе с остальными неподходящими. Компании, скорее всего, нужна команда взаимозаменяемых квалифицированных спецов. Возможно, они даже умышленно отсеивают уникумов с уникальными запросами.

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

      Ну, или эта контора тебе не подходит и не нужно даже пытаться туда попасть и тем более жалеть, что не удалось в нее пробиться.

  3. cross_join
    /#20418841

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

    • time2rfc
      /#20419015

      Очень редко пишут про работу в консалтинге, интересно что это за зверь такой. Можете пару слов писануть — как это работает, есть ли такие компании в России, правда ли что там авральный режим но огромные зарплаты и периоды безработья ?

      • cross_join
        /#20419171

        О, это длинная история, я к ней подступался в «Дефрагментации мозга», но уже 6 лет прошло.
        С российской спецификой консалтинга знаком поверхностно, однако автор текста тоже не в РФ работает.
        Если коротко, то консалтинговая фирма сосредотачивается на технической и/или функциональной компетенции сотрудников, продавая их клиентам на проекты по дневной ставке на несколько месяцев. Миссии экспертизы/аудита более короткие, от нескольких дней до недель. Клиент доверяет фирме, поэтому на короткие миссии вообще никаких собеседований не происходит, на длинные — одно-два, обычно совмещенные. Зарплаты немного выше, чем на постоянных позициях, но не в разы, конечно. Неудобство разве что в сильной динамике среды. Тем, кто привык годами «пилить» одно и то же с теми же и на том же будет трудно.

        • Dolios
          /#20419667 / +12

          В рунете подобные фирмы называются галерами и отношение к ним неоднозначное.

          • cross_join
            /#20420195

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

            • foal
              /#20420447 / -1

              Хм… PwC (pricewaterhousecoopers) это небольшая? А Java програмисты там работают, в основном, как консультанты — на краткросрочных проектах.

              • cross_join
                /#20421677

                PwC — хороший, но единичный пример (и специализируются они совсем не на Яве и ИТ). Несмотря на размер они прилагают массу усилий для поддержания уровня компетентности «выше среднего по больнице». Начиная с пяти собеседований для отсева кандидатов.
                В крупной фирме это дорого и хлопотно, поэтому их единицы, тогда как типовая консалтинговая фирма оптимального размера — 50-150 человек.
                P.S. Минусовал не я, не люблю это дело. Только «лайки», LinkedIn рулит :)

                • time2rfc
                  /#20421875

                  Сколько времени может занимать консалтинг на одном проекте и когда это перестает быть уже консалтингом и становиться аутстафингом ?

                  • cross_join
                    /#20422057

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

                    • time2rfc
                      /#20423723

                      Спасибо! Звучит очень интересно, пойду гуглить где такие специалисты нужны.

                      • cross_join
                        /#20423849

                        Видимо для РФ типовой консультант это внедренец ERP (SAP, Dynamics, 1С...), специалисты Microsoft (MSPD...), Oracle, программисты с финансовым бэкграундом (банки).
                        Успехов вам!

                      • DrunkBear
                        /#20423909

                        Дополнительно вам пригодится знание предметной области, разговорный английский и понимание индусского разговорного английского.
                        Ну и широкий кругозор — часто после внедрения системы Х будут спрашивать, что лучше внедрять и интегрировать к ней, продукт Y,Z или что-то ещё и если вы знаете о них, а лучше — и о подводных камнях этих систем, ваш контракт продлевают и расширяют.

            • dimm_ddr
              /#20423945 / +1

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

              • vladkorotnev
                /#20426081

                Смотря откуда сотрудник и какие у него взгляды. Работаю в чём-то подобном в Японии и вижу полный спектр эмоций — кто-то доволен чисто потому, что в Японии; кто-то недоволен из-за того, что не дома; кто-то вообще на седьмом небе ибо палкой не бьют и хорошо.


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

      • vershinin
        /#20419731 / +1

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

        • cross_join
          /#20420175 / +2

          Когда «ты сам делаешь себе фирму» это называется фриланс или ЧП. При этом можно быть консультантом, а можно и не быть.

          • vershinin
            /#20422211

            Да, так лучше. Однако, консультанты обычно фрилансерят, а не гребут на галерах.

      • morozko
        /#20423381

        Консалтинг — это практика продажи знаний и экспертизы, т.е. консультирование. Консалтинг бывает в самых разных сферах. Компания-клиент может заказать консалтинговый проект по разработке бизнес-стратегии, по оптимизации бизнес-процессов, по выбору или внедрению информационной системы, по диагностике предприятия.
        К консультантам обращаются, когда либо не хватает собственной экспертизы, либо нужно подтвердить уже разработанное решение именем известной компании.
        В России консультантов на любой вкус. Размер зарплаты зависит от конкретного вида консалтинга, загруженность — от того, насколько хорошо дела идут у компании.

    • AWSVladimir
      /#20425661

      Альтернатива задачкам — работа в консалтинге

      Для меня альтернатива задачкам сделать рабочий, оплачиваемый мини-проект перед устройством на работу. За это время познакомишься с командой, постановкой задачи, внедрением и другими важными подводными камнями и тараканами.
      Там где спрашивают про задачи не работал, не сложилось, но 2 компании где делал тестовые проекты, перед устройством, самые классные (тфу-тфу-тфу).
      Это была лично моя инициатива проверить компанию и что бы компания проверила меня.
      Я уже описывал свои критерии выбора работодателя, повторятся не буду, может кому будет интересно habr.com/ru/post/423953/#comment_19142917"

  4. irsick
    /#20418861 / -4

    Бедняга, это он ещё тилидом не был. На следующих этапах собеседования превратятся в допрос с пристрастием в стиле «а кто ты такой, пришёл тут с улицы руководить МНОЙ?».

    Автор находится на самом начале пути, в стадии отрицания. Очевидно, что его 5-летний опыт не релевантен рынку, т.к.:

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

    б) 5 лет без собеседований. Крышки люков и автобусы теннисных мячиков постепенно уходят в прошлое, большое О и красно-черные деревья остаются, набирает популярность код в прямом эфире, тестовые задания больше походят на реальные проблемы.

    в) Зона комфорта, высокомерие и тонкокожесть. Автор очень болезненно переживает стадию «окунания в г*но» на собеседованиях, возможно заболел по этой же причине. Лечится работой над собой и своими навыками: codewars.com, фильмами про Рокки, Karate Kid и тд.

    г) Senior в одной компании != senior в другой. На новой работе выслуга лет и опыт работы с конкретными людьми над определенным продуктом могут обесцениться практически полностью. Остаются только эмпирический опыт и computer science.

    • ukt
      /#20419575 / +1

      a) — не совсем понятно
      б) устраивался в одну международную контору, они меня своими задачками три часа мучили, меня это откровенно на втором часу подзнадоело, и спрашивали всякую ересь, вот никак не связанную с реальными задачами. Другая контора, тоже межграничная, спрашивала, а вы знаете map'у, я откровенно отвечаю поясните, что вы имеете в виду (хэшмам, тримап, редусемап, или объект из js фреймворка, отвественного за отображение граф данных), вместо пояснения галочка в опроснике… Ну и на кой писать реализацию какой то мапы, изобретая велосипед? Каждый день их писать что ли?)
      в) окунание в гогно — это эдакий способ сбить цену работнику, так себе, если с ходу, незнакомого человека макают в гогно — лесом товарищей.
      г) сеньор это таки не совсем про опыт, хотя он тоже важен, он скорее про способ мышления.

      • irsick
        /#20420113

        Благодарю за развернутый ответ. Все вышесказанное основано на собственном опыте на рынке США. На прошлой неделе, наконец, закончись мои собственные «хождения по мукам», поэтому тема оригинальной статьи особенна близка и свежа в памяти.

        а) Пять лет — целая жизнь по меркам технологий. При найме человек, как правило, более-менее соответствует требованиям рынка, но со временем начинает отставать, тк бизнес ориентируется на проверенные временем, часто «уже не модные» решения.

        Исключения тоже есть. Из моей практики это либо консультанты (у них каждый проект может быть уникальным, надо постоянно быть в тонусе), либо AAA-компании в авангарде индустрии (Google, Facebook и тд)

        б) В последние разы меня просили написать более-менее реальные CRUD приложения, а один раз просто дали кусок продакшена и попросили запилить фичу, попутно разобравшись с их архитектурой кода.

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

        г) Я использовал в контексте должности. Senior в ООО «Рога и копыта» != Senior в Google.

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

        • sshikov
          /#20420253

          >а) Пять лет — целая жизнь по меркам технологий. При найме человек, как правило, более-менее соответствует требованиям рынка, но со временем начинает отставать, тк бизнес ориентируется на проверенные временем, часто «уже не модные» решения.

          Совершенно не обязательно. Я неоднократно менял проекты в пределах компаний, и это был не консалтинг. Особо модных решений может и не было, но одинаковых все пять лет не было тоже.

          • irsick
            /#20420435

            Мне тоже приходилось паять и программировать SoC, (де)нормализовывать базы и рисовать дизайн — все это в разных проектах одного и того же стартапа. А потом 4 года воевать в суровом энтерпрайзе с legacy на Mootools в 1M LOC.

            По моему личному, субъективному, не претендующему ни на что 14-летнему опыту — интересные и актуальные решения на продакшене в энтерпрайзе встречались в 10% случаев.

            • sshikov
              /#20420991

              Если что, я отвечал вот на эту фразу:
              > (в компаниях редко бывают разнообразные проекты, если только это не consulting)

              Я и не спорю с вашим личным мнением. Я только уточняю, что исключения в этом пункте — не обязательно консалтинг. Это, к примеру, крупные и очень крупные банки. А таких видел не меньше трех.

              • VolCh
                /#20421599

                Да даже в рамках довольно небольших и даже не ИТ компаний часто бывает куча разнообразных проектах на разных стэках (ну или выбираешь стэк сам). Как минимум внутренние системы и внешние публичные "витрины"

  5. JustDont
    /#20418915

    Готовьтесь к решению тестовых задачек, пока время не поджимает.

    Никогда не понимал, зачем. Потребность в программистах, а особенно в таких, кто реально может решать задачи, которые нужно решить — огромна, и пока что всё только растёт.

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

    • dss_kalika
      /#20418941 / +1

      Когда ты чего то стоишь — покупатель найдётся.
      Когда не очень — … тогда придётся учиться проходить собеседования.

      • JustDont
        /#20418953

        Сейчас состояние рынка труда в ИТ такое, что чего-то стоит практически любой, кто вообще хоть какой-то код может писать и адекватно общаться с окружающими. И края этому не видно.

        • dss_kalika
          /#20418989

          ну да.
          Но таких людей — единицы, среди безбрежного океана странных личностей.
          Я в разное время видел много соискателей… и это грусть-тоска. =)
          Я уже не говорю про то, что потом за ними в коде остаётся.

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

          • dvenum
            /#20420951

            Мой опыт также говорит, что «риск потерять двоих кандитатов из пула стоит сэкономленного времени», это странное утверждение. Из 500 заявок как раз двое и будут, которые вам нужны. Ну еще наберется человек 50, которые продержатся месяц или два, а нанять кого-то из них, это куда большие потери, чем повнимательнее поискать.

        • glestwid
          /#20422671

          Расскажите это тем, кто например устраиваетсясейчас в KPMG во Франкфурте, где хрюша проводит каждый день по 5 собеседований и где на вакансию претендует порядка 20 человек, причем с хорошим английским и ненулевым немецким.

          • Kanut
            /#20423179

            Вы мне сейчас действительно хотите рассказать что в Германии стоит очередь в 20 человек на какое-то айтишное рабочее место, да ещё и в контору типа KPMG, где не особо новых технологий не используют, ни условия труда идеальными назвать нельзя, ни звёздочки на кунуну особого впечатления не производят? :)

            Лично у меня опыт просто противоположный. Да просто сделайте профиль среднего сениора на степстоне или монстере и посмотрите сколько предложений вам придёт в течении первого дня :)

            • glestwid
              /#20426771

              Вы мне сейчас действительно хотите рассказать что в Германии стоит очередь в 20 человек на какое-то айтишное рабочее место, да ещё и в контору типа KPMG, где не особо новых технологий не используют, ни условия труда идеальными назвать нельзя, ни звёздочки на кунуну особого впечатления не производят? :)


              Именно так. Потому как это мой свежий личный опыт с небольшим инсайдом + опыт коллеги, подававшегося туда же месяц назад. Просто они могут себе позволить хантить со всего ЕС + привет Brexit, подкинувший до фига народа из Англии на рынок во Франкфурте. По слухам, в Commerzbank ровно такая же картина — конвеер на сотни кандидатов.

              • Kanut
                /#20427367

                Ок, я могу себе представить что конкретно сейчас и конкретно во Франкфурте для айтишника с определённым стеком технологий стало сложнее найти работу. Но в очередь в 20 человек на место я всё равно не верю.

                • Druu
                  /#20428871

                  Но в очередь в 20 человек на место я всё равно не верю.

                  Если под "очередью из 20 человек" понимать каких-то 20 человек, а не тех, что нормально подходят — то вполне реально, может и все 100 быть.

              • Fedorkov
                /#20428151

                привет Brexit, подкинувший до фига народа из Англии на рынок во Франкфурте.
                А как именно брексит привёл к этому?

        • dimm_ddr
          /#20423961

          Конечно. Но вот зарплата у тех кто стоит немного но натренирован проходить такие собеседования может быть выше чем даже у того, кто знает больше, но прыгать через обруч не хочет. Так что если вы не рок стар, то вам придется расставлять приоритеты — деньги или адекватность нанимателя.

      • Acuna
        /#20420143 / +1

        Увы, но не все так просто. Сверхпрофессионалы даже чаще не могут найти работу чем студенты: большинство компаний понимают что могут не потянуть таких специалистов, либо считают что ему у них будет со временем тесно, ибо они не смогут ему гарантировать расширение круга интересных задач, а так же плюшек для удержания, ибо он больно крут для такого места, но понятно что свою крутизну при этом скрывать не выход, ибо лгать в резюме нехорошо, особенно когда вскроется, что ты работал в условном Яндексе. Зарплатные ожидания понижать тоже не выход, мой знакомый рекрутер рассказывал, что нередки случаи когда на собеседования являются рок-звезды на зарплату 30 тысяч, таких обычно они отсеивают, потому-что непонятны мотивы почему человек в возрасте со знаниями на 300 000 идет на 30 000, ибо это явно не тот предел для такого специалиста.

        • JustDont
          /#20421129 / +2

          таких обычно они отсеивают, потому-что непонятны мотивы почему человек в возрасте со знаниями на 300 000 идет на 30 000, ибо это явно не тот предел для такого специалиста.

          А открыть рот и словами спросить человека, почему он так делает — не? Слишком сложно?

          • Mirn
            /#20421241

            причин такого много:
            1. на куда джуна проще пройти если до этого программированием почти не занимался, например раз в неделю (электронщик или админ) или
            2. или есть желание просто попробовать новую отрасль без заморочек со всеми этими свистоплясками с 5-10 собесами и цирком у доски. или просто хочешь обучиться чему то нахаляву да ещё на кофе заработать (почему бы и нет?).
            3. есть очень хорошие компании которые совершенно не умеют искать и собеседовать людей и поэтому проще уйти на минимальную должность (умолчав что ты спец в искомой ими области с 20летним стажем) и быстро получить повышение, тем-более если финансовый жирок позволяет.
            4. Я знаю одного человека который тусил по компаниям которые пользовались трудом неопытных студентов с ставкой в 20-30тр и в свой стартап набрал оттуда сливки — команду крепких разрабов которые остальных тащили и задалбывались, в итоге стартап выстрелил в тех плане.

            • JustDont
              /#20421263

              Да я знаю, что причин много. Мне непонятен вывод «таких обычно отсеивают, потому что нам непонятно, как вообще так». Непонятно? Так спросите.

              • VolCh
                /#20421601

                Далеко не факт, что скажут правду.

                • JustDont
                  /#20421661

                  Далеко не факт, что скажут неправду.

              • A114n
                /#20422653

                Нестандартное — не нужно. Это основополагающий принцип любого бизнес-конвеера.

    • Dolios
      /#20419675 / +3

      Если вы хотите в фейсбук, амазон или "неадекватный" гугл, задачки решать пртдется научиться.

      • sshikov
        /#20419693 / +8

        А если не хотим?

        • nlog
          /#20425007 / +1

          Но виллу в Испании хотим, так что придётся в гугл :)

          • sshikov
            /#20425149

            Пардон, а кто вам обещал виллу? В смысле, покажите мне реальные проекты, на которые гугль берет, очень хочется посмотреть.

            Я поясню, почему скажем я совершенно не хочу в фейсбук. Для начала — на мой взгляд, все их видимые снаружи продукты — полное г. Я не утверждаю, что мои продукты скажем лучше — просто у меня не возникает желания ассоциироваться с этим. Иначе говоря, доверие к компании — на нуле. Гугль… ну это другое, но не сильно лучше. Наверное, в дебрях алфавита можно найти очень интересные проекты с высокой зарплатой, но вот так чтобы бежать туда ради виллы в Испании?

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

          • Mirn
            /#20426069

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

      • JustDont
        /#20419915

        Если вы сами куда-то хотите — то разумеется, пляшите так, как потребуют в том самом месте (если вам после этих плясок туда не расхочется, разумеется).

        А если нет?

        • sshikov
          /#20420129 / +2

          Так самое смешное в том, что при этом со стороны нанимателя это почему-то выглядит одновременно как:
          >Теперь с почти неограниченным пулом претендентов они могут себе это позволить.
          и
          >Потребность в программистах велика как никогда и тем более в Senior Developer'ах.

          Когда я бывал на стороне нанимателя, я ни разу не видел живьем этот «почти неограниченный пул претендентов». И даже не слышал про такой. Только второй вариант имеет место — большая потребность, и малый выбор кандидатов. И даже не на синьорские позиции иногда.

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

          >если вам после этих плясок туда не расхочется, разумеется
          Очень может быть, что и до них.

          • Nalivai
            /#20423935

            Неограниченный пул — он у гуглов. Просто проблема в том, что все хотят быть гуглом, оттого и культ карго. В майкрософт 400 человек на место, значит программистов неограниченно, они и в мой ооо вектор пойдут.

            • sshikov
              /#20424899

              >Просто проблема в том, что все хотят быть гуглом
              Проблема в том, что не все. Я вот например не хочу. Причем давно. И не столько потому, что задачки не хочется, сколько потому, что хрен их поймешь, в какой проект тебя засунут в итоге. И именно гугли с фейсбуками этим как раз страдают в большей степени.

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

      • blind_oracle
        /#20420743 / -1

        Гугл звонит и пишет раз-два в год.

        И каждый раз я у них спрашиваю: мне все еще придется у вас 5 часов рисовать на доске фломастером всякие квик-мерж-хип-сорты, жонглировать красно-черными деревьями и считать О-большое?

        Говорят — придется. До свидания.

        • 0xd34df00d
          /#20420749 / +2

          А я сходил. Прикольно, ничего сложного, с тремя из пяти интервьюеров было время играть в гляделки после того, как я ответил на все вопросы, это было забавно. Потом какой-то вялотекущий team matching, это уже менее забавно.


          Но хрен с деревьями этими, у них же по личным занятиям в свободное время политика драконовская.

          • vladkorotnev
            /#20420801

            А что именно за политика?

            • 0xd34df00d
              /#20420815 / +1

              Весь ваш интеллектуальный труд принадлежит им (по крайней мере, в США и конкретно в Нью-Йорке, здесь законы позволяют такие рабочие контракты, в Калифорнии может быть повыгоднее для работника). Ну, кроме, возможно, книг по садоводству, если вы вдруг решите таковые писать.


              Хотите в свободное время по вечерам и выходным делать свой проект на гитхабе? Фигушки, согласуйте, запрашивайте разрешение, ставьте копирайт (или авторство, хз) гугла. Можно и без этого, но это сложно и с существенно меньшей вероятностью разрешения. И если ваш проект вдруг противоречит их интересам (ну там, движок для адблокера захотите написать, клиент для Телеграма, или JS-компилятор, хз), то вам им спокойно заниматься не дадут. А интересов у гугла много.


              Днём пишете опердни на Java, а хотите в свободное время писать статьи по теории типов? Согласуйте, это слишком близкие области.


              В свободное время помогаете людям на SO? В примерах кода, которые вы там пишете в ответах, ставьте копирайт гугла.

              • vladkorotnev
                /#20420853 / +1

                Понятно, ну его нафиг тогда.
                Всегда предполагал, что все эти цветные офисы со столами для пинг-понга лишь для создания иллюзии уюта, а по факту большинство как на обычной галере торчит по 12 часов на работе и ничем этим не пользуется.

                • 0xd34df00d
                  /#20420871 / +1

                  Ну, кстати, зависит.


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


                  Я бы даже сказал, что большие компании к этому стимулируют.

                  • vladkorotnev
                    /#20420945

                    У нас в японской компании де-юре самопрокачка запрещена в силу белого списка софта и отгороженного политиками интернета.
                    Де-факто наш офис какой-то "удалённый" и поэтому имеет обычный неограниченный интернет, поэтому SSH с иксами домой в РФ и оттуда можно делать что хочешь.
                    Отстрелялись с релизом, клиенты ещё не пришли в себя от празднования, делать нефиг всё равно, так можно Rust покурить :-)

                    • blind_oracle
                      /#20421335

                      Дурь какая. Закрывать разработчикам доступ везде? А зачем вы там работаете?

                      • vladkorotnev
                        /#20421369

                        Работаю, чтобы накопить на перевозку крупногабарита и уехать домой, ну и параллельно по концертам всяким походить :-)


                        Здесь-то ограничений на сети нету, но на не-своём компе логиниться куда-то в свои аккаунты не хочется, поэтому удалённые иксы и только.


                        А до того сидел в компании, принадлежащей одному автопроизводителю, там да, был интернет через прокси и с кучей лимитов (в том числе отрублен habrastorage). Зато там видели моё собеседование и поэтому забивали на то, что я в свободное время пишу что-то своё, и игнорирую вайтлист, лишь бы не сбежал :-)


                        В локалке нашелся установочник макоси, засунул в виртуалбокс и вспоминал былое в икскоде.
                        А код в обход всех их изощрений прекрасно дёргался на гитхаб протоколом Git-over-GoogleMaps :-)


                        Впрочем, у них изощрения как раз были оправданными, ибо там серьёзные данные на машины, которые конкурентам были бы мягко говоря интересны. Что не отменяет того, что отношение удручает — ты NDA подпиши, но зондов мы тебе всё равно напихаем.

                        • Fedorkov
                          /#20421903

                          А код в обход всех их изощрений прекрасно дёргался на гитхаб протоколом Git-over-GoogleMaps
                          Вы имеете в виду Git over Google Translate?

                          • vladkorotnev
                            /#20426091 / +1

                            Нет, именно мапсы.


                            Краткий гайд по выживанию в анально отгороженной среде

                            Тянем репу зипом с гитхаба (ибо git не алё). Распаковываем, создаём внутри репозиторий гита. Уходим на бранч develop.
                            Работаем с кодом. Делаем коммиты как обычно.
                            В конце рабочего дня делаем (Cygwin)


                            git format-patch master --stdout | gzip --best | base64 > /dev/clipboard

                            Опционально можно добавить шифрование.


                            Идём в гугловский My Maps, ставим пин на любимую кафешку, в описание делаем Ctl-V, чуть-чуть ждём и сохраняем.


                            Придя в безопасное окружение открываем мапсы, копируем то, что насохраняли и делаем (Cygwin)


                            cat /dev/clipboard | gunzip - | base64 --decode | git apply

                            Вуаля, коммиты из закрытой среды перетекли в открытую. Пушимся, на следующий день повторяем. Если из дома не работать, а только пушиться, можно зип не тянуть каждый раз (в моём случае было актуально для репы под 300 метров).


                            Можно было, конечно, всё заскриптовать, но больно сложно для пары раз.


                            В теории так выносятся любые файлы, как показала практика, емнип до 25 мегабайт (до закодирования) влезало в один пин спокойно, лишь бы браузер не грохнулся.
                            Заносить было проще, на крайняк приклеиванием хедера и куска от PDF к зашифрованному tgz с последующей выкачкой.
                            Что как бы намекает на всю эту "безопасность" без эиргапа...

                • vvbob
                  /#20421169

                  У нас сейчас тоже все эти пинг-понги модными стали. Где бы ни работал никогда не понимал — откуда брать время на всю эту пинг-понговую хрень, я обычно все рабочее время довольно интенсивно, блин, работаю, у меня нет ни времени ни желания торчать во всех этих игровых комнатах. Я лучше с делом быстрее разберусь и пораньше домой уеду, я на работе деньги зарабатываю а не в игры играю.

                  • VolCh
                    /#20421617

                    Часто поуплрны пинг-понги всякие, когда пораньше уйти домой, получая те же деньги, нельзя

                    • vladkorotnev
                      /#20421891

                      И в такой момент задаёшься вопросом, стоит ли такая компания того, чтобы тупо продавать ей впустую время своей жизни за деньги?

                  • Endeavour
                    /#20423335

                    На обеде вполне нормально поиграть 3-4 партии.

                  • Nalivai
                    /#20423983

                    Кому как, я 8 часов без перерыва работать не могу, не хватает. Раз в пару часов встать, прогуляться, чайку-кофейку, на турничок, глядишь и силы появились.

                    • vladkorotnev
                      /#20426093

                      Опять же, это если отталкиваться от условия, что надо работать 8 часов, а не по мере решения проблемы/задачи :-)

                  • RedTalon
                    /#20426401

                    Это вам даже не эффективных менеджеров, а нейробиологов пинать нужно. Это они, стервецы, удумали, что умеренная физическая активность позволяет мозгу лучше работать. При чём и в краткосрочной, и в долгосрочной перспективе. Так что, если вы не ночной сторож, которому платят за часы, а не за результат мозговой деятельности, то работодатель действует в собственных интересах, соблазняя вас всякими пинг-понгами.

                    • vvbob
                      /#20426467

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

                  • dominigato
                    /#20427937

                    А я хотел бы в бильярд поиграть в перерыве, пинг понг требует подготовки и так сразу в него не поиграешь. А бильярд — просто и прикольно. Заодно помогает сконцентрироваться и отвлечься, потом можно вернуться к работе со свежей головой. Заменяет любой mindfulness))

          • blind_oracle
            /#20421329 / +2

            Ну, кому что нравится.

            Если меня припечет работать именно в Гугле (или прочих буквах FANG) — пойду, конечно, обратно вспоминать все эти сортировки и прочее, которые мне пока в реальной работе пригодились примерно ноль раз. Поэтому я считаю что это бесполезное занятие на собеседованиях, в отличии от того же Distributed Systems Design который у них есть на SRE.

            Но хрен с деревьями этими, у них же по личным занятиям в свободное время политика драконовская.
            В Европе, вроде, такое невозможно. Представляю себе что тут начнется если работодатель начнет мне указывать чем в свободное время заниматься… дикость. Минус 1 балл к переезду в US :)

            • 0xd34df00d
              /#20423479

              Если меня припечет работать именно в Гугле (или прочих буквах FANG) — пойду, конечно, обратно вспоминать все эти сортировки и прочее, которые мне пока в реальной работе пригодились примерно ноль раз.

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


              В Европе, вроде, такое невозможно. Представляю себе что тут начнется если работодатель начнет мне указывать чем в свободное время заниматься… дикость. Минус 1 балл к переезду в US :)

              Ну, это вопрос выбора и конкретного контракта. Моему текущему работодателю плевать вот, например. А куче других людей плевать на все эти внеклассные активности, судя по тому, как они хотят в Гугл. Хорошо, когда есть выбор!

        • wataru
          /#20422171

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

      • kashtan404
        /#20421759

        Не все так плохо. Могу сказать со стороны их поиска на позиции SRE. В Амазоне да, привет hackerrank. В Гугле, техническое интервью представляет из себя общение с сеньором/лидом на технические вопросы и последующее решение задачки, но онлайн и без привязки к синтаксису (хоть псевдокодом), лишь бы логика была верная. Конечно, вы скажете что, «да один фиг олимпиадные задачки решать», но по-моему мнению, это намного проще, когда есть живой диалог. Как минимум видно, что потенциальному нанимателю не все равно.

        • blind_oracle
          /#20422389

          В Гугле, техническое интервью представляет из себя общение с сеньором/лидом на технические вопросы и последующее решение задачки, но онлайн и без привязки к синтаксису (хоть псевдокодом), лишь бы логика была верная.
          Так это первый, удаленный этап же. Потом ты топаешь к ним в офис и имеешь 4-5 интервью по часу с разными людьми и вайтбордом. Может вайтборд уже и позволяют заменить на ноут, как указали выше, но это не делает процесс более полезным на мой взгляд.

          • kashtan404
            /#20423407

            Да, согласен с вами. Спрашивал у HR, про все этапы которые будут. Ответ был такой: есть несколько команд которые заинтересованы, поэтому на очном интервью, будут этапы с каждой из них. На что я попросил краткое описание стэка и задач, которые использует каждая из команд, чтобы сузить выборку. Оказывается так можно. Потенциально я снизил свои «шансы попасть в Гугл», но это и не является моей целью. Важно найти интересное место, а не громкое имя, имхо.

            • blind_oracle
              /#20423673

              Ответ был такой: есть несколько команд которые заинтересованы, поэтому на очном интервью, будут этапы с каждой из них
              Нет там команд в контексте интервью. Каждое из них с отдельным человеком — он потом пишет отзыв в Hiring Committee, который уже по совокупности отзывов от всех интервьюеров решает брать тебя или нет. И вот уже после этого только возможен выбор команды.

              Это насколько я понял как раз один из их способов избежать предвзятости при найме. Сомнительный, как по мне…

    • grinCo
      /#20420841

      В СНГ все легко и просто с работой. В бей эрия решения задачек не хватит для сеньера.

  6. vav180480_2
    /#20418921

    Меня однажды мой бывший руководитель (с которым я проработал несколько лет) лично рекомендовал в ЕПАМ (он там уже лет 5 работал), сказал собеседование плевое, можешь не готовиться. Я после работы прибежал на собеседование, красный, запыхавшийся (была весна, утром холодрыга, я был в теплой одежде, а днем уже жара — я вспотел пока бежал). Меня очень хотели завалить и таки завалили, я нервничал еще (первый собес за 10 лет). В итоге собеседование прошел другой мой коллега, лет на 10 младше, с гораздо меньшим опытом, но он готовился:) Мой бывший руководитель был удивлен не меньше меня, а еще сказал что я на интервьюирующих произвел впечатление больного человека (красный, потный и все такое:)) и я там вообще в черном списке теперь. Во как бывает. Хотя мобыть и к лучшему:)

    • vvbob
      /#20420159 / +1

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

      • arheops
        /#20420667 / +2

        Может это был тест на то, спросите ли вы «зачем» или нет

        • vvbob
          /#20421193

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

          • Mirn
            /#20421215

            эхх еслиб они ещё эти уроки делали и статьи читали, как то на вакансию разраба электроники автооборудовния, на полном серъёзе, попросили заполнить анкету, в которой часть вопросов была связана с гос тайной а часть что то там про звания и устав. Погуглив понял что это взято из военного опросника в случае если человек с секретностью хочет забугор и это не первая а N ая анкета в случае… итд

            • vvbob
              /#20421311

              Часто эти собеседования просто вешают на какого-либо человека, особо не интересуясь его желанием всем этим заниматься, а он идет по пути наименьшего сопротивления, «наотлюбись». Вот и имеем, то что имеем. Хорошие кандидаты отсеиваются, на фирме дефицит специалистов да еще и рабочее время проводящих интервью оплачивается впустую.

    • VolodjaT
      /#20420409

      А в черный список за что?

      • Mirn
        /#20420789 / +1

        Да чёрные списки скорее всего существуют, например, украинский чёрный список на весь инет прославился. Ну а я умудрился попасть в чёрный список Яндекса, и сразу рекрутеров со всех галер типа датаарта и епама как рукой сняло, они после этого даже прервали диалог который вёлся. А попал забавно — им нужно было сделать ускорение нейронок на FPGA причём скорее аппаратную часть, забраковали меня после теста на веб программирование с формулировкой «не ИТшник а мошенник какой то, в чёрный список тебя!» после того как я честно признался что на JS дерево не могу развернуть и не знаю что за грязные хаки мне на задание выдали (а там судя по исходникам просили объяснить смысла такого трешака за который в нормальных фирмах сразу увольняют, я потом на разных сайтах просил растолковать их «примеры» извиняюсь за ругательство — все плювались от быдлокода).
        А раз чёрные списки скорее всего существуют, то проблема в статье ещё сильнее усугубляется: Даже если предположить что только часть компаний их придерживается, то при невезении всего с одной все остальные лишаются специалиста. И наверное поделом им.

        • vvbob
          /#20421203

          Когда последний раз искал работу, на меня выходили вербовщики от яндекса, предлагали пособеседоваться, сразу честно сказали что процесс займет недели три (там что-то то-ли четыре, то-ли пять собеседований по несколько часов). Так-как у меня уже были на руках два хороших оффера, то я вежливо отказался. Я, конечно, понимаю, это одна из самых известных российских IT фирм, но такой формат поиска спецов от них многих отпугивает. Это нужно ну очень сильно хотеть работать у них, что-бы такой марафон пройти.

          • blind_oracle
            /#20421375

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

            После этого решил на зазывания их рекрутеров забить, только время тратить без обратной связи нормальной.

            • coolkimchi
              /#20422333

              ну, это известная своими программистами контора. Как-то я проходил интервью на Python разработчика и интервьюер спросил в чем разница:

              a = 1
              b = a
              a == b vs a is b

              Я ответил, что в данном примере разницы нет и оба True и даже попытался объяснить ему почему Python не C/C++. В итоге интервьюер надменно «очень удивлюсь если это действительно так». Через HR я попросил передать ему книжку Python для чайников и больше не писать мне.

              • Debug_all
                /#20423775

                a = 1
                b = a
                a == b vs a is b

                Я ответил, что в данном примере разницы нет и оба True и даже попытался объяснить ему почему Python не C/C++.
                Не могли бы раскрыть свою мысль и направить в документацию в правильном направлении?

                На мой, не специализирующийся на Python, взгляд, вопрос имеет под собой почву:
                a == b # сравнение по значению
                a is b # сравнение по object id, на который ссылаются переменные
                И в случае с мутабельными объектами разница может быть:
                a = [1, 2, 3]
                b = a # произойдет присвоение по ссылке
                с = a.copy() # произойдет присвоение по значению
                d = a[:] # произойдет присвоение по значению
                
                # Значения всех трех переменных равны:
                a == b # True
                a == c # True
                a == d # True
                # Но переменные a и b ссылаются на один и тот же объект списка:
                b is a # True
                # А переменные c и d ссылаются на отдельные объекты:
                c is a # False
                d is a # False
                
                # Модифицируем данные:
                a.append(4)
                b.append(5)
                c.append(6)
                d.append(7)
                # И получим:
                a == b # True
                a == c # False
                a == d # False
                b is a # True
                c is a # False
                d is a # False
                
                # Через переменные a и b был поочередно модифицирован один и тот же объект.
                # Значения этих переменных по-прежнему равны:
                a # [1, 2, 3, 4, 5]
                b # [1, 2, 3, 4, 5]
                # А для переменных c и d - нет:
                c # [1, 2, 3, 6]
                d # [1, 2, 3, 7]

                • coolkimchi
                  /#20423895

                  >>в данном примере разницы нет

                  Небольшие integers (кажется, до 16 но не ручаюсь) существуют в памяти Python программы как синглтоны и все ссылки указывают на один и тот же объект в памяти.

                  • Fedorkov
                    /#20424297

                    Вы, должно быть, путаете с интернированием строк.

                    Если размер переменной меньше, чем указателя, её таким образом не оптимизируешь.

                    • coolkimchi
                      /#20424481 / +3

                      О, а вы, видимо, из Яндекса :)

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

                      docs.python.org/2/c-api/int.html

                      В памяти хранится весь массив int в пределах, который попадает под оптимизацию.

                • Debug_all
                  /#20427501

                  Вопрос к сообществу и заминусовавшему в частности.
                  В чем в примере выше ошибка по существу?
                  Был бы признателен за конструктивную критику.

              • MaM
                /#20425409

                Все же тема не раскрыта. И почему питон не с++ то?

      • vav180480_2
        /#20420939

        Мне после первого собеса сказали подготовиться и попробовать снова, я подготовился и попробовал снова, мне почему то написал мой бывший начальник, его даже попросили (видимо чтобы ответственность не нести, мало ли что) и сказал что я там плохое впечатление произвел (больной или болезненный что то такое) и мою кандидатуру теперь не рассматривают в принципе, если это не ЧC, то что?

        • monah_tuk
          /#20421217

          По поводу, "больного", запыхавшегося. Я бы сходу выдал что-то подобное: "так к вам спешил, что аж дыхание сбил, да и погода внезапно намекнула, что одеться нужно было полегче". Имхо, много бы вопросов сняло :) Я, бывает, вставляю словечки, которые актуальны для игроков в онлайн PRG, так меня с опаской сразу спрашивают — в онлайн игры играете? Приходятся говорить, что любимая RPG — Fallout 2, разок в год-два пробежаться. В общем, тут скорее вопрос коммуникации. Честно, каким бы мегаграмотным не был бы человек, с ним ещё общаться нужно.

          • vav180480_2
            /#20421733

            Это был мой первый собес за 10 лет, возможно я не придал значение такой мелочи (с моей точки зрения, сейчас понятно что это реально не мелочь, потому как не просто спеца, а человека берут), все-таки это кое чему меня научило, к любому собесу надо готовиться, хотя-бы морально:) внешний вид и состояние тоже имеют значение. Опять же, оно и к лучшему, я соскочил с PL/SQL на более популярный стек, проблем с работодателями стало на порядок меньше и лишний раз понял что крупные компании это не моё (были еще Неткрекер и Куйбышевазот) — непонятная шестеренка которая непонятно что и для кого делает, на входе это, на выходе то, почему и зачем? — так в документации, мне как то поближе к человеку хочется.

    • mopkob
      /#20421911 / +1

      Прочел статью. Закрыл хабр. Вернулся.

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

      Про «нравишься» и «не нравишься», про возраст (скоро стукнет 45), про рынок труда который отдельные представители HR так структурировали (есть примеры корпораций и компаний), что приходящие вновь команды не могли не то, что специалиста нанять… На интервью никого затащить. При весьма конкурентных предложениях, ведь в кругу нужных специалистов 3% слила одна из предыдущих команд, 15% побывали на интервью и были растоптаны.

      И в этом контексте желание научится решать задачки выглядит довольно мило.

      Их обязательно нужно уметь решать. Однако это сомнительный гарант устройства на работу.

      А потребительское отношение к кадровому ресурсу — короткая дорога, оканчивающаяся тупиком.

  7. RPG18
    /#20418939

    Хорошо если 1 час. В некоторых компаниях приходится проходить N собеседований по часу, на которых решаешь задачки. Где N зависит от количество команд, в которых открыты вакансии. Может быть 5, а может 11.

    • irsick
      /#20418969 / -1

      А могут пригласить в главный офис, оплатить 6-часовой перелет и отель, чтобы завалить на самом последнем этапе.

      • Zoolander
        /#20421023

        мне кажется, в Лас Вегасе это называется не собеседование

    • snuk182
      /#20419041

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

      • Mirn
        /#20420817 / +1

        Как то взяли разработку пищалки которая пикает прерывисто когда у грузовика включается задняя передача, всё именно так и было: десятки скайп совещаний с полсотней менеджеров и директоров разных там газмяс-альф и бетт, почта превратилась в вообще Re:Re:Re:Re:… теперьточноокончательная версия(2197) с почти стократным вложением. Кое как вытянул проект и уговорил их взять готовый именно для этого предназначенный и сертифицированный на всякие морозы и IP69 компонент с защитами от всего, генертором и динамиком, из новоразработанного только крепление и корпус был.
        Хотя изначально надо было просто узнать форму корпуса и чёртёж посадочного места что обычно делается за пару бесед с адекватным бизнес процессом не нацеленным на оправдание завышенной стоимости. Да они потратив миллионы рублей на совещания потом ещё тянули до последнего с оплатой несчастных 50тр.

    • TheKnight
      /#20420281 / +1

      Где вы такую жуть встретили? В Яндексе?

      • Whuthering
        /#20420589 / +1

        У меня такое в Яндексе было, да.

        • Mirn
          /#20420829 / +2

          в Японском аналоге Яндекса есть ещё круче: там после кучи собеседований нужно прочитать всю книгу-автобиографию основателя компании ну «очень скромно» названную «моя великая борьба» и написать изложение по ней во время спец экзамена без инета и под надзором, ну и конечно всё это на японском.

          • vladkorotnev
            /#20420857 / +2

            Это у ракутена такие приколы?
            Помню, они пытались меня схантить, видимо хорошо, что не поддался :-)

            • baton4iik
              /#20420895 / +2

              Ракутен. 3 месяца собеседований. 4 интервью. В конце попросили написать эссе на книги основателя, но, благо, можно было писать дома и на английском. Похоже, если не боготворить митера Микитани, то в ракутен не попасть.

              • monah_tuk
                /#20421229

                А что… Пишешь эссе с названием "Моя (не)великая борьба" где просто стебёшься над тремя месяцами собеседований. Да ну его нафиг, им специалист или жополиз нужен?

                • senglory
                  /#20422847 / -2

                  «Я — Начальник, ты — дурак» — все вполне в духе этих косорылых макак, которые устроили Фукусиму, создав 14 уровней начальников над оператором АЭС с нулевой ответственностью в итоге.

                  • hd_keeper
                    /#20424169

                    с нулевой ответственностью в итоге.

                    Для этого и создавали.

              • siziyman
                /#20423043

                Сейчас Ракутен очень (слишком!) легко набирает на работу выпускников российских вузов без всяких подобных извращений.

                Оффер получил, не поехал.

          • lanseg
            /#20421177 / +1

            О, я тоже в Ракутен собеседовался, мне тоже дали книжку. Я прямо спросил "Это обязательно? А то я не люблю весь этот успешный успех", мне ответили "Ну не хотите — не читайте, положено предлагать, а дальше дело ваше. Всё равно, никто не спрашивает."

            • monah_tuk
              /#20421231 / +1

              "А что, так можно было!?" :)))

              • lanseg
                /#20421417

                Видимо, можно, оффер-то мне выдали. Я даже думал его принять — всё же, Япония, экзотика, пару лет вполне можно поработать, но огорчил отпуск — 11 дней и нельзя выбирать самому даты. Даже с учётом золотой и серебряной недели это слишком мало.

                • Neikist
                  /#20421465

                  11 дней не считая выходных? Мне казалось в японии норма 3-5, по крайней мере в первые годы. Или там тоже итшникам послабления?

                  • lanseg
                    /#20421505 / +1

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

                • monah_tuk
                  /#20422625

                  ИМХО, это только если очень хочется "за границу". Либо ну очень сильно к их культуре тянет. Климат тоже… Теплее, чем у меня во Владивостоке, но так же влажно. Да и менталитет относительно работы у них другой.

                  • Anarchist
                    /#20423553

                    Такие же раздолбаи, как и везде.

                • Anarchist
                  /#20423543

                  Почему всем можно, а вам запретили? :)

      • RPG18
        /#20421781

        Верно угадали. Приятель проходил два года назад, он забил после 11 собеседования. Я проходил этот квест в июне было 5. Никаких вопросов про паттерны, языки программирования, базы данных и т.д. Тупо решаешь задачки.

  8. neurocore
    /#20418947

    Я люблю задачки, особенно на собеседованиях. Одно расстраивает — это совсем не коррелирует с тем, чем ты будешь заниматься в компании.

    • nochkin
      /#20419529 / +1

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

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

  9. bugsfinder
    /#20418991

    Все правда, все о нас...

  10. Izulle
    /#20419005

    Я люблю решать задачки, но мне их далеко не на каждом собеседовании задают. Более того, туда, где я все задачки решила, меня не взяли. Даже 2 раза. Зато взяли туда где никаких задач не задавали.
    Однако обижаться не стоит. Просто цена ошибки при найме довольно высока, а нормальных способов оценки кандидатов нет.

    • JustDont
      /#20419121 / +2

      нормальных способов оценки кандидатов нет

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

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

      • siziyman
        /#20423139 / +1

        разговор «по душам» о прошлом опыте и сложных случаях из жизни

        Может быть проблемным, если много что под NDA.

        • JustDont
          /#20423151 / +1

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

          • siziyman
            /#20423219 / +1

            Я встречал задачи, рассказ о которых вне бизнес-конкретики абсолютно лишает разговор смысла.

            • PsyHaSTe
              /#20431439

              Вряд ли NDA защищает диаграмки вида "вот тут у нас сыпались сообщения в очередь, сервис разбирал и писал в эластик, а вот тут фронт оттуда читает"

              • siziyman
                /#20431553

                Я не сказал, что не существует задач, которые невозможно обсуждать, если проект закрыт NDA.
                Я сказал, что есть задачи, к которым очень сложно задать разумные вопросы, и от которых совершенно невозможно отойти вправо-влево и развить беседу, если не понимать бизнес-задачи проекта, которые могут быть закрыты NDA.

                • PsyHaSTe
                  /#20431613

                  Формально есть, вопрос, в том ли ареале, где живет большинство разработчиков. Я лично думаю, что нет.

    • smarthomeblog
      /#20419161

      Олимпиадные задачки ведь тоже гарантии качества разработчика не дают. Тем более, сеньера. Тогда зачем они?

  11. ingvarwolf
    /#20419053

    В Монреале есть одна компания, у которой процесс найма на работу занимает очень продолжительное время. Самый короткий срок от первого собеседования по телефону до контракта, который я знаю, занял 6 недель. Самый длинный — 18 месяцев. Как правило они проводят несколько интервью по телефону и несколько личных встреч. Всегда на первом интервью задают вопросы о том как работает сборщик мусора, как там всё устроено. Ни один из проводивших интервью не смог мне внятно привести примеры из их реальных проектов, когда эти знания помогли или были по-настоящему необходимы.
    Я спрашивал нескольких разработчиков, которые работали в этой компании, как им приходилось использовать эти конкретные знания в работе. Самый лучший ответ: «Знание о том, как работает сборщик мусора, нужны чтобы пройти интервью. Больше они не нужны.»

    • AllexIn
      /#20419365

      Для меня ваше сообщение выглядит очень странным.
      Знание как работает GC нужны, чтобы понимать когда объект будет удален, чтобы понимать что если мы только что освободили большой объект и хотим сразу создать еще один большой объект, то нельзя расчитывать что память уже есть, её вполне может не быть(правда тут надо смотреть на конкретный GC, потому что есть такие, которые увидят что памяти не хватает и грохнут ранее освобожденный объект, а есть такие, которые так не делают. и это надо знать).
      В общем и целом, такие особенности рабочего окружения знать надо.
      Если ваши коллеги и вы живете без этого знания, скорее всего вы либо пишите мелкий софт, либо плохой.

      • snuk182
        /#20419441 / +2

        Как часто вы создаете объекты размером со всю доступную VM память?
        Как часто вам встречаются бизнес задачи, требующие создания объектов размером со всю доступную память?

        • amaksr
          /#20419917 / +2

          Как часто вы создаете объекты размером со всю доступную VM память?
          Это и не нужно. Достаточно в цикле читать и обрабатывать какую-нибудь таблицу (или запросы). Если в этом цикле используются любые ресурсы ОС, то забыть закрыть ресурс (а с ним и все связанные объекты) очень даже легко. И даже если не забыть, то не факт, что сборщик будет чистить так, как вам бы хотелось. Мне как-то довелось оптимизировать память процессу на яве. Поставил явный вызов GC, хоть во всех мануалах пишут, что это делатьне надо. Коллеги на ревью удивились, но после демонстрации уменьшения памяти на 50% смеяться перестали. Так что всяко бывает, а памяти всегда мало.

          • snuk182
            /#20419975 / +3

            забыть закрыть ресурс

            Это не "объект размером с память", это баг.


            не факт, что сборщик будет чистить так, как вам бы хотелось

            Для этого придумали пулы объектов.


            Поставил явный вызов GC

            Вам сильно повезло. Обычно жор памяти в Java = утечка. С множеством короткоживущих объектов GC справляется без полной остановки, чисто за счет Эдема.

            • amaksr
              /#20420275

              Вам сильно повезло. Обычно жор памяти в Java = утечка.
              Вот код без утечек, только-что запускал:
              public class MyTtest {
              	public static void main(String argc[]) {
              		while(true) {
              			List<String> arr = new ArrayList<String>();
              			for(int i=0; i<10000000; i++)
              				arr.add(new String("abc"));
              			System.out.println(new java.util.Date());
              			System.gc();
              		}
              	}
              }
              

              Запустил без строчки с GC, процесс быстро набрал 2GB оперативки, CPU циклично скакал от 25 до 90%,
              лог выглядел так
              Mon Jul 22 15:39:31 EDT 2019
              Mon Jul 22 15:39:34 EDT 2019
              Mon Jul 22 15:39:34 EDT 2019
              Mon Jul 22 15:39:35 EDT 2019
              Mon Jul 22 15:39:35 EDT 2019
              Mon Jul 22 15:39:37 EDT 2019
              Mon Jul 22 15:39:37 EDT 2019
              Mon Jul 22 15:39:39 EDT 2019
              Mon Jul 22 15:39:39 EDT 2019
              Mon Jul 22 15:39:42 EDT 2019
              Mon Jul 22 15:39:43 EDT 2019
              Mon Jul 22 15:39:43 EDT 2019
              Mon Jul 22 15:39:46 EDT 2019
              Mon Jul 22 15:39:46 EDT 2019
              Mon Jul 22 15:39:47 EDT 2019
              Mon Jul 22 15:39:50 EDT 2019
              Mon Jul 22 15:39:50 EDT 2019
              Mon Jul 22 15:39:51 EDT 2019
              Mon Jul 22 15:39:51 EDT 2019
              Mon Jul 22 15:39:51 EDT 2019
              Mon Jul 22 15:39:53 EDT 2019
              Mon Jul 22 15:39:53 EDT 2019
              Mon Jul 22 15:39:54 EDT 2019

              • Endeavour
                /#20420287

                В зависимости от GC, вызов System.gc() может быть заимплеменчен как угодно, в том числе и nop.

              • snuk182
                /#20420325 / +1

                Резюме: так писать не надо, и вот почему:


                • с добавлением ноликов в условие цикла разница будет все менее заметной
                • в многопоточном приложении вы получите паузы во всех потоках, и это не обязательно то, что вам позволено
                • более того, явный вызов GC совершенно не гарантирует запуск GC, это зависит от множества факторов и малопредсказуемо в общем. Например, в моем случае (openjdk-11/i7-8750H/16G) в данном примере постоянный вызов GC жрал те же 100% проца и вдвое больше оперы, чем без явного вызова. Зато замена GC на Thread.sleep(500) успокоила процессор в прежних пределах памяти.
                • если придираться: конкретно в этом случае стоит использовать пул. Думаю, это понятно и так, просто сделано в угоду постоянному выделению большого куска памяти, но на практике такое даже джуны себе не позволяют. Кейсы с массивным выделением памяти обычно предсказуемы и предусматриваются архитектурой приложения в особом порядке.

                • amaksr
                  /#20420441

                  с добавлением ноликов в условие цикла разница будет все менее заметной
                  вообще-то, если добавить нолик, то у меня программа без GC просто падает достигнув 2GB RAM (java se 1.8 под виндой). А с GC работает.
                  в многопоточном приложении вы получите паузы во всех потоках, и это не обязательно то, что вам позволено
                  не факт, ведь я же не получаю паузы в одном потоке, даже наоборот — в данном однопоточном быстодействие с GC в разы выше.
                  более того, явный вызов GC совершенно не гарантирует запуск GC
                  здесь полностью согласен, нужно экспериментировать
                  если придираться: конкретно в этом случае стоит использовать пул
                  я список сделал такой большой чтобы сразу было понятно чем занята память процесса — надо же чем-то заполнить пару гигов. Но при других значениях счетчика я получил похожий результат, что с GC работает лучше: видимо моя имплементация GC прислушивается к советам, и это позволяет оптимизировать программу.
                  Вобще всему этому есть объяснение: только программист может знать когда в его программе лучше сделать сборку мусора, так как это зависит от множества факторов, которые из кода и рантайма вычислить или невозможно, или слишком сложно, и поэтому такая задача сборщику может быть в принципе не под силу. Поэтому хотелось бы, чтобы со сборщик перестал быть черным непредсказуемым ящиком.

                  • Source
                    /#20420463 / +4

                    только программист может знать когда в его программе лучше сделать сборку мусора

                    Поэтому хотелось бы, чтобы со сборщик перестал быть черным непредсказуемым ящиком.

                    В чём проблема? Пишите на Rust.

                  • snuk182
                    /#20420469

                    программа без GC просто падает достигнув 2GB RAM (java se 1.8 под виндой). А с GC работает.

                    Что вообще-то ненормально — разница всего лишь в явной рекомендации вызова мусорщика. При тесной физической памяти мусорщик должен вызываться и без запроса.


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

                    Я не о том. В случае сервера приложений вам прямо запрещено так вызывать мусорщик — будут остановлены все потоки, которые заняты неизвестно чем и насколько важным для пользователя.


                    Поэтому хотелось бы, чтобы сборщик перестал быть черным непредсказуемым ящиком.

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

                    • user_man
                      /#20422561

                      >> В случае сервера приложений вам прямо запрещено так вызывать мусорщик — будут остановлены все потоки

                      А с чего вы это взяли? Или про nop не читали? И да, вот это ваше — «это не просто не черный ящик, это хрень с кучей параметров и ручек для тонкого тюнинга под конкретные задачи» тогда как понимать? Ну и для полноты — вы в курсе как ведёт себя GC при наличии нескольких class loader? С учётом кучи параметров и ручек для тюнинга, разумеется.

                      • snuk182
                        /#20422959

                        1. Несмотря на то, что GC в JVM постоянно улучшается, энтерпрайзные заказчики крайне неохотно перелезают даже на Java 8, не говоря уже о более поздних версиях. И я не слышал о полном отказе от stop-the-world тактики в худших случаях GC даже с Java 11, такое умеет (умел?) только Azul — то есть всегда есть шансы получить StW, которые возрастают при ручном вызове gc(). Может если порыть офдоку, где-то найдется явное упоминание StW независимо от количества потоков приложения (я не задавался целью найти), но просто по логике — общая куча + Full GC + старые не ThreadLocal-данные = хороший повод для StW.
                        2. Количество класслоадеров влияет на мусорщик только в том плане, что для деинициализации объекта нужен соответствующий его классу лоадер. В старых джавах была проблема чистки пермгена в случае нескольких лоадеров, потому что пермген в силу своей природы херово чистится. Сейчас с общим метаспейсом проблем мусорщика, связанных с класслоадерами, нет или мало (исключая случаи кастомных класслоадеров, но это еще более отдельная тема). Но я говорил о потоках, а не класслоадерах, а если потоки шарят общую кучу, StW вполне реален.
                        3. Я вам не отвечку про настройки GC, потому как последний раз явно касался этого еще при Java 6, с коих пор прошло достаточно времени и изменений JVM, о которых знаю лишь в теории. В большинстве случаев вопрос о тюнинге памяти встает только после проблем с производительностью, и решение этого вопроса очень индивидуально.

                        • user_man
                          /#20428033

                          Вы упираете на остановку всей java-машины, но сами отлично понимаете, что это явление редкое, случающееся только тогда, когда уже ничего не помогает. Соответственно — если ситуация не находится в состоянии «всё безнадёжно», то явное указание на сбор мусора машина может воспринимать очень по разному, включая отсутствие каких-либо действий. Ну а если «всё плохо» всё же наступило, то запустите ли вы gc сами, или это сделает машина — без разницы, ибо мир всё равно остановится. При этом, как вы сами знаете, толстые конторы никогда не спешат с модернизацией парка серверов по первому писку очередного малолетнего гения, а потому там есть весьма стабильная среда на какой-нибудь веб-сфере 7.0, где всё прекрасно можно отладить один раз и далее годами ни о чём не беспокоиться, ну а за эти годы, как известно, либо ишак, либо падишах. Поэтому с практической точки зрения ваше желание быть осторожным ведёт лишь к бессмысленному повышению сложности в и без того сложном толсто-корпоративном мире.

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

                          • snuk182
                            /#20428189

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

                            • user_man
                              /#20428963

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

                              • snuk182
                                /#20430821

                                Не спорю. Но в случае спорных решений — они должны быть обсуждены и оправданы. И документированы.

                    • balexa
                      /#20423347

                      Что вообще-то ненормально — разница всего лишь в явной рекомендации вызова мусорщика. При тесной физической памяти мусорщик должен вызываться и без запроса.

                      Вы все верно говорите. Но в реальности, мало кого интересует, что должен делать GC, как должен оптимизировать компилятор, и т.д, можно ли создавать объекты в цикле.

                      А интересует, как это все работает. И да, черный ящик то черный, но он имеет вполне конкретное устройство. И зная это устройство можно писать более производительный или менее требовательный к памяти код.

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

                      Да с чего вы решили что явный вызов GC == stop world?

                      • snuk182
                        /#20423433

                        Я имею в виду, что что шансы StW сильно повышаются при явном вызове. И про черный ящик я не говорю, наоборот опровергаю — высокая нагрузка требует понимания внутренностей и подгонки их под конкретный случай, а это должно быть позволено языком/VM и документировано. Но я бы не спрашивал о тонкостях управлением GC на интервью, разве что позиция напрямую требует.

              • Source
                /#20420457 / +4

                Явный вызов GC — это скорее симптом того, что у вас что-то не в порядке с самим алгоритмом. Как правило, в таких случаях достаточно несложно переписать так, чтобы, в принципе, минимизировать аллокацию памяти.

                • amaksr
                  /#20420473 / -1

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

                  • Source
                    /#20420619 / +2

                    Это звучит примерно как: нас устраивало O(n?3), и всё было нормально до тех пор, пока n не начало расти.

                    • alex_zzzz
                      /#20423099 / +1

                      С этой фразой всё в порядке.

                    • balexa
                      /#20423383 / +1

                      А что тут такого? Вполне нормальный подход.
                      Более того, алгоритм n^2 бывает значительно быстрее чем n log n. Для примера взять реализацию той же сортировки почти во всех библиотеках всех языков.

                      • alex_zzzz
                        /#20423605

                        На небольших n И/ИЛИ маленьких константах и n^3 может быть вполне нормально, т.к. всё равно быстро, а напишется за минуту в 4 строчки, скорее всего.


                        O() само по себе, в отрыве от значений констант и практических значений n, не несёт большого смысла. Вот когда n стремится в бесконечность, когда да, несёт, а так — нет.

                  • PsyHaSTe
                    /#20431485

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

                    • amaksr
                      /#20431603

                      У нас в конторе (вернее сказать, у нашего клиента) видел только один апгрейд VM за 5 лет. Причина проста: на нескольких серверах крутится около сотни приложений и сервисов, и при любом апгрейде нижележащих компонент приходится регрессивно тестировать всё. А суппорта на Java-приложения всего 8 человек…
                      Поэтому, посмотрев на результаты тестов, посоветовавшись внутри команды, и, естественно, с клиентом, коллегиально был сделан выбор вставить строчку с GC в код, а не переписывать кучу legacy-кода.
                      Клиент был очень доволен, так как этот вариант позволил решить проблему минимум на пару лет, а там условия и требования скорее всего опять изменятся.

                      • Endeavour
                        /#20432673

                        Клиент был очень доволен, так как этот вариант позволил решить проблему минимум на пару лет, а там условия и требования скорее всего опять изменятся.
                        Можно так сказать. Пофиксить умирающий прод действительно сойдет.
                        А можно сказать — «накинули еще тыщу техдолга в общий котел», если после фикса на эту строчку все благополучно забили.

                • Druu
                  /#20420891

                  Явный вызов GC — это скорее симптом того, что у вас что-то не в порядке с самим алгоритмом.

                  На самом деле нет. Учитывая особенности работы перемещающих сборщиков, сдвинув время вызова gc, можно на десятичные порядки снизить затраты на этот gc. Потому что сам по себе сборщик не знает, когда у вас достижимые объекты дают локальный минимум.

                  • Source
                    /#20422245

                    Я про то, что сначала стоит задаться вопросом: как избежать создания большого кол-ва объектов на ультракороткий срок? А не сразу переходить к вопросу: как побыстрее собрать мусор?
                    Чисто не там, где убирают, а там, где не мусорят )))

                    • Druu
                      /#20425691

                      Я про то, что сначала стоит задаться вопросом: как избежать создания большого кол-ва объектов на ультракороткий срок?

                      Это как раз не вопрос, т.к. данный кейс нормальными сборщиками отрабатывается наиболее оптимально, в этом случае сложно заставить тормозить, а не наоборот :)
                      Так что избегать создания объектов на ультракороткий срок, обычно, не надо.
                      Проблема возникает в объектах со средней продолжительностью жизни — когда у вас етсь некоторая задача и выделяемые объекты нужны до окончания ее работы. И, конечно, зачастую можно справиться перереботкой алгоритма и ворохом микрооптимизаций. Но нередко одна строчка с вызовом гц даст значительно больший эффект.
                      Очень печально, конечно, что в той же jvm вызов гц по ручной команде не обязателен.


                      Вообще, жаль, что обычно программисту не дают способа локального тюнинга гц "изнутри" программы. Вроде как "вот на этом участке гц не вызывай" или "сделай мне здесь nursery размером Х" и т.п. вещи.

        • ofigenn
          /#20420293

          Как раз на днях конвертил ~100Gb видео потока. Немного ошибся с реализацией стрима и бац) Но я смог)

          • snuk182
            /#20420355

            Круто :) А как с производительностью? Неожиданное применение языка с автоматическим управлением памятью, если честно.

            • ofigenn
              /#20420389 / +1

              Я вам страшную вещь сейчас скажу: я на JavaScript написал обертку, а само сжатие я делал через ffmpeg)
              Главное получилось и быстро) Просто разовая задача)

      • playermet
        /#20419725 / +7

        Знание как работает GC нужны, чтобы понимать когда объект будет удален
        При этом сама концепция GC создавалась, чтобы программисту не приходилось заморачиваться тем, когда объект будет удален.

        • AllexIn
          /#20419923

          Создавалась, да. Но при этом существование GC всё равно надо учитывая в процессе разработки, так или иначе.
          Весь гугл в своё время был завален обсуждением Android bitmap recycle.
          И это только одна тема, где играю особенности GC. А так — GC везде очень активно обвешан костылями и особенностями.

          • snuk182
            /#20419993

            Android bitmap recycle

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

            • AllexIn
              /#20420035

              А какое значение имеет причина?
              Факт есть факт — просто принять «у меня GC» и больше не думать о том, что так под капотом — не получается почти никогда.

              • snuk182
                /#20420051

                Так это баг АПИ, документированный и впоследствии исправленный. Конечно же, документация открывалась после первого ООМа. А сейчас уже вполне можно следовать заповеди "у меня GC", с текущими-то гигабайтами оперативки в смартфонах. Чем разработчики невозбранно и пользуются — приложения жрут все больше и больше.

                • AllexIn
                  /#20420055

                  Разработка не ограничивается смартфонами.
                  Ну и в целом это лишь пример. Таких примеров — вагонами.

                  • snuk182
                    /#20420229

                    Насчет вагонами — очень спорно. В случае широко известных приколов, где GC не работает, как выше, вопросы задаются конкретно под них. Еще меня бывало спрашивали про ключи JVM, имеющие отношение к управлению памятью, но это было собеседование внутри компании на сеньорность после релиза проекта, где нужно было нестандартно тюнить кучу и GC.

              • depadep
                /#20423029 / +1

                Около десяти лет назад так рассказал о .Net GC на собеседовании, что после офера меня отдельно спросили откуда я всё это знаю.
                С тех пор эти знания на практике не пригодились ни разу, даже на проекте с очень активной работой со всей доступной оперативной памятью.
                Похожая ситуация с сортировками и бинарными деревьями (но пару раз пригождались, как и знание О большого разных алгоритмов).
                А вот знание принципов проектирования, рефакторинга, тестирования — требовалось на каждом проекте. Теорвер, мат. логика и работа с координатами реже, но тоже бывало.

        • gudvinr
          /#20420269 / +2

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


          Это действительно средство от человеческого фактора — невнимательности, а не от нежелания разбираться с инструментом, которым пользуешься. GC всё-таки инструмент, которым может либо помочь что-то хорошее созидать, так и наговнокодить рано или поздно, если не знать про особенности.

          • PsyHaSTe
            /#20431453

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

      • dominigato
        /#20419895 / -2

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

        • alex_zzzz
          /#20423143

          Либо хорошие (с технической стороны) игры.

      • ingvarwolf
        /#20420647 / +1

        Я не писал, что не знаю, как работает сборщик мусора. Я написал, что одна фирма отсеивает множество кандидатов на первом интервью такими вопросами и при этом ни один из собеседовавших меня людей не смог мне внятно привести пример как им это помогло в работе. Я знаю какие у них проекты, и они не маленькие. Качество — уж простите, не проверял.
        Я не писал, что не прошёл такое первое интервью. Я просто получал оффер из другой компании раньше, чем эта компания звала меня на следующее интервью, у них очень длительный процесс найма.
        Мне приходилось проводить технические интервью, то есть я был по обе стороны в процессе найма на работу. Я готовил вопросы на темы, которые плотно используются в проекте, на который мы искали кандидата. Время интервью ограничено и сроки поиска нового программиста в команду тоже не резиновые. Поэтому лучше уж спрашивать знания того, что конкретно используется в проекте, чем знания о внутреннем устройстве Java, которые при достаточно прямых руках могут и не понадобиться.
        Я знаю лично много программистов, которые затрудняются объяснить устройство сборщика мусора, но при этом пишут нормальный код с минимальным количеством проблем. И знаю также программистов, которые идеально расскажут как устроен сборщик мусора и как работает память в Java-приложении, но при этом пишут вот такой код:

        class SomeClass {
            private String someValuableData = "Most Valuable Information";
        
            /* Getters and Setters are ommitted. */
        
            public void updateData(String newData) {
                this.setSomeValuableData(this.getSomeValuableData());
            }
        }
        

        Пример утрированный конечно, но суть проблемы демонстрирует. Реальный пример из реального проекта.

        • PsyHaSTe
          /#20431457

          "Такой код" демонстрирует опечатки, написание бесполезных дублирующих сеттеров или что-нибудь еще? Затрудняюсь понять, что является частью примера, а что упрощением для читателей.

    • Neikist
      /#20419513

      Я бы скорее предположил что вопросы по работе GC это из разряда вопросов на эрудицию, интерес к теме, широту этих самых интересов.

    • DrunkBear
      /#20421771

      Возможно, они хотели получить встречный вопрос «какой именно из алгоритмов GC?»
      На хабре был цикл статей по ним ( если интересно — тык )

  12. truebest
    /#20419135 / +2

    Скоро мне стукнет 45 и свой стартап (где был CTO) я покинул в декабре. С тех пор я завалил не меньше 10 тестов и интервью на программиста. Пишу код при этом я уже почти 20 лет, включая создание прошивок (по образованию я инженер-электронщик) и полномасштабные распределенные веб-приложения с интеграцией IoT. Я с нуля создавал ПО для крупных специализированных производственных объектов по всему миру. Тем не менее, я просто не могу устроиться программистом, потому что постоянно проваливаю эти тестовые задачки.


    Тем-же занимаюсь по сути, и кодингом и железом, iot и все что с ним связано, также есть крупные реализованные проекты, есть свой стартап, но переодически уделяю время прохождению интервью, хоть и работать там как правило не собираюсь. Очень нравятся собесы по Skype и тп. Для меня обычно выглядит так, 2-3 интервью проваливаю, потом есть предложение и я отказываюсь. Вопросы на 1-3 интервью практически однотипные, и по факту на повторение. Некоторые вещи, которые никогда не применяю, да и в здравом уме они не нужны, просто записываю, и потом на следующем интервью отвечаю.
    С этого года ноу-хау добавилось, спрашивают часто про контроль версий, про управление задачами, проектами, и другие инструменты, ну и вообще как ты придумываешь, как и куда записываешь, с кем обсуждаешь и как реализуешь.
    Все это превратилось уже даже не в решение тестовых задачек, за решение которых тебя все равно не возьмут, тк ты не знаешь jira или еще какой инструмент, а в банальные как нужно отвечать и как не нужно отвечать. Психопатия. Это и называется навыком прохождения интервью.

  13. pvsur
    /#20419151 / +5

    Анекдот в тему:
    Работают два HR, опытный и молодой. Приходит стопка резюме на должность топ-менеджера. Опытный сразу берет и половину стопки отправляет в корзину. На удивленный взгляд молодого коллеги коротко отвечает: — А зачем нам топ-менеджер — неудачник ?!

  14. smarthomeblog
    /#20419153

    Столкнулся с подобным сам, когда искал работу. Такое ощущение, что идет поиск не сеньера, а участника игр «Что. Где. Когда». Разнообразие задачек ограничивается только фантазией нанимателя. Тут тебе и веселые шарады, и вопросы про паттерны (куда же без них родимых), и алгоритмы. А потом откроешь проект, а там — контроллеры с методами по 4-е экрана! Тестов нет и деплой по FTP. И вот назревает вопрос — для чего все это? Чтобы потешить свое самолюбие? Плюс ко всему, большая часть задач может быть решена больше, чем одним способом, как говаривал незабвенный Ларри Уолл.И не факт, что человек, проверяющий задание, имеет наиболее оптимальный вариант решения. Несмотря на то, что сам ее сочинил :)

    • snuk182
      /#20419183 / +3

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

      • smarthomeblog
        /#20419203

        В общем именно по рекомендациям в основном получалось устраиваться — без олимпиадных задачек как-то все получалось. И работодатели не жаловались :) И сам собственно нанимал нескольких людей просто по результатам беседы по теме. И нескольких с тестовым заданием, но без извращений. Просто чтобы оценить уровень. Тут из 4-х человек, три оказались на высоте, один — так себе. Но поняли это только по истечении пары-тройки месяцев.

        • snuk182
          /#20419229

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


          В противовес: один раз получил оффер после парного программирования с будущим архитектором, один раз выполнил довольно разумное тестовое задание по совершенно незнакомым мне ранее технолониям. Пару раз мне вообще задавали только вопрос вида "ну ты ж шаришь, да?" (да, оба раза по рекомендации).

      • urtow
        /#20419329

        Последние два раза устраивался работать по рекомендации.
        Интервью больше напоминало обсуждение тенденций в современном IT и обсуждение применимости стандартных решений/библиотек.

      • deitry
        /#20423287

        На текущую работу устраивался без рекомендаций, без корпоративного опыта (программировал только для себя и в аспирантуре в рамках коллектива из полутора человек). Уже прошёл собеседование в другое место, но тут вдруг позвонили, сказали, что заинтересовал, и дали тестовое задание, на которое я успешно забил. Через пару дней предложили хотя бы просто поболтать, и после того самого разговора по душам (ну и небольшого теста по языку на проверку адекватности) дали оффер. Всегда бы так.

    • mapron
      /#20420697

      А что не так-то? В компании не было знающего человека, они его нанимают, чтобы пришел и все сделал по-человечески (тесты и код по паттернам) :) если в требованиях вакансии это отражено — в чем проблема?

      • smarthomeblog
        /#20421271

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

        • mapron
          /#20426177

          Если расклад такой да, смахивает на лицемерие. Но это можно попытаться узнать на этапе собеседования вопросами «а чем вы планируете меня занять на новой должности?»
          если будет какое-то монотонное «поддержка ХХХ… сопровождение YYY...», то должно напрячь) можно спросить «а зачем указан в вакансии С++42, где он у вас там применяться планирует?» Я когда на работу устраивался, спрашивал как применяются указанные в вакансии технологии, мне вполне без утайки все сказали.
          Опять же странно если начнут отмазываться корпоративными секретами, ибо всегда можно найти способ как не сказать слишком много)

    • bodqhrohro
      /#20423607

      откроешь проект, а там — контроллеры с методами по 4-е экрана
      для чего все это
      Возможно, как раз для того, чтобы преемники не писали такой говнокод, а то и старый в порядок привели?

  15. Ketovdk
    /#20419159

    Дело не только в отсеве кандидатов. Просто часто бывает такое, что в коде есть явные алгоритмические ошибки, которые сразу же бросаются в глаза задачколюбам, но незаметны даже для людей с 15-тилетним стажем, которые являются отличными программистами, разбираются в архитектуре, патернах, чем угодно. И в итоге в месте, где должно работать за O(n) или O(log(n)) вылезает квадрат, который можно обнаружить уже только на проде или ближе к нему. Ну как обнаружить, просто все начнет валиться по тайм-ауту

    • Naglec
      /#20419371

      Нагрузочные тесты на что?

      • Ketovdk
        /#20419641

        ну обычно подобные недочеты лежат где-то глубоко в системе, например на ДЛ уровне, и когда от нагрузочных тестов (если даже допустить, что нагрузка была правильно оценена) время отдачи начинает просядать, то в лучшем случае приходится профилировать и находить эту ошибку (если посмотрит человек, который алгоритмы знает), либо же добавлять какое-нибудь кэширование и ждать, пока она всплывет снова.
        Я не хочу сказать, что это главное, что есть в разработчике, но и забивать, делая вид, что это никогда не пригодится не стоит. Может пригодиться. Причем обязательно там, где не ждешь (и даже не в самой большой системе)

        • Naglec
          /#20419687 / +2

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

          Это не отменяет необходимости понимания, что полный перебор — плохо, а кэширование — хорошо.

          В реальном мире, когда у нас есть performance-critical часть приложения, то у нас есть и время все обдумать, почитать, посоветоваться с коллегами, и нет никакой необходимости решать такую задачку на доске за 15 минут.

          • slonopotamus
            /#20419815 / +1

            реальные проблемы с производительностью вскрываются код-ревью

            Звучит как "это ок что я не умею искать оптимальное решение, пусть за меня мой коллега-ревьювер его ищет".

            • Naglec
              /#20419841

              Это звучит как «если я что-то недоглядел/не знал более удачное решение, то увидит кто-то другой или авто-тесты». В этом треде мы обсуждаем риск попадания неоптимального решения в прод, если что.

      • Ketovdk
        /#20419657 / +1

        и я не говорю о каких-то хардкорных оптимизациях с построением Ахо-корасика или дирамид, но если где-то можно легко и непринужденно поднять с O(n*n) до O(n) просто использовав хэш-таблицу, вместо кучи избыточных linq, делать это автоматически (а не когда начнет подгорать) вполне полезно

  16. dbelka
    /#20419209

    14 лет общего стажа в веб-разработке в достаточно крупных фирмах (где хайлоад и всё такое).
    Помимо основного неплохо знаю C++, писал расширения для PHP, решал задачи по ML и много чего ещё.
    Не собеседовался только уже как лет 7. Два собеса я уже не прошёл :-)

  17. Hydro
    /#20419245 / +1

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

    • playermet
      /#20419777 / +2

      Так это же совсем просто. Делаем счетчик, ставим ему 0. Если встречаем открывающую — прибавляем 1, закрывающую — отнимаем 1. Если счетчик в любой момент становится меньше 0, или больше 0 по завершению потока — значит ошибка. Или я не так понял задачу?

      • Hydro
        /#20420213 / -2

        Все-так)) На с Ваши решением следующие строки тоже будут валидны:
        }{, ][, )(
        Ожидается такой поток: {[<()>]}, и проверять нужно было именно правильность открытия-закрытия))
        В любом случае, я получил оценку «procedure inefficient» за реализацию и был послан hr далеко и надолго)

        • siziyman
          /#20420231 / +2

          Во-первых, нет, если внимательно вчитаться.
          Во-вторых, для разных вариантов скобок за 5 минут делается примитивный стэк.

          • Hydro
            /#20420369

            Да, Вы правы, читать было лень. Видимо поэтому и пролетел))

            • siziyman
              /#20420431

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

              • Hydro
                /#20420923

                В том то и дело, что я ее решил) Пусть и не самым оптимальным образом.
                Да и я ведь, вроде, не утверждал, что собеседующие плохие?..
                Я поддерживаю идею топика, что нерешение базовых задач на алгоритмику не обнуляет скилы программиста)) И уж точно нельзя отсеивать по такому признаку.

        • Razoomnick
          /#20420279 / +1

          Заводим стек, начинаем обрабатывать поток. Открывающие скобки добавляем в стек. Удаляем элемент из стека, если в потоке встретилась закрывающая скобка. Если при удалении тип скобок не совпал — ошибка. Попытка удалить элемент из пустого стека — ошибка.

          • Hydro
            /#20420319

            Все так и было сделано)

            • ainoneko
              /#20421195

              Все так и было сделано)
              Эээ… А что тогда у них считается эффективным?

              • VolCh
                /#20421655

                Ну, например, найти решение, когда поток (вернее уровень вложенности скобок) на порядок больше объёма доступной памяти.

                • JustDont
                  /#20421683

                  Принципиальное решение будет другим только тогда, когда вид скобочек строго один. В противном случае учёт порядка следования скобок (то есть стек в том или ином виде) — обязателен, вопрос с памятью варьируется только в том, сколько бит вам нужно для записи одной скобки. Алгоритмически это всё равно остаётся работой со стеком.

                • ainoneko
                  /#20422475

                  К каждой скобке в стеке добавить счётчик?
                  (А потом ещё проверять, помещается ли количество скобок в этот счётчик??
                  (Так и до числа Грэма дойти можно.))

                  • JustDont
                    /#20422753 / +1

                    Счётчик не поможет, важен порядок. Иначе будут проходить потоки типа "{([}])" — что, конечно, по условиям задачи могло бы быть допустимо, но «в жизни» такое обычно никому не нужно.

                    • ainoneko
                      /#20424999

                      К каждой скобке в стеке добавить счётчик?
                      Счётчик не поможет, важен порядок.
                      Почему не поможет-то? К каждой скобке:
                      "{((([[(..." — здесь в стеке:
                      ("{", 1), ("(", 3), ("[", 2), ("(", 1).
                      При появлении такой же (или парной) скобки, как в вершине стека, — увеличивать счётчик в вершине стека (соответственно, уменьшать (и выбрасывать при достижении нуля)).
                      Иначе будут проходить потоки типа "{([}])"
                      Как это получится?

                      • JustDont
                        /#20425057

                        А, вы в этом смысле. Ну а где тут особая экономия-то? Вот скажем, если у нас 2 вида скобок, то нам хватит 1 бита на каждую, а если вы рядом с каждым битом будете дописывать да даже 8 бит на количество, то расход памяти едва ли убавится — зависит от кейсов, конечно. Если ожидаются сотни одних открывающих скобочек — то наверное какая-то экономия будет. Если нет — то едва ли.

                        • ainoneko
                          /#20425141

                          Если ожидаются сотни одних открывающих скобочек — то наверное какая-то экономия будет. Если нет — то едва ли.
                          Если нет, то при формулировке
                          «например, найти решение, когда поток (вернее уровень вложенности скобок) на порядок больше объёма доступной памяти.»
                          задача становится немного слишком сложной.
                          (Можно, конечно, пытаться, например, использовать код Хаффмана или ещё что-нибудь для сжатия стека, но это уже извращения начинаются (мой вариант был "RLE-encoding", как в некоторых старых форматах картинок).
                          Или ваш вариант — упаковка в битовые поля (для трёх-четырёх видов скобок уже нужно по 2 бита — не очевидно, хватит ли памяти, если " уровень вложенности скобок на порядок больше объёма доступной памяти" (что бы это ни значило) ))

                • PsyHaSTe
                  /#20431479

                  С трудом себе такое представляю. Разве что гигабайтные потоки скобочек разбирать на 512 байтах памяти.

      • Spaceoddity
        /#20420657 / +1

        {][}
        Такой пример ваш валидатор пропустит?
        <div<span>>
        А такой?

        • siziyman
          /#20421389 / +1

          Первый пример — нет, второй пример — правильная скобочная последовательность, заданием было не написать парсер HTML.

          • Spaceoddity
            /#20422079

            А, ну т.е. задачи фильтровать такие варианты как {[}] не стоит? Главное просто посчитать кол-во открывающих и закрывающих? Нормальное задание для сеньора.

            • siziyman
              /#20422983

              Про это я писал выше в другом комментарии в 00:12, почитайте тред до того, как комментировать, уважайте собеседников, пожалуйста.

              Указанная автором комментария формулировка задания оставляет простор для интерпретации. На сложность задания это влияет весьма условно.

        • Kodiak
          /#20430645 / +1

          Ещё скажите, что такое должен не пропускать.

          std::vector< std::vector< int > >

          Разве что по поводу отсутствия пробела между ">" варнинг выдавать.

  18. usharik
    /#20419259 / +1

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

    • Hydro
      /#20420219

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

    • 0xd34df00d
      /#20420703

      А эти работодатели удивляются потом, когда для скриптов докера наворачиваются ахо-корасики и прочие препроморфизмы?

  19. lyadnov
    /#20419265

    Я смирился с тем, что все эти собеседования — рулетка.
    5 раз тупые шарады и конкурсы, на которых тебя отсеют, потому что «вспотел через чур».
    А 1 раз, с тобой поговорят по душам и не проверяя реальных знаний возьмут на тестовый срок.
    Вот на тестовом сроке ты и показываешь на что способен.

  20. Yago
    /#20419275

    Чем крупнее компания, тем больше вероятность нарваться на задачки и вопросы, ответы на которые никак не расскажут о тебе как о специалисте.

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

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

    Тут нужно понимать, на какую компанию нацелен кандидат. Крупные корпорации с их подходами к собеседованию могут не меняться годами. А более гибкие и шустрые не так стабильны. И если вы выбрали крупную рыбу, то будьте добры играть по ее правилам.

    • PsyHaSTe
      /#20431489

      Я никогда не собеседовал, только собеседовался, но неужели так трудно отличить человека с опытом от проходимца? Спросите про последний проект, что было сделано так, что не так, что бы поменять хотели, и как именно.


      Дайте задачку на проектирование простенького модуля (если речь про сениора). Ну там "как бы вы сделали логирование с разных модулей", "а вот теперь нам хотелось бы трекать время выполнения запросов", "а вот у нас куча IO-bound задач на сервер валится, а он не справляется, что это может означать?"...

      • Yago
        /#20432741

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

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

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

        • PsyHaSTe
          /#20433997

          Для меня персонально "закостенелый" и "разработчик" это очень плохо дружащие факторы.

          • dss_kalika
            /#20434031

            Если работать в одном стеке 15-20 лет (причём — если стек при этом и сам не меняется), то не вижу ничего что можно было бы особо нового в нём найти и не быть «закостенелым».

            • PsyHaSTe
              /#20434103

              20 лет писать на одном стеке, звучит как-то грустно.


              У меня за 9 лет произошел переход сначала от процедурного к ООП, сейчас вот от ООП к ФП, дальше наверное можно будет к формальным доказательствам двигаться, когда языки соответствующие подрастут.


              А с другой стороны человек, Который десятилетиями пишет одно и то же на одном языке, знает все подводные камни, но все равно периодически забывает/ошибается просто потому, что он не робот. Поискать что-то что кардинально решает проблему ему не хочется, максимум находит какие-нибудь средства в рамках существующего стека, чтобы чуть-чуть облегчить себе жизнь.

              • dss_kalika
                /#20434121

                Ну, если за это платят и это неплохо получается — почему бы и нет? Кто то же, в конце концов, должен. (поддерживать и развивать системы созданные в прошлом тысячелетии).

                Вы молодец, вы меняли стеки. Но не у всех есть такое желание. =)

                Поискать что то, кардинальное? Переписать проект с дикого размера кодовой базой и без документации?
                … и, да — ничто не защитит от ошибок из разряда «он не робот».

                • PsyHaSTe
                  /#20434575

                  Ну, если за это платят и это неплохо получается — почему бы и нет? Кто то же, в конце концов, должен. (поддерживать и развивать системы созданные в прошлом тысячелетии).

                  Ну да, люди получают деньги за боль, а потом пишут разгромные статьи про выгорание.


                  Вы молодец, вы меняли стеки. Но не у всех есть такое желание. =)

                  Кмк это желание любого разумного автоматизатора: работать меньше, получать результата больше.


                  Поискать что то, кардинальное? Переписать проект с дикого размера кодовой базой и без документации?

                  1. не все проекты такие
                  2. есть хорошие книги по тому, как приводить легаси в адекватное состояние.

                  У меня были проекты, где старожилы говорили "Да зачем тебе надо его трогать? Ну да, говно, но у нас же вон в кроне таска настроена чтобы перезапускать, а твой фикс конечно работает, но тестировать его мы не хотим, да и дифф за 200 файлов читать лень".

                  • dss_kalika
                    /#20434753

                    Ну да, люди получают деньги за боль, а потом пишут разгромные статьи про выгорание.
                    Почему за боль? Работать в привычной среде и привычными инструментами? о_О
                    Выгорание — это о неправильно поставленном рабочем и жизненном процессе, а не о том, что он не меняет стек и работает там и так как ему нравится.

                    Кмк это желание любого разумного автоматизатора: работать меньше, получать результата больше.
                    Что если за эту работу платят достаточно неплохо и нет альтернатив работать меньше, а получать больше? Редкие и узкие специалисты по старым стекам частенько получают совсем неплохие деньги.

                    не все проекты такие
                    есть хорошие книги по тому, как приводить легаси в адекватное состояние.

                    У меня были проекты, где старожилы говорили «Да зачем тебе надо его трогать? Ну да, говно, но у нас же вон в кроне таска настроена чтобы перезапускать, а твой фикс конечно работает, но тестировать его мы не хотим, да и дифф за 200 файлов читать лень».


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

                    А про книги… читал я несколько. Но ничего что могло бы помочь переписать за разумный срок проект на, к примеру, Delphi/SQL, который жил и развивался 15 (или уже 20?) лет, включая динамический sql, динамическое создание dfm-ок, отсутствие тестов и документации я что то там не заметил. Особенно — без увеличения свободных ресурсов программистов.

                • pprometey
                  /#20434759

                  Это ужасно, и страдает в целом бизнес в перспективе. Я вот устраивался в одну такую контору пол года назад. Там до сих пор стек с 2003-го года где-то.
                  И они довольно успшно таки пилят с предсказуемыми сроками и качеством решения. Вот только их качество уже во многом проигрывает тем молодым компаниям, кто пилят решения на каком-нибудь новом стеке.

                  Это какой-то ремесленеческий подход, который уже давно умер, еще в эпоху ренесанса.

                  • dss_kalika
                    /#20434783

                    Качество — по каким критериям?

                    • pprometey
                      /#20434789

                      Ну даже с точки зрения пользователя. Сравни хотя бы ASP .NET WebForms и SPA на Angular c бакендом на ASP .NET Core 2. (ну либо JEE). А еще стоимость лицензий и поддержку устаревший решений?

                      • dss_kalika
                        /#20434795

                        И в чём будет разница с точки зрения пользователя?

                        • pprometey
                          /#20434825

                          А ты попробуй. И таких вопросов не будет.
                          В чем разница между жигули копейкой и теслой? И та и та везет ведь.

                          • MacIn
                            /#20434867

                            Ну, в наших условиях стоимость содержания копейки (учитывая возможные ремонты) может оказаться более приемлемой…

                          • Igor_O
                            /#20435277

                            Если ты по каким-то причинам не можешь жить в солнечной Калифорнии, ну или во Флориде или, на худой конец, в Техасе, то чтобы пользоваться Теслой нужно потратить еще две-три цены Теслы на организацию ее зарядки. И еще иметь жигули копейку, чтобы ездить за 10 км до паркинга, в котором согласились подключить Теслу к розетке… Ну и да, еще жигули копейка пригодятся в морозы, когда пробег Теслы внезапно сокращается в 3-5 раз… Ну или в сильную жару, когда каждая поездка съедает год ресурса аккумулятора.

                            Это я все к чему? «Жуткое легаси» очень часто — это очень хорошо для бизнеса. Работал я как-то в одной конторе. Там ядро всего бизнеса крутилось на 15-летнем мэйнфрейме. Это был жуткий антиквариат. Но. Сколько думаете было суммарное время простоя этого ядра за 15 лет эксплуатации? Единицы минут! И то, уже ближе к 15-му году эксплуатации, когда электролиты на некоторых платах совсем уже пересохли.
                            И да, вокруг были обернуты всякие новомодные тогда веб-морды, импорты-экспорты из экселя, и прочие выдачи отчетов. И вот тут-то и возникали время от времени письма от админов: «Веб-морда поломалась, мы ее скоро починим, если что-то срочное — го в терминал с командной строкой, там все работает.» И были старожилы, которые застали еще время до веб-морд, которые делали все то же, что и через веб-морду, но в два-три раза быстрее…
                            Да даже элементарно. Вспоминая обучение «юзеров» во времена ДОСа и до них и обучение «юзеров» после появления виндоузов. С ДОСом и раньше — «вот тебе команда чтобы сделать это, вот тебе команда чтобы сделать то. Если что-то пошло не так и на экране не показывают :> с моргающей „|“ после — нажми „Esc“, если не помогает — то „Ctrl-c“. И человек мог через час продуктивно работать! Потом появился виндоус… И просто на то, чтобы человек мышкой попадал в кнопки и умел опознавать ситуацию, когда у него поверх всего диалоговое модальное окно, в котором что-то надо сделать — уходило по неделе и больше…
                            Вспоминается история из промежутка между чистым ДОСом и Виндоус. Когда уже появился NC… Вызывают моего друга бороться с вирусом. Приезжает. Просит продемонстрировать проблему. Дама достает тетрадочку. Открывает на правильной странице, щелкает тумблером на корпусе. Ждет синих окошек. Дальше по тетрадке: „7 раз вниз, энтер, три раза вниз, энтер, 15 раз вниз, энтер“. Дама тщательно отсчитывает нажатия и тщательно жмет энтеры. На экране все те же окошки, ничего не запустилось. Друг начинает разбираться. Оказывается на днях кто-то поставил новую программу на компьютеры бухгалтеров. И теперь, чтобы все работало, нужно начинать с „8 раз вниз“… Дали бы ей „набрать на клавиатуре cd С:\buh\base\ нажать энтер, набрать buh.exe нажать энтер“ — »вирус" бы никто не заметил…

                            PS: яркая демонстрация проблемы сейчас произошла у меня в предпросмотре коммента. Все кавычки съехали. Там где должны были быть "«" вдруг стали "»" а вместо "»" появились “. Но пока писал PS страница почему-то перерисовалась и большая часть багов пропала… Но остался »вирус" в конце…

                            • MacIn
                              /#20435483

                              Весьма странная точка зрения.
                              С тем же успехом после каких-то изменений могло не видоизмениться меню, а, скажем, программа была бы перемещена из \buh\ в другое место, или перестала бы работать еще из-за чего-то. И получившуюся ошибку пользователь точно так же не смог бы разрешить.
                              Ну, а то, что он вместо семантики (выбор чего-то из меню) записал последовательность нажатия клавиш — это либо о его умственных способностях, либо о способностях обучающего, говорит нам нехорошее.
                              В наше время (да и по правде, почти с самого начала так было, просто мало кто этим пользовался) вы можете выкинуть стандартную оболочку и сделать нужную вам программу единственно доступной.

                            • pprometey
                              /#20435971

                              Что-то я не видел, чтобы таксопарки активно пересаживались на копейку. На худой конец выбирают у нас лично — шкоду.

                          • dss_kalika
                            /#20436979

                            — Легаси плохое, модное — хорошее!
                            — Почему?
                            — А ты попробуй!
                            =))
                            Может всё-таки сформулируете чем лучше то для пользователей, раз уж взялись это утверждать?

                            • pprometey
                              /#20437713

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

                              • dss_kalika
                                /#20437833 / -1

                                Т.е. вы даже сами не можете сказать чем лучше?
                                Круто-круто.

                                • Kanut
                                  /#20437877

                                  Вы хотите увидеть ответ, которые описявет преимущества любых абстрактных «модных» технологий, над любыми абстрактными «легаси»-технологиями? Тогда я могу вам предложить одно преимущество для, которое применимо в большинстве случаев: цена разработки и самое главное сопровождения продукта. Всё остальное надо смотреть на конкретных примерах.

                                  • dss_kalika
                                    /#20437925 / -1

                                    Цена полной переписки продукта развивающегося уже 15 лет — колоссальна и не сопоставима с ценой поддержания.
                                    Более того — не факт, что поддержка нового продукта будет дешевле, кстати, учитывая размер проекта.

                                    Нет, я хочу увидеть ответ на

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

                                    Качество — по каким критериям?

                                    Человек же явно уверен, что раз они пилят на модных фреймворках, то качество выше. Иначе я не вижу логики в этом высказывании )

                                    Вот мне и стало интересно — чем таким эти фреймворки ДЛЯ ПОЛЬЗОВАТЕЛЯ (как утверждает тот кому я это вопрос задал) лучше.

                                    Вопрос то простой (раз всё так очевдно), но почему то ответа на него нет.

                                    К примеру — классические легаси проекты на делфи/sql. Учёт там какой-нибудь, отчётики, гридочки и прочая классика. Чем так пользователям будет лучше на новых / более модных фреймворках? )

                                    • Kanut
                                      /#20437967

                                      Цена полной переписки продукта развивающегося уже 15 лет — колоссальна и не сопоставима с ценой поддержания.

                                      Практически всегда наступает момент когда переписать оказывается дешевле чем поддерживать.

                                      Человек же явно уверен, что раз они пилят на модных фреймворках, то качество выше.

                                      И я пожалуй готов с этим согласиться в том плане что «модные» фреймворки дают более высокое «базовое» качество. Естественно криворукие программисты могут загубить любой фреймворк, но в среднем продукты сделанные на новых технологиях и с новыми подходами пожалуй будут качественне чем «легаси»-аналоги.

                                      • dss_kalika
                                        /#20438023

                                        Практически всегда наступает момент когда переписать оказывается дешевле чем поддерживать.
                                        Если проект активно развивается — стоимость его переписывания точно так же растёт со временем, как и стоимость поддержки. =) А если не развивается — зачем переписывать?

                                        И я пожалуй готов с этим согласиться в том плане что «модные» фреймворки дают более высокое «базовое» качество. Естественно криворукие программисты могут загубить любой фреймворк, но в среднем продукты сделанные на новых технологиях и с новыми подходами пожалуй будут качественне чем «легаси»-аналоги.


                                        И снова — что значит «качественнее»? И как это зависит от фреймворка, а не от архитектуры и подхода к разработке? )

                                        • Kanut
                                          /#20438045

                                          Если проект активно развивается — стоимость его переписывания точно так же растёт со временем, как и стоимость поддержки.

                                          Не согласен. Растёт и то и другое, но стоимость поддержки по моему опыту всегда растёт быстрее.

                                          И снова — что значит «качественнее»?

                                          В данном контексте «качественнее» для меня означает менее подвержено багам и критическим ошибкам.

                                          И как это зависит от фреймворка, а не от архитектуры и подхода к разработке? )

                                          Это зависит и от того и от другого. Естественно архитектура и подход имеют большее значение, но и «инструменты» играют свою роль. Если бы это было не так, то до сих пор все бы писали исключительно на ассемблере или даже на перфокартах.:)

                                  • VolCh
                                    /#20438121

                                    Стоимость к качеству обычно отношения не имеет. Смотрят как раз на соотношение цена/качество, если качество нужно, но не любой ценой

                                • pprometey
                                  /#20437943

                                  Могу, но не хочу и не буду. Это мой личный выбор. Не вижу смысла «распыляться». Вот именно по отношению к тебе лично и твоим вопросам. Имею право. Без обид. Еще раз, прочитай что такое технический долг, как он может обрастать процентами. Если все же хочешь действительно для себя себе ответить на этот вопрос.

                                  • dss_kalika
                                    /#20437997 / -1

                                    Ну что ж. Раз сам не можешь объяснить — значит сам не понимаешь.
                                    В следующий раз когда захочется какие то оценки порядка «качественнее-не качественнее» давать — стоит разобраться в том, как это оценивать.

                                    Спасибо, что прояснил это )

                                    ЗЫ: и, да — «техдолг» — понятие не связанное с фреймворком. =)

                                    • pprometey
                                      /#20438033

                                      Вот в том числе из-за такого провакативного способа ведения диалога, нет вообще никакого желания тебе что-либо объяснять и «напрягаться».
                                      Вижу больше с твоей стороны попытку самоутвердиться, чем достичь истины.

                                      Можешь считать, что я не знаю как объяснить, если тебе будет так легче жить. Ради бога, ни в чем тебя переубеждать не собираюсь. И так много времени потратил впустую на разговоры с тобой.

                                      • dss_kalika
                                        /#20438083

                                        Извини, просто тяжело общаться с человеком, который просто утверждает что что то «качественее» просто потому что он так сказал. А потом ещё всячески уходит от попыток как то это обосновать.

                                        Ну раз попытки узнать, откуда информация про «качественность» в твоих постах — самоутверждение, то пусть будет так.

                                        И так много времени потратил впустую на разговоры с тобой.
                                        Не насилуй себя )

  21. Mox
    /#20419475 / +4

    Это про США, в России нет неограниченного пула кандидатов.

    • sshikov
      /#20419673

      Значит, не только я вижу тут противоречие. Кстати, откуда у них пул кандидатов? В США большая безработица среди синьоров?

      • playermet
        /#20419785 / +1

        Имеющие работу частично входят в пул.

        • sshikov
          /#20419807

          Чтобы сманить имеющего работу, нужно как минимум сразу предложить ему повышение — а иначе зачем он будет менять текущую? И одновременно дать ему задачки? С трудом могу себе такое представить.

      • DenisTrunin
        /#20420979

        В Австралии рассказывают что при открытии вакансии почтовый ящик часто переполняется от резюме(думаю в США так-же). А если компания еще готова предложить визу, то это вообще будет вал. Плюс босс рассказывал что ему каждую неделю названивают рекрутеры и предлагают кандидатов

    • andersong
      /#20422459

      в России нет неограниченного пула кандидатов

      В России это называют очередью за воротами))))

  22. vsantonov
    /#20419535 / +1

    Проходил несколько раз подобные тесты, в том числе на HackerRank по специфике Sysadmin/Devops, были довольно практические задачи, например отсортировать скриптом файлы по расширению в папке. Однажды тест был вообще повторением экзамена одной красношляпой компании, где удаленную машину нужно было настроить в соотвтетствии с требованиями. Почему программистам не могут сделать так же? Может просто гугл задал этот идиотский тренд и все слепо повторяют?

    • Anthony_K
      /#20419615 / +1

      отсортировать скриптом файлы по расширению в папке

      э-э-э… ls -la? не?

      • vsantonov
        /#20419965

        Не, в смысле физически распихать по папкам, считать, создать на основе списка и раскидать файлы в соответствующие директории.

    • snuk182
      /#20419845

      Почему программистам не могут сделать так же?

      Потому что реальные задачи старшего разработчика: а) не решаются однострочником, б) не описываются одной строкой, в) очень часто нелинейны и не решаемы без обратной связи с заказчиком/БА/менеджером.

      • vsantonov
        /#20420013 / +1

        Почему сразу однострочник, одно задание я выполнял честный час. Там было кучу проверок знаний в разных областях, в том числе и на внимательность. Мои фантазии, например, дается кусок кода, задача уменьшить время исполнения в два раза, чем не практическая задача?

        • Source
          /#20420493

          например, дается кусок кода, задача уменьшить время исполнения в два раза, чем не практическая задача?

          Кстати, очень хороший вариант. Можно даже без уточнений во сколько раз… просто ускорить. Кто сильнее ускорит, тот и больший молодец :-)

          • arheops
            /#20420677

            А не получится.
            Без запуска в реальном окружении практически невозможно сказать, какой из двух вариантов для более-менее сложной задачи выполняется быстрее.
            Ну например один выполняется лучше если у процессора быстрый кеш, а второй — если SSD чуть быстрее.

            • snuk182
              /#20421559

              Оценка алгоритмической сложности. Кстати, хороший вариант задачи. К тому же жизненный, если зовут на рефактор проекта, изначально написанного и оплаченного по количеству строк кода.

              • PsyHaSTe
                /#20431493 / +1

                Но бесполезный, если на проекте пофиг на время выполнения кода, то есть в 99% проектах. По-моему опыту либо на проекте производительности даже питона за глаза, либо с производительностью проблемы, но все они IO bound и нужно уметь запросы в базу писать да шардирование настраивать, а не сортировки бенчить.

                • snuk182
                  /#20433029

                  Ох, вы не знаете, пофиг или нет, если проект изначально написан антисанитарами, где в критических ситуациях впилен крончик "в случае неотзывчивости сервера просто прибей его и запусти заново".

            • Source
              /#20422335

              Ну, не многие конторы пишут софт под конкретное железо. Можно изначально рассчитывать на SSD и более-менее современный проц, но жёстко оптимизировать под конкретные модели — это слегка перебор в большинстве случаев.
              А так, можно и тестовый стенд выделить, чтобы все решения в одних условиях сравнивать. Во всяком случае, это достаточно реалистичная задача, которая позволяет отличать сеньоров от джуниоров.

              • michael_vostrikov
                /#20425095

                А так, можно и тестовый стенд выделить, чтобы все решения в одних условиях сравнивать.

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

                • Source
                  /#20425371

                  Эм, а конфигурацию выписать и приложить к заданию сложно что-ли? Зачем гадать? Да и, по факту, не упрётесь вы в железо в рамках тестового задания. Что вы там собрались оптимизировать за 1-2 часа, чтобы модель процессора влияла на место вашего алгоритма в общей таблице результатов?

                  • michael_vostrikov
                    /#20425465

                    Ну так разговор же про "один выполняется лучше если у процессора быстрый кеш, а второй — если SSD чуть быстрее". Угадать в смысле выбрать код, который на этом железе будет работать быстрее. По конфигурации нельзя понять, какой вариант из них имеет место, надо брать оба и измерять результаты.

                    • Source
                      /#20427377

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


                      По конфигурации нельзя понять, какой вариант из них имеет место

                      Можно. Характеристики конкретных моделей никто не скрывает.

                      • michael_vostrikov
                        /#20427611

                        Вы такой код за пару часов не напишете, а если и напишете, то это будет говорить о вас с негативной стороны

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

                      • PsyHaSTe
                        /#20431499

                        Что делать на проектах где важна произвотельность кода? Ну вот например у меня как-то MS SQL построил план на триллион строк, потому что оптимизатор решил что будет циклами джойнить, хотя если сначала через хэш мерж склеить две других таблички, то время выполнения с 3 минут падало до скольких-то миллисекунд. И никто не знает, почему.


                        В итоге я день потратил на поиски принципов, по которым оптимизатор определяет такой порядок, и еще сколько-то времени пытался понять какой вид запроса поможет ему сделать правильный вывод. В результате выход нашелся, добавил в order by фейковое условие, которое пустило оптимизатор по нужному следу.


                        Проблема в том, что в реальном проекте почти всегда будет вопрос к БД, и почти всегда каждая проблема будет уникальна. В другой раз я, например, пытался понять, почему парсер того же SQL Server ломается, если в контенте XML колонки встречаются значения с ведущими пробелами.


                        Ну и все в таком духе. Как это проверять?

                        • Source
                          /#20432703

                          Если что, ветка про тестовое задание на оптимизацию, как альтернативу тупым задачкам. Или вы ожидаете, что кандидаты будут решать реальные проблемы вашего продакшена за 1 час?
                          В принципе задание на оптимизацию конкретной выборки — это тоже вариант. Даёте доступ к БД, медленный запрос и задание ускорить выборку. Но если Вы сами потратили 2 дня, то странно будет ожидать, что другой человек справится за 1 час. А если справится, компания готова ему платить в 10-15 раз больше, чем Вам?


                          В результате выход нашелся, добавил в order by фейковое условие, которое пустило оптимизатор по нужному следу.

                          Как-то костыльно и хрупко выглядит, где гарантия что после обновления минорной версии MS SQL сохранит нужное вам поведение? Я бы попробовал "сначала через хэш мерж склеить две других таблички" в подзапросе, чтобы у планировщика не было выбора, а потом уже поверх него добавить всё остальное.

                          • PsyHaSTe
                            /#20434033

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

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


                            Как-то костыльно и хрупко выглядит, где гарантия что после обновления минорной версии MS SQL сохранит нужное вам поведение? Я бы попробовал "сначала через хэш мерж склеить две других таблички" в подзапросе, чтобы у планировщика не было выбора, а потом уже поверх него добавить всё остальное.

                            Подзапрос не помогает. Фишка еще в том, что запрос формируется не в SQL, а через ORM, и те же хинты использовать не получится (ORM их не поддерживает). Собственно, задача была именно в том, чтобы придумать как через имеющийся апи сделать, потому что к хранимкам на проекте относились хуже, чем к таким костылькам. На SQL можно было просто влепить left hash join в нужном месте и все бы отработало как надо.




                            Хотя сейчас я наверное какой-нибудь даппер взял и прямой запрос написал. Просто этот подход плохо дружит с паттерном query builder, который используется чуть менее чем везде.

                            • PashaNedved
                              /#20434067

                              Кандидатам не дают реальные задачи из юридических соображений.

                              • PsyHaSTe
                                /#20434105

                                В чем юридическое соображение запрета задачки вида "у вас есть три таблички с такими-то записями, и вам нужно их поджойнить через общеизвестный фреймворк"?

                                • PashaNedved
                                  /#20434227

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

                                  • PsyHaSTe
                                    /#20434579

                                    И что?

                                    • PashaNedved
                                      /#20435741

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

                                      • Druu
                                        /#20435839

                                        Вы не можете просто так взять и использовать

                                        Так не используйте.


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

                                        Не может.

                                      • PsyHaSTe
                                        /#20435883

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

                                        • PashaNedved
                                          /#20435927

                                          в целом реальные задачи тем и хороши, что во-первых показывают уровень проблем проекта

                                          Вы правда думаете, что люди побегут рабочее решение (которое давно внедрено)

                                          Я думал, что у вас есть проблемы, а они уже решены оказывается.
                                          Конечно, нужно упростить, чтобы реально было решить за час, и это не требовало конкртеных знаний конкретной страницы мануала,

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

                                          Выбросите всю специфику — это реальная задача? Чем она будет отличаться от задач из мануалов.
                                          Сколько времени вы будете тратить на составление одной задачи рассчитанной на один час времени кандидата? Я думаю, минимум рабочий день. Сколько подобных задач вам понадобится составить за 1 год?
                                          Бизнес не стоит на месте, возникают новые проблемы в проектах, их тоже нужно учитывать. Задачи, как и код — их нужно поддерживать, устраняя неточности и противоречия. И в любом случае, срок годности ваших задач будет истекать довольно быстро.

                                          • PsyHaSTe
                                            /#20435961

                                            Я думал, что у вас есть проблемы, а они уже решены оказывается.

                                            Реальные проблемы просто источник хороших вопросов. Понятное дело, что чтобы оценить решение кандидата нужно уже самим сделать, сравнивать-то с чем-то надо.


                                            Выбросите всю специфику — это реальная задача? Чем она будет отличаться от задач из мануалов.
                                            Сколько времени вы будете тратить на составление одной задачи рассчитанной на один час времени кандидата? Я думаю, минимум рабочий день. Сколько подобных задач вам понадобится составить за 1 год?

                                            на одном из собеседований меня попросили спроектировать сервис коротких ссылок. Ну там с изменением требований и т.п. Сколько по-вашему должно пройти времени прежде чем этот вопрос устареет?


                                            И в любом случае, срок годности ваших задач будет истекать довольно быстро.

                                            Срок годности таких задач в пределах времени жизни фреймворка или технологии, для которой его сделали. Вопрос по грамотному проектированию индексов в SQL будет например актуален для любой версии любой реляционной бд.

                                            • PashaNedved
                                              /#20436013

                                              на одном из собеседований меня попросили спроектировать сервис коротких ссылок. Ну там с изменением требований и т.п. Сколько по-вашему должно пройти времени прежде чем этот вопрос устареет?

                                              Написать сервис коротких ссылок — это распространенное тестовое задание для мидлов, 3 часа — 1 день. Видимо у нас с вами разное представление о сеньорности.
                                              Вопрос по грамотному проектированию индексов в SQL будет например актуален для любой версии любой реляционной бд.

                                              Это вопрос знания технологии, можно обсудить устно, вы собираетесь усложнить его конкретикой, что бы дать в качестве тестового задания? Да, возможно получится хорошее задание, но…

                                            • VolCh
                                              /#20436071

                                              Вопрос по грамотному проектированию индексов в SQL будет например актуален для любой версии любой реляционной бд.

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

                                        • VolCh
                                          /#20436063

                                          Был такой случай:


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

                                          Ну и в процессе передачи в одном месте говорит что-то вроде "ну вот тут сделано как мы с тобой тогда обсуждали, я дня три думал и решил это сделать как ты предлагал".


                                          Мне просто приятно было и прикольно. Но кто-то на моём месте мог и по другому поступить. А техлид мог бы быть свидетелем истца, поскольку лояльности к его по сути бывшему начальству было меньше ноля после сделки.

                                          • vvbob
                                            /#20436277

                                            недружественное к персоналу, в частности всех программистов в ней увольняют «по собственному»

                                            И нафига они соглашались? Пусть сокращают по закону, со всеми положенными выплатами.

                            • Source
                              /#20437279

                              Фишка еще в том, что запрос формируется не в SQL, а через ORM

                              Ну, это так себе фишка. Нет никакого оправдания городить днями костыли в угоду ORM для случаев, которые нормально решаются на SQL. Большинство ORM позволяют выполнить raw SQL или использовать его фрагменты в нужных местах. Если ORM этого не позволяет, то следует его отправить на другие 3 буквы ещё до старта проекта.

                          • AlexeySoshin
                            /#20434599

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

                            • Source
                              /#20437299

                              Так это не типовое тестовое задание. Тут уже есть код, который можно запустить без доп.настройки на готовом сервере. И 1-2 часа, чтобы ускорить этот код. Что успел ускорить, то успел. Поэтому долго не будет.

        • gohan
          /#20420847 / -1

          Там было кучу проверок знаний в разных областях, в том числе и на внимательность

          «было кучу» — тоже проверка на внимательность? Эти слова склоняются не так сложно, вроде.

  23. helions8
    /#20419649 / +1

    Вопрос, мне кажется, не в задачках – они бывают разные, не только на алгоритмы. Вопрос в том, что собеседование зачастую не отбирает кандидатов, реально необходимых требуемой позиции. Нанимающая сторона зачастую не знает, как отобрать нужных им людей – мне кажется, что именно поэтому возникают негативные ощущения от собеседований. Мне очень понравилось мое же недавнее собеседование в большой банк, которое я не прошел, но было сразу понятно 1) кто им конкретно нужен 2) чем они занимаются 3) почему ни я им, ни они мне не подходят. А вот когда мелкий «стартап» начинает устраивать Google-style interview, говоря, что раз вы с задачками справитесь, то и с остальным точно справитесь, то вот тут уже возникают вопросы. За прошлый год я провел 50+ собеседований, как интервьюер, и для меня самой важной задачей было выяснить 1) проверка минимально необходимого нам уровня (ну должен он знать про хеш-таблицы) 2) границы опыта 3) хотел бы я с таким человеком работать 4) если кандидат нормальный, то дать задачку, чтобы порассуждать. Процесс постоянно надо менять и подстраивать, нужны итерации… Хороший найм и проведение собеседований — это сложно и утомительно.

  24. The_Vlad
    /#20419653 / -17

    Синьеришки по гуглению, не могут решить элементарных базовых задач по компьютер сайнс и по этому жалуются на habr. Ай-яй-яй какой ужас. Бедные синьеришки.

    • knotri
      /#20428051

      Так если бы это было собеседования на синьер комьютер саинз специалиста — вы правы.


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

  25. hoack
    /#20419751 / +1

    На самом первом собеседовании я даю задачку на HackerRank и смотрю, как кандидат ее решает. Задачку даю простую, чуть-чуть сложнее, чем FizzBuzz. Зачем? Для того, чтобы убедиться, что кандидат умеет программировать, то есть может, получив практически чистое описание несложного алгоритма, взять и закодировать его на том языке, который он выберет сам. И да, я периодически встречаю кандидатов, у которых 10 с лишним лет опыта работы, все резюме заполнено крутыми технологиями, но закодировать простой алгоритм они не в состоянии.

    • SergeyVin
      /#20420061 / +8

      Если отсечь откровенный обман, что тоже бывает, получается, что кандидат 10 лет не писал ни строчки, получал за это какие-то деньги, а только вы спустя 10 лет раскрыли этого сукиного сына.
      Что-то мне кажется, что это проверка не на умение писать код, а на умение работать под прессингом. Это тоже важно, не спорю. Но не лучше ли спокойно пообщаться, а потом уже разбираться: если сотрудник стрессоустойчив — будет работать с заказчиками, если нет — ну ок, оградим его от стресса, будет пилить свой модуль. Зачем людьми сразу разбрасываться? Тем более «борзый» и «стрессоустойчивый» с более высокой вероятностью кинет вашу компанию, как только получит поинтересней офер. Спокойные же разрабы будут лояльней.

      • gohan
        /#20420863

        Если отсечь откровенный обман, что тоже бывает, получается, что кандидат 10 лет не писал ни строчки, получал за это какие-то деньги, а только вы спустя 10 лет раскрыли этого сукиного сына.

        А вдруг он «читерил»? Вдруг в гугл лазил всё это время, а надо без него уметь! Как вот прочитал тут недавно где-то в интернете байку, типа разработчик из дома работает, ну кодит и постоянно гугл открывает, что-то ищет нужное. Жена ему говорит: «А разве ты не жульничаешь? Ты же дожен сам всё это знать, а ты в гугл лазишь!»

        • smarthomeblog
          /#20421293

          99% кода уже написано давно. Нужно просто его найти и адаптировать для своих нужд. И да, для этого нужен и Гугл, и StackOverFlow. И ничего зазорного в том нет. ИМХО гораздо хуже, когда изобретается велосипед, который по всем параметрам хуже уже готовых аналогов, и кроме геморроя с дальнейшей поддержкой ничего не принесет.

          • Whuthering
            /#20421779

            Мне кажется у комментатора выше был сарказм)

            • gohan
              /#20425263

              Сарказм, сарказм. Я ж там специально написал историю про жену программиста. Увы, походу, чуток переоценил интеллект хабраюзеров.

        • GreenBee
          /#20422303

          А в чем проблема в использовании гугла?
          Если ты еще не решал данную задачу — логично погуглить, чем изобретать велосипед.
          На том же SO можно по некоторым вопросам увидеть прямо «изобретение поезда»: вопрос задан, кто-то на него ответил, вроде даже правильно, потом в комментариях оказалось, что есть нюансы, потом оказалось, что эту задачу можно решить совершенно по-другому, потом, через пару лет, еще появился ответ с использованием каких-нить новых фич языка/инструментария.
          Умение применять существующие решения, а не изобретать свои — очень хороший навык.

      • hoack
        /#20424743

        Нет-нет, я не говорю про обман. Я имею в виду ситуацию, в которой человек, работая, не программирует, а модифицирует/адаптирует/клонирует чужой код. Где взял уже написанное, где на Stack Overflow сходил… Так можно очень долго работать, и даже вполне результативно. Моя цель на этом этапе совсем не вызвать стресс, поэтому я даю очень простые задачи. Ну, например, одно время давал вот такую:

        «Определим последовательность Трибоначчи как последовательность, первые 3 элемента которой равны 1, а каждый последующий равен сумме трех предыдущих. Написать функцию trib(n), которая будет возвращать n-ный элемент последовательности.»

        С моей точки зрения, человек, имеющий минимальный опыт программирования, должен без труда справиться с этим заданием меньше, чем за двадцать минут. Я даю на это до 45 минут, при этом сразу говорю, что основное задание — написать работающую программу, пусть даже она не оптимальна. Разве это стресс?

        • Kwisatz
          /#20425833 / +1

          Конечно стресс:
          — Сам факт экзамена
          — Все эти игры с простыми/сложными задачками и кусками кода привели к тому, что не поймешь толи правда элементарщина, толи где то заныкали заковыку
          — Этот код никогда не увидит жизнь, у меня например при этом мозг начисто отключается
          — Разные критерии оценки: мне важно оформление кода и читаемость, вам оптимальность, 3ему обязательно нужно чтобы это было обернуто в класс, 4му знание математических формул и теорем, 5му знание встроенных функций языка, 6му знание плугинов/фреймворка, 7му слабодокументированных хитростей языка. И во всех этих случаях есть очень высокий шанс того, что вместо разговора двух профессионалов это превратиться в: Как, вы незнаете?!!! А вот это вы тоже не знаете? *мерзкий тон, осуждающий взгляд*. Это очень неприятно знаете ли.
          — многим, в тч и мне не нравиться писать на листочке. Нет автодополнения, писать нужно ручкой (чего многие годами не делают), текст уползает (хоть кто бы дал листок в клеточку/линеечку) итд

          ЗЫ ну вот я накидал примерчик, по-моему минуты 4 ушло, еще столько же пробелы расставлял, затолкал его в класс от нефиг делать, прописал нормальное имя (нам же читаемый код нужен, правда?), переименовывал функции чтоб читалось лучше(на листочке, ага), загуглил как пишеться Трибоначчи(«ааа, незнаете», помним, да?))

          class TribonacciSequence
            {
            public static function getElement($elementNumber)
              {
              $sequence = [1, 1, 1];
              if ($elementNumber >= 4)
                {
                return self::extendSequence($sequence, $elementNumber);
                }
              else
                {
                return $sequence[$elementNumber - 1];
                }
              }
            
            private static function extendSequence(&$sequence, $targetElementNumber)
              {
              $elCount = sizeof($sequence);
              $newElement = $sequence[$elCount - 1] + $sequence[$elCount - 2] + $sequence[$elCount - 3];
              $sequence[] = $newElement;
              if ($elCount + 1 < $targetElementNumber)
                {
                return self::extendSequence($sequence, $targetElementNumber);
                }
              else
                {
                return $newElement;
                }
              }
            }
          
          echo TribonacciSequence::getElement(10);


          Осталось 34 минуты, вспотел, переписал:

          
          function trib($n)
              {
              $sequence = [1, 1, 1];
              return $n >= 4 ? extendSequence($sequence, $n) : $sequence[$n - 1];
              }
            
          function extendSequence(&$sequence, $n)
              {
              $elCount = sizeof($sequence);
              $newElement = $sequence[$elCount - 1] + $sequence[$elCount - 2] + $sequence[$elCount - 3];
              $sequence[] = $newElement;
              return $elCount + 1 < $n ? extendSequence($sequence, $n) : $newElement;
              }
          
          echo trib(10);
          


          Осталось 32, еще переписал
          
          function trib($n)
            {
            $first = 1;
            $second = 1;
            $third = 1;
            for ($i = 3; $i < $n; $i++)
              {
              $curr = $first + $second + $third;
              $first = $second;
              $second = $third;
              $third = $curr;
              }
            return $curr;
            }
          


          Еще 30… Да пока 45 прошли я бы в ужасе был, честно говоря)

          • Source
            /#20427481

            У вас в финальном варианте $curr не определён при $n <= 3, и нет проверки что $n > 0
            Ну и мемоизацию не помешало бы докрутить, а то нафига всю последовательность пересчитывать при каждом вызове xD

            • Kwisatz
              /#20427767

              А я в курсе) Я специально убрал, чтобы было до чего докопаться. А в третьем варианте в угоду минимальному коду)

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

          • hoack
            /#20429167

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

            Так вот, как минимум 30%, а то и больше, кандидатов НЕ МОГУТ за 45 минут написать хоть как-то работающее решение.

            • Kwisatz
              /#20429471

              В таком случае любой пример уровня (но не он сам) FIzzBuzz по идее должен показать ровно такой же результат. Хотя ваша тоже не сложная, если не на листочке, то вообще без проблем. Хотя разработчик, меняющий работу второй раз в жизни может очень сильно растеряться при определенной манере ведения допроса.

              Кроме того поймите, вот вы вроде адекватен, были бы на месте, мы бы с вами обсудили. Очень часто это заканчивается не так. Либо уже на первой задаче: «а вы знали что тут можно very_rare_function_name? Как нет?» И таким тоном, что поневоле начинаешь себя чувствовать идиотом, тем более что все это знаешь же. Либо задачи сменяют друг друга до тех пор пока не возникнет такой момент.

              Однако, все еще зависит от постановки вопроса. Ну например «какие индексы бывают в PostgreSQL». Простой вопрос? По идее звучит просто, но на практике большинство разработчиков кроме b-tree в жизни своей ничего не использовали. Ну некоторые вспомнят GIN/GIST, возможно даже hash (хотя он редко упоминается во всевозможных гайдах да и пользоваться им ну очень редко кому приходится), BRIN не вспомнит никто (если вы недавно не читали документацию и то врядли). Да и сама постановка вопроса ставит в тупик: что значит какие? многоколоночные, уникальные, частичные, функциональные. Вот только часто разговор двух профессионалов и будущих коллег больше похож на допрос и тут прям простор для фантазии. А это всего лишь один простенький вопросик, к задачам еще может добавиться отсутсвие обратной связи, неочевидный синтаксис (ой а какие прелести можно вытворять с использованием магических методов в php) и разные критерии оценки.

              Посему если собеседование начинается с задачи то сразу нет. Тем более если на листочке или на н часов.

              • VolCh
                /#20429951

                Вот, кстати, да. Вопросы "Какие… вы знаете" в принципе нормальные. И когда я задаю подобный вопрос, то или предельно чётко, надеюсь, формулирую типа "типы данных в PHP" или ожидаю уточняющих вопросов по каким измерениям делить. Хотя вот тут сам попался на вопрос "какие виды репликации знаете" и начал говорить про бинарную, стейтмент, смешанную, синхронную и нет, а имелось в виду мастер-слейв и мастер-мастер. Вот как-то совсем из головы вылетело.

                • Kwisatz
                  /#20430937

                  Такие вопросы вполне нормальны, когда цель собеседования — найти коллегу/подчиненного. И становятся сущим адом если вы попали на допрос к человеку с желанием вас унизить.

                  С другой стороны: очень хорошо, что это видно на собеседовании а не позже.
                  Одно из самых разрывающих в клочья собеседований (а оно ли это, работу я не искал, просто пришел послушать что скажут) вроде было в крупной компании, достижения и методы очень впечатляли (хотя офис — нет). Основной собеседующий не представился, очень удивился когда я попросил рассказать о компании (еще более когда услышал, что я их оцениваю в той же мере, что и они меня), выражал крайнее нетерпение, выдавал аргументы в стиле «это говно» и вишенкой на торте: когда я попросил стакан воды прям так закатил глаза как будто я икры намазать попросил. Как представлю, что я сними работаю, брррр.
                  Хотя второй был приятен, улыбался, говорил интересные вещи. Полагаю первый был нач отдела, второй тимлидом.

          • symbix
            /#20430511

            За Whitesmiths coding style я бы сразу не взял.


            Если человеку это нравится, он очень странный!

            • Kwisatz
              /#20430867

              Не переживайте, я бы вас тоже не взял с таким уровнем аргументации)

              Очень странно когда компания переживает не о том насколько оптимальным/читаемым/etc будет код, а о том как будут расставлены скобочки и пробелы)

              The advantages of this style are similar to those of the Allman style. Blocks are clearly set apart from control statements. The alignment of the braces with the block emphasizes that the full block is conceptually, and programmatically, one compound statement. Indenting the braces emphasizes that they are subordinate to the control statement. The ending brace no longer lines up with the statement, but instead with the opening brace.

              Whitesmiths, along with Allman, have been the most common bracing styles with equal popularity according to the Jargon File

              Давным давно, когда я еще был маленький, отец меня учил C++ и я усердно читал книжки с листингами сишного кода, вот как раз в таком стиле. Потом были Basic,Pascal, PHP, Java, SQL etc и большая часть кода с которым работал была написана в таком же стиле. Конечно, когда я дописываю библиотеку или участвую в проекте с другим стилем я копирую его в точности, кроме жуткого легаси, где давно всем плевать.

              Вот что кстати забавно, begin/end никто не ставит на ту же строку, а вот скобочку уже очень всем хочется. Но вообще то совершенно все равно, код, кроме всего прочего, можно форматировать единым стилем при комите. А вот именование в стиле i,j,k,x,y,z уже не пофиксишь, mont/mons/mesyac уж тем более, говнокод тоже никуда не денется.

              Хотя форматирование SQL единой простыней заслуживает порицания. Ибо я не верю, что это вообще можно прочесть.

              ЗЫ Вы знаете, за 20 лет вы первый кто поднял этот вопрос)

              • symbix
                /#20431083

                Да я вообще пошутил скорее. :)


                Но, как говорится, в каждой шутке есть доля шутки. Whitesmiths style не используется примерно нигде, и человек с опытом работы в команде давно бы уже отвык, потому возникает подозрение, что кандидат "не такой, как все" и будет вечно спорить по ерунде вместо того, чтобы сделать "как тут принято". Разумеется, это проверяется провокационными вопросами, ну вот как щас :-)

                • Kwisatz
                  /#20431117

                  А почему нет? Читается легко)

                  Нести свет у меня нет никакого желания уже давно. Фреймоврк? Да пофигу какой, код стайл? Ссылочку. Хотя… давайте зарежем ваши богомерзкие недоБД и воткнем постгрес, да и вместо монги тоже)

                  А ну еще могу по UX попрыгать)

                  ЗЫ вообще отвыкать причин не вижу, даже после продолжительного времени работы в другом стиле мне все равно нравиться так. Кроме того у меня есть свои плюшечки, которых очень много, кстати.

                • PsyHaSTe
                  /#20431513

                  Какая вам разница, как написан пример? В нормальном проекте у вас есть editorconfig/gitattributes/…, который форматирует весь код всех участников единообразно. Предъявлять человеку что у него другой стиль это… Такое.


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


                  За редкими исключениями, конечно


                  image

          • Igor_O
            /#20430881

            Третий вариант красив, но не работает — для N = 1, 2 и 3 выдает неопределенное значение. Нужно еще добавить в начало функции $curr = 1;
            Проверка на граничные условия — первое, что в нас пытались вдолбить на программировании на первом курсе в 1987-м году…
            Ну и да, переменные объявлять и инициализировать тоже руками приходилось в те времена, обычно…
            Причем, в первых двух вариантах вы выполнили проверку… А в третьем — почему-то проигнорировали.

            • Kwisatz
              /#20430971

              Потому что достаточно громоздко получится. $curr=1 подойдет только в том случае, если первые 3 равны (в этом плане в первом варианте все красиво, не хватает только проверки на >0, которую убрал намерено, чтобы посмотреть только ли это может быть причиной обсуждения). В 3 хотел специально сделать поменьше, можно еще инициализацию в одну строчку собрать но это уже перебор.

              • Igor_O
                /#20431175

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

                $curr=1 подойдет только в том случае, если первые 3 равны

                Ну они равны по условию задачи. Без этого придется передавать первые три значения и номер в последовательности в качестве аргумента…
                В любом случае, хоть я уже и не занимаюсь кодингом 25 лет как, но про такую базовую проверку… Я когда первокурсникам помогал на лабах, в таких случаях просил их показать мне устройство чтения мыслей в компьютере и где у них в программе обращение к устройству чтения мыслей.

                можно еще инициализацию в одну строчку собрать

                … но у нас уже исходник не на перфокартах, где каждая лишняя строчка — лишняя перфокарта, которая может не прочитаться.

                • Kwisatz
                  /#20431343

                  … но у нас уже исходник не на перфокартах, где каждая лишняя строчка — лишняя перфокарта, которая может не прочитаться.


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

                  • PsyHaSTe
                    /#20431521

                    Ну тогда объясняете человеку, что его код не будет понятен коллегам, и что вам не по пути.

              • PsyHaSTe
                /#20431517

                Если внимательно посмотреть, можно увидеть, что curr это и есть third, кроме случаев от 0 до 2, когда он с ними совпадает по значению.


                Поэтому можно просто заменить на return third. Нужно только чуть-чуть поправить цикл, чтобы он учел это изменение.

          • mobi
            /#20432899

            А как же переход к матричному формализму и быстрое возведение матрицы в степень? Или даже приведение этой матрицы к диагональному виду? (но тут, в отличие от ряда Фибоначчи, к сожалению будет комплексно-сопряженная пара собственных значений)

  26. jakobz
    /#20419781 / +20

    Ну вот я всегда когда нанимаю — прошу открыть IDE, и мы начинаем писать код. Начинаю с супер-простого. Например есть массив городов, есть строчка от пользователя. Давай найдем в ней все города. Уточнаю что все просто и без подвохов. Пишет String.Split(" "), цикл, String.Find() — пойдет. Дальше давай предположим что массив большой, какая сложность алгоритма? Ну типа сколько сравнений будет если 1000 городов и 100 слов в строке? Как ускорить? А давай сделаем поиск case insensitive. И запятые обработаем. А как бы ты ускорял поиск, если бы табличка городов была в БД?

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

    Просить писать красно-черные деревья — перебор. Спрашивать как работает garbage collector — бред. Но и не просить писать код — это тоже же глупость, так реально нанять человека, который вообще не умеет код писать.

    • Source
      /#20420527 / +5

      Таким подходом хорошо нанимать джунов, но не сеньоров же. Сеньор должен вас зае**ть на первом же этапе кучей вопросов. Почему города хранятся в массиве? Как часто возникает задача поиска городов? Проходит ли ввод от пользователя валидацию формата? Зачем мы даём пользователю вводить несколько городов в одно поле? Какую пользовательскую задачу мы вообще решаем? Какие SLA есть к этой задаче? И если вы вразумительно не сможете ответить на все эти вопросы, то контрольный: Нафига вы меня спрашиваете такую дичь?


      Но и не просить писать код — это тоже же глупость, так реально нанять человека, который вообще не умеет код писать.

      Ну конечно, как минимум 5+ лет работал программистом и не умеет писать код.
      Работа сеньора состоит в том, чтобы сначала думать, а не бросаться кодить. Поэтому всякие учебные задачки и перестают работать. Если у задачи нет никакой практической пользы, то она может поставить в тупик лучших специалистов. Ведь их прямая обязанность — избегать решения подобных задач, т.к. решать любую бесполезную задачу — это прямые убытки для бизнеса.

      • tangro
        /#20421745

        Так а чем плох вышеуказанный подход для сеньйоров? Если за час собеседования только задавались вопросы, а до кода дело так и не дошло — ну, значит, сеньйор :)

        • Source
          /#20422361

          Ахах, ну как вариант )))

      • jakobz
        /#20424793

        Ну, сеньер тоже должен уметь писать код. Он просто сделает задачку быстро и четко, можно придумать доп. требования посложнее — если видно что умеет. Ну, или можно вокруг этого кода разговор продолжить. Или просто перейти к моему любимому «расскажи что-нибудь интересное из того что в последнее время сделал».

        Я вообще раньше сеньеров кодить не просил. Ну типа как-то неудобно — чувак с 10 лет опыта, а я его тупую задачку из института прошу делать. Но один раз пришел товарищ, который умел что-то там по теории рассказать, но не мог писать код вообще. Ну типа вот эту самую задачку — не смог. Типа «ну понимаешь, я лидил, забыл уже что там как». С тех пор, обязательно сначала исключаем волчанку.

        • Source
          /#20425195

          Он просто сделает задачку быстро и четко
          String.Split(" "), цикл, String.Find()

          Вы это в контексте данной задачки считаете решением?
          Она же изначально сформулирована не как задача, а как проверка "конформизм vs профессионализм": прогнётся ли человек под вас в стрессовой ситуации, поступится ли профессиональной этикой, начав писать то, что вы просите?

          • jakobz
            /#20429301 / +2

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

            У этих прекрасных парней есть великое будущее без меня. Кто-то из посадит на золотой трон, вокруг которого стоят негры с опахалами, и приходят просители, и просят написать код, а они им объясняют что код этот писать не будут, и просителей казнят. А тут я такой — взял их, и принял! И это прекрасное их будущее прошло мимо них. Я же от совестливости сопьюсь и повешусь — великую жизнь большому человеку так бездарно испортить.

            Так что я все-таки спрошу всех код написать, а если кто мне плюнет в лицо — сотру специальным платочком, его положу в сейф, и потом продам плевок великого Стива Джобса 2 за миллион денег. И всем хорошо будет.

          • AlexeySoshin
            /#20434661

            Решать задачи на интервью — это уже нарушение профессиональной этики? :)

      • AlexeySoshin
        /#20434655

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

        • VolCh
          /#20436073

          А сколько вообще получили оффер из сотни?

    • MRDjeko
      /#20420983

      Вы же описали процесс найма на позицию джуниора? Или у сеньоров такие же задачи и вопросы?

      • AlexeySoshin
        /#20434665

        Задачи одинаковые, потому что в итоге все должны писать код. Отличается время на решение задачи, и ожидаемое качество.

    • Kwisatz
      /#20425899

      Если бы табличка была в бд, то вы бы построили по ней индекс и не задавали таких вопросов.

      • AlexeySoshin
        /#20434667

        Задавал бы :)


        • Как эта таблица будет выглядеть?
        • А какой бы индекс построили?
        • А как вообще индекс в БД в целом можете рассказать?

        Задача должна быть предлогом пообщаться с человеком.

        • Kwisatz
          /#20436205

          А как бы вы собственно на них ответили?)

          Зы формулировка 3 более чем странная

    • sergey-b
      /#20426003

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

    • ainoneko
      /#20426179

      Уточнаю что все просто и без подвохов. Пишет String.Split(" "), цикл, String.Find() — пойдет.
      А «Великий Новгород» в массиве есть?
      А надо ли находить «Петропавловск» в «Петропавловск-Камчатский»?
      (И «Ростов» в «Ростов-папа»?)

      • PsyHaSTe
        /#20431531

        После таких вопросов можно переходить к более синьорским темам )

  27. JediPhilosopher
    /#20419819 / -1

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


    А я вот тоже на собеседованиях даю простую задачку. И мой опыт найма программистов, хоть и небогатый, но однозначно показывает: тот кто не способен написать на собеседовании что-то типа FizzBuzz — тот и в реальности программировать не способен. Пусть хоть 10 лет опыта и стопицот дипломов и регалий — этот человек будет очень медленно решать простые алгоритмические задачи, которые регулярно всплывают тут и там. Он будет адово тупить и зависать на любых задачах сложнее чем "сконфигурировать что-то по шаблону" и "переложить объекты из одного апи в другое".

    • Fedorkov
      /#20420139 / +1

      По вашему опыту, какой процент потенциальных мидлов/синьоров не способны написать FizzBuzz?

      • JediPhilosopher
        /#20420183 / +4

        Я скорее джунов-миддлов собеседую, среди них примерно половина из тех, кто приходит на собеседование.


        Я обычно даю задачку — обратить массив. Это простейший пример на понимание работы с циклами и индексами. Сразу предупреждаю, что не надо изобретать сложных алгоритмов, никакого подвоха тут нет и любое простое решение сойдет, даю настроенный ноутбук с ИДЕ, сам отхожу в сторонку и прошу позвать меня когда будет готово.
        В итоге многие городят какую-то дичь, которая в итоге не работает и валится с выходами за границу массива.


        Тут можно сколько угодно рассуждать на тему стресса и "написания кода под прессингом", но если человек такое не может написать (даже без лимита времени) — он не программист и на вакансию программиста претендовать не может.


        Пару раз приходилось "на безрыбье" брать людей, которые с этой задачей справлялись плохо — в итоге результаты работы были соответствующие.


        Помню из своей первой конторы еще историю — после одного собеседования проводивший его вышел из коридора, начал биться головой об стену и приставать к проходившим по коридору и задавать им вопросы. Что характерно, на его вопросы даже наши 3д художники смогли ответить (ну они у нас там подкованные в ИТ были, для Maya всякие скрипты автоматизации писать умели, но все-таки не программисты). А (по его словам) люди, приходившие на позиции сеньора, с опытом и внушительным резюме, не могли. Но при этом не стеснялись просить ощутимых денег.

        • AlexTest
          /#20420739 / +1

          Я обычно даю задачку — обратить массив. Это простейший пример на понимание работы с циклами и индексами.
          Ну а если он использует что-то типа array_reverse(), аналог которого есть в любом ЯПВУ, что вы тогда узнаете про
          понимание работы с циклами и индексами
          ?

          • Whuthering
            /#20421795

            Более того, если он не использует Array.reverse(), а сразу начнет изобретать велосипеды, то это уже минус для разработчика:)

            • JediPhilosopher
              /#20422185

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

              • deespater
                /#20422289

                Но потом я все-таки прошу сделать это ручками.

                Зачем?

                • Kobalt_x
                  /#20422297

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

                • JediPhilosopher
                  /#20422709

                  Затем, что программирование это не только перекладывание из коллекции в коллекцию и вызов пары-тройки методов API. Иногда приходится своими руками что-то придумать. Ну вот пришел к вам набор данных, надо их отфильтровать, как-то упорядочить, преобразовать и только потом передать дальше.


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


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

                  • JustDont
                    /#20422801

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

                    • JediPhilosopher
                      /#20423183

                      Буду рад, если вы какую-нибудь такую задачку порекомендуете. Которая не настолько общеизвестная (как FizzBuzz), не требует написания больше 5-7 строчек кода и проверяет какие-нибудь базовые навыки программирования.

                      • JustDont
                        /#20423397

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

                        Но сейчас наверное и эта задача уже настолько же замылена, как и FizzBuzz.

                  • deespater
                    /#20423119

                    При этом в рамках собеседований достаточно сложно родить какой-то содержательный пример «из жизни»

                    Поэтому лучше попросить кандидата написать абсолютно синтетический код, который никогда не понадобится?

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

                    И кстати, как бы вы ответили на встречный вопрос кандидата «зачем»?

                    • JediPhilosopher
                      /#20423203

                      Поэтому лучше попросить кандидата написать абсолютно синтетический код, который никогда не понадобится?

                      Любой код с собеседования скорее всего будет синтетическим и никогда в жизни не понадобится. Можно пытаться создать задачу исходя из своего релевантного опыта работы, но это как правило довольно нетривиально — суметь упаковать что-то несинтетическое в несколько строчек кода.


                      с завязанными руками и без ноутбука

                      Почему без ноутбука-то? Я как раз и пишу, что даю ноутбук с IDE и подготовленным проектом.


                      И кстати, как бы вы ответили на встречный вопрос кандидата «зачем»?

                      "Небольшая проверка на ваше умение писать простой код".


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

                      • deespater
                        /#20423253

                        но это как правило довольно нетривиально — суметь упаковать что-то несинтетическое в несколько строчек кода

                        Согласен. Но с моей точки зрения нужно объяснять ограничения: просьба развернуть массив не пользуясь библиотечной реализацией просто потому что интервьюер запретил, как раз и является очень синтетической задачей без предпосылок и искусственными ограничениями (читай с завязанными руками).

                        Небольшая проверка на ваше умение писать простой код

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

                        Да простой вопрос «а напишите map/reduce по таким-то условиям» уже на порядок лучше чем «разверните массив не пользуясь компилятором»

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

                        Так может вам процессы пооптимизировать? Скрининг ввести, чтобы таких кандидатов отсеивать.

                        Опять же, я ничего против такого подхода не имею, просто для меняон выглядит иррациональным и слегка пассивно-снисходительным для кандидата.

                        • JediPhilosopher
                          /#20423451

                          А кто их отсеивать-то должен? По резюме? Так резюме обычно еще меньше о человеке говорят, чем умение решать задачки. По дополнительному собеседованию? Не у всех есть на это ресурсы, да и тут вон все воют когда вместо начальника отдела их начинают всякие хрюши мучать.


                          В общем нет тут правильного ответа, на любой вид собеседования найдутся те, кому он не понравится.

                    • wataru
                      /#20423677

                      Я даю задачу, которою пришлось решать самому в нашем проекте. Вернее не решать, а перерешивать — там был написан вырвиглазный запутанный рекурсивный полный перебор, который можно было переписать на ДП, сократив в несколько раз, сильно ускорив и упростив при этом.


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


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

                      • PsyHaSTe
                        /#20431543 / +1

                        Мне кажется такие задачи надо в сборник собирать. Чтобы хотя бы принципы как придумать похожую были видны.

                        • AlexeySoshin
                          /#20434695

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

                  • PsyHaSTe
                    /#20431539

                    Затем, что программирование это не только перекладывание из коллекции в коллекцию и вызов пары-тройки методов API.

                    Как правило, оно и есть.


                    Ну вот пришел к вам набор данных, надо их отфильтровать, как-то упорядочить, преобразовать и только потом передать дальше.

                    Ну вот эту задачу и задавайте. Хотя я бы её так и решал xs.filter().group_by().map()....


                    От программиста следует ожидать самого простого способа решить задачу, а не вставлять палки в колеса "не используйте букву i в названии переменной цикла".

                • serge-phi
                  /#20423207

                  Потому что завтра может возникнуть задача, для которой нет библиотечного решения.

                • AlexeySoshin
                  /#20434677

                  Предлагаете кандидата сразу брать? Пришел — молодец, нанят? :)

            • dominigato
              /#20422327

              Да уж, если ваш девопс начал изобретать методы сортировки, он явно делает что-то не то, время бить по рукам))
              Но почему-то на интервью просят сделать именно неэффективную реализацию, которая никогда в жизни не может быть использована, которую нельзя делать потому что уже есть в библиотеке — то есть ровно наоборот того, что понадобится на рабочем месте.
              Именно это почему то называется проверкой.

        • Xander_Vi
          /#20421989

          Обратить массив?
          Не знаю, насколько сложно это реализовать в других языках, но в Python это не просто одна строчка — это буквально 6 символов (без учета названий переменных): reversed_list = input_list[::-1]

      • PsyHaSTe
        /#20431535 / +1

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

        • AlexeySoshin
          /#20434717

          Существуют :)


          Даже тут полно товарищей "я уже знаю один язык, работу найду, больше и не нужно".

  28. borv
    /#20419839 / +5

    Хмм… Я тоже завалил какую-то шнягу на трансформацию бинарного дерева в конторе "с совой". Потом еще какую-то другую шнягу на ограниченный поиск в другой такой же "перспективной компании".


    Я думаю упражнения — это хорошо, но есть один нюанс. Проходить они должны в нормальных рабочих условиях, максимально приближенных к боевым. Как часто вы impromptu будете объяснять комнате полной инженеров как манипулировать двоичными деревьями? А кодить по тимвьюверу на чужой машине, параллельно объясняя ход своих мыслей? А как на счет оптимизации кода под конкретный GC без телеметрии? Может подъем кубов с масштабируемой трехзвенкой с нуля в проде за час? Вы правда именно так работаете? Если ответ — реально "да", то, простите, я ваш вертеп укурков не пойду работать ни за какие деньги. Если "нет" — тогда зачем весь этот цирк с конями? Что вы проверяете?


    Куда более реалистично — поговорить про задачу у доски, придумать дизайн и уйти кодить, а через день принести код на ревью. Собственно у нас есть упражнение на дизайн (на доске, с группой из 4 человек) и задача часов на 4-6 которую надо сделать дома и прислать на ревью. Оба упражнения очень близки к тому, что реально делалось когда-то. Мне этот подход сразу показался адекватным, что существенно повлияло на мое решение работать с ними. После 2 лет в коллективе — не жалею ни разу. Контора (внезапно!) тоже оказалась очень адекватной, и по режиму работы, и по отношению к инженерам, и по компенсации.


    В интервью очень многое — дань моде, к сожалению. Раньше было модно думать за пределами коробки, потому были круглые люки и автобусы набитые шариками. Сейчас модно хипстерство и коллаборешн, поэтому задачки и интерактив. Завтра будет найм только через нетворкинг и по количеству звезд на гитхабе. Если контора гоняется за трендами как ошпаренная, десять раз подумайте есть ли смысл там работать за +15К в год.

    • PsyHaSTe
      /#20431549

      Куда более реалистично — поговорить про задачу у доски, придумать дизайн и уйти кодить, а через день принести код на ревью. Собственно у нас есть упражнение на дизайн (на доске, с группой из 4 человек) и задача часов на 4-6 которую надо сделать дома и прислать на ревью. Оба упражнения очень близки к тому, что реально делалось когда-то. Мне этот подход сразу показался адекватным, что существенно повлияло на мое решение работать с ними. После 2 лет в коллективе — не жалею ни разу. Контора (внезапно!) тоже оказалась очень адекватной, и по режиму работы, и по отношению к инженерам, и по компенсации.

      Подход хороший, но ИМХО предельное время на задачу — 1-2 часа, причем желательно и собеседующего, и собеседуемого, иначе это какая-то домашняя работа строгого учителя. "Разошлю сотне претендентов задачку, пусть помучаются". И потом 2 минуты на проверку каждой.




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

      • AlexeySoshin
        /#20434725

        Как software architect, именно так и стараюсь делать :)


        Правда стараюсь не на бумажке, а на доске, но если кандидат очень хочет — можно и на бумажке, конечно.

  29. botyaslonim
    /#20419893 / +1

    Меня (устраивался фронтэндом) тоже валили на бинарных деревьях. Причём, как мне показалось, собеседнику это было просто по приколу: он закончил МехМат МГУ и, видимо, любил эту древесину.
    С тех пор прошло два года. Я устроился в другую компанию. Решил просто огромную гору задач, разработал кучу виджетов, отрефакторил тонны старого кода, вырастил джуна, написал много документации и так далее. С коллегами обсуждали: кажется, не два года прошло, а четыре, работы реально много. Моим поделками ежедневно пользуются миллионы людей, и вроде бы компанию устраивает качество работы.

    А те ребята ещё спустя где-то полгода всё искали человека. И потом ещё через год искали.

    ps. Думаю, более-менее разумным выходом были бы сертификации в авторитетных центрах. Что-то типа прошёл двухнедельные курсы, показал себя со всех сторон, порешал сложные задачи, получил лычку и право называться senior. Тогда и собеседующим было бы спокойнее. Смотрели бы на собесах soft skills и мотивацию кандидата, а не знание на память всех встроенных методов. Но до этого, очевидно, далеко.

  30. musicriffstudio
    /#20419919 / -2

    Нытье какое-то.


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


    Да, они сами не пройдут такое же точно интервью у такого же горе-программаста.


    Нужно просто подготовиться к преодолению данной преграды и пройти квест. Даже если у спрашивальщика гораздо меньше опыта и он просто не понимает о чем ему говорят.


    Выяснить заранее о процессе, пройти тесты пару раз, почитать какие вопросы задают и какой ответ у них в бумажке.


    Это ж на один раз.

    • AlexeySoshin
      /#20434733

      И как успехи, где уже квест прошел? Google/Facebook/Netflix, Uber/Microsoft/Amazon хотя бы? :)

  31. CrushBy
    /#20419921 / +11

    Когда я нанимал строителей на ремонт, то действовал по простому принципу: нужно брать тех, кто хуже всех «продает себя». Так как если они плохо продают, но до сих пор на рынке, то значит делают хорошо. А мошенники всегда просто отменно умеют ездить по ушам. К сожалению, с наймом тоже самое. Нету никакой гарантии, что люди, которые умеют хорошо проходить собеседования, также хорошо умеют работать.

    • Hydro
      /#20420337

      Как и люди, которые не умеют хорошо проходить собеседования.
      Гарантии вообще, обычно, нет.

      • CrushBy
        /#20421051

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

        • VolCh
          /#20427569

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

  32. VGoudkov
    /#20419927

    Мы вот тоже, после некоторого количества неудач, решили, что раз мы нанимаем программиста — он таки должен уметь программировать! И сделали класс с заготовками методов, заданиями в виде JavaDoc и тестами TestNG, которые проверяют результаты.Первый метод — реализовать тело FizzBuzz, далее задачки чуть хитрее (но все из практических ситуаций), в пределах стандартной библиотеки Java. Кандидату предоставляется ноутбук с IDEA, изображение дублируется на проектор в переговорке. Вопросы задавать можно, гуглить тоже. Обычно кандидаты справляются за 15-40 минут.
    Интересен не столько достигнутый результат (все тесты зелёные), сколько способ решения задачи / кодирования. Если предложенный вариант решения мягко говоря странен — начинается дискуссия по возможным улучшениям и/или краевым случаям, что позволяет оценить опыт кандидата и количество косяков в production, которые от него можно ожидать.
    Экономит просто ТОННЫ времени и нервных ресурсов на собеседованиях и неплохо отделяет тех, у кого код на кончиках пальцев, от заучивших ответы про устройство HashMap.

    • sergey-b
      /#20431219

      Можно мне к вам на собеседование прийти?

    • AlexeySoshin
      /#20434741

      Это один из наиболее здравых подходов, кстати. Видел такое у OLX и Atlassian как минимум.

    • VolCh
      /#20436079 / +2

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

  33. moonster
    /#20419931

    Год уже как участвую в найме — провожу техническое интервью. Никакой теории не спрашиваю, сплошная практика.
    За отпущенные 2 часа большинство не успевает.
    Всего две задачи, можно использовать IDE.
    Первая — разработать некий сервис + тесты, из сложностей — нужно уметь читать требования на английском, иметь базовые навыки многопоточного программирования, уметь писать юнит-тесты. Разрешаю пользоваться документацией, даже гуглить при сильных затруднениях.
    Вторая — до 20 строк забагованного кода, нужно почитать и найти косяки (уже без документации).
    Обе задачи вполне себе боевые, первая имитирует процесс разработки, вторая — кодревью.
    За год я смог одобрить 9 человек, прошло через меня несколько десятков.
    А резюме почти у все были хорошие. Многообещающие.
    Зато многие кандидаты говорят, что это был их лучший собес за все время. )))

    • dominigato
      /#20420025 / +7

      Если бы это делалось дома, я бы еще согласился. Но пока человек сидит под стрессом интервью, это никак не «имитирует процесс разработки». У вас все разработчики пишут сервисы под вашим пристальным взглядом и на время?
      Интервью может быть только тогда репрезентативным, когда максимально имитирует рабочие условия, тогда вы можете экстраполировать и предположить что человек так и будет работать.
      Хотя даже и это не панацея — я как-то брал работника и было все хорошо первые полгода, а потом оказалось что он не понимает что такое работа вообще. То есть делать что нужно на работе и что от тебя требуют — это как-то странно, нужно же делать что тебе хочется и интересно. Даже если результатов нет, главное — процесс. Кстати, технически он был подкован на все 100.
      Вот такие вещи нужно на интервью узнавать, а не сортировку пузырьком. Я пузырьком научу за 10 минут, а работать человека уже вряд ли кто-то научит.

      • moonster
        /#20420347 / +1

        У вас все разработчики пишут сервисы под вашим пристальным взглядом и на время?
        Таки да. Сами при планировании дают оценки, а потом иногда укладываются в них. Непосредственно во время разработки наблюдения нет, зато потом перекрестное code review проходят вообще все, разработчики, лиды, архитектор. Причем люди уже поняли, что тащить сомнительное себе дороже, если нужна ранняя критика — сами придут к коллеге и попросят взглянуть.

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

        • dominigato
          /#20420483 / +1

          При чем тут сроки и code review, вы же не стоите за спиной разработчика или занимаетесь микроменеджментом? Или пристально смотрите на него в течении всего дня, угрожая уволить если он сделает ошибку? Именно это и происходит на интервью и именно об этом был вопрос.
          Стрессовое программирование, наверное, тоже требуемый навык где-то, правда мне трудно представить где. Но явно не в большинстве мест.
          Гораздо вернее дать человеку сделать задание в комфортной для него среде и его рабочей атмосфере, в которой он и будет скорее всего работать. А потом уже можно обсудить им сделанное и отсюда танцевать, например.

          • moonster
            /#20420593

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

            • dominigato
              /#20420735 / +1

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

      • AlexeySoshin
        /#20434743

        Так домашние задания тоже не хотят делать :)

        • dominigato
          /#20434879

          А вы хорошо попросите :)
          Задания тоже разные бывают. Мне тут недавно дали одно, которое взяло бы примерно недели две фул-тайм. Я, конечно, рад узнать новое и потренироваться, но блин, надо же совесть иметь. Я не могу взять отпуск только чтобы ваше задание делать.
          Я в другом месте дали примерно на неделю по вечерам, и технологий много и довольно бесполезное, то есть не оставляет впечатления что ты работаешь забесплатно на это компанию. Вполне нормально
          А то есть любители раздавать свои баги и проблемы в продакшне в качестве «домашних заданий».

          • AlexeySoshin
            /#20435399

            Бывают и такие случаи, хотя боюсь представить, что там на две недели могли прислать.


            Сам даю обычно написать сервис на три endpoint'а буквально: create/get/getAll
            Persistence — как бонус. Даже тесты бонусом.


            И все равно многие отказываются писать :)

        • VolCh
          /#20436333

          Из заданий, которые делал в последние годы:


          • написать интерпретатор простого языка. Решил использовать наконец-то полученные кучу лет назад по теории трансляторов, все эти парсеры, токенайзеры, токены, AST и т. д. Бонусом было компиляция скрипта в LLVM
          • написать простой CRUD на голом PHP. Применил по полной SOLID, продублировав частично PSR интерфейсы, создал adhoc DataMapper ORM+identityMap+UnitOfWork c детектором изменений (Doctrine/Hibernate like в общем), DI-контейнер и т. п.
          • написать программу выявления десинка частот часов двух нод на ассемблере с очень ограниченным набором команд. Говорили что использовали систему команд каких-то реальных процессоров, но по ощущениям даже если так, то сильно порезали

          Во всех случаях главное, что побудило согласиться их делать: задачи интересные сами по себе или легко делаются интересными, если не решать их в лоб. Всем остальным с тестовыми вроде "на хорошо известном фреймворке сделать CRUD веб-сервис с паблишингом событий в рэббит, и консьюмер, которые их тупо выводит консоль, но устойчивый к повторной отправке" отвечал "могу устно рассказать техспециалисту (задания давали рекрутеры) как их буду делать". По статистике соглашались на это на проектах с европейскими заказчиками, американские, израильские, японские и российские — нет: или решение, или "нам не нужны люди, которые вместо решения задач буду рассказывать как они их будут решать" (почти дословная цитата).

    • siziyman
      /#20420081 / +6

      Ну «разработать сервис и покрыть тестами» не звучит, как задача, влезающая в час-полтора, да. Неудивительно, если честно.

      • moonster
        /#20420321

        К сожалению, не могу раскрывать детали тестового задания, чтобы убедить вас.
        Никто не требует от кандидата слишком многого.
        Речь не идет о коде качества, достойного production. Сервис, который нужно сделать, имеет одну зависимость (с единственным методом), и сам тоже имеет единственный публичный метод. Протестировать нужно ровно те кейсы, которые упомянуты в требованиях, их три. Это много?

      • moonster
        /#20420371

        А вы не могли бы привести пример задачи на час — полтора, с учетом того, что решать будет сеньор и можно пользоваться IDE и документацией?

        • siziyman
          /#20420407

          Я не считаю, что любая практическая задача на час-полтора позволит надёжно отличить даже хорошо знакомого со стеком толкового джуниора (в моей системе координат) с годом-полутора практического опыта от сеньора. Это как раз больше про теоретические беседы, понимание нюансов и технических, и командного взаимодействия.


          Беседа по существующему коду даст больше, например — ввести в приблизительный контекст, показать код, попросить найти проблемные места — совсем необязательно ошибки per se, просто "это выстрелит нам в ногу при описанных условиях". Поговорить о командной работе, понять, комфортно ли вам с таким человеком взаимодействовать, достаточно ли вы схоже понимаете процессы разработки.

          • moonster
            /#20420551

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

            Если кандидат на практическом уровне знает Java и JDK, способен реализовать тестовую задачу с многопоточностью, способен понять, какие тесты нужны и написать их — сеньор почти наверняка.

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

            Было за все время два интересных кандидата — правильно решили задачу на кодинг (с документацией и гуглом), но не смогли решить на ревью. Оказалось — сеньоры, но язвк недавно сменили. Умели тесты писать, принципы многопоточки понимали, но еще плохо знали JDK.

            Таким образом, сочетание задач позволяет с приемлемой долей вероятности позволяет отличать новичков в Java, мидлов и джунов от сеньоров.

            • siziyman
              /#20421405

              Знакомые мне хорошие джава-джуны более чем достойно знают стандартную библиотеку. Да и сам я джавист.

              • moonster
                /#20426043

                Видимо, джуны могут быть очень разными. Я никогда не видел таких хороших джунов, но это не значит, что их не бывает. )

        • 0xd34df00d
          /#20420729

          Написать парсер json или чего-то json-подобного.
          Наваять обёртку вокруг mmap, которая прикидывается pod-типом.
          Написать свой std::any. Или optional.


          На проектирование, увы, придумать сложнее.

          • moonster
            /#20420811

            Полноценный парсер JSON — боюсь, слишком круто для полутора часов, если в языке нет какой-то специфической поддержки и нельзя использовать сторонние библиотеки. Ну разве что какое-то подмножество покрыть можно.

            • 0xd34df00d
              /#20420821

              Прям совсем полноценный — да, сложновато, но вполне значимое подмножество сделать можно. Голыми руками тоже (по крайней мере, если знать про PEG и просто на коленке сваять свою реализацию).

          • Skerrigan
            /#20421071

            Не сам парсер, но «инструмент выборки/обработки», близкий к полному, писал сам в 2014-ом, когда еще не знал про JSONPath… ну чтобы «как в jQuery все было» (по селекторам).
            Году в 2017 гугл в поисковой выдаче выдал JSONPath и… весь мой код спокойно был пересажен на опенсорсную библиотеку, без правок на моей стороне (по селекторам). Я доволен :)