company_banner

Спасибо за собеседование, мы ответим о нашем решении… сейчас

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

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




    Серия статей про собеседования:
    1. Я прочитал 80 резюме, у меня есть вопросы.
    2. Наш первый обед вместе: почему и как мы проводим тестовый день.
    3. Собеседование в Додо Пиццу.
    4. Уходя уходи: почему не стоит принимать контроффер.

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

    Раньше я проводил собеседование по стандартной схеме:

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

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

    Почему я решил давать фидбек сразу


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

    Сейчас я провожу собеседование так:

    1. Рассказываю о структуре собеседования. Буквально то, что вы сейчас читаете.
    2. Рассказываю кратко про наш проект, его интересные стороны и будущие вызовы, про команду. Отвечаю на вопросы, которые могут появиться.
    3. Кандидат рассказывает про свой опыт, а я попутно записываю вопросы. Спрашиваю всё в конце, чтобы не перебивать.
    4. Если какую-то тему не обсудили, то спрашиваю точечно. Чтобы ничего не забыть, беру с собой на встречу чеклист из тем и вопросов.
    5. Часто к концу встречи у кандидата снова появляются вопросы. Отвечаю на них.
    6. В конце даю фидбек: принимаю решение на своём этапе технического собеседования и рассказываю о нём.
    7. Раньше я думал, что на шестом этапе собеседование заканчивается, но у меня раз за разом происходила магия: после фидбека (неважно, положительного или отрицательного) кандидаты преображались, рассказывали необычные детали о себе и своём опыте, раскрывались с новой стороны.

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

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

    Инструменты и последствия моментального фидбека


    До фидбека


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

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

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

    Чеклист вопросов и тем, чтобы ничего не забыть. Не пропустить какую-то тему мне помогает чеклист. Обычно процентов 60% из него кандидат рассказывает сам. Задавая дополнительные вопросы, стараюсь отталкиваться от рассказа самого человека, чтобы быть в мире собеседника, он там лучше разбирается. Получается нормальное общение.

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

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

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

    Во время фидбека


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

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

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

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

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

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

    После фидбека


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

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

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

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

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

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

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

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

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

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

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

    Надо уметь объяснять причину отказа. Хорошо, если всё целостно: у нас есть боль, из неё мы составляем портрет кандидата для вакансии, о проблеме я рассказываю в начале интервью и с акцентом на это задаю вопросы. Получается, что в конце собеседования вопрос один: «Подходит ли человек для решения нашей боли и проблемы?». Ответ на него и будет вашим фидбеком, надо только добавить, что удалось, а чего не хватило.

    Обратный вывод: если вас не взяли в компанию Х, то просто вы не подошли ей. Такое бывает и с сильными разработчиками: специалист по 3D-графике может плохо работать с базами данных и UI-тестами, но отлично справляться с задачами в другом месте.

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

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

    Итоги и выводы


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

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

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

    Если в вашей компании открытость и честность — это часть культуры, то почему бы не начать прямо на интервью?
    Свои мысли и идеи о мобильной разработке я пишу в телеграм-канале Dodo Pizza Mobile. О том, как развивается IT в компании, инженеры пишут в телеграм-канале Dodo Pizza Engineering. А ещё у нас открыто две вакансии в мобильном направлении. Так что я просто оставлю это здесь: iOS-developer (Нижний Новгород), Android-developer (Нижний Новгород).

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

    А вы хотели бы получать результаты собеседования сразу?

    • 85,2%Да639
    • 11,2%Не всегда84
    • 3,6%Нет27

    Вопрос для тех, кто проводит собеседования: вы готовы давать фидбек сразу?

    • 35,4%Да138
    • 50,5%Не всегда197
    • 14,1%Нет55
    Dodo Pizza Engineering
    О том как IT доставляет пиццу

    Похожие публикации

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

      +9

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

        +8

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


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

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

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

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

          0

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

            +7

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

              +4

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


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

                0

                Ну тут помог бы ты только прямой вопрос, наверное "а баги в X репортишь?"

                  0
                  Как мне кажется есть ряд подводящих вопросов которые позволят собеседнику раскрыться:
                  • какие задачи приходилось решать с помощью X?
                  • с какими проблемами сталкивались при работе с X?
                  • как бы вы решали проблему Y при работе с X?
                  • сравните X с Z. Какие +- у обоих?
                    0

                    и многие на вопрос о сравнении отвечают "не сравнивал — нам библиотеку X сверху тимлид/архитектор спустил"

                +2
                Потому что ни в коем случае нельзя пользоваться «абстрактными» словами типа «средний, низкий, высокий». И даже «Сеньор, мидл, джун» тоже нельзя.

                Нужно использовать только измеримые показатели. Пусть даже формата «сколько у вас багрепортов».
                  +2
                  что же ты не сказал, что у тебя больше 10 грамотных багрепортов с воркэоандами за последний год, половина из которых уже пофикшена. Это же отличные знания


                  Ну да, «отличные». А потом слушаем историю, как автора фремворка, использумого в Гугле не взяли работать в этот самый Гугл.
              +35
              Оказавшись на месте интервьюера, я заметил, что чаще всего все нужные выводы делаются буквально за 5 минут после встречи.


              Все верно. Но если я вам скажу «у нас есть еще кандидаты, и кандидаты A, B и C понравились мне больше, чем вы, но если все они откажутся от оффера, я вам перезвоню» вы вряд ли нормально это воспримете, ведь так?
              А еще есть вариант «ну вы вроде ничего, не рыба, не мясо, не прям супер но вакансию закрывать надо, так что если ничего лучше за следующие 3 дня не найду — перезвоню». Норм такое услышать будет?
                +5
                ну вы вроде ничего, не рыба, не мясо

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


                кандидаты A, B и C понравились мне больше

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


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


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


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

                  +4
                  Хочется нанимать сильных ребят, он может им стать через год, надо только помочь с направлением

                  А может ведь и не стать. А у вас скажем на этой неделе намечены ещё несколько собеседований. И что вы будете делать?

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

                  Я вот не уверен что пошёл бы работать на фирму после такого ответа. Особенно если есть другие варианты.

                  П.С. И на мой взгляд решение может быть обычно принимается и относительно быстро, но не настолько быстро чтобы сразу дать ответ кандидату. Лично мне надо как минимум пару часов чтобы впечатление «осело» и я мог что-то решить и сформулировать обоснование. А уж если на собеседовании был кто-то ещё «с нашей стороны», то это ещё и с ним/-и посоветоваться спокойно надо.

                    +6

                    Все это может быть, жизнь сложнее моей статьи.

                      +8
                      А может ведь и не стать. А у вас скажем на этой неделе намечены ещё несколько собеседований. И что вы будете делать?

                      Я понравившимся кандидатам так и говорю: «Вы нам понравились, но у нас на этой неделе намечены ещё несколько собеседований, поэтому я не буду принимать решение сейчас. Давайте через неделю созвонимся?» У кандидата тоже же могут быть намечены собеседования в другие компании, и кандидат вправе ответить мне так же.
                        +1

                        Ну так об этом и речь. Понятно что не дело отправлять кандидата домой вообще ничего ему не сказав и потом ещё неделями не давать о себе знать.


                        Но на мой взгляд именно принять окончательное решение "берём/не берём" сразу после собеседования это очень редко когда сработает. Если вообще.

                          0

                          За последние 4 "раунда" поиска работы с 2-4 офферами в каждом, два оффера было, как говорится, "не успел в метро зайти". На месте ни разу.

                        0

                        А я бы пошёл. Если контора нравится. Я ведь тоже могу выбирать. "Если меня не возьмут вот сюда, я соглашусь работать у вас. Просто у них ХХХ есть, а у вас только ННН".

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

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

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

                              А как там фирмы кандидатов оценивают и приоризируют это для меня в данном контексте не особо то и важно.
                                0

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

                                  0
                                  Окей, «мы вам перезвоним [когда не найдём вариантов получше]» — так лучше?

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

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

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

                                    Ну а я вот наоборот, при прочих равных скорее пойду в такую фирму, которая считает, что моей квалификации недостаточно им:


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

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

                                      0

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

                                        0

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

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

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

                                            Мне говорили, когда предлагали зарплату процентов на 50 больше рынка.


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


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

                        +1
                        КМК узнать что ты «запасной аэродром» всегда более обидно, чем просто получить отказ, не?
                          +6

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


                          Когда я устраивался на работу я точно также рассказывал о своих вариантах и мы открыто обсуждали это с СТО.

                            +1
                            если убрать отношения


                            Довольно странно «убирать отношения», нематериальная мотивация зачастую более сильна, нежели материальная. И опять же, как мне кажется, отношение к тебе на работе как к ценному кадру играет огромную роль. Чувство сопричастности опять же отсюда же и произрастает.
                            Не стоит отказываться от всех этих замечательных методик, которыми веками пользуются руководители и лидеры всех мастей. «Общее же дело делаем, товарищи!» Ну вы понимаете.
                              +4

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


                              Как красиво отказывать и потом возвращать обратно — отдельная тема.

                            +8

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


                            но все "краснеют как красны девицы", когда говорят об этом в открытую...

                              +8

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


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

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

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


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

                                  +1
                                  что я ни на что не гожусь, но так уж и быть, они соизволят взять даже такого убогого

                                  Уф, жестко. Так нельзя.

                                  +5
                                  КМК узнать что ты «запасной аэродром» всегда более обидно, чем просто получить отказ, не?

                                  Сильно зависит как это будет сказано, например, «по результатам технического интервью мы видим, что ваши опыт и технические навыки подходят нашей команде, однако у нас запланировано еще несколько интервью с другими соискателями и мы сможет дать окончательный ответ вам после них через 2 недели».
                                  На мой взгляд, ничего обидного тут нет. И часто что-то подобное я слышал.
                                    +1
                                    Вот только, часто, даже через 2 недели ответа нет).
                                    +1
                                    Не! Я, как кандидат всегда подхожу с такой позиции к конторам. И мне не будет обидно, если такая позиция будет зеркальна. Ну это субьективно.
                                    А вот по звезде — вполне прагматично. Нужен некоторый опыт, чтобы понять, что, как идти на должность «звезды» в конторе, так и идти на должность «на безрыбье», говорит только о том, что понял интервьюер. Как правило он понял не всё(если сказать мягко). И орентироваться на это очень глупо. Бывали случаи, когда голова кружилась от задачь, которые поручали, потому, что взяли как звезду. Бывали, когда отказывался до оформления, потому, что всё было очень тривиально с задачами и нетривиально с граблями.
                                    Обчыно, специалисты составят некоторое мнение друг о друге, верное, хотя-бы процентов на 80. А вот при собеседовании со специалистом из другой сферы результат, очень часто, бывает неверным полностью.
                                      +3
                                      У соискателя точно такая же история ведь – он не в одну фирму собеседуется, и если ты ему говоришь «да, ты нам подходишь, вот оффер», он ответит «ну знаете, у меня тут еще 3 собеса, я еще подумаю». Это нормально. Компания хочет себе лучшего работника, работник хочет себе лучшие условия
                                        0

                                        Даже не "ещё подумаю", а "посмотрю что они предложат"

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

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

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

                                    В итоге просто получилось, что из компании номер 2 мне перезвонили просто на пару часов раньше чем из компании 1.

                                    Но в любом случае это было лучше, чем те десятки раз когда перезвонить обещали, но не перезванивали.
                                      +1
                                      Как-то на собеседовании HR заливала меня тупыми вопросами из книжки «HR для чайников», а потом когда я начал спрашивать про белую зарплату и прочий ДМС начала блеять что-то невнятное.
                                      Так я ушел с собеседования с фразой «ну, я вам перезвоню».
                                      +7
                                      Услышать такое, конечно неприятно, но это лишь первая реакция.
                                      В целом быстрый и честный фидбек с причинами отказа куда приятнее чем отказ по непонятным причинам через неделю.
                                        +1
                                        Если бы мне такое говорили сразу, я бы очень был бы рад. Потому что это честно, а честность — лучшее начало отношений. Всегда есть кто-то лучше и замечательно понимать, это из уст других, а не самому домысливать.
                                          +1

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


                                          Если это так, то что в этом такого, что говорят правду? Неопределенность и полное отсутствие фидбека это очень плохо!


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

                                          +9
                                          Был на собеседовании в Додо зимой 2019 (где-то в феврале). Сразу мне фидбек мне никто не дал, а через где-то неделю отказали. Просто вспомнилось :)
                                            +4

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

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

                                                Это недавно было?

                                                  0
                                                  Ну я уже точно не вспомню, где-то в то же время что и у Seals наверное.
                                              +5
                                              Главная причина не отвечать сразу понятна — эмоционально сложно обсуждать решение с кандидатом, ведь часто нужно отказывать.

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

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


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

                                                  +4
                                                  А может и другая ситуация получится — вы дали человеку положительный фидбек, что вам все понравилось. И человек ушел довольный, думая что у него наверняка место в кармане.

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

                                                  За это время вы пособеседовали еще других кандидатов, и кто-то оказался сильнее и взяли его. Далее вы сообщаете первому кандидату отказ.

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

                                                    +4

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

                                                      +4

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

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

                                                          Именно это тезис я и комментировал.
                                                          расстройство будет только следствием его домысливания (или фантазии)

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

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

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


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

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


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

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

                                                          0
                                                          противоречие в том, если у человека есть только 1-2 сильные стороны — то он мне не подходит, ему не найдется место в маленькой команде
                                                            0

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

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

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

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

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

                                                          Да, согласен с вами. Те системы, которые я видел, ещё до собеседования присылают тебе «извините, но мы нашли другого кандидата. Удачи вам во всём». И всё.


                                                          Сидишь и думаешь: «ну на этот раз что не так?!»

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

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


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


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

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

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


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

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


                                                                Это как раз просто. Развиваться в познании дзен, что твой номер в мире имеет 10 знаков и идти в другие места. Или развиваться в направлении soft skills, скорефаниться с кем-то из этой конторы, если это контора-мечта, и прийти к ним по такому блату, а не как лох, с улицы.
                                                                +1

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


                                                                И ещё маленький вопрос. Что делать если кандидат не принимает фидбэк и не признает за собой всего, что вы сказали (возьмём пример негативного фидбека)? Как поступить, вступить в дискуссию или просто закончить на этом?

                                                                  +2
                                                                  есть ли планы масштабирования этой инициативы

                                                                  Я подбиваю всех до кого дотягиваюсь


                                                                  Что делать если кандидат не принимает фидбэк?

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

                                                                  +7
                                                                  Подход к собесам в додо провальный уже потому, что вы akaDuality там работаете.

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

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

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

                                                                  Какие скиллы я стараюсь оценить на собеседовании?

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

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

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

                                                                  Скорость работы — ну тут все понятно. Если человек в среднем таски выполняет медленно, он просто не тянет работу.

                                                                  Что я не НЕ спрашиваю на собесе?

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

                                                                  Так же я не спрашиваю умение работы с т.н. «технологиями». Rx, DI, паттерны, фреймворки, архитерктуры, языки программирования (в разумных пределах) и т.п. Причина проста — это бесполезно. Если человек толковый, то он на ходу разберется с фреймворками и паттернами которые есть в проекте. Если совсем толковый то еще и понимает какие «технологии» уместны в проекте, а какие нет. А если бестолковый, но зато знает фреймворки — то он нахер не нужен.
                                                                    0
                                                                    В 80% случаев понятно кто придет на собеседование по резюме.

                                                                    Это я уже проходил.


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

                                                                    Я вижу это иначе: статья про DI в runtime и compile time, часто популярные опенсурс решения могут приносить проблемы, а похожую статью я не встречал. И я не создал проблему, я ее решил и рассказал об этом.


                                                                    Идеальный вариант собеса это тестовое + собес по результатам тестового

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


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

                                                                    Ну да, никто не спорит


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

                                                                      +1
                                                                      Я вижу это иначе: статья про DI в runtime и compile time, часто популярные опенсурс решения могут приносить проблемы
                                                                      Проблемы приносят не опенсурс решения, а отсутствие базовых навыков проектирования.
                                                                      Проблема не в том что вы взяли херовую реализацию DI, а потом заменили на «нормальную». А то что вы вообще используете DI в маленьком ios проекте на десяток экранов, что и порождает кучу проблем.

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

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

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

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

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

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

                                                                      Да, для зумерков ваша статья выглядит как «Они заменили модный фрейморк А на модный фреймворк B, круто, coding matters!». Но для любого разраба уровнем выше мидла, она показатель состояния дел в команде.

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

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

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

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

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

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

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

                                                                          0
                                                                          Какой дешевый слив
                                                                            0

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


                                                                            Энивей, вместе нам не работать и это хорошо для обеих сторон.

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

                                                                                Может я сильно не понимаю, но что вот это:


                                                                                • Подход к собесам в додо провальный уже потому, что вы akaDuality там работаете.
                                                                                • на должности руководителей команды разработки попадают люди, которые не умеют проектировать
                                                                                • не понимает как позорится
                                                                                • посмотрите какую хрень сделали дебилы в легаси, и какими костылями мне пришлось это решать
                                                                                • факта внедрения DI — уже маркер некомпетентности (честно, как это связано? Что вы вкладываете в DI?)
                                                                                • обозначает ваш уровень как специалиста
                                                                                • дать вам проект с нуля написать — точно нет (одних только пет проектов у меня 4 штуки)
                                                                                • Вы просто не умеете их читать (про резюме)

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

                                                                                  0
                                                                                  Вы просто вырезали аргументы из моих слов. Давайте разберем по пунктам

                                                                                  внедрения DI — уже маркер некомпетентности (честно, как это связано?)

                                                                                  Хорошо, раз вы не понимаете, давайте проясним. Простой вопрос — вот есть такой подход — Dependency Injection, есть фреймворки для него. Объясните какую проблему\задачу этот подход решает? Какие есть альтернативы ему? Какие у него минусы, и какие плюсы? Почему в конкретно вашем приложении по вашему мнению стоит использовать именно его?

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

                                                                                  Эта фраза наиболее точно и емко описывает ситуацию, описываемую вами в вашей статье про DI. Вы с этим не согласны?

                                                                                  внедрения DI — уже маркер некомпетентности (честно, как это связано?

                                                                                  Я еще в первом комментарии написал. В небольшом rest-клиенте под ios на десяток экранов этих проблем которые решает DI не существует. Если вы используете такой подход в этом проекте, значит вы не понимаете что делаете. Если вы не понимаете что делаете, значит в вопросах проектирования вы некомпетентны.

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

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

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

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

                                                                                  не понимает как позорится

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

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

                                                                                  дать вам проект с нуля написать — точно нет (одних только пет проектов у меня 4 штуки)

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

                                                                                  Вы просто не умеете их читать (про резюме)

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

                                                                                    Теперь точно нет сомнений, что вам хватает резюме, ведь вы из чего угодно вытащите то, чего там нет.

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

                                                                                        Даже если представить специалиста, который работал 20 лет на одной работе, он наверное додумается написать в резюме побольше информации чем, «2000-2020, software engeener in Vector ltd». А если не додумается, то он вероятно и по своей специальности так же херово думает
                                                                                          +1
                                                                                          Такое себе. Делать работу и рассказывать о ней — это сильно разные навыки. Просто «головой» без опыта не придумаешь, что там важнее рассказать среднему читателю резюме, насколько детально и с каких сторон.
                                                                                            0
                                                                                            Под написано мало — я имею ввиду, когда реально ничего не написано.

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

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

                                                                                                Вот с гуглить сложно — разные ресурсы/авторы часто дают противоположные рекомендации по написанию резюме. начиная от объёма: одни советуют чуть ли не на одну страницу уложить 25 лет опыта, навыки, мотивацию и т. д., а другие "пишите как можно более подробно о своих обязанностях и достижениях". Фотографию надо или нет, указывать ли размер ЗП, в каком порядке писать что — сколько людей столько мнений.


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

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

                                                                                                  0
                                                                                                  Не понимаю как вы вообще интерпретируете мои слова.

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

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

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

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


                                                                                                    Ваша подпись в профиле хабре говорит о вас больше чем все резюме.

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


                                                                                                    Хабр — это же клуб по интересам, а не карьерный ресурс. Для этого "Мой круг" есть, Линкедин и т. п.

                                                                                                  0
                                                                                                  Я в своё время пару раз устраивался на работу через HR-агенства. Они брали мою виту и расписывали её так что всё вроде правильно, но я сам себя не узнавал. В том числе мне там и «папку проектов» нарисовали очень красивую. Ну то есть что делал, где делал, как делал.

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

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

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

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

                                                                                                    С чего это? Вы тут вообще неправильно мои слова интерпретируете.

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

                                                                                                    Если вам рекрутер завысил опыт, это на собесе вылезет. Если вы написали сильно меньше чем на деле делали, это на собесе тоже вылезет.
                                                                                                      +2
                                                                                                      Потому что они любят дописать разной мусорной воды типа «кандидат очень целеустремленный».

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

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

                                                                                                      То есть точно так же есть шанс что и человек сам сделает виту похожую на виту «от рекрутеров»…

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

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

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

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

                                                                                                        В другом случае вас реюме устроило и вы человека на собес пригласили.
                                                                                                        Теперь всех без разбору звать? Я не понимаю с чем вы спорите.

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

                                                                                                          Для банального резюме? Совсем не обязательно. Может вполне себе хватить некоего понимания материи и опыта написания резюме для программистов.

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

                                                                                                          Теперь всех без разбору звать? Я не понимаю с чем вы спорите.

                                                                                                          Всё ещё о том что «Делать работу и рассказывать о ней — это сильно разные навыки.» А вы оцениваете именно «умение рассказывать».

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

                                                                                                          Ну так это ведь вы, а не я, написали вот это:
                                                                                                          Даже если представить специалиста, который работал 20 лет на одной работе, он наверное додумается написать в резюме побольше информации чем, «2000-2020, software engeener in Vector ltd». А если не додумается, то он вероятно и по своей специальности так же херово думает


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

                                                                                                            0
                                                                                                            Для банального резюме? Совсем не обязательно
                                                                                                            Обязательно. Правильно употребить слово, если не знаешь его значения можно только случайно. В итоге по ошибкам либо видно, что писал рекрутер — а значит инфу надо делить на 2. Либо если писал сам кандидат, то видно что он тему не знает но хочет показать что знает.

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

                                                                                                            Всё ещё о том что «Делать работу и рассказывать о ней — это сильно разные навыки.» А вы оцениваете именно «умение рассказывать».
                                                                                                            Просто facepalm. Спор в этом вопросе исчерпан в этом коменте habr.com/ru/company/dodopizzadev/blog/506378/#comment_21764700. Не удивительно что у вас проблемы с чтением резюме, если не можете коменты прочитать.
                                                                                                              0
                                                                                                              Обязательно. Правильно употребить слово, если не знаешь его значения можно только случайно.

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

                                                                                                              Просто facepalm. Спор в этом вопросе исчерпан в этом коменте habr.com/ru/company/dodopizzadev/blog/506378/#comment_21764700. Не удивительно что у вас проблемы с чтением резюме, если не можете коменты прочитать.

                                                                                                              Ну так в том споре с тем человеком для вас вопрос исчерпан. Я с вами общаюсь уже в другой ветке дискуссии и честно говоря не вижу почему я должен мониторить кто там что и где ещё написал.
                                                                                                                0
                                                                                                                Или на чём строится ваше мнение о том как они работают?
                                                                                                                Работал с ними с обеих сторон. Ваши нормальные рекрутеры скорее исключение чем правило.

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

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

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

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

                                                                                                                  И в чём проблема? Ну не понравилось вам как рекрутер что-то описал, ну так попросите его переделать так как вам нравится. С другой стороны если вы сами красиво писать и формулировать не умеете, то…

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

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

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

                                                                                                                    Вам концепт «ветки» в дискуссиях на хабре хоть немного понятен? Кнопочкой «Показать ветку комментариев» вы хоть раз пользовались?
                                                                                                                    Вы спор до конца не прочитали, влезли в середину, это ваша ошибка, а не моя.
                                                                                0
                                                                                Если не трудно, посоветуйте какие книги читать после паттерной и прочего DI?
                                                                                Что-нибудь по разработке архитектуры приложений.
                                                                                Спасибо.
                                                                                  –1
                                                                                  Про книги не подскажу к сожалению, не знаю таких. Может кто-то другой ответит, буду рад.

                                                                                  Могу посоветовать писать побольше пет-проектов и придумывать там архитектуру с нуля. Лучше всего взять какуюто тему, где еще нет массовых готовых архитетур, игры например.
                                                                                    0
                                                                                    В пет-проектах я стараюсь придерживаться следующих принципов:
                                                                                    1. легкая расширяемость (стараться делать все на интерфейсах) — потому что я могу забросить пет проект на полгода-год и вернуться к нему. Недавно, переделал в 2 строки переход с монги на эластик.
                                                                                    2. легкая поддержка — пет проекты забрасываются быстро — работа, увлечения, дела. И снова «войти» в этот же проект надо быстро — дома есть час-два на личные дела.
                                                                                    3. Использовать по-максимуму сторонние библиотеки — по этой же причине.
                                                                                    +1
                                                                                    Чисто для себя определил следующий список на «что почитать по архитектуре после паттернов»:
                                                                                    • Мартин Фаулер «Шаблоны корпоративных приложений»
                                                                                    • Кент Бек «Implementation Patterns»
                                                                                    • Крис Эванс «Domain Driven Design»
                                                                                    • Вон Вернон «Реализация методов предметно-ориентированного проектирования» (implementing domain driven design)
                                                                                    • Роберт Мартин Clean architecture ( не путать с «Чистый код» и «Совершенный код! =)
                                                                                    • Цикл постов Джеффри Палермо (Jeffrey Palermo), посвященных луковой архитектуре (Onion architecture)
                                                                                    • Алистар Кокбёрн (Alistair Cockburn) про Гексагональную архитектуру (Hexagonal architecture)
                                                                                      0
                                                                                      Не советуйте вредных вещей.

                                                                                      Роберт Мартин Clean architecture

                                                                                      Это делит на ноль весь ваш комментарий. Чистая архитектура — разновидность бизнес-религии, придуманная чтобы продавать консалтинговые услуги менеджменту крупных компаний, в т.ч. тренинги и прочее. Это аналог scrum/agile/safe, но для программирования. Посмотрите основное место работы Роберта Мартина, если вам не понятно. К проектированию никакого отношения не имеет, скорее наоборот поощряет вас делать ошибки, для решения которых потом будут платить за консалтинг.
                                                                                        0

                                                                                        Приведите конкретный небольшой пример — какие именно ошибки поощряет Clean Architecture?

                                                                                          +1
                                                                                          Неоправданное усложнение архитектуры/кода/системы.

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

                                                                                          Конкретный пример — есть локальное хранилище в мобильном приложении, по clean architecture получается что надо сделать интерфейc Storage, и сделать конкретную реализацию например SqlLiteStorage. Все логично, ведь тогда можно будет легко поменять реализацию хранилища. А теперь внутри хранилища мне надо получить данные, например из настроек приложения. Все просто, делаем интерфейс Settings и IosSharedPrefsSettings реализацию, и передаем ее в SqlLiteStorage как зависимость. Зависимостей в проекте таким образом получается очень много, поэтому делаем еще менеджер зависимостей для всего этого.

                                                                                          В итоге получили 5 сущностей с кучей связей друг между другом.

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

                                                                                          В итоге получаем 2 сущности, вместо 5.

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

                                                                                          Что будет если реализацию хранилища всетаки придется сменить? Ну потратить немного времени чтобы переписать внутрянку класса Storage всяко будет дешевле чем тратить время на поддержку и тестрирование и фикс возросшего количества багов зоопарка из clean architecture каждый день.

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

                                                                                          Вот только таких мест у вас в приложении будет одно-два. А clean architecture предлагает делать такое на каждый чих. Т.е для большинства случаев clean architecture решает проблему, которая в вашем проекте НЕ СУЩЕСТВУЕТ, принося десятки новых проблем усложняя код. Вывод из этого только один: люди, которые всегда и везде применяют сlean architecture, не только тотально некомпетентны как проектировщики, но еще и не адекватны.

                                                                                          Разве адекватный человек будет создавать себе новые проблемы, чтобы решить проблему которой нет?
                                                                                            +1
                                                                                            реализации настроек и подмены этих вещей в рантайме — так вообще нулевая

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


                                                                                            Поэтому сделает хранилище синглтоном

                                                                                            Нет никакой проблемы сделать хранилище синглетоном, и при этом весь по-прежнему иметь интерфейс Storage отдельно от SqlLiteStorage.


                                                                                            а настройки вообще статиками.

                                                                                            Если настройки не меняются — это константы, а не настройки.


                                                                                            Что будет если реализацию хранилища всетаки придется сменить? Ну потратить немного времени чтобы переписать внутрянку класса Storage

                                                                                            При этом нормальный разработчик выкинет реализацию SqlLiteStorage — а это сделает приложение неработоспособным на системах, где живёт SQLite. Особенно это видно на другом вашем примере — если Settings нет, а есть только IOSPrefsSettings — у вас нет и не может быть версии под Windows. А когда вы сделаете версию под Windows — у вас пропадёт версия под IOS, ведь прежнюю реализацию вы только что выкинули. А ещё у вас нет и никогда не будет версии Settings, которую можно настроить в ходе тестов, потому что чтобы такая версия появилась, вам придётся выкинуть версии для Windows и IOS. Но, видимо, компетентные проектировщики всегда пишут без багов, и ничего не нужно тестировать.

                                                                                              0
                                                                                              Ну да, главная помеха переноса ios приложения под windows это же реализация настроек.

                                                                                              Я видимо в точку попал, говоря про (не)адекватность. Вы несете полную чушь. Приложение написанное на swift\objc никогда не будет перенесено под windows, только если написать отдельное приложение с нуля.

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

                                                                                              Если настройки не меняются — это константы, а не настройки.
                                                                                              А если человек не видит различия между static и const, то кто он?

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

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

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

                                                                                              Ну и вишенка на торте. Вот есть у вас сущность A которую вы тестируете, и есть замоканый инерфейс B с которым она взаимодействует. Так как основной источник ошибок в мобильных приложениях это системный код UI, а в тесте мы вместо него используем мок, который ведет себя далеко не так как реальный UI, то получается что мы тестируем НИЧЕГО. Т.е. мы вместо реальной работы мы тестируем абстрактную. Из 10 ошибок мы поймаем 2, зато скажем что тесты зелененькие.

                                                                                              Вот вы выучили что надо делать абстракции, выучили что нужно писать тесты, а КАК и главное ЗАЧЕМ они делаются вы не понимаете.
                                                                                                0
                                                                                                Ну да, главная помеха переноса ios приложения под windows это же реализация настроек.

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


                                                                                                Приложение написанное на swift\objc никогда не будет перенесено под windows, только если написать отдельное приложение с нуля.

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


                                                                                                А если человек не видит различия между static и const, то кто он?

                                                                                                Никакое глобально видимое состояние не должно быть открыто к изменениям, следовательно всё что static должно быть и const — мы же не хотим усложнять архитектуру, вводя кучу мьютексов и семафоров? Расследование гонки — это вам не две сущности вместо одной.


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

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


                                                                                                только для того чтобы тестировать бизнес-логику

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


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

                                                                                                Сильное утверждение. Докажите.


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

                                                                                                Ещё одно сильное утверждение. С вас ещё одно доказательство.


                                                                                                а КАК и главное ЗАЧЕМ они делаются вы не понимаете.

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

                                                                                                  –1
                                                                                                  Передёргиваете

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

                                                                                                  Вы же натурально говорите, что проще и дешевле выкинуть ваш код и написать заново
                                                                                                  Да, зачастую небольшой кусок кода дешевле выкинуть и написать заново, чем строить систему таким образом, чтобы любой кусок можно было заменить за 2 строчки кода. Вы же тратите по 100 рублей каждый день, чтобы раз в два года потратить 5 рублей вместо 1000.

                                                                                                  вообще невозможно написать транслятор со swift на другие платформы
                                                                                                  Более того, его можно даже не писать — код на свифте комплиляется на разные платформы, на винду вроде тоже при желании можно. Вот только приложение это не только язык программирования, это еще и api системы и для мобилок первую очередь UI api. И большая часть приложения — взаимодейтсвие с этими api. В итоге вам даже с clean architecture придется переписать всю реализации, за исключением кода который предназначен для связки этих реализаций. Т.е. вы полностью перепишете приложение с ios под windows, только на уебанском стеке.

                                                                                                  Я-то кросс-платформенные приложения разрабатываю
                                                                                                  Судя по стилистике и бредовости утверждений разрабатываете на React Native. И да, это оскорбление.

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

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

                                                                                                  Ах, ну и да. Чтобы избежать усложнения архитектуры, вкрутив синхронизацию доступа, вы предлагаете усложнить вообще все остальное избегая использования static. Где тут логика?

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

                                                                                                  >Сильное утверждение. Докажите.
                                                                                                  Ну вообщето кейс приводится в следующем же абзаце. Вы тестируете сущность А, которая работает с моком B. Вы так не поймаете ошибки, специфичные для связки сущности A и реального UI. Но тесты будут проходиться.

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

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

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

                                                                                                  Вообще просто попробуйте троллить менее бездарно
                                                                                                    0
                                                                                                    Приведите конкретные кейсы в которых static без const приведет к ошибкам.

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


                                                                                                    если я вообще не обращаюсь к глобальным состояниям из фоновых потоков.

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


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

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


                                                                                                    вся логика на беке

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


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

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

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

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

                                                                                                0
                                                                                                Обосновать свое утверждение сможете? Своими словами, на конкретном примере, а не цитатками из псевдоумных книжек.

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

                                                                                                Использовать зависимости вместо синглтонов следует когда ограничения накладываемые синглтонами в проекте неприемлемы
                                                                                                  +1

                                                                                                  С конструктором:


                                                                                                  Скрытый текст
                                                                                                  class Settings
                                                                                                  {
                                                                                                      int param1;
                                                                                                      int param2;
                                                                                                      string param3;
                                                                                                  }
                                                                                                  
                                                                                                  class SqlLiteStorage
                                                                                                  {
                                                                                                      Settings settings;
                                                                                                  
                                                                                                      construct(Settings settings)
                                                                                                      {
                                                                                                          this->settings = settings;
                                                                                                      }
                                                                                                  
                                                                                                      doSomething()
                                                                                                      {
                                                                                                          if (this->settings->param1 == Mode1) {
                                                                                                              ...
                                                                                                          }
                                                                                                          else if (this->settings->param1 == Mode2) {
                                                                                                              ...
                                                                                                          }
                                                                                                          else if (this->settings->param1 == Mode3) {
                                                                                                              ...
                                                                                                          }
                                                                                                          ...
                                                                                                      }
                                                                                                  }
                                                                                                  
                                                                                                  class Controller
                                                                                                  {
                                                                                                      Settings settings;
                                                                                                      SqlLiteStorage storage;
                                                                                                  
                                                                                                      construct()
                                                                                                      {
                                                                                                          this->settings = this->loadSettings('settings.ini');
                                                                                                          this->storage = new SqlLiteStorage(this->settings);
                                                                                                      }
                                                                                                  }

                                                                                                  Что будет если реализацию хранилища всетаки придется сменить?
                                                                                                  Что будет если понадобится второй конфиг для стороннего компонента?
                                                                                                  Что будет если часть конфига будет доставаться с сервера через API?


                                                                                                  Поменяется только название класса в конструкторе, в объявлении свойства и при создании объекта. Код doSomething() останется без изменений, как и все другие обращения к this->settings и this->storage. А да, и тесты нормально писать можно.


                                                                                                  Без конструктора:


                                                                                                  Скрытый текст
                                                                                                  class Settings
                                                                                                  {
                                                                                                      static int param1;
                                                                                                      static int param2;
                                                                                                      static string param3;
                                                                                                  }
                                                                                                  
                                                                                                  class SqlLiteStorage
                                                                                                  {
                                                                                                      doSomething()
                                                                                                      {
                                                                                                          if (Settings::param1 == Mode1) {
                                                                                                              ...
                                                                                                          }
                                                                                                          else if (Settings::param1 == Mode2) {
                                                                                                              ...
                                                                                                          }
                                                                                                          else if (Settings::param1 == Mode3) {
                                                                                                              ...
                                                                                                          }
                                                                                                          ...
                                                                                                      }
                                                                                                  }
                                                                                                  
                                                                                                  class Controller
                                                                                                  {
                                                                                                      SqlLiteStorage storage;
                                                                                                  
                                                                                                      construct()
                                                                                                      {
                                                                                                          this->loadSettings('settings.ini');
                                                                                                          this->storage = new SqlLiteStorage();
                                                                                                      }
                                                                                                  }

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


                                                                                                  Что будет если реализацию хранилища всетаки придется сменить?
                                                                                                  Что будет если понадобится второй конфиг для стороннего компонента?
                                                                                                  Что будет если часть конфига будет доставаться с сервера через API?


                                                                                                  Будут классы Settings1 и Settings2, код doSomething() надо будет поменять, как и все другие обращения к Settings, то есть "переписать внутрянку класса SqlLiteStorage и внутрянку loadSettings()". Даже банально Settings в Config переименовать потребует изменений во многих местах. Сэкономили пару присваиваний и получили сложность при чтении и измении кода. Где же тут проще?


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

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

                                                                                                    0
                                                                                                    Что будет если реализацию хранилища всетаки придется сменить?
                                                                                                    Что будет если понадобится второй конфиг для стороннего компонента?
                                                                                                    Что будет если часть конфига будет доставаться с сервера через API?
                                                                                                    Что будет если вам на голову кирпич упадет? Не думаю что вы носите каску на улице каждый день.

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

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

                                                                                                    А что будет если изменение реализации хранилища сломает его интерфейс?

                                                                                                    Если вам сложно без менеджера распределить 2 зависимости, значит у вас проблемы с архитектурой. А если кода настолько много, что их надо постоянно куда-то таскать, значит там и так больше 2 сущностей.
                                                                                                    Так это синтетический пример, почти в любом проекте сущностей у вас будет намного больше. Даже если вы в своем примере создадите еще контроллер, то ему надо будет передавать storage\settings что сразу все усложняет. Ну и плюс это вы тут взяли и создали объекты storage и settings. В реальности это надо будет делать гдето в root контроллере и потом раздавать остальным контроллерам по цепочке. Опа, и уже менеджер зависимостей понадобится.

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

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

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

                                                                                                    А если всетаки произойдут? Ходите по улице в каске каждый день, и зонт не забудьте еще.
                                                                                                      +1
                                                                                                      Для начала надо оценить вероятность того или иного события, если она ничтожна — то готовиться к наступлению такого событию неадекватно.

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


                                                                                                      Если бы вызов был внутри самой сущности Settings, все бы было логично.

                                                                                                      Вот-вот, а потом появляются классы FileSetting и APISettings, про что я и написал, либо один класс Settings c кучей функций loadFromSomething() с неявными зависимостями — и от файлов, и от http, и от чего угодно (GodObject). Ну либо да, при небольшом изменении большой рефакторинг. Хотя обычно рефакторинг делать неохота, и добавляется еще больше такого кода. И все потому что лень конструктор написать.


                                                                                                      А что будет если изменение реализации хранилища сломает его интерфейс?

                                                                                                      То же самое, что и в вашем варианте. Только в вашем варианте еще и других недостатков много.


                                                                                                      В реальности это надо будет делать гдето в root контроллере и потом раздавать остальным контроллерам по цепочке.

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


                                                                                                      Обоснуйте

                                                                                                      Я же написал — менее понятно, что происходит при вызовах, а про изменения целый пример с кодом привел.


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

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

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

                                                                                                        Вся ваша логика, основанная на этом тезисе не верна.

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

                                                                                                        класс Settings c кучей функций loadFromSomething() с неявными зависимостями — и от файлов, и от http, и от чего угодно (GodObject)
                                                                                                        Если у вас настройки зависят от httpклиента, то вы дурачок, независимо от того явная зависимость или нет.

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

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

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

                                                                                                        Скрытый текст
                                                                                                        class Settings
                                                                                                        {
                                                                                                            loadFromIni() { ... }
                                                                                                        
                                                                                                            getParam1() { return int }
                                                                                                            getParam2() { return int }
                                                                                                            getParam3() { return string }
                                                                                                        }
                                                                                                        
                                                                                                        class Storage
                                                                                                        {
                                                                                                            doSomething()
                                                                                                            {
                                                                                                                if (Settings::getParam1() == Mode1) {
                                                                                                                    ...
                                                                                                                }
                                                                                                                else if (Settings::getParam2() == Mode2) {
                                                                                                                    ...
                                                                                                                }
                                                                                                                else if (Settings::getParam3() == Mode3) {
                                                                                                                    ...
                                                                                                                }
                                                                                                                ...
                                                                                                            }
                                                                                                        }
                                                                                                        
                                                                                                        class Controller
                                                                                                        {
                                                                                                            var controller2 = Controller2()
                                                                                                        
                                                                                                            doSomething() {
                                                                                                                Settings::loadFromIni()
                                                                                                            	Storage.shared.doSomething()
                                                                                                               
                                                                                                                controller2.doSomething()
                                                                                                            }
                                                                                                        }
                                                                                                        
                                                                                                        class Controller2
                                                                                                        {
                                                                                                            doSomething() {
                                                                                                                if (Settings::getParam1() == Mode3) {
                                                                                                            	   Storage.shared.doSomething()
                                                                                                                }
                                                                                                            }
                                                                                                        }
                                                                                                        
                                                                                                        class Controller3
                                                                                                        {
                                                                                                            doSomething() {
                                                                                                            	if (Settings::getParam1() == Mode1) {
                                                                                                                    ...
                                                                                                                }
                                                                                                            }
                                                                                                        }
                                                                                                        
                                                                                                        

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

                                                                                                        Усложнение системы не может упрощать ее понимание, только усложнять. То что такой вариант вам кажется проще — когнитивное искажение, изза того что вы привыкли к такому варианту. Закладывать упрощение изменения кода, который вероятно меняться не будет — в лучшем случае пустая трата времени. Ваши утверждения логически не верны.
                                                                                                          +1
                                                                                                          Вам сложно носить каску каждый день? Думаю не сильно сложнее чем шапку.

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


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

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


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

                                                                                                          Давайте не будем заниматься демагогией, это в обе стороны работает. То, что вам привычнее видеть запутанный код со скрытыми зависимостями — ваша профессиональная деформация. То, что вы привыкли кушать суп вилкой, не значит что так удобнее. И я даже могу предположить почему это деформация — потому что вы занимаетесь мелкими приложениями, и раньше писали всё в одиночку, а может и сейчас пишете. А книжку "Clean architecture" я вообще не читал.


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

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


                                                                                                          В реальности же, больше сущностей — сложнее, больше связей — сложнее, конструкции из многих элементов с раздутой логикой, вместо конструкций из 1-2 элементов с минимальной логикой — сложнее.

                                                                                                          Я про это тоже уже писал. От того, что вы параметры конструктора заменили на static-вызовы, количество сущностей у вас не уменьшилось. Просто из явных они стали неявными, и стало сложнее понимать их взаимозависимости. "Ваши утверждения логически не верны."


                                                                                                          но стоит добавить еще пару контроллеров

                                                                                                          А где у вас там в Controller2::doSomething() вызов Settings::loadFromIni()? Раз это контроллер, значит он может быть вызван независимо от Controller. Вот и баг на ровном месте. А если не может, значит у вас снова неявная зависимость "перед использованием Controller2 надо обязательно вызывать Settings::loadFromIni()". А когда они в конструктор передаются, получается то же самое, только явно, и не надо писать эти пометки ни в комментариях, ни в документации. И вот у вас Settings::loadFromIni() вызывается во всех методах контроллеров, которые могут быть вызваны независимо, а можно было бы загрузить их один раз при старте приложения.


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

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

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

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

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

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

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

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

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

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

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

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

                                                                                                            Усложнение системы не может упрощать ее понимание, только усложнять.

                                                                                                            Очень спорные утверждения. Множество практик в самых разных областях человеческой деятельности ему противоречат. Введение дополнительных сущностей далеко не всегда усложняет систему. Банальный пример: сеть компьютеров (на самом деле любая сеть из услов и ребёр между ними) по топологии "все-со-всеми" и по топологии "звезда" — количество узлов на один больше, а количество связей уменьшаетcя в (N-1)! раз. Неужели первая для вас проще? Десять узлов и 3628800 связей или 11 узлов и 10 связей — какая проще?

                                                                                                              0
                                                                                                              Ну так вы противоречите своему же утверждению.

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

                                                                                                              Слои абстракции вообщето затем и нужны, чтобы снижать сложность системы. Вот есть у вас 10 сущностей, обернули в слой абстракции и на этом слое стала одна сущность. Это упрощение.

                                                                                                              А если у вас была одна сущность, а вы обернули ее в 2 слоя абстракции — вы просто добавили слоев абстракции, которые на более высоком слое — являются такими же сущностями. Это усложнение.

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

                                                                                                                +2

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


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

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

                                                                                                                  Вы бы разобрались с терминами уже. С вашим то опытом такие вещи стыдно не понимать. Все таки есть доля правды в вашей подписи на хабре :) Тем более раз уж вы ее потерли.

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

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

                                                                                                                    Абстракции "узёл", "ребро", "звезда" я использую только в диалоге, говоря про реальные сети.


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


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

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

                                                                                        А чем собственно плох DI в маленьких проектах? Или вы путаете DI с DI container?
                                                                                          –3
                                                                                          Или вы путаете DI с DI container?

                                                                                          Если передать экземпляр класса в конструктор — DI, а DI container — использовать для этого фреймворк, который раздает зависимости, то да, путаю.

                                                                                          А чем собственно плох DI в маленьких проектах?
                                                                                          Во-первых тем что в маленьких проектах нет большого количества зависимостей и необходимости их менеджить. Если проект маленький, а зависимостей много — вы вообще что-то в корне не так делаете.

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

                                                                                          Передавать единичные зависимости в конструктор — это ок, строить на этом архитектуру без нужных оснований — не ок.
                                                                                            0

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

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

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

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

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

                                                                                      А что имеется в виду под умением проектировать и какие вы вопросы на этот счет задаете?
                                                                                        +1
                                                                                        но на собеседованиях куда чаще попадаются «задачки, технологии и паттерны».
                                                                                        Что я могу сделать, самого это калит

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

                                                                                        Если хотите практических примеров, то на примере коментария выше: умение проектировать это понимать что такое DI, какие проблемы он решает, когда его стоит использовать, а когда нет, какие есть альтернативные подходы, какой вариант DI (compile\runtime) лучше подходит к текущему проекту, и какую конечную реализацию выбрать. А не умение выбирать из 3 модных реализаций DI и опыт работы с ними.

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

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


                                                                                          Умение понимать, как сделать так, чтобы когда оно вместо 10К сообщений в секунду начнет получать 10М в секунду — все не оторопело до полного ступора — вот это да, это про проектирование. А формочки через джейсонапи к недосерверу прикрутить — да хоть в дельфи каком-нибудь клац-клац — и в продакшн.

                                                                                            0
                                                                                            Ну а если есть «опыт разработки с нуля 2-3 проектов» — то это даже проектами смешно называть
                                                                                            Ну так это базовый минимум, а не показатель крутых скиллов.

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

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

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


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


                                                                                            Скажу за себя: за жизнь решил 4 тестовых задания
                                                                                            1) Это был 2009 год и с работой было совсем плохо. Хотел устроиться хоть куда-то. После отправки решения ответ так и не получил.
                                                                                            2) Решил большое сложное задание, потому что оно было очень интересным. И компания в теории платила много денег. На собеседование не пригласили, фидбек состоял из одной фразы. Но о потраченном времени не жалею т.к. задание было ну просто очень клевым.
                                                                                            3) Решил задание, потому что хотел попрактиковаться на новых технологиях. Компанию послал лесом, потому что HR был невежлив. Но задание решил чисто для себя.
                                                                                            4) Решил маленькое простое задание потому что вакансия произвела вау-эффект. По результату отсобеседовался и получил оффер.


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


                                                                                            Если фирма не в топ-5 компаний на рынке, если зарплата не сильно выше рынка, если вакансия не производит эффект разорвавшейся бомбы, то зачем кандидату решать задания?

                                                                                              0
                                                                                              >Идеальный для кого?
                                                                                              Идеальный для того, чтобы максимально точно оценить навыки кандидата

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

                                                                                              Вообще лично мне, например проще сделать тестовое за вечер, чем болтать с зачастую неадекватными интервьюерами, которые спрашивают полную херню. И уж точно лучше чем ходить на 3 или 5 собесов.
                                                                                                0

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

                                                                                                  +2
                                                                                                  Вообще лично мне, например проще сделать тестовое за вечер, чем болтать с зачастую неадекватными интервьюерами, которые спрашивают полную херню. И уж точно лучше чем ходить на 3 или 5 собесов.

                                                                                                  Хм, а с чего вы взяли, что тестовое задание будет адекватным? Давайте будем логичны: если интервьверы зачастую неадекватны, то они зачастую будут давать неадекватные тестовые задания. И даже если они скоммуниздили где-то задания (то есть задания — норм), интервьюверы ввиду своей неадекватности уж точно неадекватно будут их оценивать.


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


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

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

                                                                                                    Давайте вынесем эмоции за скобки, и подумаем логически: 3-5 собесов в 3-5 раз увеличивают шанс найти хорошую работу
                                                                                                    Я имел ввиду 3-5 собесов в одну компанию, например в яндексе или додо. А не 3-5 собесов в разные.
                                                                                              0

                                                                                              Делали что-то похожее — streamlined recruitment. Всё этапы интервью в один день: сначала простенькие технические вопросы, чтобы кандидаты настроились, потом маленькая задачка покодировать (не на бумажке, с доступом в интернет и к документации), и заключительная часть — soft-scills, где вообще был разговор с рядовыми инженерами из команды за жизнь. Потом отправляли кандидата на обед за счёт компании, и через час давали ответ да/нет.
                                                                                              Не все соглашвлись на такое.

                                                                                                +1

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

                                                                                                  +4
                                                                                                  Причины почему бы я сильно задумался об оказе от такого формата:

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

                                                                                                  2. Сложно найти время на целый день, особенно если еще работаешь на другой работе,

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

                                                                                                    ЗЫ: Я тоже проводил собеседования в таком формате. Кандидат большую часть времени знакомится с компанией. Атмосфера более чем непринужденная. Если на этот день есть какие собрания — очень желательно чтобы он на них попал… В общем, главная задача — не только познакомиться с навыками человека, как это делают 90% компаний, но и познакомить человека с компанией.

                                                                                                    ЗЗЫ: Если человек не способен справится со стрессом 3х часового собеседования, у меня обычно возникает вопрос: а как он выдержит стресс 8ми часового рабочего дня?

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

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

                                                                                                        0
                                                                                                        Мы совмещаем. Опыт показал, что проводить всё в 2 дня очень накладно по времени и нам и кандидату, да и не особо нужно. Обычно лёд тает к концу тех. интервью. У меня даже был случай, когда на архитектурном коммитете кандидат подсказал одно очень интересное решение…
                                                                                                        +2
                                                                                                        На самом деле само «собеседование» длится часа 3.

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

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

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

                                                                                                        Не очень удобно с точки зрения кандидата. Ладно если компания Амазон или Гугл и кандидат хочет пойти именно в неё — но в обычные компании — не очень удобно.
                                                                                                          0
                                                                                                          Однако планировать все равно нужно весь день? Ведь потом будут встречи и т.п.
                                                                                                          При этом если в первый час станет понятно, что компания кандидату неподходит или кандидат не подходит компании — все равно весь день кандидат потеряет.

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

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

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

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

                                                                                                          Ну давайте посчитаем. Предположим кандидату ехать до нас час (среднее время добора по Москве). Значит каждый этап — 3 часа времени. Предположим 3 этапа (а такое часто бывает). Итого: 9 часов времени. Если к этому добавить тестовый день, если он таки есть — картина становится совсем неприглядна. Лично я, при наличии такого количества беготни, компанию рассматривать врядли бы стал. Тут же все просто — приехал, прошел все скопом, сделал выводы для себя, по результатам получил либо оффер либо отказ. 25 компаний за неделю рассмотреть не получится. Поскольку проходить по 5 собеседований в день невозможно по логистическим причинам, да и мозг после второго начнет вытекать.

                                                                                                          Не очень удобно с точки зрения кандидата. Ладно если компания Амазон или Гугл и кандидат хочет пойти именно в неё — но в обычные компании — не очень удобно.

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

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

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

                                                                                                            Которых вы нанимали по этой же системе?

                                                                                                            да и мозг после второго начнет вытекать

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

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

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

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

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

                                                                                                              А также завести в офисе 7218 сортов чая, чтобы угодить всем? И офисы снять в каждом здании Москвы для удобства добора каждого?

                                                                                                              Которых вы нанимали по этой же системе?

                                                                                                              Некорректно выразился. 75 сотрудников было на момент введения таких собеседований. Сейчас — 112.

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

                                                                                                              Где вы увидели 3 собеседования по 3 часа? Собеседование (этап) длится час. Плюс 2 часа дорога до него и обратно, тоесть я считал общие временные затраты.

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

                                                                                                              Простите, а что в статье или комментариях дало вам повод считать что речь о Западной Европе? Речь о Москве. И, простите, в Европе вас тоже не возьмут ни в одну приличную контору без пары очных собеседований МИНИМУМ.

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

                                                                                                              У меня складывается чувство, что это не компании назначают вам собеседования, а вы им… Да чтобы рядом находились, и чтобы удаленно в обязательном порядке, и чтобы у них HRы и тех-лиды на это время обязательно свободны были исключительно для вас… Простите, но мы кажется на разных планетах живем.
                                                                                                                0
                                                                                                                А также завести в офисе 7218 сортов чая, чтобы угодить всем? И офисы снять в каждом здании Москвы для удобства добора каждого?

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

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

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

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

                                                                                                                Ну, логический предикат «никогда» опровергается единичным примером:
                                                                                                                Уже взяли, без единного очного собеседования. Насчет приличности — ну ее сайт в top50 самых популярных ресурсов интернета по версии alexa rank, а позиция — поддержка и разработка одной из самых важных частей этого ресурса.

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

                                                                                                                У меня складывается чувство, что это не компании назначают вам собеседования, а вы им

                                                                                                                Не совсем. Хотя в Европе хороших разботчиков не хватает и в линкед и stackoverflow мне приходят сотня предложений от рекрутеров каждый месяц (но я не считаю себя суперзвездой — они всем разработчикам по популярному стеку приходят). В принципе, можно найти работу вообще не рассылая резюме.
                                                                                                                  0

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


                                                                                                                  Откуда все эти люди берут железобетонные познания про «как оно в Европе» — тайна великая есть.

                                                                                                      0
                                                                                                      У нас в компании все интервью проходят так — 4-5-6 интервью подряд в один день. Да, это очень тяжело (сам такое же проходил), но отстреляться разом и получить ответ в течение пары дней — это очень удобно (ехать один раз и брать только один день) и быстро, по меркам больших энтерпрайзов. Давать ответ прямо после собеса у нас не готовы, тк все интерсьюеры должны вбить свои отчеты в систему, обсудить результаты и проголосовать. А это по любому конец дня или даже следующий день.
                                                                                                        +1
                                                                                                        А можно чуть подробнее о том, что обсуждается на 5-6 интервью? Это разные люди собеседуют или где? Без сарказма, реально интересно. Просто тяжело в собственном понимании размазать зону принятия решения на 6 этапов в данном вопросе.
                                                                                                          0
                                                                                                          Обычно сперва по телефону собес с рекрутером, чтобы понять, есть вообще интерес. Потом phone screening чтобы не заставлять ездить за тридевять земель людей, которые объективно «не понянут» по технической части. Часто еще дают домашку после этого. Потом согласовывается день, когда кандидат приезжает в офис почти на день (часа 4-5 точно) и 5-6 человек собеседуют по очереди один-на-один по 45 минут. Роли и время распределены заранее — те каждый знает, какая область его. Среди них обычно один-два по технической части, остальные тн behavioral interviews. Это когда с пристрастием спрашивают примеры из прошлой карьеры типа «расскажите мне о ситуации, когда вы были не согласны с начальником, но вам пришлось что-то сделать» или «расскажите, как вы не смогли сделать то, что обещали». Звучит просто, но на самом деле без подготовки очень сложно такое отвечать связно и нигде не выставить себя безответственным раздолбаем :)

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