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

На данный момент я являюсь тимлидом .Net с необходимостью набора в свою команду хороших специалистов на новый проект. За долгие несколько месяцев мне так и не удалось укомплектовать команду на новый проект, и это сподвигло меня на рассуждения о том, а всё ли мы правильно делаем. За техническое интервью несём ответственность я и техлид нового проекта с опытом уровня senior. Голоса ЗА и ПРОТИВ после интервью поделены пополам и из этого вытекает проблема. Все те кандидаты, что понравились мне, не нравились техлиду, и наоборот. Опишу несколько случаев интервью с последующим отказом.

Первый случай

Наш HR рассказывает о компании, но не рассказывает о стеке технологий и практиках в команде разработки. Далее задает общие вопросы, передает резюме и описание кандидата нам и приглашает на интервью. Кандидат имеет хороший опыт в том, что не применяется в новом проекте. Этого мы не знали до момента тех. интервью. Итог следующий. Я за кандидата, знает и понимает что делает, умеет реализовывать поставленные задачи. Но с немного урезанной вилкой зп по причине отсутствия опыта в применяемых нами технологиях; с надеждой на то, что он быстро всё схватит и вольётся в рабочий процесс. Техлид против, так как нет опыта в технологиях. При этом общий уровень кандидата ему неинтересен. Отказ, потерян очередной хороший специалист.

Второй случай

С учётом предыдущего опыта HR рассказывает о компании и о стеке технологий и практиках, задаёт вопросы о их знании, передает резюме и описание и приглашает на интервью. Кандидат имеет хороший опыт в микросервисах, знает, что и как реализовать, может прикинуть описание реализации чего-то нового для него, понимает нюансы, которые стоит учитывать. Итог. Я за кандидата, всё понравилось, быстро вольётся в работу. Техлид против со словами "Плохо знает базу". Действительно, кандидат запорол пару вопросов. Но запорол их он банально по причине того, что редко применял на практике и уже забыл, что к чему. Для понимания, что это были за вопросы, заданные техлидом. "Ты знаешь о многопоточности и синхронизации, тогда опиши углублённо работу класса Thread", "Опиши принцип работы DLR и поколения объектов в GC". Честно, даже я сходу не смог бы ответить на эти вопросы и скорее всего так же завалил, тем более не понимал, зачем они нужны нам. Мы, как и многие, используем TPL для реализации многозадачности, а нативные потоки сейчас используются достаточно редко для новых проектов. Но "всезнающий" техлид посчитал, что это и есть база, и её должны знать все. Отказ, снова потерян хороший кандидат.

Третий случай

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

Четвёртый случай

Снова кандидат у нас на тех. интервью. Заваливание техлидом вопросами о "БАЗЕ". Переход на этап лайвкодинга. Кандидат немного нервничал, и я могу его понять. Написание кода немного, скажем так, интимная штука. Любой программист пишет код в одиночестве в состоянии сосредоточенности. А тут неестественные условия для него, как будто пишешь домашнее задание под пристальным взором строгого отца, который за любую ошибку даёт подзатыльник. И тут я в первый раз увидел задачи, которые подготовил техлид. Это набор задач на алгоритмы из leetcode среднего уровня. Как это относится к нашим веб-микросервисам, где алгоритмы такого уровня не применяются знает только техлид. Поборов своё волнение, кандидат написал рабочий алгоритм и достаточно неплохо. Но техлид снова его забраковал. В этот раз по двум причинам. Снова "База хромает", так ещё и впридачу "Алгоритм медленно работает". Очередной отказ. На этом моменте я усомнился в адекватности техлида. Честно, среди крутых разработчиков даже в нашей компании я знаю одного-двух людей, которые периодически пишут алгоритмы для поддержания мозгов. Но опять-таки, это единицы. Алгоритмы и leetcode больше прерогатива крупных компании а-ля Яндекс, где для этого выведен отдельный этап тех. собеседования. И там это можно оправдать реальным использованием в их практике.

По итогу сейчас мы имеем:

  1. Дикую нехватку рабочих рук в команде.

  2. Постоянно не укладываемся в очередные дедлайны.

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

  4. "Всезнающего" техлида, на которого давит начальство, который давит на меня.

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

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

Первый случай

HR компании рассказывает о компании, рассказывает о стеке технологий, задает вопросы по опыту и приглашает на техническое интервью. Подключаюсь к собеседованию и не вижу никого. Сижу 10 минут в одиночестве и в конференцию залетает некий сотрудник. Без представления начинает закидывать меня техническими вопросами. В состоянии лёгкого недоумения я ответил. Далее произошёл интересный диалог с этим неким сотрудником, назовём его Вася.

Вася: "Можешь показать свой код, пет-проекты там?"
Я: "У меня нет сейчас времени на пет-проекты, а те, которые есть, уже не актуальны для моего текущего уровня."
Вася: "Тогда покажи свой код на текущем месте работы."
Я: "Эмм, вы знаете что такое NDA?"
Вася: "Да, а в чём проблема?"
Я: "Мне стоит объяснять, почему я не могу показать этот код? Может лайвкодинг лучше?"
Вася: "Всё понятно, я не могу оценить твои знания без твоего рабочего кода, всего хорошего."

Что-то мне это напомнило, но не помню, что же... После этого небольшого казуса получил отказ уже от HR с вопросом, может, мне что-то не понравилось в собеседовании ) Для понимания: собеседование было в известный всеми банк, где NDA должен знать любой сотрудник.

Случай второй (типовой)

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

Случай третий (ещё более типовой)

Назначено техническое собеседование без какой-либо прелюдии и рассказе о компании, при этом даже не спросили, есть ли возможность в назначенное время. Дикое удивление HR, почему же я не знаю, какие проекты реализует их компания, она же скидывала ссылку на сайт-визитку, в которой кроме бизнес-домена и названия ничего нет. Техническое собеседование, очень колоритный техлид встречает меня фразой примерно "Ну здарова, Noname, какими судьбами к нам залетел, чего ищешь, кто по масти?" На этом моменте я подумал, что вместо того, чтоб вспомнить базу .Net-а мне нужно было прочитать пару статей о том, как входить в хату. Далее началось типичное бессмысленное и беспощадное полуторачасовое энциклопедическое насилие, попытки подловить хоть на малейшем незнании. Особенно это позабавило после фразы "Я тебе пару вопросов позадаю, каких-то энциклопедических знаний не нужно, отвечай как знаешь." После такой кучи вопросов, ответы на которые в практике не применяются в 90% случаев, ради интереса задал старшему разработчику в другой команде парочку таких каверзных вопросов и был послан с фразой "Я тебе Google что ли, я забыл это уже давно. Отстань, у меня интеграция нереализованная."

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

В сухом остатке мы имеем:

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

  2. Из-за ухода компаний, задающих высокий уровень, местные "Рога и копыта" имеют своего рода монополию на рынке труда, по этой причине нет смысла как-то улучшать методы рекрутинга.

  3. Из-за оставшихся компаний, собеседования в которых проводятся по типу экзамена, получается прекрасная картина, уже описанная комментарием на другой пост о собеседованиях "идиоты ищут идиотов". Такие собеседования мне всегда напоминали либо экзамены в университете, либо уже давно пройденное ЕГЭ, где зубрёжка одного и того же материала нужна только для того, чтобы просто сдать экзамен, а далее происходить типичное "Забудьте всё, что вы учили...".

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

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

  6. Мифическая "БАЗА", представления о которой у всех разные в зависимости от собеседующего специалиста. В итоге происходит поиск специалиста, который знает ту же "БАЗУ", которую знает собеседующий, а не поиск разработчика, умеющего умело решать поставленные ему задачи.

Я видел много отличных специалистов-практиков, умеющих хорошо реализовывать проекты, но не занимающихся постоянным оттачиванием теории. Теорию они подтягивают в моменты реализации новых для них задач, которые они ещё не выполняли. Я сам являюсь одним из таких, так как знания любого специалиста приходят по мере нового вызова для него. При этом сам найм в зависимости от языка и технологии сильно не отличается, что Java, что C#, что любой другой язык. Нехватка специалистов в итоге обусловлена неверным поиском самих специалистов. Для собеседования специалисту даже с опытом необходимо выделить время на подготовку в неделях. Вспомнить "БАЗУ", терминологию, механизмы, которые он не применял на практике уже годами. При этом после получения оффера и выхода на новую работу специалист поймёт, что эта "БАЗА", терминологии и механизмы не имеют ничего общего с работой на новом месте и просто будет выполнять задачи, используя свой опыт. Я почти не встречал на собеседованиях вопросов на основе реальных задач и практики. Только один раз я услышал вопрос о том, как бы я реализовал некий реальный механизм. Но по итогу как бы хорошо специалист не ответил, как бы не показал свой практический опыт, критерием для выбора это не являлось. Возможно, в чём-то я не прав, хотел бы услышать ваше мнение и опыт, поделиться рассуждениями.

