Pull to refresh

Comments 223

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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


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


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

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


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

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


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


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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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


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

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

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


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

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


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

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


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

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


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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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


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

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

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


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


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

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

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


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

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


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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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

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

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

Вы же натурально говорите, что проще и дешевле выкинуть ваш код и написать заново
Да, зачастую небольшой кусок кода дешевле выкинуть и написать заново, чем строить систему таким образом, чтобы любой кусок можно было заменить за 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 (особенно на андроиде) и доказательств этого очевидного наблюдения просить не будет

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

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

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

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


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

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


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

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


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

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


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

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

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

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

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

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

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

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


Скрытый текст
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 сущностей. Не говоря уже о том, что при статических вызовах зависимости все равно есть, просто неявные. И чем их больше, тем сложнее разбираться и менять код.

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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


Обоснуйте

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


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

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

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

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

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

класс 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) {
            ...
        }
    }
}


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

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

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


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

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


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

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


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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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


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


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


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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

По результатам каждый интервьюер пишет отчет в систему и ставит там свое мнение брать или нет (чужих отчетов и голосов ты не видишь, пока свой не отправил). Потом в конце дня общий митинг, где все обсуждают каждого кандидата отдельно и решают. В 90% случаев кандидат получает результат на следующий день или через день.
Вот-вот… Для компании кандидат априори безответственный разгильдяй… Убивал бы за такое. Даже как работодатель.
И интервью все таки не все 6 в один день (ну это так, поправка), сомневаюсь что кандидат после 2-3 телефонных звонков сорвется срочно на собес. Оно таки размазано. Я имел ввиду «деньZ» — день очного собеседования.
Совсем нет, я просто сказал, что готовить такие истории нужно серьезно — это не так просто связно изложить, как кажется, без подготовки. И это вот прямо сильно видно на собесе.

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

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

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


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

Утрирую, конечно :), просто есть некий когнитивный диссонанс между профилем компании и политикой найма, похожей, грубо говоря, на условный гугл. Получается, что вы задаете высокую планку отсечения, чтобы снизить вероятность промаха, понятно. Скажите, пожалуйста, всегда ли эта стратегия работает, — были ли случаи мискаста, когда люди преодолевали эту планку, и с ними приходилось расставаться позже, — на испытательном сроке или даже позже?
вы задаете высокую планку отсечения

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


были ли случаи мискаста

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

И всё-таки, чем вы там, в IT ДОДО, занимаетесь? Что у вас, кроме сайта, мобильных приложений (по сути каталогов с корзиной) и собственно системы заказов?
ERP, скорее всего, есть. Но скорее всего, покупная, а не самописная.

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


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


Коротко говоря, Dodo IS – это узкоспециализированная система, которая объединяет в себе возможности ERP, CRM и HRM систем.

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

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


Это ведь лучше чем не сказать ничего? Я только об этом.

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

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

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

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

Мой опыт показал другое:


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

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

А то, что озлобится за отсутствие фидбэк, а вам не важно?

Давайте чуть с другой стороны посмотрим. Вот вы сидите и пишете код.
Далее есть несколько "вкусов":


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

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

В вашей логике есть один большой изъян: у компилятора нет своих интересов. У него нет цели собрать вокруг себя лучших программистов и не допустить их до других компиляторов. Однако же заметьте, обычно лучшие IDE сделаны не абы кем, а самими владельцами платформы (например, Visual Studio). И огромные деньги вбухиваются в улучшения вовсе не затем, чтобы в мире стало чуть больше добра, а затем, чтобы залочить как можно больше компаний на своих технологиях.

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

И экономия ресурсов тут вообще ни при чём. Как правильно заметил топикстартер, вопрос сводится к философскому «зачем делать людям полезно просто так, если это не ваши союзники».
Однако же заметьте, обычно лучшие IDE сделаны не абы кем, а самими владельцами платформы (например, Visual Studio)

Скорее это исключение из правила среди мэйнстрим платформ. Что там с IDE для Go, Java, PHP, Python, Ruby?

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

Человек её воспримет, проведёт работу над ошибками, подрастёт, и устроится к вашим конкурентам.


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

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

Думаю, это не самый типичный случай. За годы и десятки собеседований у меня такого не было ни разу. У коллег нынешних и прошлых, судя по разговорам под бокал и стакан, тоже ничего такого никогда не было.
Простите, но это не кандидаты, это вы такие. Вам нечего предложить поверх чужого оффера? Пичаль… Никто не пойдет к вам просто потому что вы красивые. «Канарейку за копейку» в нынешних реалиях не катит.
Разработчик — это актив. В него нужно вкладывать деньги. Включая этап найма. Позиция «к нам не пойдут» — убыточна с точки зрения бизнеса изначально.
чаще всего все нужные выводы делаются буквально за 5 минут после встречи

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

почему в конце, а не через 5 минут?

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

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

Я пишу на ноуте и заранее рассказываю о чем записываю:


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

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

Я, знаете, раньше интервьюировал людей в кафе. За маленьким столиком. Шум, гам, кофемашина завывает и люди шастают, чай подливается. А мы сидим с листочком (попрошенным у бармена) и на нем прямо программируем, ручкой (от официанта). В 95% — ну не очень идет, не очень… но в остальных 5% или меньше — случается чудо: 10 минут, и глаза у человека горят, и весь мир/звуки исчезают, и 1 (а то и 2) часа пролетают, как миг, причем для обоих. Вот с такими людьми и срабатываемся. Они все сейчас, что интересно, в Микрософте, Гугле, Фейсбуке и Букинге как на подбор.

Бывало, по 3-4 в день таких интервью было в горячую пору.

Жестоко? Наверное, жестоко. Но работало просто идеально.

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