Комментарии (403)


  1. panzerfaust
    04.09.2023 14:32
    +104

    Тема про БАЗУ вытекает из того, что 90% интервьюеров - лентяи. К собесу надо готовиться с обеих сторон. В резюме надо вчитываться и корректировать свой пул вопросов под конкретного человека, продумывать тактику разговора. Но зачем, если можно подрочить в сотый раз устройство хэшмапы и шлифануть литкодингом. Говорю это как интервьюер, если что (надеюсь, что не лентяй).


    1. microuser
      04.09.2023 14:32
      -21

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


      1. panzerfaust
        04.09.2023 14:32
        +31

        А в чем собственно проблема вопросов по базе?

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

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

        К тому, в чем разница между ArrayList и LinkedList? Или чем в спринге синглтон от прототайпа отличается? Было б смешно, если б не было так грустно. Я специально хожу по собесам как кандидат с целью найти интересные вопросы и темы для моих собственных собесов. Вдохновиться, так сказать. Так вот за последние полгода улов нулевой. Мне просто досадно, что я трачу по полтора часа на очередное обсуждение "Top 50 Java questions you should know"


        1. poxvuibr
          04.09.2023 14:32
          +15

          Мне просто досадно, что я трачу по полтора часа на очередное обсуждение "Top 50 Java questions you should know"

          Потенциальные работадатели, наверное, тоже переживают, что в очередной раз потратили полтора часа на чтобы подсказать интересные вопросы кандидату, который не собирался у них работать. Баланс ))


          1. panzerfaust
            04.09.2023 14:32
            +27

            кандидату, который не собирался у них работать

            Так я бы может и засобирался бы. Но точно не к людям, которые с постными лицами устраивают тебе "ЕГЭ по джаве" по опроснику с первой страницы гугла.


            1. Mazik228
              04.09.2023 14:32

              С .Net'ои та же ситуация


              1. impruvd
                04.09.2023 14:32

                Да ну совсем не та же. Вакансий намного меньше, денег тоже платят меньше:)


        1. microuser
          04.09.2023 14:32
          +2

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


          1. panzerfaust
            04.09.2023 14:32
            +46

            если человек не знает чем отличается связный список от массива это уже звоночек

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

            Вы пойдете к врачу который не знает "базу" и умеет лечить только то что лечил на прошлом месте?

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


            1. Rive
              04.09.2023 14:32
              +2

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

              Особенно когда бенчмарки фреймворков и БД меняются от версии к версии.


            1. Samhuawei
              04.09.2023 14:32
              -3

              ЛОР должен знать группы крови и как минимум должен смочь прочитать результаты анализа крови даже если не гематолог. Если вилку из глаза в живот то это не доктор.


              1. imbalance
                04.09.2023 14:32
                +6

                Когда Вы идёте к ЛОРу за лечением проблем, которые лечит ЛОР, то Вы будете гораздо более счастливы, если он эксперт конкретно в своей области, который не тратит своё время на знания, которые для конкретно его работы помогают мало. Нужен специалист широкого профиля — идите к терапевту, он вероятно отправит к нужному доктору, но не всегда. И уж вряд ли вылечит что-то сложнее ОРЗ.


                1. Samhuawei
                  04.09.2023 14:32

                  База необходима даже ЛОРу. Допустим он видит запредельное количество лейкоцитов в анализе крови. Он не спец по раку, но может послать человека к другому специалисту. Это как в программировании. Фронтэндщик может проигнорировать неправильный ответ от сервера, типа моё дело маленькое, не работает да и хрен с ним. А может подойти к бекендщику и грамотно рассказать о проблеме. Вся команда только выиграет от этого.


                  1. voldemar_d
                    04.09.2023 14:32
                    +1

                    ИМХО, количество лейкоцитов в крови обычно терапевт смотрит. И только если видит, что надо к ЛОРу, то отправляет к ЛОРу.


                1. Meklon
                  04.09.2023 14:32
                  +2

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

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


              1. saboteur_kiev
                04.09.2023 14:32
                +1

                ЛОР должен знать группы крови и как минимум должен смочь прочитать результаты анализа крови даже если не гематолог. Если вилку из глаза в живот то это не доктор.

                Группы крови может знать любой школьник. В базе их 4*2. А на самом деле их там сотни.

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


                1. Samhuawei
                  04.09.2023 14:32

                  Ну ок, то есть ЛОР по вашему у умирающего должен вылечить ухо и послать домой.

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


                  1. Kanut
                    04.09.2023 14:32
                    +1

                    Ну ок, то есть ЛОР по вашему у умирающего должен вылечить ухо и послать домой.

                    Если к нему пришли с больным ухом, то он должен лечить больное ухо. Вопрос скорее в том почему терапевт направил человека в таком состоянии только к ЛОРу.


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

                    Если у человека грубо десятисантиметровые лимфоузлы, то ЛОР на это тоже сможет указать.


                    А миддл клепающий формочки придёт в 9 уйдёт в 5 и ничего его не волнует.

                    Нормальный программист тоже может придти в 9 и уйти в 5. Или там решить что дела другого отдела его не касаются.


                  1. alexzaides
                    04.09.2023 14:32
                    +1

                    а зачем нормальный программист должен лезть в чужую работу и почему он не может прийти в 9 и уйти в 5?


                    1. Samhuawei
                      04.09.2023 14:32

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

                      Знакомому в похожем случае оплатили поездку в США, он был доволен.


                1. Meklon
                  04.09.2023 14:32

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


            1. microuser
              04.09.2023 14:32
              +4

              Ходил я к одному такому ЛОРу горло лечить, месяц потратил, потом поменял врача и за один прием выяснилось что это был рефлюкс. Вот что значит база.


              1. panzerfaust
                04.09.2023 14:32
                +14

                Доктор вполне мог иметь аналогичный случай месяцем ранее. И у вас он просто увидел знакомый паттерн. Вы не можете 100% знать, что тут некая "база", а не обычный рабочий опыт.

                Точно так же разраб может решить проблему перфоманса БД не потому, что он собаку съел на реляционной алгебре и внутреннем устройстве СУБД, а просто потому, что разбирал похожий кейс на прошлом месте.


                1. microuser
                  04.09.2023 14:32
                  +3

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


                  1. panzerfaust
                    04.09.2023 14:32
                    +19

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


                    1. ruslan_sverchkov
                      04.09.2023 14:32

                      Скажите, вам правда кажется сложным вопрос про AL vs LL? Вопрос без подводных камней, мне действительно любопытно


                    1. Tarnella
                      04.09.2023 14:32
                      +1

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

                      Если сэкстраполировать данный тезис консолидированно с вашим, то, боюсь, у нас вовсе не останется иного варианта, кроме как сделать статистически обоснованный вывод о том, что степень задрачивания базой В БОЛЬШИНСТВЕ СВОЕМ обратно пропорциональна прикладной полезности специалиста.

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

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

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


                      1. Samhuawei
                        04.09.2023 14:32

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

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

                        Наверное потому что базу знал.


                1. czz
                  04.09.2023 14:32
                  +1

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


                  1. Samid777
                    04.09.2023 14:32

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


                    1. Meklon
                      04.09.2023 14:32

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


                      1. Samid777
                        04.09.2023 14:32

                        Сейчас я это понимаю... А в то время меня останавливал каждый сотрудник ППС, т.к. мои глаза ему казались весьма странными. За несколько месяцев до инфекциониста, я посетил окулиста, т.к. сильно болели глаза. Она нашел аллергический конъюнктивит, быстренько его вылечил, а вот глядя на мои глаза к эндокринологу меня не отправил. И в момент посещения окулиста глаза выглядели не лучше, чем в период лечения у инфекциониста, Грейвс был лет 5 наверное как минимум, до начала лечения. Так что да, там может быть и все очевидно, но без знания базы и очевидные вещи не замечаются.


            1. nameless323
              04.09.2023 14:32
              +7

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


              1. panzerfaust
                04.09.2023 14:32
                +4

                То есть для вас не звоночек что человек не знает структур данных

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


                1. nameless323
                  04.09.2023 14:32
                  +1

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


                1. faiwer
                  04.09.2023 14:32
                  +10

                  как устроена хэшмапа

                  Есть некоторая разница между:


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

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


                  1. vdshat
                    04.09.2023 14:32
                    +3

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

                    К сожалению, подобное, когда знания не соотносятся с реальностью, а воспринимаются как что-то абстрактное довольно распространенное явление не только в программировании, а в любой сфере. Более того, неадекватное восприятие реальности было обозначено, как одна из трех наиболее значимых проблем современного человечества. Ну, и как тут жить прикажите?! Остановите Землю, я сойду ! :)


                    1. evadesad
                      04.09.2023 14:32
                      +1

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

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


                      1. Samhuawei
                        04.09.2023 14:32

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


                    1. Andr1an0
                      04.09.2023 14:32

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

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

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

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

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

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

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

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

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

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

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


            1. faiwer
              04.09.2023 14:32
              +8

              что можно писать ПО и без этого

              Это вообще как? Что это за ПО такое, что можно все массивы на связные списки поменять и всем плевать?! Я бы к вам не пошёл. Пишите такое ПО сами. И пользуйтесь тоже им сами.


              24 плюса. Хабр, что с тобой? Я понимаю, если бы человек написал что ему человек со знанием эхо-корасиков не нужен. Но блин не отличать связный список от массива… Причём в Java… Что дальше? Кандидат путается в 3-х IF-ах? Ок, берём. Будем давать задачи с 2 IF-ами.


              1. panzerfaust
                04.09.2023 14:32
                +4

                Во-первых, вы еще пойдите найдите кейс, где в современном джава-приложении ArrayList и LinkedList ведут себя драматически по-разному. Типовая обработка коллекций вся давно на функторах - а они разницу не видят. Сценарий, где мы зачем-то берем энный элемент списка и получаем ту самую разницу O(1) vs O(n) - это экзотика, которая встречается скорее на литкоде, а не на практике.

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

                В-третьих, LinkedList в джаве - предмет шуток даже для его автора. Why so serious?

                Что-то не выходит драмы.


                1. faiwer
                  04.09.2023 14:32
                  +2

                  то это решается ровно 1 замечанием на код ревью.

                  Не решается. Если человек не знает этого, то он не знает почти ничего. Его придётся учить почти с нуля.


                  где мы зачем-то берем энный элемент списка

                  Т.е. вы используете массивы, но адрессная арифтметика вас не интересует. Какие-нибудь матрицы смежности это видимо high end технологии. Понял. А ну да. Графы это наверное уже литкод. К реальному коду отношения не имеет. В реальном коде мы ведь за пределы итераторов никогда не вылезаем. Понял, понял.


                  Что-то не выходит драмы

                  И правда. В вашей вселенной не выходит. Главное от неё держаться подальше.



                  1. panzerfaust
                    04.09.2023 14:32
                    +3

                    Графы это наверное уже литкод. К реальному коду отношения не имеет. В реальном коде мы ведь за пределы итераторов никогда не вылезаем. Понял, понял.

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

                    Главное от неё держаться подальше

                    Я рад, что искусство диагноза по аватарке все еще живо.


                    1. faiwer
                      04.09.2023 14:32
                      +1

                      выдроченный курс CS… связный список

                      Ох. И это Java, которую всегда ставили в пример. А я думал у нас всё плохо.


                      1. panzerfaust
                        04.09.2023 14:32
                        +2

                        В джаве в 99.(9)% случаев используют ArrayList. И вообще есть бест практис работать с листами как с интерфейсом List. А обрабатываются они через стримы (т.е. функторами). Обращаться к элементу по индексу - это реально редкость в энетрпрайзе. LinkedList лично я за 8 лет практики использовал только на литкоде, т.к. этот класс также реализует интерфейсы Queue и Stack.

                        Реальной проблемы в выборе реализации просто не стоИт. Поэтому вообще ноль проблем, если человек не знает разницу или подзабыл. На самом деле джуны+ и далее знают все прекрасно.

                        В чем именно ваша проблема? Почему вы продолжаете хамить даже не разобравшись в ситуации?


                      1. faiwer
                        04.09.2023 14:32
                        +1

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


                        Queue и Stack

                        Не-не. Никаких очередей и стеков. Долой литкодщину. Слишком сложно. Спринт горит!


                        P.S. я там выше скриншот добавил. У нас вроде тоже ынтерпрайз. И тоже итераторы.


                      1. javalin
                        04.09.2023 14:32
                        +1

                        В джаве в 99.(9)% случаев используют ArrayList.

                        Не сказал бы. У нас около 20% LinkedList, и есть даже над ним обвертки, для большей эффективности. Все зависит от задач.

                        Обращаться к элементу по индексу - это реально редкость в энетрпрайзе.

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

                        вообще ноль проблем, если человек не знает разницу

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


                  1. KReal
                    04.09.2023 14:32

                    Судя по вашему скрину, у вас а) фронтенд б) что-то связанное с графикой


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


                    1. faiwer
                      04.09.2023 14:32

                      Открыл наш backend:


                      • 955 results in 293 files
                      • 3916 results in 654

                      Полистал. Часть, конечно, что-то левое. Но более чем достаточно кода где прямое обращение к элементу массива по индексу. Как и вызовов всяких splice, findIndex, slice.


                      Backend самый обыкновенный (ну кроме того что это high-load). Посмотрел по смыслу — всякие сопоставления коллекций, их merge-инг, валидация, группировка и т.д… Ну т.е. довольно рутиные операции. Не какие-нибудь графические вектора.


                  1. Virviil
                    04.09.2023 14:32

                    Покажите пожалуйста пару мест - очень интересно где вы обращаетесь по индексу.


                    1. wataru
                      04.09.2023 14:32

                      Простите, но влезу в разговор ссылкой на код хромиума. Куча обращений по индексам. Где-то 80% найденного там — это действительно тупо итерация по контейнеру, объявления массивов и прочие комментарии: не считается, да. В оставшихся там есть обращения к подряд идущим элементам. Еще где-то индекс является ключем в колекции — это именно обращение по индексу, которое нетривиально заменить на что-то еще.


                    1. faiwer
                      04.09.2023 14:32

                      Выше кратко привёл вид задач. Включил поиск по проекту:


                      • Самый частый кейс это какая-нибудь реализация навигации стрелками с клавиатуры по списку.
                      • Какой-то кейс где у нас есть несколько уровней тарифных планов, которые поддерживают разный набор фич. И у них есть иерархия. Задача — выбрать ближайший в пределах иерархии план, содержащий нужную фичу, чтобы попросить юзера купить этот план.
                      • Какой-то мудрёный код в иерархическом контроле где всякие каталоги, подкаталоги. Я вижу там вообще полно индексов. Но это надо вникать в каждый конкретный метод.
                      • Merge-инг разнородных коллекций во что-то новое.
                      • Много кода со всяким парсингом строк. Тоже индекс на индексе.
                      • Ооочень много кода, где массивы используются в роли хеш-мап, но с числовыми ключами (которые и есть индексы в коллекции). Формально можно заменить на хешмапы с сохранением порядка и со случайной генерацией ID, но на кой чёрт? :)
                      • Куча какого-то кода с поиском. В том числе иерархическим.

                      Ну и прочие примеры. Там 513 кейсов даже по такой регулярке: \[(idx|index).


                1. nameless323
                  04.09.2023 14:32

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


                  1. faiwer
                    04.09.2023 14:32

                    мммм всё на хипе и в массиве все равно будут указатели на куда попало

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


                    1. nameless323
                      04.09.2023 14:32

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


                      1. faiwer
                        04.09.2023 14:32

                        Мне кажется это уже скорее не про Java или .Net. Более низкий уровень. Каждой задаче свой инструмент.


                      1. nameless323
                        04.09.2023 14:32

                        Каждой задаче свой инструмент.

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


              1. ruslan_sverchkov
                04.09.2023 14:32
                +2

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


            1. botyaslonim
              04.09.2023 14:32

              Вот тут чуть мимо. Человек сложно устроен. Я однажды мучился с почками, ходил по врачам, пока однажды уролог не сказал: "Да у вас просто мышцы спины в гипертонусе" и отправил к совершенно другому специалисту


          1. Gusotron
            04.09.2023 14:32
            +4

            Смею заметить, что пример с врачом по моему мнению в корне некорректен: люди намного хуже стандартизованы в деталях функционирования конкретного организма нежели 90 процентов программных продуктов. А еще код можно читать, совсем как текст, а вот состояние человеческого организма прочитать, увы, не выйдет, его можно только оценить по огромному комплексу сложных, непостоянных и индивидуальных метрик. Если выкинуть совсем энциклопедические случаи - даже терапевту, чтобы лечить хорошо, действительно нужен кругозор и база. Чтобы написать рабочий, просто рабочий код требуется, ИМХО, на порядок меньший кругозор и пресловутая «база».


            1. develmax
              04.09.2023 14:32
              +1

              Когда код закрыт, информационная система превращается в чёрный ящик, который тоже нужно уметь диагностировать))


          1. 0ctESA
            04.09.2023 14:32
            +4

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


            1. microuser
              04.09.2023 14:32
              +1

              Во первых гуглить тоже надо уметь, человек без нормальной базы на гугление потратит в 5 раз больше времени и не факт что вообще поймет что он там нагуглил.

              И потом может тогда врачам тоже не стоит 5 лет учиться, пусть идут на трёхмесячные курсы от гикбрейнс и вперёд, все равно 90% больных у ЛОРа болеют вирусными заболеваниями которые сами пройдут за неделю, а остальные можно и нагуглить


              1. werpo
                04.09.2023 14:32

                может тогда врачам тоже не стоит 5 лет учиться, пусть идут на трёхмесячные курсы от гикбрейнс и вперёд, все равно 90% больных у ЛОРа болеют вирусными заболеваниями которые сами пройдут за неделю, а остальные можно и нагуглить

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


              1. dormin
                04.09.2023 14:32

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


                1. microuser
                  04.09.2023 14:32
                  +3

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


                  1. Leetc0deMonkey
                    04.09.2023 14:32
                    +2

                    Я учился в ВУЗе (да ещё в доЭГЭшную эпоху), джонсоны не перекладываю. Но интервью, да, неправильные. Возможно лет 20 назад алгоритмы и правда могли выделить лучших инженеров из просто хороших. Но нынче эта система геймится и абьюзится просто в промышленных масштабах. Вплоть до состояния антипаттерна: видишь выходца из FAANG - считай абсолютно бесполезная в реальной разработке литкод-макака.


                    1. blind_oracle
                      04.09.2023 14:32
                      +4

                      @Leetc0deMonkey

                      литкод-макака

                      Ироничненько (с)

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


                    1. wataru
                      04.09.2023 14:32
                      +1

                      видишь выходца из FAANG — считай абсолютно бесполезная в реальной разработке литкод-макака.

                      Опишите, пожалуйста (или ссылку на ваш старый коммент дайте, если уже писали), в чем конкретно они бесполезные в разработке?


                    1. microuser
                      04.09.2023 14:32

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


                      1. Leetc0deMonkey
                        04.09.2023 14:32
                        +3

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


                    1. faiwer
                      04.09.2023 14:32
                      +8

                      видишь выходца из FAANG

                      Работаю с выходцами из FAANG. Отличные спецы знающие своё дело. Имеющие превосходное представление о реальной разработке, причём часто с позиции business-а. Прекрасно понимают где и когда можно скосить углы, где будут perf-bottleneck-и, где можно писать код ногами, и куда подстелить соломку. Хорошо понимают роль логирования, умеют в продвинутый troubleshoot-инг и debug-инг. И обладают высокой инициативой. Хорошо доносят своё мнение. Умеют идти на компромисы. Обладают глубокими познаниями в используемых инструментах. Без проблем пишут свои решения, библиотеки. Прекрасно разбираются в чужом коде.


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


                      ИЧСХ далеко не все из них умеют в "литкод-макакинг".


                      1. sergiodev
                        04.09.2023 14:32
                        +7

                        business-а

                        perf-bottleneck-и

                        troubleshoot-инг и debug-инг


                      1. nameless323
                        04.09.2023 14:32
                        +3

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


                    1. nameless323
                      04.09.2023 14:32
                      +4

                      видишь выходца из FAANG - считай абсолютно бесполезная в реальной разработке литкод-макака.

                      А вы много таких выходцев реально встречали/работали? Литкод в ФААНГЕ это может 10%-15% от всей серии интервью на позиции выше джунов, остальное как у всех - тех, опыт работы и всё вот это вот. Или у вас все операционные системы, иде и т.д. пишут исключительно литкод макаки и просто рэндомно выходят продукты которыми буквально пользуются миллионы/миллиарды?


          1. mixsture
            04.09.2023 14:32

            Я думаю что нет, почему тогда в мире ИТ это норма?

            Потому что мир ИТ совсем не похож на мир физиологии человека.
            "База" анатомии довольно статична и не расширяется так, как "база" ИТ. Анатомию без специализаций выучить можно, а объять также сферу ИТ невозможно. Во фронте каждые 10 лет прикладные фреймворки меняются — вы представляете себе врача, у которого инструментарий каждые 10 лет абсолютно не похож на предыдущий?


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


            1. microuser
              04.09.2023 14:32
              +7

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

              https://habr.com/en/articles/758838/comments/#comment_25932550


          1. markmariner
            04.09.2023 14:32

            Вы пойдёте к такому врачу, так же как и я, и уже много-много раз ходили. Вы же каждого врача не интервьюируете?


            1. microuser
              04.09.2023 14:32
              -1

              Раньше ходил, спустя какое то время понял что есть способ эффективнее. Сначала я иду к обычным врачам по ДМС что бы назначили необходимые стандартные исследования "по протоколу" чисто для экономии средств, а затем с результатами иду к профессору с большим опытом.


          1. develmax
            04.09.2023 14:32
            +1

            Когда вы последний раз использовали связный список?


            1. wataru
              04.09.2023 14:32
              +1

              По крайней мере в гугле их используют постоянно. Писать их, конечно, с нуля почти не пишут, за очень редкими исключением, но на интервью иногда спрашивают, чтобы убедится, что кандидат таки поймет, когда использовать std::vector, когда std::list. Можно было бы просто спрашивать о свойствах списков, но все равно же надо выдавить из кандидата 5-10 строк осмысленного кода, почему бы не спросить что-то со списком написать?


              1. develmax
                04.09.2023 14:32

                Вы так и не ответили на вопрос.


                1. wataru
                  04.09.2023 14:32
                  +1

                  Лично я — около месяца назад. Но это не значит, что оно мне нужно ~12 раз в году. Когда кое-что немного другое писал, оно мне было нужно каждые несколько дней.


          1. kenoma
            04.09.2023 14:32
            +1

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


            1. microuser
              04.09.2023 14:32

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


              1. faiwer
                04.09.2023 14:32

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


                1. microuser
                  04.09.2023 14:32
                  -1

                  То есть по факту такой проблемы не существует


        1. vdshat
          04.09.2023 14:32
          +3

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

          Т.е. лень самому придумать вопосы и темы, но не лень время тратить на пустые собеседования? Может это и есть ответ про других: им тоже лень думать и подстраиваться под каждого кандидата.


          1. panzerfaust
            04.09.2023 14:32
            +3

            Т.е. лень самому придумать вопосы и темы

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


            1. vdshat
              04.09.2023 14:32
              +1

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


              1. Nialpe
                04.09.2023 14:32

                сам именно так и провожу интервью - даю кусок кода и в нем уже (неожиданно! ) находим и паттерны, и solid, и структуры данных, и прочие языковые моменты. кандидаты более расположены общаться, нежели спросить "билет 5. вопрос 1. паттерн синглтон")))


        1. Kergan88
          04.09.2023 14:32

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

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


        1. NuckChorris
          04.09.2023 14:32

          Ну вот, например, после вопроса про устройство hashmap можно спросить - а можно ли в качестве ключа исользовать null? А что будет при постоянных коллизиях?


      1. DancingOnWater
        04.09.2023 14:32
        +1

        Проблема что это не всегда что-то из разряда фундаментального. Для той же системы .Net вы влет может огрести от разной реализации в mono и clr.

        Для c++ реализация хэша в контейнерах может меняться от версии компилятора.

        И т.д.


        1. Calc
          04.09.2023 14:32

          Для c++ реализация хэша в контейнерах может меняться от версии компилятора.

          И в команде никто этого не знает и не знает где бывают эти проблемы в их проекте?


          1. isadora-6th
            04.09.2023 14:32

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


        1. nameless323
          04.09.2023 14:32
          +1

          Ну имхо что такое хэшэйблы (всякие unordered_) и по какому принципу оно работает это как раз фундаментальное и это по хорошему надо знать, а как оно уже конкретно реализованно это детали. Хотя С++ страдает от того что все знают 5% языка и у всех эти 5% свои с небольшими пересечениями, а спрашивать "а зачем нужен виртуальный деструктор, а можно ли выбрасывать исключения в деструкторе" и так далее как-то не серьезно (да и отвечать на это тоже задалбливает)


      1. AllexIn
        04.09.2023 14:32
        +14

        Проблема вопросов по базе в том, что они могут не иметь отношения к реальным юз кейсам.
        Не так давно собеседовался в компанию как Unreal Engine плюсовик. Обсуждали ромбовидное наследование что это, как правильно наследоваться и что будет в разных вариантах наследования. Всё что я мог сказать: "Да, я конечно читал про проблемы ромбовидного наследования. Лет 10 назад. Потому что на практике мы его нигде и никогда не используем из-за того что это проблемная штука, которой нужно избегать."

        И вот получается - это база. И это база, которую я не знаю(вернее не помню, но это одно и тоже). Давайте меня браковать за это?


        1. avost
          04.09.2023 14:32
          -6

          проблемы ромбовидного наследования

          И это база, которую я не знаю(вернее не помню, но это одно и тоже).

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


          1. NeoNN
            04.09.2023 14:32
            +6

            Для энтерпрайзных разрабов обычно нет проблем рассказать про солид во всех его проявлениях, связать di c юнит тестами, и c них перескочить на bdd с примерами из реальной жизни, рассказать про легаси, в котором пришлось это все править и проч. Рассказать про проблемы, которые приходилось решать, поиски боттлнеков и гейзенбагов. А вот вопросы по "БАЗЕ" - ну блин... Бывают такие дебильные. Но правда бывают и хорошие и можно глубоко по ним докопаться. Как повезет с интервьюером. Судя по статье везет не всем.


            1. avost
              04.09.2023 14:32
              +5

              Да я не про рассказать. Я про буквы. Из этих букв я, обычно, только первую помню потому что она первая и L потому что она Бабра Лискофф :).
              Рассказать потом не проблема, проблема вспомнить что какая буква означает.


              1. svoezemtsev
                04.09.2023 14:32

                А была бы у этой "Бабры" фамилия не на Л - не было бы никакого SOLID. Мне вот интересно - что бы было?


                1. avost
                  04.09.2023 14:32
                  +1

                  Ну, можно, например, вовсе выкинуть L в пользу I, а сам Interface segregation переименовать в Abstraction segregation и получится SODA :)


                1. Suharkov
                  04.09.2023 14:32

                  А была бы у этой "Бабры" фамилия не на Л 

                  Так ведь была. Вполне могли получить SOJНID вместо SOLID.


                  1. tommyangelo27
                    04.09.2023 14:32

                    Jane — это второе имя, так что просто SOНID


        1. Wesha
          04.09.2023 14:32
          +7

          И это база, которую я не знаю(вернее не помню, но это одно и тоже)

          "Не дожидаясь отказа, свою кандидатуру я снимаю сам." (c) некто по фамилии Эйнштейн


          1. AllexIn
            04.09.2023 14:32

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


      1. Wrench_IT
        04.09.2023 14:32
        +13

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

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


        1. Samhuawei
          04.09.2023 14:32

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

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

          Я думаю что в чём-то конкретном программист должен разбираться досконально. В остальном можно зазубрить. Например, если он фронтендщик, ему не надо разбираться в node.js, достаточно запомнить пару команд как быстро поднять сервер локально, дальше пусть devops парится.


          1. vdshat
            04.09.2023 14:32
            +1

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


      1. venanen
        04.09.2023 14:32
        +26

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


      1. zamsisadmin
        04.09.2023 14:32
        +1

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


        1. microuser
          04.09.2023 14:32
          +3

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


      1. ReadOnlySadUser
        04.09.2023 14:32
        +14

        А в чем собственно проблема вопросов по базе?

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

        вкатыши в айти которые знают только то с чем работали и нафиг не нужны

        Я в айти уже считай 10 лет. И, удивительным образом, я знаю только то, с чем работал :) А то, с чем не работал - не знаю. Да и не стремлюсь особо. Знать всё невозможно и не нужно.


      1. saboteur_kiev
        04.09.2023 14:32
        +3

        IMHO, основная проблема вопросов по базе, что многие путают низкоуровневые нюансы и базу.

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

        Мало кто пытается на интервью выяснить что человек знает, чаще стараются что не знает.

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


      1. Animegravitation
        04.09.2023 14:32
        +2

        а что за пренебрежение к тем кто хочет "вкатиться в IT" ? может если бы в нашей стране норм ЗП получали не только нефтяники и ITшники то может быть и вкатышей не было бы ?

        А то странно ругать людей в стране скатывающейся в "темные века технологий" что кто то хочет вкаиться в IT

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


    1. s207883
      04.09.2023 14:32
      +3

      А как же тогда повыделываться знанием алгоритмов?


      1. NeoNN
        04.09.2023 14:32
        +28

        Мне кажется пара реальных сценариев из жизни может быть гораздо интереснее литкодинга. Начать например так - ты знаешь что такое рекурсия. Окей, а вот допустим у тебя есть рекурсивный алгоритм, но внезапно вылетает stackoverflow - а что это? А почему это - и как ты решишь эту проблему.? Оо, развернешь в стек или очередь, здорово. А слышал про хвостовую рекурсию? А в C# она есть? А где есть? Ооо, а ты использовал F# для реальных задач в проектах? Расскажи. А что ты еще знаешь про приемы функционального программирования, если мы пишем на C#? А что такое Result<T> и где он используется?

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


        1. s207883
          04.09.2023 14:32
          +4

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

          Это и собеседованием сложно назвать. Скорее обмен мнениями, диалог специалистов или что-то похожее.


        1. vdshat
          04.09.2023 14:32
          +3

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


        1. funca
          04.09.2023 14:32
          +22

          но внезапно вылетает stackoverflow - а что это?

          Это сайт, с ответами на все вопросы)


          1. vdshat
            04.09.2023 14:32
            +1

            Был случай из практики про stackoverflow.

            -- я взял ответ на stackoverflow там куча вариантов

            -- а в чем между ними разница?

            -- ????

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

            -- ну, я ж не знал!

            -- ...


      1. adenis78
        04.09.2023 14:32

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

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


      1. wnder
        04.09.2023 14:32
        +1

        Общался в среде литераторов - они конкурсы проводили, на которые писатели подавали свои рассказы. Повыделывался знанием сортировок.

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

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


    1. valery1707
      04.09.2023 14:32
      +8

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

      Чаще всего в резюме написано что "работал работу", ещё может быть стек указан, но сразу на весь срок в компании на протяжении 5+ лет.
      Во что тут вчитываться и что корректировать?

      Резюме со ссылкой на Github я ещё не встречал.
      Правда встречал со ссылкой на Stackoverflow, только там реальная активность была 5+ лет назад, а потом всё - ни вопросов ни ответов - что мне дал это профиль? В чём смысл оставления этой ссылки в резюме?


      1. panzerfaust
        04.09.2023 14:32
        +1

        Чаще всего в резюме написано что "работал работу"

        Ну если кандидат про все Х лет своего опыта поднатужился и выдавил только "работал работу", то не зовите такого кандидата, не вчитывайтесь и не корректируйте. И в целом я не согласен с "чаще всего". У нас сейчас на HR доске где-то 15 кандидатов висит. Почти в каждом резюме глаз за что-то цепляется.


        1. valery1707
          04.09.2023 14:32
          +1

          И в целом я не согласен с "чаще всего".
          У нас сейчас на HR доске где-то 15 кандидатов висит.
          Почти в каждом резюме глаз за что-то цепляется.

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

          Да, у некоторых есть за что зацепиться, но это именно исключение из правил.

          У меня вот такая статистика.


          1. chilicoder
            04.09.2023 14:32

            в 10 последних собеседованиях у меня ни разу не спросили про проекты, хотя в резюме указаны довольно вкусные, специально отбирал.


        1. Wan-Derer
          04.09.2023 14:32

          Как-то странно. Если человек 15 лет отработал в ИТ, но давно забил на личные проекты, а в свободное время выращивает помидорки - он уже не кандидат?


          1. alexzaides
            04.09.2023 14:32

            ага. А если он работает по 8 часов в день с двумя выходными в неделю - видимо с ним уже вообще не о чем разговаривать :-)


          1. panzerfaust
            04.09.2023 14:32

            Вы же даже не поняли о чем речь. Какие личные проекты вообще? Речь про людей, которые пишут что-то типа "работал в ООО Рога и Копыта с 2012 по 2019, правил баги, делал фичи" - и все, другой информации нет. На чем писал, чего достиг, какие проблемы порешал?

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


            1. alexzaides
              04.09.2023 14:32
              -1

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


              1. Ivan22
                04.09.2023 14:32

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

                Ну а про фичи и тем более - всегда можно найти и важную и уникальную.

                p.s. попросите ЧатГПТ помочь, ставлю десятку он придумает что написать


                1. alexzaides
                  04.09.2023 14:32
                  -1

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


                  1. panzerfaust
                    04.09.2023 14:32
                    +1

                    Если поднапрячься и выдать красивую картинку для удовлетворения чувства прекрасного интервьютера

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


      1. Nebesnaya94
        04.09.2023 14:32

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


        1. FelixTheMagnificent
          04.09.2023 14:32
          +18

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

          Люди проводят время с семьей или с самим собой, крутят гайки в машине, путешествуют, катаются на лыжах, ходят в походы, танцуют, и свободное время используют для социализации. А если что и будет - в 99% это что-то, решившее проблему конкретного человека, и который сделал это для себя, возможно совершенно неоптимально, не покрыв тестами и т.д. Так сказать, as is.

          К тому же, за крайне редким исключением, у всех компаний код под NDA, и как следствие - 8+ лет опыта у меня есть, гитхаб тоже, а показать есть говнокод 10-летней давности)


        1. nameless323
          04.09.2023 14:32
          +1

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


        1. haradrime
          04.09.2023 14:32
          +4

          Подскажите мне, я вот почти 10 лет уже являюсь ETL-разработчиком (Oracle BI + Oracle Data Integrator). Я вот смотрю на свои огромные схемы ETL-процессов и не понимаю каким образом я это должен выложить на github? А еще у меня куча разработанных дашбордов в BI, скриншоты может мне выложить на github? или я просто не разработчик? Так пишите как будто сами вот только-только вкатились в айти


      1. VladimirLadynev
        04.09.2023 14:32

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


    1. megazoid007
      04.09.2023 14:32

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


    1. vvk78
      04.09.2023 14:32
      +5

      Только вопросы по базе и алгоритмам и представляют настоящий интерес. Говорю это как человек проведший несколько сотен интервью.

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

      И да, 50% кандидатов заваливают простейшие вопросы по коллекциям - а это ведь основа.


      1. Leetc0deMonkey
        04.09.2023 14:32
        +5

        Структуры и Алгоритмы это не база, это всего-лишь одна из граней Компьютерных Наук. У нас даже предмет такой был, САОД назывался. И теперь, 25 лет спустя, я узнаю что это оказывается была "база" и без неё ты никто и звать тебя никак...

        И да, 50% кандидатов заваливают простейшие вопросы по коллекциям - а это ведь основа.

        Значит их сфера ответвенности лежала совсем в других областях программирования.


        1. ReadOnlySadUser
          04.09.2023 14:32

          И теперь, 25 лет спустя, я узнаю что это оказывается была "база" и без неё ты никто и звать тебя никак...

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

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

          Сейчас вообще есть ChatGPT, который мне и подводные камни подскажет в случае чего, и примеры напишет и вообще распрашивай не хочу) Я согласен с тем, что в целом понимать архитектуру ЭВМ и "архитектуру" алгоритмов и структур данных бывает полезно, но только на уровне "могу порассуждать". Знания уровня даже Leet Code medium обычно не нужны никому.


      1. alexzaides
        04.09.2023 14:32
        +2

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


    1. ZloyLis
      04.09.2023 14:32
      +5

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

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


    1. 0xUL
      04.09.2023 14:32
      -1

      Вот и получается, что собеседования в России - чистой воды рандом


    1. DNK1
      04.09.2023 14:32

      Согласен полностью! Хожу по собесам и первый вопрос: 'Что у вас с английским?'. Резюме моë состоит из 10 строк, а в 3й строке написано, что преподавал английский в университете 10 лет)) Сидишь и просто не знаешь, что ответить))


      1. panzerfaust
        04.09.2023 14:32

        Ответьте фразой на английском с максимальным уровнем редких вычурных слов. Как в диалогах из Legacy of Kain. Пусть страдают, если чтение на русском не освоили.


  1. benjik
    04.09.2023 14:32
    +26

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


    1. xsevenbeta
      04.09.2023 14:32
      +8

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

      Потом они рассказывали о том, чем надо будет заниматься и их интересовали мои знания этих продуктов или схожих. Из того что я не знаю RabbitMQ не делалось трагедии, они просто интересовались на каком уровне я вообще знаю работу брокеров, например. Но это были в основном люди 30-35+, уверенные в себе, которым ничего не надо себе доказывать и которым был нужен специалист.

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

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


  1. Nialpe
    04.09.2023 14:32
    +23

    а у вас были кандидаты, которых ваш сеньор с ролью техлида одобрил? может сперва с ним обсудить подход к отбору?


    1. DyadyaBob Автор
      04.09.2023 14:32
      +5

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


      1. yoshka
        04.09.2023 14:32
        +35

        А ларчик просто открывался :) То есть кадры есть, просто нет на них денег. Тогда может с техлидом обсудить, что на "сеньоров" как он их видит, нет денег, есть на мидлов? Чтоб требования тоже были пониже.


        1. Germanets
          04.09.2023 14:32
          +1

          Предвижу ответ уровня "Это же БАЗА, её даже джун должен знать!")


      1. jam12345
        04.09.2023 14:32
        +7

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

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


      1. botyaslonim
        04.09.2023 14:32
        +3

        Вот до этого комментария не хотел писать, что техлид дурак, но теперь напишу )
        У вас одна проблема в команде


  1. bubn0ff
    04.09.2023 14:32
    +62

    Может просто техлида поменять и дело пойдёт быстрее?


    1. onets
      04.09.2023 14:32
      +22

      Хотя бы просто попробовать не пускать на собесы.


    1. Alesh
      04.09.2023 14:32
      +10

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


      1. alexzaides
        04.09.2023 14:32
        +4

        ну тут вопрос, кого поменять проще. У меня знакомая hr в одной компании как то 10 месяцев не могла закрыть позицию. то одно техлиду не нравилось, то другое.. при этом сроки горели, баги лезли косяками, техлид героически превозмогал и показывал свою незаменимость работая до 10 вечера и по выходным. А кандидаты все какие то не такие были - ну вот никак не могли ответить на простейшие вопросы и показать знания элементарных алгоритмов. А потом техлида ушли. И позицию закрыли за неделю - просто взяли одного из ранее отвергнутых кандидатов. И работать он стал более менее по 8 часов. и со сроками и качеством стало получше.. только говорят периодически матерился на код ушедшего техлида..

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


        1. MadeByFather
          04.09.2023 14:32
          +2

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


          1. nameless323
            04.09.2023 14:32
            +4

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


            1. Samhuawei
              04.09.2023 14:32
              +1

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


            1. werpo
              04.09.2023 14:32

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

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


          1. ReadOnlySadUser
            04.09.2023 14:32
            +3

            В принципе, у меня было даже наоборот однажды. Я пришёл в проект на чистом Си и такой: "вау, как всё круто и удобно сделано, буду делать теперь также" :) Я даже немножечко разлюбил С++, настолько был код хорош, прост, понятен и расширяем. Но там и сам проект - это была относительно небольшая библиотека, которая писалась без спешки и делала хорошо поддающийся декомпозиции функционал, который был отлично документирован.

            Иногда чудеса случаются)


  1. terrier
    04.09.2023 14:32
    +52

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


    1. Alexsey
      04.09.2023 14:32
      +16

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


      1. terrier
        04.09.2023 14:32
        +4

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


        1. vendelieu
          04.09.2023 14:32
          +1

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


          1. terrier
            04.09.2023 14:32
            +5

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


    1. VaNnOrus
      04.09.2023 14:32
      +1

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


      1. terrier
        04.09.2023 14:32

        А разве в статье сказано, что проблема не обсуждалась с руководством?

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


    1. Duraleev
      04.09.2023 14:32

      К сожалению, подобные обсуждения на практике редко приносят пользу, даже если состоятся.

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


      1. terrier
        04.09.2023 14:32

        К сожалению, подобные обсуждения на практике редко приносят пользу, даже если состоятся.

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


    1. DyadyaBob Автор
      04.09.2023 14:32
      +9

      Эта проблема уже обсуждается и уже не в первый раз. Если бы я был плохим тимлидом, то конфликт с техлидом был бы уже в рутинных задачах. Возможно открою секрет, но одним из важных факторов утвердить должность специалиста является авторитет самого специалиста в его области работы. Так же и здесь. Техлид является авторитетом для начальства как "технический гуру", по этой причине равный мне голос при выборе кандидата.
      Я не начинающий тимлид и скажу, что один из основных навыков - это умение работать с разношерстными людьми и получать явный результат. Создать конфликт и бежать к начальству со словами "Меня обидел техлид, он не хочет дружить с теми, с кем хочу я", вот это поведение начинающего тимлида.
      А на счёт решения, универсального нет, как в технических, так и в управленческих задачах. Нужно всегда учитывать много факторов, которые затрудняют решение, а в каждой команде в разных компаниях они разные. Да и статья не голден хаммер по решению вопроса найма разработчиков, а по большей части описание личного опыта и приход к проблемам, которые присуще найму айтишников в целом.


      1. yoshka
        04.09.2023 14:32
        +2

        А у вас техлид не устал ли случайно до той степени, что у него сил нет на принятие решений, и он "нет" говорит просто потому что так легче? Может, ему в отпуск?


        1. DyadyaBob Автор
          04.09.2023 14:32
          +1

          Уже думал об этом моменте, как раз одним из вариантов решения был найм спецов пока сам техлид будет в отпуске)


          1. yoshka
            04.09.2023 14:32
            +2

            Мне кажется, вы себе врага таким образом наживете.


            1. Tarnella
              04.09.2023 14:32
              +1

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


          1. alexzaides
            04.09.2023 14:32

            а потом он выйдет из отпуска и чисто из принципа съест кандидата


      1. terrier
        04.09.2023 14:32
        +6

        Эта проблема уже обсуждается и уже не в первый раз.

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

        >> Создать конфликт и бежать к начальству со словами "Меня обидел техлид, он не хочет дружить с теми, с кем хочу я", вот это поведение начинающего тимлида.

        Именно. Последнее, что вам нужно - это создавать конфликт и жаловаться. Не надо так делать.

        Судя по тому, что формат собеседования и критерии оценки со стороны техлида для вас раз за разом оказывались сюрпризом - вы с ним по делу не говорили, а между тем, вопрос "А почему он себя так ведет" у вас сейчас один из основных.
        Вы уцепились за самый простой ответ "Он упырь и упрямый долбоящер, который понятия не имеет как проводить собеседования", а между тем все может быть совсем не так.
        Может быть, у него годовая премия зависит от того, насколько теоретически подкованными будут нанятые кандидаты. Может быть его к вам приставили именно потому, что у начальства есть подозрения, что без няньки вы наймете слабых людей. Может быть, в целом у начальства есть сомнения в, так сказать, engineering excellence в организации и оно решает проблему таким способом - попросив техлида "Пожощще там спрашивать на собесах". Может быть, что-то похожее думает сам техлид. Можно сколько угодно гадать, но пока вы с ним продуктивно не поговорите, можно будет долго изучать "культуру рекрутинга" в других компаниях, пока у себя найм стоит.
        Здесь мы, понятно, исходим из того, что техлид и сам хочет нанять лучших из возможных кандидатов в том смысле, в котором он это понимает. Если он саботажник, то дело другое, но это, конечно, маловероятно.

        По переговорам с начальством у вас в статье упоминается, что на вас давят через техлида ( WAT?! ) и что задаются вопросы о медленно достигаемых результатов. А вы-то какие запросы к ним адресуете? Чего от них хотите, что предлагаете?

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


    1. Tarnella
      04.09.2023 14:32

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


  1. Soupbreak
    04.09.2023 14:32
    +28

    Нет противника страшнее, чем союзник-идиот


  1. Psychosynthesis
    04.09.2023 14:32
    +3

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

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

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

    Интересно как собесы будут через пять лет выглядеть.


    1. mikronavt
      04.09.2023 14:32

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


      1. Psychosynthesis
        04.09.2023 14:32

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


  1. Leetc0deMonkey
    04.09.2023 14:32
    +5

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

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


    1. olku
      04.09.2023 14:32

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


    1. DyadyaBob Автор
      04.09.2023 14:32

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


      1. Floyd54
        04.09.2023 14:32
        +1

        Будут. Наблюдаю тут за одной компанией. Там сменился начальник и понеслось... Условно написано: кандидат должен знать такую-то базовую вещь и три надстройки над ней. На опыте моём я ни разу не видел человека, который знает все три. Максимум две. Штуки крайне специфичные. Вакансии год! Начальник рубит всех, потому что не знают люди все три. Хотя доучить человека дело полутора месяцев(я понимаю, о чем речь, так как стек мой, я тем же самым занимаюсь). И таких вакансий у них уже штуки 4.


        1. Tarnella
          04.09.2023 14:32

          Надо понимать что иногда нужно найти кандидата, а иногда нужно искать кандидата.


        1. Leetc0deMonkey
          04.09.2023 14:32
          +1

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

          ЧТД: вакансия не такая уж и хорошая. С учётом как легко разменяли год на "полтора месяца обучения" - значит не очень-то кто и нужен. Нечего тратить на таких своё время.


          1. Floyd54
            04.09.2023 14:32
            +1

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


  1. Areso
    04.09.2023 14:32
    +6

    Снова отказ от техлида по причине отсутствия пет-проектов и невозможности оценить практическую часть.

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

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


    1. Leetc0deMonkey
      04.09.2023 14:32
      +9

      Судя по всему, в конторе просто не нужен особо человек.

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


      1. DyadyaBob Автор
        04.09.2023 14:32
        +1

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


        1. Calc
          04.09.2023 14:32
          +2

          Заносите экспертную оценку от 1 до 10 с серединой в 5-6 и не парьтесь
          подключайте третьего по софтскиллам
          через 3 собеседования у вас будет градиент оценок сотрудников, берите топового


      1. alek0585
        04.09.2023 14:32

        Такие как этот техлид это психически больные люди.

        ...

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

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


  1. zergon321
    04.09.2023 14:32
    +15

    У меня на одном собеседовании спросили, какой ассемблерный код сгенерирует компилятор Go для инкремента

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


    1. DyadyaBob Автор
      04.09.2023 14:32
      +2

      Ну, думаю, не стоит из-за одного собеседования с немного неадекватным интервьюером вешать нос) Я помню случаи когда и меня спрашивали, как будет выглядеть конечный автомат в async-await механизме в предкомпилированном коде c#. Но мне больше жалко людей, которые задают такие вопросы, так как все их знания и мир, как мне кажется, сконцентрированы на подобных вещах.
      А по поводу того, чем бы заняться вместо it думаю любой выгоревший специалист думал. Даже я в какой-то момент подумывал просто скопить начальный капитал и заняться своим делом, достаточно банальным и без особых сложностей в процессах, но приносящих денег на уровне работы it-специалистом.
      Да и не стоит думать, что другого не умеете) Я всегда был уверен, что большинство it-спецов умные ребята вне зависимости от сферы, но, к сожалению, не уверены в себе)


      1. zergon321
        04.09.2023 14:32

        Это я самое неадекватное привёл, что мне попадалось, но проблема в том, что "средняя температура по больница" всё же не сильно далеко от этого вопроса ушла


    1. zuek
      04.09.2023 14:32

      Ну, я бы предположил, что любой вменяемый компилятор для инкремента сгенерирует конструкцию на безе инструкции "inc", хотя... смотря для какой архитектуры - я только на x86, да Z-80 в ассемблер смотрел...


  1. AllexIn
    04.09.2023 14:32
    +4

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

    Я и сам таким был. Помню как гневался что приходится работать с людьми, которые не понимают почему float width = 1 / screenWidthPixelsCount; дает ноль.
    Я бы таких на работу не взял!!!
    Хорошо что я лидил, а не брал на работу. Потому что люди приходили, спрашивали почему не работает, получали ответ, исправляли и дальше просто делали свою работу.


    1. micronull
      04.09.2023 14:32
      +2

      почему float width = 1 / screenWidthPixelsCount; дает ноль.

      Для тех кому интересен ответ: деление целых чисел. Надо явно указать что единица является float числом.
      float width = 1.0 / screenWidthPixelsCount;


      1. AllexIn
        04.09.2023 14:32
        +3

        1.0f иначе там double. Ответ даст правильный. Но для производительности похуже. Да и варнинг будет.


    1. Rorg
      04.09.2023 14:32

      Честно говоря, я бы тоже гневался.. Видимо мне тоже не стоит набирать людей)


  1. Ravager
    04.09.2023 14:32
    +4

    А вы не имеете влияние на техлида? Если вы понимаете что техлид неправ, можно поговорить или попытаться отстранить его от собесов.


    1. DyadyaBob Автор
      04.09.2023 14:32

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


  1. ReDev1L
    04.09.2023 14:32
    +1

    Потому что нужен Raft и Leader Election, а у вас консенсуса нет.

    И в топку вашу базу, если вы не делаете HFT, embedded, web3, cryptography и паблик либы.


    1. Akon32
      04.09.2023 14:32
      +4

      Им для raft третьего нанять надо, а они не могут.


  1. samsdemon
    04.09.2023 14:32

    оффтоп, но расскажите, пожалуйста, как у вас получается "техлид нового проекта с опытом уровня senior"

    Следующий уровень за senior у вас не lead, причём не technical lead?


    1. Alesh
      04.09.2023 14:32

      Похоже что уровень lead над senior встречаю в вакансиях всего как несколько лет. Раньше это однозначно была роль. А уровней квалификации три.

      И например teamleadом вполне мог быть middle+


      1. hello_my_name_is_dany
        04.09.2023 14:32
        +2

        Одно дело team lead, там мидл мог на софтах вырваться, а другое дело tech lead, там обычно люди чуть выше senior-разработчика


    1. DyadyaBob Автор
      04.09.2023 14:32

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


  1. iiwabor
    04.09.2023 14:32
    +4

    "Крупные it-игроки ушли, с ними ушли стандарты, топовые специалисты и рабочие места. " - в первых же строках статьи автор дает ответ на все вопросы... И боюсь, что это только начало конца - госкомпаниям нет смысла переманивать разработчиков друг у друга бОльшими ЗП, а наоборот - проще сделать ЗП примерно одинаковыми, чтобы не переходили туда-сюда, да и прибыль от госконтракта не зависит от качества продукта (все равно купят), и, соответственно - от уровня разработчиков...


    1. DyadyaBob Автор
      04.09.2023 14:32

      Тут двоякий момент. Если смотреть на уровень зп, то за 22-23 год темпов роста относительно одной и той же позиции почти нет. До этого год за годом зарплаты росли как на дрожжах, да и достаточно было пройти несколько собеседований чтоб получить оффер с +30% зп от текущего места. Сейчас таких чудес нет. А на счёт госпроектов сложно сказать однозначно. В основном реализация госзаказа прилетает частной конторе под пристальным взором или управлением свыше. Но it-шники тоже не дураки и работать за прайс ниже того, к чему они привыкли не всегда хотят. Из-за этого постоянно будет появляться конкуренция продуктов в тех или иных бизнес-доменах. Хотя есть один продукт-монополист в своей сфере в странах снг, 1с, но это частный случай.


    1. KLIJIN
      04.09.2023 14:32

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


  1. bondeg
    04.09.2023 14:32
    +4

    Либо проблема в техлиде либо автор чего-то не договаривает. Не хватает точки зрения второй стороны.


  1. olku
    04.09.2023 14:32
    +5

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


    1. senglory
      04.09.2023 14:32
      +1

      Это если рутина - копаться в легаси в попытке понять что там диды напридумывали внукам на головную боль.


      1. Samhuawei
        04.09.2023 14:32
        +5

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


      1. olku
        04.09.2023 14:32

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


    1. Ioanna
      04.09.2023 14:32

      Кстати, мое самое лучшее собеседование примерно так и выглядело) Прошла его на ура и досрочно, получила оффер)


    1. DyadyaBob Автор
      04.09.2023 14:32

      Хмм, интересно, не пробовал, стоит поразмыслить на счёт этого, спасибо)


      1. olku
        04.09.2023 14:32

        Не за что. Собеседования кандидата сократились до двух звонков общей длительностью в полтора часа - 30 минут знакомство, 30 кодинг, 30 поведенческое финальное. Вы все равно не узнаете как сотрудничество пойдет через 3-6 месяцев. Кандидаты тоже занятые люди, и скажут спасибо за гуманное отношение. ФААНГ может позволить себе разбрасываться талантами, то набирая, то увольняя, а у маленьких лояльность это критический актив.


  1. offline268
    04.09.2023 14:32
    +1

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


    1. vdshat
      04.09.2023 14:32
      +1

      К тому все идет, раз есть время бегать по собеседованиям в другие компании :)


    1. DyadyaBob Автор
      04.09.2023 14:32

      Это уже совсем крайний случай) И только в безвыходной ситуации)


  1. klopp_spb
    04.09.2023 14:32
    +4

    У меня было два лучших собеседования за последние 3 года (на самом деле значимых всего 4 за >20 лет, но пара из них не считается).

    Исходно:

    0) Удалёнка, Россия.

    00) После пробивки HR (BTW, резюме читали, это уже плюс, но идиотские вопросы "почему ушёл" - сразу в минус, как и "почему к нам")

    1) Тимлид: не будем тянуть кота за, вот два тестовых задания.

    За второе даже не брался, после первого сразу оффер.

    Расстались, увы.

    2) Совсем недавно.

    После первого созвона: "OK, дай мне минут 40"

    ???

    "Посмотрел твой гитхаб, мне спрашивать нечего, давай начнём" (первый! за столько лет! не трахал мозги мусорными вопросами про коллективные ценности, и олимпиадными подколами, а посмотрел в реальный код)

    Работаем :-)


    1. xzeexcz
      04.09.2023 14:32
      +6

      А можно посмотреть твой гитхаб?


      1. klopp_spb
        04.09.2023 14:32

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


  1. vassabi
    04.09.2023 14:32
    +1

    На этом моменте я усомнился в адекватности техлида.

    то есть раньше таких сомнений не возникло ? 8-0


  1. ToSHiC
    04.09.2023 14:32

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


  1. Samhuawei
    04.09.2023 14:32
    +1

    Я думаю правы оба, и техлид, и тимлид.

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

    Расскажу пример. У нас закончился очередной проект и освободилось время. Мне дали задание поискать потенциальные проблемы в многопоточном C# коде проекта соседнего отдела. Код вполне рабочий, продажи идут. Через пару дней число заведённых мною багов перевалило за сотню и мне сказали "горшочек не вари". В основном потенциальные race conditions и незащищённые переменные которые могли изменяться одновременно несколькими потоками. С одной стороны пока не падало, с другой упадёт мало не покажется.

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

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


  1. dalerank
    04.09.2023 14:32
    +3

    Совсем недавно было забавно, техинтервьювер думал подловить на вопросе чем отличается tas от ttas в спинлоке, а я совсем недавно эту тему копал немножко ну и выложил ему теорию и пять или шесть реализаций того и другого, еще и графиков нарисовал. Были круглые глаза и они с лидом полезли смотреть в гугль чем они реально отличаются, потом вопрос "А зачем тебе это?". Тут уже я сослался на митинг и ушел с созвона


    1. Samhuawei
      04.09.2023 14:32
      +2

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


    1. befart
      04.09.2023 14:32
      +4

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


      1. DyadyaBob Автор
        04.09.2023 14:32

        В точку, как раз один из моих пунктов об этом) Если пазл представления о базе интервьюера сходится с базой кандидата, то происходит коннект)


      1. Rorg
        04.09.2023 14:32

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


  1. micronull
    04.09.2023 14:32
    +2

    Хожу на тех. собесы чтоб держать себя в тонусе и подтягивать скиллы.

    Я тебе Google что ли, я забыл это уже давно. Отстань, у меня интеграция нереализованная.

    Удручает ситуация, когда компании среднего уровня берут задачи для собеседования от Google и хотят чтоб кандидат решил их за ограниченно отведённое время (весь тех собес ~1ч 30м).
    Что самое забавное, в этих компаниях работники занимаются перекладыванием json между микросервисами. И никаких тебе низкоуровневых, требующих реального знания алгоритмов, задач.

    У Google и Яндекса такие собеседования из-за того что они ВСЁ реализуют сами. Остальные 95% пользуются готовыми решениями, и как правило лучшими, чем если бы вы написали их сами.

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

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


  1. aaa_bbb
    04.09.2023 14:32
    +3

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


    1. Samhuawei
      04.09.2023 14:32
      +5

      Вспомнил как лет 20ть назад ходил на собес в Proctor and Gamble. Мне админ-бородач заранее прислал типичную задачку из его практики, мы поговорили в его каморке под лестницей, он говорит всё отлично, пошли к гендиректору. Поговорил с гендиректором. На следующий день отзвонилась HR. Вы нам не подходите. Я говорю почему? Вы в кедах пришли, а у нас компания серьёзная, директору не понравилось как вы одеваетесь.

      Ну ОК.


      1. Dimsml
        04.09.2023 14:32
        +2

        И вас даже не заставили проходить психологическое (или это IQ тест?) тестирование с кружочками и фигурами?


      1. LeVoN_CCCP
        04.09.2023 14:32

        лет 20ть назад? Простите, а как был одет админ-бородач?)


        1. 0Bannon
          04.09.2023 14:32
          +1

          Остроносые ботинки на шерстяной носок и в трико.


      1. Areso
        04.09.2023 14:32
        +2

        У меня был такой отказ. Эйчар сказала "а у вас обувь грязная, а у нас компания знаменитая - ну как так админ в грязной обуви будет?"
        На минуточку, за окном было типа такого:


        1. voldemar_d
          04.09.2023 14:32
          +1

          Намек на то, что "нищеброды без своего авто либо денег на такси нам не нужны"? ;-)


          1. Areso
            04.09.2023 14:32
            +2

            Почему намек? Это было в следующем предложении, когда сказал "а вы улицу-то видели?". Но предлагаемая зарплатка не покрывала указанных расходов.


  1. back-and-hit
    04.09.2023 14:32
    +3

    База у каждого своя. В универе хотя бы был список всех вопросов перед экзаменом


  1. evgeniy2525
    04.09.2023 14:32
    +1

    В первом предложении вы пишете, что кандидатов очень много. А потом о том, что работать некому. К примеру у меня весь опыт на Upwork, но клиентами были в том числе небольшие компании. Образование - ф-т Компьютерных наук, АСУ. Но найти постоянную работу Front-end React я не могу - получаю отказы, не доходит даже до переписки. Хотя на Upwork брал проекты с приличным рейтом. Пока его не заблокировали. Есть что показать, но не получается дойти даже до собеседования.


    1. Ioanna
      04.09.2023 14:32

      Не проходите фильтр эйчаров... :(


    1. Ilirium
      04.09.2023 14:32

      Попробуйте напрямую через LinkedIn находить инженеров и писать им. Поищите советы, как улучшить резюме и сделайте, как говорят. Замените в резюме Upwork на название какого-нибудь аутсорсера в РФ. И т.п., не проходите фильтр HR, нужно понять, в чем причина. Взять консультацию у HR, которые правят резюме или карьерного консультанта, сейчас таких услуг очень много.


      1. mapnik
        04.09.2023 14:32

        Так LinkedIn тоже заблокировали!


        1. Ilirium
          04.09.2023 14:32

          Если чего-то заблокировали, и это главное препятствие для человека найти работу, то значит он не хочет работать, а хочет ныть и получать пособие ;)


  1. BoltHold
    04.09.2023 14:32
    +2

    "Мы пустили всезнающего техлида к нам на собесы и он всех разогнал!"


  1. DmitryKozlov1
    04.09.2023 14:32

    Хз чё там в дот нете, проходил в том месяце собесы на java midle, я сам не откликался ни на одну вакансию. У меня ща пару недель было 6 тех собесов и это я ещё от части отказывался. 3 тех собеса были весьма хорошими, ещё 2 сносными, откровенно печальный был только один. Итог 3 оффера. На одном собесе я спросил прямо как сейчас рынок. Они мне сказали что жопа с кандидатами и они не могут закрыть штат. Коллеги у меня кто ходил по собесам тож без проблем получали оферы. Вилки предлагают хорошие. Так что как то ваши наблюдения не могу подтвердить.


  1. Ilyaantipanov
    04.09.2023 14:32
    -1

    Сегодня только на собеседовании спрашивали мол вот код использует асинхронное программирование мол найдите ошибку, ответил по коду мол что идёт и никакой ошибки не вижу. Потом через какое то время hr менеджер сообщает что само собой я не подхожу так как не нашёл ошибки и вообще меня всячески к ней подталкивали. Возникает закономерный вопрос, почему я должен искать ошибку по коду который при мне даже не удосужились запустить? Меня брали на работу по ASP NET Core или в качестве аналога VS чтобы я ошибки тупо по коду искал без компилятора и заменял им среду разработки?

    К одним я уже устраивался на работу, мол тестовое задание было написать контролёры в формате REST API, требовались знания по ASP NET Core, а реально потом в работе пришлось ковырять монструозное BBOM на WPF которое напрямую цеплялась к базам своих клиентов. Хочется спросить, что с вами не так? Требуются одни, тестовое задание другое и не относится к тому чем реально придётся заниматься.


    1. micronull
      04.09.2023 14:32
      +2

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

      Вероятно проверка на знание синхронизации асинхронных функций. Например мьютексы.


      1. Ilyaantipanov
        04.09.2023 14:32

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


        1. nameless323
          04.09.2023 14:32

          Обычно race conditions и например stack/heap corruption выдает программа как "что-то в рандомном месте в рандомное время упало, good luck (особенно если на проде, часто локально даже не воспроизводится)". Кто в этом случае будет искать ошибку? Только вам даже упростили задачу сказав что вот кусок кода и там есть ошибка.


          1. Ilyaantipanov
            04.09.2023 14:32

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


            1. nameless323
              04.09.2023 14:32
              +1

              Не бывает так что в рандомном месте что то упало

              А точно не бывает? А как хип или стэк корапшн проявляется например тогда? А рейсы? А дэдлоки? А что должно в логах быть? Вы логируете каждое обращение к каждому адресу памяти чтобы оттрейсить назад кто её испортил? И все это на проде в релиз конфиге?


              1. MihaTeam
                04.09.2023 14:32

                Бывают ли в C# лавйлоки? Если да, то вот их на порядок сложнее искать, чем дедлоки и тд.


              1. Ilyaantipanov
                04.09.2023 14:32

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

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


                1. nameless323
                  04.09.2023 14:32
                  +1

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


                  1. Ilyaantipanov
                    04.09.2023 14:32

                    Да, только я на своем игровом движке тоже асинхронное программирование использовал и знаю какие моменты могут возникнуть если lock не поставить перед изменениями данных и там довольно тривиально такие вещи отслеживаются. Когда значение должно быть одно, а валяется там другое значение значит произошла перезапись из другого потока, следовательно смотрим где данная переменная используется и изменяется, и проверяем стоит ли lock чтобы данные корректно записались или нет. Так что даже "фазы луны" можно отследить.

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


                    1. nameless323
                      04.09.2023 14:32

                      Свой движок это очень ограниченная область, про то и речь. Одно дело в своем движке, другое дело вы выпустили ААА игру с тоннами кода который писался десятками лет сотнями программистов, где там десятки трэдов работают с кучей данных. А ведь тогда еще и GPU появляется, когда любой gpu hang это просто отложенный краш через 2-3 кадра и в сис логах у вас "ой, вэйвфронт такой-то сдох". И вот у вас ничего не падает, у тестеров ничего не падает, а задеплоили игру в сторы и у пользователей просто валится в разных местах с одним общим - segmentation fault. Логи это конечно хорошо, но куда в таком случае их ставить? Всюду? Так они неплохо перфу выжирают и тайминги сбивают, не обрадуются пользователи просадке в два раза, потому что вы в лайве решили пологать, а оно может больше и не воспроизвестись. Такие вещи тривиально отслеживаются только в очень тепличных условиях на очень маленьких кодбазах.


                      1. Ilyaantipanov
                        04.09.2023 14:32

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

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


                      1. nameless323
                        04.09.2023 14:32

                        Так не выводи их все

                        Так для этого и нужен программист, что падает рэндомно, но нужно понять что и где логать. Логи в любом случае тормозят систему (и лишние понатыканные кондишны), а обычно движки и так оптимизированы что там свободного места на GPU-CPU нет и люди буквально спускаются до LIKELY/UNLIKELY в условиях чтоб хоть немного выжать, а тут целые логи вставлять чтобы отдебажить на проде. Причем учитывая что в тот же пс или майковские сторы надо еще ревью по неделе проходить, то есть пользователи будут крашится - краши вспыли на проде + ревью билда с логами неделю + пофиксить + сабмит с фиксом. И если логи программист поставил не там и не те, то смело накидываем + 3 недели злых пользователей.

                        это может быть далеко не пару кадров

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

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

                        Что то мне подсказывает что Sony и MS спасибо не скажут если на их платформах рэндомно запускать случайные процессы. А если корапшн вызывает Kernel Panic? Я и такое видел.

                        Скажем так, за 10+ лет программинга ААА игр (на кастомных движках которые в разработке уже лет под 20), я повидал достаточно трэша и что-то отваливается рэндомно и не репрится ни у тестеров ни у девелоперов, к сожалению не редкая ситуация, так что для собеса показать кусочек кода и спросить где тут может быть проблема мне не кажется каким-то странным, такое возникает достаточно часто, это интереснее, чем спрашивать "а что такое дедлок (рейс, whatever)?".


                    1. wataru
                      04.09.2023 14:32
                      +1

                      Когда значение должно быть одно, а валяется там другое значение

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


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


                      1. Ilyaantipanov
                        04.09.2023 14:32

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


                      1. wataru
                        04.09.2023 14:32

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


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


                      1. nameless323
                        04.09.2023 14:32

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

                        Заодно можно и данные карты увести, чтобы два раза не вставить)

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


                      1. Ilyaantipanov
                        04.09.2023 14:32

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


                      1. nameless323
                        04.09.2023 14:32

                        Если у одного из тысячи пользователей чето крашиться и нельзя это решить то что нужно сделать?

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

                        Это что же за логи такие которые тайминги сбивают? 

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


                      1. nameless323
                        04.09.2023 14:32
                        +1

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

                        Логировать с умом надо 

                        нельзя это решить то что нужно сделать

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

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


                      1. Ilyaantipanov
                        04.09.2023 14:32

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


                1. dimaaannn
                  04.09.2023 14:32

                  Тут не 3 ошибки, а целый сборник "как не надо делать"


                  1. Ilyaantipanov
                    04.09.2023 14:32

                    Не мой код, так что не ко мне вопросы) я только его из памяти восстановил как запомнил


                    1. dimaaannn
                      04.09.2023 14:32

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


                1. sphinks82
                  04.09.2023 14:32

                  Навскидку - не надо делать Thread.Sleep внутри async-а, не надо делать i++ без Interlocked внутри многопоточки, и не надо вызывать Count() у IEnumerable в цикле (тут даже не важно, многопоток или однопоток), это что глаз резануло за минуту смотрения на код.


                1. 7bnx
                  04.09.2023 14:32

                  Выделил бы следующие проблемы:

                  1. Строка 27: Модификатор доступа для Main -> public(для Framework, в .NET, на сколько помню, допускаются другие модификаторы)

                  2. Строка 27: Сделать Main асинхронным

                  3. Строка 29: Предполагаем, что db.GetOrders() - репозиторий, возвращающий IQueryable. Т.к. IEnumerable является базовым для IQueryable, то все последующие использования orders(из-за полиморфизма) приведут к обращению к источнику данных(например, БД). Думаю, что стоило привести к чему-то "материальному", типа ToListAsync()

                  4. Строка 34: Потенциальный Race Condition. Значение i будет не детерминировано. Необходимо использовать Interlocked.Increment, либо примитивы синхронизации

                  5. Строка 35: Переменная i будет захвачена и преобразована в отдельный объект, поэтому вывод значения i будет разниться - возможно напечататься только последнее значение либо будут повторы. Стоит завести отдельную переменную для передачи на вывод

                  6. Строка 35: Если предположить, что п.3 верен, то на каждой итерации будет запрос к источнику данных(БД)

                  7. Строка 38: Лучше использовать асинхронный WhenAll()

                  8. Строка 43: Также лучше использовать Task.Delay()


            1. aceofspades88
              04.09.2023 14:32


    1. Samhuawei
      04.09.2023 14:32
      +6

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


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


      1. Ilyaantipanov
        04.09.2023 14:32
        -1

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


        1. Samhuawei
          04.09.2023 14:32
          +1

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


          1. Ilyaantipanov
            04.09.2023 14:32

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


            1. micronull
              04.09.2023 14:32

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

              Потому что это стандартный вопрос, на стандартный код в эпоху многоядерных процессоров.

              в вакансии про асинхронное программирование не было пунктика к требованию кандидату еще один звоночек

              Это стандартное требование. Разработчики должны понимать что это и как работать с этим инструментом. Какие минусы и плюсы применения асинхронного кода. И какие есть риски.


        1. nameless323
          04.09.2023 14:32

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

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


  1. POMXARK
    04.09.2023 14:32

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


  1. Selector83
    04.09.2023 14:32
    +1

    Интересно как статьи про набор возбуждают народ) комменты - огонь.

    А теперь по делу.

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

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

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

    Самое же интересное - эту тему затронули выше - то, что сейчас очень много контор и "групп" помогающих и натаскивающих соискателей на прохождение собесов уровня мидл и выше. И работает это как раз потому, что задачи и требования на собеседованиях - типовые. И уже базой, теорией и тестами не добьешься результата - возьмёшь мидла, а он вообще код не писал, а только зазубрил и научился решать типовые задачки с помощью друзей из "групп". Поэтому ситуация - две стороны одной монеты. И нужно понимать, что задачи соискателя и работодателя как ни странно - противоположные. Одному нужно взять хорошего специалиста, крутого, решающего сложные задачи, организованного и желательно не очень дорого. А у другого - найти работу, желательно без собеса (по результату разговора) с понятными задачами, не очень сложными и чтоб зп была побольше. Конечно же, это все обобщение :) Как и многое в этой статье.

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


    1. alexzaides
      04.09.2023 14:32

      СПРАШИВАТЬ то, что вы считаете базой у специалистов мидл и выше - глупость. У зелёного джуна спрашивать смысл есть - он по определению ничего толком не умеет - так хотя бы теоретические знания проверить. И то - иногда лучше просто поговорить и что то обсудить


    1. Samhuawei
      04.09.2023 14:32

      По поводу базы и алгоритмов - не спрашивать базу у специалистов уровня мидл и выше - глупость.


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

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


    1. Tarnella
      04.09.2023 14:32

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

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


  1. titan_pc
    04.09.2023 14:32
    +4

    Когда ты тимлид, техлид, devops, архитектор и 2 твоих личности не смогли договориться.


  1. diogen4212
    04.09.2023 14:32

    .

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


  1. swordgna
    04.09.2023 14:32
    +2

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

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

    Как всегда, зри в корень. Надо искать причину, а не лечить симптомы. Причина как всегда в людях. Некомпетентные собесы дают негативное представление о своей компании. В хорошей компании хорошо встречают. Так и в моём случае было в местом, где сейчас работаю, хорошая компания!

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


    1. voldemar_d
      04.09.2023 14:32

      Это очень плохая тенденция, так как ограничивает свободу рынка труда

      Может, надо ввести аналог ЕГЭ для приема на работу в IT? Типа, имеешь сколько-то баллов по набору тестов - всё, тебя обязаны взять в любую IT-организацию ;-)


  1. blind_oracle
    04.09.2023 14:32

    Что-то вспомнилось.

    Proton (которые ProtonMail и прочее) уже лет точно 7 всем присылают одно и то же тестовое задание "на логику" перед основным процессом, оно за это время почти не изменилось.

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

    После этого тебе выдают уже домашнее задание на кодинг, более адекватное, ещё мучают тебя штук 5 собеседований и предлагают грустный оффер, где 20% дохода это их акции, которые *нигде не торгуются* т.е. продать ты их не можешь :)

    Поразительные ребята.


    1. Rive
      04.09.2023 14:32

      А они платят по этим акциям дивиденды?


      1. blind_oracle
        04.09.2023 14:32
        +1

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


        1. Areso
          04.09.2023 14:32

          стандартная история со стартапами =)


          1. blind_oracle
            04.09.2023 14:32

            Им 9 лет уже, 400 сотрудников, пора из фазы стартапа выползать...


  1. Ioanna
    04.09.2023 14:32
    +3

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


    1. AleVaKa
      04.09.2023 14:32
      +1

      Там в первой десятке 2 easy, 2 hard и 8 medium. Вы которую из них дали? =)

      И спасибо за идею решать из начала списка. Я сам примерно такой же, только чуть помоложе, и решал задачки через peak one или study plan, а они там случайно надёрганы. Надо будет пойти по порядку.


      1. Ioanna
        04.09.2023 14:32

        Какую-то из медиум. Правильно-то, конечно, по темам решать...


      1. Alexandroppolus
        04.09.2023 14:32

        Вы которую из них дали?

        Судя по всему, номер 3


        1. brotchen
          04.09.2023 14:32

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


          1. Alexandroppolus
            04.09.2023 14:32

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


            1. brotchen
              04.09.2023 14:32

              Задаться левой и правой границей подстроки.

              Двигать правую границу подстроки.

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

              Квадратичная сложность готова.


              1. Alexandroppolus
                04.09.2023 14:32

                В задаче фиксированный алфавит из где-то 70 символов, и строка длины N. Соответственно расстояние между left и right не более 70 - если больше, то заведомо есть повторы. Таких подстрок всего O(N), проверка каждой подстроки O(1). Итого линия. Просто с большой константой.


                1. brotchen
                  04.09.2023 14:32

                  Я не понял, что значит проверка каждой подстроки за О(1) в вашем варианте.

                  У меня есть решение за линейное время, вы просто спрашивали как сделать квадратичное.


                  1. Alexandroppolus
                    04.09.2023 14:32

                    Имелось в виду, что если длина подстроки не более некоторой константы, то проход по ней занимает время O(1)


                    1. brotchen
                      04.09.2023 14:32

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


            1. Kergan88
              04.09.2023 14:32

              Очевидно же что про размер алфавита надо уточнять, иначе задача решена наверно.

              По тоьйлогике по которой вы оцениваете указанное решенин вообще дает ответ за константу. Как и практически любое другое.


              1. Alexandroppolus
                04.09.2023 14:32

                Почему за константу?


                1. wataru
                  04.09.2023 14:32

                  Строки там тоже ограничены сверху. По идее и вашу оценку надо расширять и считать от n и k — длина строки и размер алфавита. И там не линия будет, а что-то вроде O(nk), но как вы выкинули k, так же можно выкинуть и n.


                1. Kergan88
                  04.09.2023 14:32

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

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


            1. wataru
              04.09.2023 14:32

              Ха! Можно хоть четвертую степень придумать запросто: Перебираем все подстроки, через substr их выделям, потом сравниваем каждую пару символов.


              1. BugM
                04.09.2023 14:32

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

                Может попробовать на собеседовании каком....


    1. zergon321
      04.09.2023 14:32
      +4

      Почему кто-то вообще в принципе должен задротить LeetCode?


    1. vtal007
      04.09.2023 14:32
      +6

      вроде дроч на литкод это прерогатива крупных компаний. Когда у них 1000 человек на место и им сложно выбрать. Ставят высокие барьеры


  1. FlyingDutchman
    04.09.2023 14:32
    +3

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

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

    Минусы: на каком-то повороте или этапе круга могут уволить вас.


  1. egaoharu_kensei
    04.09.2023 14:32
    +1

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

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

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


  1. Mat1lda
    04.09.2023 14:32

    Было бы интересно дополнить примеры вакансий ЗП, с сравнением её с средней по больнице.


  1. trabl
    04.09.2023 14:32

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


    1. DyadyaBob Автор
      04.09.2023 14:32

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


  1. ChessMax
    04.09.2023 14:32
    +4

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


  1. Insurgent2018
    04.09.2023 14:32
    +4

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

    1. читаю, что там про себя написал кандидат, выделяю технологии, которые прям сейчас сам хорошо знаю, с чем не сталкивался, сам гуглю, зачем они вообще - потому что иногда встречаются специфические вещи, на всё 20 - 30 мин.

    2. если есть github - обязательно иду и смотрю, ну минут 30, если есть на что смотреть.

    На самой встрече:

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

    2. Потому непосредственно про разработку (python). Ничего особенного, иногда задаю вопросы типа используют ли functools, как организовать работу со множеством корутин, получить результаты от них, при разных условиях, всякое разное в общем, в основном цель - "раскачать" кандидата, оценить широту кругозора по языку скорее. Никаких вопросов про Django, никаких Flask-ов и ORM. Часто встречались джанго программисты, которые язык не знают, но уверенные джанго-разрабы.

    3. Если "чую", что-то не устраивает, иногда, можем дать задание на "дом", без всяких алгоритмических изысков.


  1. BerdBerd
    04.09.2023 14:32
    +2

    Откликался тут на аналитика в Playrix - их hr (Ирина Воронина) открыла в себе экстросенсорные способности и без созвона в принципе мне вот что ответила на отклик:

    Отказ

    Здравствуйте, Александр!

    Большое спасибо за интерес, проявленный к вакансии "Senior Data Analyst" и отдельно за сопроводительное письмо с комментариями. К сожалению, в настоящий момент мы не готовы пригласить вас на дальнейшее интервью по этой вакансии. На текущей позиции помимо хард-скилов - которые у вас как раз очень ярко проиллюстрированы и в резюме, и в письме - очень важен опыт плотной работы с продуктом, сейчас кажется что уклон в вашем опыте больше на инженерные задачи - ближе к Data Engineering/BI Analysis - у нас периодически появляются и эти позиции - возможно они так же будут вам интересны? Мы не хотели бы прощаться совсем, поэтому в случае если наше видение изменится - то будем рады вернуться. Успехов вам в поиске новой работы!

    Т.е. сама признаёт, что хард скилов на вакансию хватает - но говорит, что не хватает софт скилов - вообще без каког-либо общения. При том, что и в резюме у меня помечено, и hr-ам я всем тоже говорю - что с заказчиками и составлением ТЗ я тоже нормально работаю - в плоть до постановок задач напрямую от генерального директора.

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

    Сейчас если смотреть не в РФ, а на международном рынке - конверсия в тех собес резюме Senior уровня 100% подходящее под вакансию - на уровне 3-5%.

    А на рынке РФ - наоборот, сами пишут.

    Если в принципе убрать прослойку в виде hr-ов - лично мне гораздо лучше было бы.


    1. Odin_Himself
      04.09.2023 14:32
      +1

      Треть? Да что вы, ИМХО у 9 из 10 hr плоховато с головой!

      Вы написали - "Если в принципе убрать прослойку в виде hr-ов - лично мне гораздо лучше было бы." Полностью с вами согласен!!!!!!!!!!!!

      Считаю, что объем hr сильно раздут и если не полностью убирать, то в любом случае необходимо сильно сокращать.

      hh.ru вообще бесполезный сайт, ни одной попытки трудоустройства, лет наверное за 10, не привели к удачному результату


      1. 0Bannon
        04.09.2023 14:32

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


      1. fomiash
        04.09.2023 14:32

        А что посоветуете взамен hh.ru?


      1. Tarnella
        04.09.2023 14:32

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


  1. Dev0pser
    04.09.2023 14:32
    +1

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

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


    1. Samhuawei
      04.09.2023 14:32

      когда из 100500 необходимых для должности технологий, ты не знаешь буквально одну

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


      1. k0nst
        04.09.2023 14:32
        +1

        Ну и что это поменяет? Это ни сколько не добавит вам опыта эксплуатации этой технологии. С таким подходом вы ничем не лучше скилбоксера или любого курсанта. Ну вот, к примеру, поднимите вы кафку в докере, кинете пару событий, считаете. Всё? Готовы к эксплуатации распределенной промышленной системы? Заешь - знаешь, не знаешь - не знаешь. Работал - работал, не работал - не работал. Надо говорить как есть

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


        1. Samhuawei
          04.09.2023 14:32

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

          Вот если конкретно скажем flutter то тут да, нужны глубокие знания.


  1. Odin_Himself
    04.09.2023 14:32

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

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

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

    Кстати, 7-ю книгу перевел с помощью нейросети ChatGPT, делюсь опытом в своей статье на Хабре тут:
    https://habr.com/ru/articles/758406/


  1. LeVoN_CCCP
    04.09.2023 14:32

    Первый случай

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


  1. JavaDok
    04.09.2023 14:32

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

    Да, полностью согласен с вами.


  1. Xeldos
    04.09.2023 14:32

    Тестовые задания мы не рассматриваем, так как я стараюсь уважать личное время кандидатов, да и на данный момент тестовое уже моветон

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

    Вас ничего не смущает?


  1. emerald_isle
    04.09.2023 14:32

    Техлид против, так как нет опыта в технологиях.

    Техлид против со словами "Плохо знает базу".
    Для понимания, что это были за вопросы, заданные техлидом. "Ты
    знаешь о многопоточности и синхронизации, тогда опиши углублённо работу
    класса Thread", "Опиши принцип работы DLR и поколения объектов в GC".

    Снова отказ от техлида по причине отсутствия пет-проектов

    Поборов своё волнение, кандидат написал рабочий алгоритм и достаточно
    неплохо. Но техлид снова его забраковал. В этот раз по двум причинам.
    Снова "База хромает", так ещё и впридачу "Алгоритм медленно работает". Очередной отказ.

    На этом моменте я усомнился в адекватности техлида.

    Только "на этом моменте"? А раньше непонятно было?

    Рецепт счастья прост - уволить и гнать в шею этого "техлида". Как он сам вообще эту должность получил?

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

    Подождите, вот этой фразы не понял... Так не изменился ни разу, или всё-таки изменился? Как он может быть вообще не похож, если не изменился?

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

    Это заблуждение. То есть конкретно про Яндекс не скажу, не знаю, как там. Но про "крупные компании, которые любят leetcode" - какие бы хитрые вопросы на алгоритмы не придумывали, на практике мало что из этого применяется, >80% разработчиков в таких компаниях занимаются формошлёпством.


  1. fomiash
    04.09.2023 14:32
    +2

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


    1. Samhuawei
      04.09.2023 14:32

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


  1. 0Bannon
    04.09.2023 14:32
    +1

    Что-то я уже передумал входить в айти после такого. Весёлого там вообще ничего нет, похоже. Ещё всякие с ЧСВ завышенным будут глумиться. Ладно бы 20 лет ещё было.


    1. blind_oracle
      04.09.2023 14:32
      +5

      Правильно, не надо


    1. HellWalk
      04.09.2023 14:32
      +2

      Нечего тут ловить сегодня.

      В 2008 году я вошел в it на 1500$, с пары собеседований, позанимавшись пол года htm/css/версткой/photoshop/продвижением своих любительских сайтов.

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


    1. panzerfaust
      04.09.2023 14:32
      +1

      Весёлого там вообще ничего нет

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


    1. Tanya2492
      04.09.2023 14:32
      +1

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


  1. Megadeth77
    04.09.2023 14:32

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


    1. sergeyns
      04.09.2023 14:32

      +++


    1. MihaTeam
      04.09.2023 14:32
      +2

      Да, но может быть несколько подводных камней из-за которых это перестает выглядеть так просто:
      1. Техлид имеет больший авторитет в компании, чем автор статьи.
      2. Техлид долго в компании, в коде много легаси, проект держится только на нем

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

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


  1. Algrinn
    04.09.2023 14:32

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


  1. mikegordan
    04.09.2023 14:32
    +2

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


    1. Samhuawei
      04.09.2023 14:32

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


  1. Ava256
    04.09.2023 14:32

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


  1. opv88
    04.09.2023 14:32

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


    1. Samhuawei
      04.09.2023 14:32

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

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


  1. OwDafuq
    04.09.2023 14:32

    Меня автоматически браковали из-за отсутствия вышки (которой, к слову, до сих пор и нет). Но меня дико раздражает, что берут часто глупых, но с вышкой. На собеседования даже не зовут, когда видят "нет высшего", сразу отказ даже в разговоре с HR. Они даже не интересуются, что ты умеешь и что знаешь, а я хочу развиваться, писать красивый и лаконичный код, заниматься архитектурой приложений, но закрывают двери из-за вышки, после которой люди даже не поймут и 10% моего кода, который я на данный момент пишу (в данный момент работаю, 1 компания в меня поверила и взяла без "вышки").

    HR, вопросы к вам, как моя ценность, как сотрудника, вырастет, если я получу "вышку"? Меня научат в универе разрабатывать микросервисы, расскажут зачем нужен EntityFramework, DTO модели, AutoMapper и прочие вещи? Очень сомневаюсь.

    Накипело, извините :(


    1. DyadyaBob Автор
      04.09.2023 14:32

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


      1. OwDafuq
        04.09.2023 14:32

        Язык как и в посте - C#. Надеюсь, что позже будут приглашать уже из-за опыта, а не из-за того, что у меня, например, есть вышка, а у другого её нет.


        1. Kanut
          04.09.2023 14:32

          А почему "из-за опыта", а не скажем "из-за умений"? Опыт он сам по себе ничего не гарантирует и в этом плане ничем не отличается от наличия вышки.


          1. Areso
            04.09.2023 14:32

            Почему? Он показывает, что некому Васе платили (в некоторых местах можно даже узнать сколько) на протяжение N-го срока и он что-то делал и им были удовлетворены.
            Тут возникает лишь вопрос, сможет ли он делать задачи нового работодателя, но существующий опыт показывает, что старые задачи он делал как минимум на тройку.
            Грубо говоря, если вы видите человека, который работал маляром в условном домостроительном комбинате номер 7 10 лет, то очевидно, что красить человек умеет. Как хорошо - уже другой вопрос, но вопрос умеет или нет уже не стоит на повестке дня.
            Тут только проблема, что айтишечка сложнее (глубже, шире) покрасочных работ, ну и коллективы с "традициями" тоже разные. В некоторые можно и не вписаться.


            1. Kanut
              04.09.2023 14:32

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

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


              А что там кому-то платили, причём ещё и неизвестно сколько, оно точно так же не особо о чём говорит. Может это "вечный джун" какой-нибудь.


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


          1. OwDafuq
            04.09.2023 14:32

            Потому что сначала смотрят на опыт в резюме, а потом на собеседовании уже смотрят на умения :)


            1. Kanut
              04.09.2023 14:32

              А сейчас смотрят на ВО а резюме, а потом на собеседовании точно так же на умения.

              Оно от этого сильно лучше не становится ведь...


    1. Areso
      04.09.2023 14:32

      Так получите уже эту вышку, что вы. Заочка и через 3,5 года будут корочки.


      1. OwDafuq
        04.09.2023 14:32

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


    1. Samhuawei
      04.09.2023 14:32

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


      Это скорее софт-скилы. Если человек смог закончить ВУЗ он как минимум упорный и умеет решать поставленные задачи. Опять таки стрессоустойчивый (сессия) и способен грамотно излагать свои мысли. Это всё может присутствовать и у вас, но придётся проводить дополнительное тестирование. Опять таки в нынешней ситуации программиста без вышки могут забрать на СВО, а с вышкой попадёт под бронь.


      1. OwDafuq
        04.09.2023 14:32

        Это было и до, и после


  1. mbait
    04.09.2023 14:32

    А в чём проблема добавить зависимость премии (или вообще большей части компенсации) техлида от успеха проекта? Не хочет нанимать предложенных? - Пусть сам до ночи сидит и кодит. Хочет нанимать только гениев? - Ну пусть подкарауливает их возле НИИ, РАН или бауманки, или где там гении обитают.


    1. Samhuawei
      04.09.2023 14:32

      Может в данном случае техлид и старается для успеха проекта. Потому что предыдущие уволенные программисты накосячили и пришлось переделывать, что задержало проект. Лучше день потерять и потом за 5 минут долететь (с)

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


      1. mbait
        04.09.2023 14:32
        +1

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


        1. Samhuawei
          04.09.2023 14:32

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


  1. igosja
    04.09.2023 14:32
    +1

    Несколько раз мне приходилось собеседовать кандидатов, которые приходили к нам устраиваться. Я никогда не понимал смысла вот этих экзаменов по часу-два.
    Я всегда на собеседовании держал в голове, что мне нужно заркыть позицию в штате толковым сотрудником. Собеседование - это не то место, где нужно доказать, что ты умнее кандидата.
    Пару вопросов по "базе", sql, фреймворку, небольшой лайвкодинг, обсуждение реальной проблемы из нашего проекта и как её можно решить.
    Зачем мне спрашивать про алгоритмы, которые мы не используем в работе?
    В целом после 15 минут диалога, я уже понимал подходит нам кандидат или нет.


    1. SeApps
      04.09.2023 14:32

      У меня 20 :)

      Концепцию горячо поддерживаю, за исключением лайвкодинга.


  1. Slyress
    04.09.2023 14:32
    +2

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

    Рассматривала в основном банки. Почти у всех вопросы под копирку. Столкнулась со следующими пунктиками:

    1. БАЗА... Конечно, я не зубрю статьи из вики, мне проще рассказать пример из реализованных задач. Где-то вопросы еще норм, а где-то прям дайте определение. Один банк из 10-ки топ после собеса вернул ответ, что мой уровень джун. Я была удивлена, но посмеялась. Ибо с тем, кому вики важнее практики, мне не по пути.

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

    3. Был банк, который презентовал проект, где они делают процесс один-в-один, как я делала в банке топ-3. Менеджер был счастлив. Там же рассказывают условия, мол надо будет и тестировать немного, и дизайн рисовать, и где-то самому менеджером быть, и график ненормированный, т.к. коллеги в разных часовых поясах. Подумав, что я все равно из дома и в большинстве случаев не проблема, ок. И тут пригласили тех лида. Он зажал два вопроса про технологии, которые они поанируют использовали, но в моем резюме их нет. Логично, что я их не знаю. И всё, отказ. Ребят... серьезно?))) Посмотрите на разный опыт и технологии, вы думаете что я не освою это за неделю-две? При этом вы отказываетесь от человека с идентичным опытом? Удачи))

    4. Было много предложений, которые не отвечают запросу в резюме. Написано черным по белому: удаленка. Ладно гибридные пишуи, но есть и те, кто пишет мол вэлкам в офис... И почему должна вдруг ради них передумать?

    5. Банк с известными 5-этапными .. или больше собесами вообще вначале отказывал на входе. Типа нет и всё, хотя общались мы с ними лет 7 назад на собеседовании... и стекла в аквариуме их я не била, вполне все адекватно прошло. В итоге, зашли туда через консалтинг. Прошла все этапы. Финальный - общение с командой. Неделя тишины. Выяснилось, что под мой стек у них нет сейчас команды. Типа всем нужна БД 90%. А какого вы вообще мое время тратили?

    6. И был случай, который меня крайне возмутил. Это был второй банк, который решил, что я не знаю теорию, то типа я джун. Увидев от hr в ответе в первых строчках, я продолжила спать утром дальше. А потом я прочитала, в чем конкретно джун. Оказалось, что я не умею описывать процессы.... (интересно, за что я 13 лет получала зп?) И не знаю UML (это моя любимая нотация и я в ней как рыба в воде. Рисовать схему не просили на собесе, вопросы какие-то там особо и не задашь из теории). В итоге, я написала в ответ hr, в котором под каждую цитату привела аргумент против, а также спросила, почему они не попросили им в моменте нарисовать схему, написать запрос, хотя бы прислать пример документации. И главное, тот самый sql, которые они используют раз в 2 месяца, они почему-то не указали как слабые навыки, от чего я не отказываюсь. Не указали, потому что сами не сильны. В итоге hr извинилась, мол это были аналитики, которые обычно не собеседуют, просто техлид команды не смог. Договорились на повторное собеседование в др команду. Шла туда ради принципа обелить свою репутацию. Обелила. Оффер.

      По итогу месяца собеседований скажу, что я зазубрила теорию ровно настолько, чтобы проходить этот этап на собеседование. Сейчас это мне снова не требуется в работе, знания потихоньку забываются. Вспомнила все вещи, которые умею... потренировалась на практике. Аналогично, что не используется отложено в долгий ящик. И создала себе черный список работодателей, кого не рекомендую своим друзьями -коллегам. Остается вопрос... я вот сама набирала аналитиков в команду свою, когда была менеджером. Я всегда скептически отношусь к цитатам из вики, стараясь сразу спросить, где на практике использовал. Один товарищ был с крутым резюме, но три менеджера так и не добились примера из практики. Он психанул, поняв, что одной болтавней и вики нас не купишь, и заявил, что вообще не ищет работу) И второй кандидат - скромный, мало опыта, но рассказывать как и что применял увлеченно, с техническими моментами... конечно да! Лучше такого дорастить, ведь там виден сразу потенциал. Это мое видение.... но у всех взгляд разный. Главное найти своих людей, с кем на одной волне.


    1. AxeFizik
      04.09.2023 14:32
      +1

      Банк с известными 5-этапными… или больше собесами вообще вначале отказывал на входе. Типа нет и всё, хотя общались мы с ними лет 7 назад на собеседовании… и стекла в аквариуме их я не била, вполне все адекватно прошло. В итоге, зашли туда через консалтинг. Прошла все этапы. Финальный — общение с командой. Неделя тишины. Выяснилось, что под мой стек у них нет сейчас команды. Типа всем нужна БД 90%. А какого вы вообще мое время тратили?

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


    1. Samhuawei
      04.09.2023 14:32

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

      Зачастую ответы в надзор писали как казаки турецкому султану - всем отделом. Тщательно выверяя каждую фразу. И перед отправкой показывали юристу.


  1. Natalia_Vladimirova
    04.09.2023 14:32
    +1

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

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


  1. werymag
    04.09.2023 14:32

    Отчасти оффтоп, что в целом понимают под "БАЗОЙ", какой список вопросов ожидают услышать интервьюеры по .NET? И что за Пет проекты ожидают?


  1. Sanchous98
    04.09.2023 14:32
    +1

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


  1. IgorRuskin
    04.09.2023 14:32

    Я не знаком с текстами как же работают джуны и стажёры в "программистских конторах", те кто: пришел с универа, с курсов, закончили вуз более 15 лет назад и вспомнил что у него диплом в котором написано "Вычислительные машины, комплексы, системы и сети". Есть что посмотреть? Как вообще входят в работу? На других работах все ясно, тебе платят авансом и ты в течении какого то срока втягиваешься в работу, отрабатывая аванс и рассчитывая на повышение з/п.


  1. WizMe
    04.09.2023 14:32
    +2

    мимо .net джуняра

    С описанным в посте не сталкивался, видимо опыта собеседований не достает пока, но вот пара кейсов.

    Кейс 1.
    Закидывали вопросами по "БАЗЕ" только единожды (в целом по теме, но со своими особенностями). По итогу махнули рукой на мои ошибки при ответах, мол, нормально, опыта наберешься, а у нас все равно на этот проект человек нет. Оффер.

    Кейс 2.
    В одной компании сказали "У тебя офигенный профиль на GitHub, готов прямо сейчас с руками отрывать... только техлид хочет, чтобы все кандидаты тестовое делали". Пообщались еще по теории, пара формальных вопросов - всё всех устроило. Дали тестовое на неделю, я его сделал. Выясняется, что ответ дадут через две недели... Ладно, дождался-таки. Отказ.

    Кейс N.
    В основном, если не отказывают на этапе великого фильтра HR, все просят сделать им сразу тестовое задание, на которое выдаётся 7-10 дней. Без предварительного общения с HR хотя бы. Нужно ли говорить, что после этого следует закономерный отказ... если вообще ответят. И таких немало. Это очень сильно замедляет поиск и получение обратной связи.

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


  1. botyaslonim
    04.09.2023 14:32
    +1

    Подумалось, пора начать продавать услуги собеседования. Я прихожу к вам, получаю расклад: кого ожидаете, какая культура в коллективе, оргструктура. Дальше провожу собеседования не как просто хрюша, а как ваш коллега с техбэкграундом. Короче, IT-сваха


  1. AstroSphynx
    04.09.2023 14:32
    +1

    Далее интереса ради я решил понять, а что сейчас на рынке творится, и что же мы делаем в найме не так

    и что же мы делаем в найме не так

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


  1. jenki
    04.09.2023 14:32

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

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

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

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

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

    вы знаете что такое NDA?

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

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

    Да, всё так. Иногда даже не от каверзных вопросов, но фундаментальных на собеседовании можно сразу словить минусов в карму.

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

    Мы имеем дефицит высококвалифицированных (с той самй БАЗОЙ) и ответственных и опытных, но низкооплачиваемых специалистов.


    1. dimaaannn
      04.09.2023 14:32

      NDA у нас - это скорее хороший тон.

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


      1. MihaTeam
        04.09.2023 14:32

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


  1. k0nst
    04.09.2023 14:32

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

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

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

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


  1. 66demon666
    04.09.2023 14:32

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


    1. Samhuawei
      04.09.2023 14:32

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


  1. GameOwner
    04.09.2023 14:32

    Какое счастье, что уже больше 5 лет не участвую в этих крысиных гонках, работая над своими проектами и имея пассивный доход, бОльший, чем я имел работая на дядю вплоть до CTO(в промежутке еще был и тимлид, и принципал эксперт). Иногда зовут на собеседования по моим старым CV, дежурно пишу отказ. Зарекся работать на кого-то, чего и всем желаю :)


  1. cocaineeboy
    04.09.2023 14:32

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


  1. karmadorje
    04.09.2023 14:32

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

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


  1. aimkaboy
    04.09.2023 14:32

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

    Я за последний ровно год провел порядка 100 собеседований и сделал 6 офферов, вот и считай конверсию. Это были аналитики и разработчики. Аналитика толкового найти очень тяжело, а разработчика, даже который имеет потенциал, но при этом всего год опыта работа за 300-400к я брать ну никак не вижу смысла. Вылью за эту цену он принисет сильно позже.


  1. PeterKhud
    04.09.2023 14:32

    Закончил курсы по профессиональной переподготовке на QA инженера. Около 6-7 месяцев откликался буквально на все вакансии на всех возможных площадках. Опыт имелся на момент поиска работы, но небольшой (мелкая подработка). Могу сказать что будь ты хоть трижды знающим, дважды умным и вообще классный по всем фронтам - работы ты не получишь потому что ты джун, а их никто не любит. Около 30% откликов остались висеть мертвым грузом, вакансии переносились в архив, открывались вновь, публиковались по 10 раз в день, но тишина. Еще 50% это обычные отказы где "не готовы пригласить и бла-бла" и что самое забавное, такие отказы летели по вакансиям где не нужен опыт и набирают просто на стажировку с окладом в 15-20 в месяц (какой-то bread, не правда ли?). Еще 18% это с ноги тестовое задание которое просят выполнить (и тестирование каки-то сайтов-визиток и боевые сайты, что скорее всего бесплатный труд на благо, чего только не было), из этих 18% убираем около 15% выполненных тестовых которые остались без ответа, и еще 3% это отказы потому что "мы хотели не так" (а в сопроводе писали "делайте как вам удобно") штош. И у нас остаются 2% по которым предложили собеседование (я откликнулся более чем на 600 вакансий и реально приглашения приходили по 2 из 100 в среднем). Собесы были разные, где-то гоняли по базе которую я еще хорошо помню с курсов, где-то задавали конкретные вопросы связанные с работой команды в которую я собеседуюсь, где-то спрашивали почему я ухожу с нынешнего места работы, кто-то назначал собес и за 5 минут до его начала говорил, что начальство отменило поиск/нашли кандидата лучше/мы передумали (нужное подчеркнуть). И вот я пришел на собес в своем городе. Буквально 40 минут общения с HR, ПМ и бывшим тестировщиком (на место которого меня и искали) и я вышел с четким понмианием что это место в котором хочется работать. Вопросы по делу, приятная обстановка, по теории как на экзамене не гоняли, но некоторые все же позадавали. Сейчас работаю в этой команде и могу сказать, что лучше одно очное собеседование чем 10 по зуму/скайпу/тг и тд.


  1. My-MyGovoritKorovka
    04.09.2023 14:32

    Спасибо за статью. Я 7 месяцев гонял по собесам плотно. Во-первых я подтверждаю то что Вам попадалось. Во-вторых есть еще один вид собесов.

    Ты проходишь все три этапа, а то и 4 - и прилетает отказ. Просто без комментов.


    1. Kanut
      04.09.2023 14:32

      Ты проходишь все три этапа, а то и 4 — и прилетает отказ. Просто без комментов.

      Просто нашли кого-то более подходящего и "стесняются" об этом открыто сказать.


      1. My-MyGovoritKorovka
        04.09.2023 14:32

        К сожалению, мне остаются только догадки.