Так что все относительно. Очень, очень часто так бывает, что можно оффер делать сразу же.
> Жестоко? Наверное, жестоко. Но работало просто идеально.

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

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


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

Как в некоторой степени юрист, отвечу следующее: ни при каких условиях не пойду работать в компанию, назначающую «встречи» в кафе.
Так в том-то и дело, что это не про людей типа «утром на работу, вечером с работы, дома дети сопливые», это про поиск founding engineers, единомышленников, родственных душ, можно сказать — «украл, выпил, в тюрьму, украл, выпил, в тюрьму — романтика!» (как в старом фильме). :)
Многие, кто писал в комментариях, не заметили, что автор не делает оффер и не решает брать человека на работу или нет, после него еще может быть 2 этапа собеседования.

Автор решает отказать кандидату или нет. Если его собеседование последнее во флоу, то по сути он решает брать или нет.

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

Совсем не последнее, еще впереди знаменитый тестовый день.

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

После проведения сотни собеседований могу сказать, быстрый вывод(фидбек) — это ошибка. Если время не жмет — лучше подумать, это почти всегда будет более взвешенное и адекватное решение, нежели сразу сгоряча правду-матку рубить.
UFO just landed and posted this here
Читайте внимательнее. Не на шестом собеседовании, а на шестом шаге в собеседовании (где шаги вида рассказать о том как будет проходить собеседование, рассказать о компании, рассказать о команде… дать фитбек и т.п.).

Все так, там же шаги из 7-15 минут

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

Пересмотреть свой подход к собеседованиям — это нормально. Зачем устраивать из собеседования экзамены и создавать напряжённую атмосферу? Сколько уже написано статей, что это плохо работает, это неэффективно и т. д. и т. п. Но всё равно находятся те, кто хочет делать так же как GAFAM. А вы уже догнали по количеству собеседований Яндекс или только в планах?

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


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

сейчас чтобы получить норм feedback после собеса — должны каким-то странным образом сойтись звезды

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

в больших конторах, за исключением АйТи, все эти отделы «кадров» сами не понимают кого ищут, и их АйТишники не рапортуют им feedback

Максимум что ты получишь это «спасибо, мы будем про вас помнить, а пока что спасибо»
А помнить будут ВСЕ, сейчас это модно, все ведут свою «базу» (вопрос только как они ее анализируют, или же просто сравнивают фамилию дату и сумму на руки, скорее только так) и умно делают какие-то закулисные выводы

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

лично мне становится понятно — будет что-то дальше или нет — через 10-15 минут собеса
я конечно понимаю что статья рисует нам картинку со стороны нанимателя, но и с другой стороны бывает понимание «не сработаемся»/нудный тип/кривая вакансия/подвальное помещение/слишком тихо/все в галстуках/секта…

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

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

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


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

Я вам даже больше скажу: скорее всего, все нужные выводы вы уже сделали в первые секунды интервью, а всё остальное время (незаметно для себя) занимались подведением базы под эти выводы:https://www.sciencemag.org/careers/2004/08/tooling-first-impressions-are-interview-results-preordained
Поэтому отсрочка с результатами имеет значение: она даёт хотя бы небольшую возможность переосмыслить это самое первое впечатление от кандидата, обсудить его с другими интервьюерами, может быть, собрать фидбэк от других, кто с ним работал как с контрактором, партнером и т.д.

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

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

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

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

Как можно отвечать сразу (даже положительно), если, например, на вакансию десять кандидатов, и вы собеседуете в данный момент только первого, а остальные девять придут позже?
Вообще-то это как раз и есть норма, просто годы разнузданного владычества тупых HR эту норму сломали.
Если вам нужно ЕХАТЬ, т.е. человек, выполняющий работу — вы смотрите на него, проверяете тестами и делаете вывод: не, он не тянет или да, он может работать. Если он может работать вы его и берёте сразу, без дурацких проволочек.
А если вам нужны ШАШЕЧКИ, т.е. «KPI на HR отдел», десять собеседований в день, стопка резюме, имитация бурной деятельности кадровиков — тогда конечно тогда нужно перебирать кандидатов и подольше, подольше.

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


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

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

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

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

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

Спросил у HR:


В вакансии указана ЗП, максимум по данной вакансии. У нас нет точных грейдов. Мы исходим из 3 составляющих: пожелания кандидата, его тех и софт скилов и аналитика рынка по ЗП. Отсюда получается оффер.
Я так понимаю, вы даёте HR процент от максимума, к примеру, на ваш взгляд кандидат тянет на 90% от идеала. HR умножает этот процент на макс зп, к примеру, 250тыс, получается 250*0,9 = 225, и отправляет оффер кандидату, если этот кандидат устроил менеджмент и HR. А дальше кандидат или отказывается, или принимает. При отказе, сумма не повышается.
Я правильно понял процесс?
И ещё интересно, уровень зп корректируется? Премии, бонусы? Или зп корректируется раз в полгода, с рассмотрением итогов работы?

Да, прошу прощения, если любопытен, если что секретно — так и скажите )

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


уровень зп корректируется?

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

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

Что-то среднее, это технический маркер.


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

То есть стимуляция к росту кнутом и пряником? Просто "бежать, чтобы оставаться на одном месте" недостаточно — или двигайся вперёд или до свидания?

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


бежать, чтобы оставаться на одном месте

Кажется, вы попали в точку, это написано на стенах офиса.


Фото из офиса

Для того, чтобы стоять на месте, надо бежать.


Для того, чтобы бежать, надо бежать в два раза быстрее...

В Big4 это up or out вообще норма вещей.

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

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

Желаемая наверно обсуждается и с HR, но основное обсуждение с СТО в самом конце.

Sign up to leave a comment.