Як інтерв’ювати людей на позицію, вищу за свою?

Mykola Savoniuk IOS developer – IDAP Group 21.09.2020 18:49

Не баян а классика
Ну, как правило, у сеньоров спрашивают нетривиальное, типа:

Если кинут баг под ноги, его фиксить или переступить?

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

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

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

Grez 21.09.2020 16:03

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

Vlad Stelmahovsky Software Engineer в Verity AG 21.09.2020 09:50

стать на табуретку?

TechnoBarbarian 20.09.2020 23:22

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

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

Уже этого достаточно для серьезного и обстоятельного диалога даже с rock star сеньором.

Даже если интервьюируемый в рамках ответа начнёт говорить о вещах в которых ты некомпетентен, абсолютно нормальным будет подойти к этому с позиции обучаемого человека и попросить объяснить идею максимально детально и доходчиво. Это, в конце концов, одна из ключевых компетенций сеньора. Пост-фактум можешь изучить тему и перепроверить ответ. Можно даже связаться с этим человеком и повторно обсудить какие-то моменты после «ликбеза». Я так делал неоднократно будучи с обеих сторон «стола». «Individuals and interactions over processes».

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

Max Shnurenok .NET Architect в LogiqApps 20.09.2020 23:58

Я бы не согласился, т.к. в моей градации Senior (уточню — бэкендщик) уже должен заходить в сторону архитектуры и (крайне желательно) инфраструктуры. Шанс миддла задать правильные вопросы в этом случае стремится к нулю, и даже если он их всё-таки задаст, весь смысл в том, чтобы оценить это с точки зрения реального применения, а не мейнстримовых статей в интернете (при чём, кандидаты их же, в основном, и повторяют). Ответы на вопросы, которые и дают самую большую ценность в случае сеньора, миддл оценить уже не сможет ну никак. Можно, конечно, записать интервью и кому-то скилловому показать потом, чтобы оценил, но это уже будет второй сорт, т.к. правильных уточняющих вопросов не будет. Я сторонник того, чтобы задавать хай-левел вопросы, а если уже человек не знает на них ответы, то можно опускаться ниже (если мы хотим узнать сильные стороны кандидата и соглашаемся, что именно это — цель интервью). Тратить же собеседование сеньора на задротство а-ля внутренности платформы считаю крайне вредным занятием и потерей времени как своего, так и кандидата. Недавно рекомендовал мужика на .NET тех лида, не задав (о ужас) почти ни одного вопроса по, собственно, «чистому» .NET (только по Entity Framework в вопросе про ORMки, и по касательной всплыл один нюанс использования ASP.NET/Core — всё :) ).

TechnoBarbarian

Luci 21.09.2020 16:24

это утверждение исходит из позиции, что интервью — это экзамен

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

TechnoBarbarian

Yuriy Zaliznyak regular pizza delivery officer 21.09.2020 17:11

нет. экзамен — это проверка «выучил / не выучил». интервью — это проверка «справится / не справится». абсолютно разные вещи.

Luci

Luci 21.09.2020 17:31

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

Yuriy Zaliznyak

Yuriy Zaliznyak regular pizza delivery officer 21.09.2020 17:42

опять мимо. рассмотрим сферического коня в вакууме: вайтишник-пицценосец после 20-ти лет занятий теоретической и вычислительной физикой решил вайти, вашол, и, скажем, отвеслал три года на галере промышленным дотнетчиком в крвавом энтерпрайзе. справится ли он через 21 день с работой миддла-питонщика? справится канешно. есть ли у него релевантная практика? нету канешно, не натирал он того питона сроду. или вот возьмём типического укроинского выпускника киивского питомника и..инженеров. скоко недель ему нада шобы стать настоящим мужчиной-радиофизиком©, а?

Luci

Luci 21.09.2020 17:59

сорян, я этот поток сознания не распарсил

Yuriy Zaliznyak

Yuriy Zaliznyak regular pizza delivery officer 21.09.2020 18:00

значет тупой, чо. интервью не прошол.

Luci

Luci 21.09.2020 18:17

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

Yuriy Zaliznyak

Молдавский Узбек 20.09.2020 14:42

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

А он умëн, менеджер этот ваш.

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

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

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

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

anonymous 20.09.2020 14:36

-

Кодерок 20.09.2020 14:40

Є кращі програмісти, є гірші, є більш досвідчені, є ті, хто кодить по «best practices» а за те, що і як в реальному житті працюєі чи задоволений замовник ніколи не відповідали.

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

anonymous

anonymous 20.09.2020 14:50

-

Кодерок 20.09.2020 14:53

Oк, твой вариант — нанять студента, вместо запрашиваемого синьора и не париться. :)

Всё одно все разрабчики и проекты/таски вокруг — одинаковые.

anonymous

anonymous 20.09.2020 14:56

-

Luci 19.09.2020 17:01

Никак.
И, что важно, этому есть даже научное обоснование. Причем в нашей профильной дисциплине.
The law of requisite variety по сути отрицает такую возможность.

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

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

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

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

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

Олексій Пєніє 21.09.2020 15:35

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

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

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

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

Простой тест: дайте человеку кусок среднестатистического говнокода, и попросите провести рефакторинг. Тест занимает минут 5. Но в нём важна ВАША квалификация, в понимании как именно выглядит зрелый код. Здесь очень легко ошибиться. Но здесь можно спросить кандидата, какие МОТИВЫ. Чем дальше они от практики, чем больше кандидат использует отсылок к авторитетному мнению, тем ниже его собственные скиллы. Архитектор вообще ответит «я художник, я так вижу».

Luci

Дмитрий Мирошник Lead QA Automation Engineer 18.09.2020 21:19

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

Denys Poltorak Embedded | C++ (opentowork) 18.09.2020 12:50

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

Victor Mikhaylov junior manual tester 18.09.2020 12:10

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

Luci 19.09.2020 17:52

А чем это плохой способ и почему не относится к разряду «умных»?

Victor Mikhaylov

Grez 21.09.2020 15:56

в том что это не имеет никакого отношения к работе которую нужно работать.

Luci

Luci 21.09.2020 16:15

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

Grez

Grez 21.09.2020 17:03

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

Luci

Luci 21.09.2020 17:29

1. Требование касательно алгоритмов это не дурость со стороны Фаангов. Уже написал почему.
2. «Мелким» конторам виднее.

Grez

Denys Poltorak Embedded | C++ (opentowork) 21.09.2020 17:39

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

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

Luci

Luci 21.09.2020 17:45

Зачем это конторе: чтобы сотрудники были в ситуации «тяжело нести и жалко бросить»

1. Чтобы проверить интеллект и мотивацию.
2. После гугла у человека обычно нет проблем с трудоустройством. Так что не надо никого жалеть :-)

Denys Poltorak

Denys Poltorak Embedded | C++ (opentowork) 21.09.2020 17:48

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

Luci

Luci 21.09.2020 18:16

Зазубривание тут ни при чем вообще. В чистом виде никак не поможет. Т.к. там не задают вопросов «запили мне шелл-сорт за 3 минуты». Сколько ни общался, ни разу не слышал о таком. Практически всегда дают задачи, которые могут быть сведены к ним. А это требует понимания работы/применения алгоритма/типа данных.

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

Denys Poltorak

Олексій Пєніє 21.09.2020 15:46

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

Victor Mikhaylov

Олексій Пєніє 18.09.2020 01:53

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

Другими словами, вы десятки раз в неделю собеседуете специалистов, которые лучше вас разбираются в какой-то области. Даже покупая гамбургер. Так что установите себе ПОГРЕШНОСТЬ в 15% вероятности увольнения в первый месяц, грубо говоря с испытательного срока, и 30% в течение года. И можете смело рисковать в этих рамках. Попытка сузить рамки будет вам стоить отсева самых ценных спецов ещё на ранних этапах.

Объясню почему: Вы не просто не понимаете их работу, вы не понимаете их ошибок и их компетенцию. То что вы считаете важным — они НЕ ЗНАЮТ, потому что забыли. Такова цена узких спецов, весь бюрократический мусор они выбросили из памяти. Угадайте, что спросите вы, нагуглив «вопросы для синьора»? И задумайтесь на секунду — а кто писал эти вопросы?

Пример: сколько способов сделать Синглтон вы знаете? А синьор — только один: Ctrl-C/Ctrl-V. И только если оно ему надо часто, у него прямо в проекте или фреймворке лежит ШАБЛОН, который он тупо прототипирует. И это лишь синглтон, самый простой из якобы ценных шаблонов проектирования.

PS. И вы не удивляйтесь, если в коде синьора вы встретите те самые шаблоны... выполненные самыми плохими из возможных способов. И они будут работать. Потому что суммарное время работы этого кода за всё время его существования вряд ли превысит время на его написание и тестирование. HighLoad крайне редко затрагивает шаблонные участки. А вот время на ЧИТАБЕЛЬНОСТЬ кода весьма ценна.

Кодерок 18.09.2020 10:11

Ну очень словоохотливый джун. Просто-таки джун-болтун.

Олексій Пєніє 21.09.2020 00:51

По себе судит просто таки каждый. Но тебе даже джуном не дано быть, ты просто

Andriy Loboda 21.09.2020 12:39

Не только лиш все энто могут. ©

Roman Sheremeta Software Engineer (Golang) в Influ2 18.09.2020 12:03

Так что установите себе ПОГРЕШНОСТЬ в 15% вероятности увольнения в первый месяц, грубо говоря с испытательного срока, и 30% в течение года.

Це вже менеджерське питання, з мене, як інтерв’юера, тільки технічна складова співбесіди (ну і софт-скіли також).

Але комент тим не менш цінний, дякую.

Олексій Пєніє 21.09.2020 00:53

Якщо коротко, ти технічну складову не можеш перевірити НІЯК, якщо спробуєш — відсієш усіх, хто має цінність.

Але існують недокументовані способи запустити самоперевірку :)

anonymous 17.09.2020 21:55

-

Олексій Пєніє 21.09.2020 15:49

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

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

anonymous

Forrest Gump 17.09.2020 21:08

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

Если команда маленькая, важно оценить soft skills (впишется ли человек). Если команда большая, то концентрация только на technical skills.

Нам когда-то нужен был CTO на проекте. Долго искали, всей командой собеседовали. А потом взяли самого ответственного и проактивного Seniorа. Все были довольны.

Олексій Пєніє 21.09.2020 00:58

У меня есть две секретных методики. Первая с гарантией 50% определяет, впишется ли человек. Вторая даёт ≈91% положительного результата. Первая состоит в подбрасывании монетки, вторая — в отказе от оценки вообще, считая результат заведомо положительным.

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

Forrest Gump

anonymous 17.09.2020 19:10

-

Roman Sheremeta Software Engineer (Golang) в Influ2 17.09.2020 20:32

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

anonymous

Леголас Трандуилович 17.09.2020 21:03

Я б вашому менеджеру відповів

А камон. Менеджери то ж хитрі створіння, вони ж не просто так такі питання питають.

anonymous

Леголас Трандуилович 17.09.2020 15:17

Як на мене, це нелегко, бо кандидат вже Senior-рівня і знає нюанси роботи на цій позиції, а ти ще не був на тому рівні, але треба якось провести інтерв’ю.

В ідеалі — ніяк. І ти сам сказав чому.
Якщо дуже вже дуже треба, ну первір для початку основну технічну грамотність, так само як перевіряв би в мідла. А потім попитай чим людина займалась, що добре знає, ну і з того можеш його попитати що тобі самому цікаво. Хай роскаже про технології, засоби розробки, що завгодно ще що тобі цікаво. Скористайся можливістю поспілкуватись на технічні теми з більш сіньйорним спеціалістом. Ну і спитай себе чи ти хотів би працювати з тим чуваком, особливо в ролі старшого і чому.
Імхо то найкраще що ти можеш сам зробити.

Ну і трошки більш формальний підхід взнай які в твоїй конторі формальні вимоги до сіньйора. В серйозних конторах вони є. Подивись що з того ти можеш перевірити і як.

Roman Sheremeta Software Engineer (Golang) в Influ2 17.09.2020 20:33

Ну і спитай себе чи ти хотів би працювати з тим чуваком, особливо в ролі старшого і чому.
Імхо то найкраще що ти можеш сам зробити.

Це дійсно корисна порада.
Цікаво, дякую

Леголас Трандуилович

anonymous 17.09.2020 14:04

-

Roman Sheremeta Software Engineer (Golang) в Influ2 17.09.2020 20:42

Омг, наступне ж речення —

Але якось не комільфо.

вам не дало зрозуміти, що я не вважаю такий підхід чимось хорошим?

П.С. якщо це був сарказм, тоді ще не п’ятниця

anonymous

anonymous 17.09.2020 21:54

-

Олексій Пєніє 17.09.2020 13:44

Віддай питання на аутсорс. Невже так важко разово найняти чи позичити сеньйора щоб найняти сеньйора?
Можна по-простому: викладаєш колекцію сиру і питаєш по списку :)

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

anonymus ps 17.09.2020 19:13

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

Олексій Пєніє 18.09.2020 01:56

А что если все синьоры такие — в смысле, «откуда знаешь» какие?

anonymus ps

anonymus ps 18.09.2020 09:42

охх...

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

Олексій Пєніє 20.09.2020 23:04

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

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

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

Почему метод работает? Он тестирует механизм генерализации памяти на конкретном контексте. То есть умение в частностях быстро видеть значимое и отсекать кучи мусора, не значимые для решения поставленной задачи. Чем быстрее кандидат назвал ОБЩИЕ ПРИЗНАКИ этого кода, чем они короче, чем меньше деталей счёл значимыми для ответа на вопросы «что это?», «что оно делает?» — тем больше ОПЫТ кандидата, тем больше подобного контента он видел и с ним разбирался.

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

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

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

anonymus ps

Denys Poltorak Embedded | C++ (opentowork) 21.09.2020 15:42

А ты веришь, что быстрый кандидат == хороший работник?
Типа срам с ней, этой вашей архитектурой, у нас спринт горит?

Олексій Пєніє 21.09.2020 15:52

Нет. Я верю, что если кандидат НЕ ЗНАЕТ, что это тест на скорость — то можно узнать его скорость КАЧЕСТВЕННОЙ работы. Но не замерив её в целом, а фиксируя на самых быстрых фрагментах. Общий показатель будет неинформативен, поскольку скорость памяти критически зависит от привычности окружения. Добиться привычного окружения на собесе невозможно.

Denys Poltorak

Roman Sheremeta Software Engineer (Golang) в Influ2 17.09.2020 20:34

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

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

Олексій Пєніє 18.09.2020 08:20

Вкрасти без співбесіди — так не буває :))

Я ж казав, то сильно просто, щоб повірити: левова доля «роботи» українського HR — просто релігійні ритуали, народжені в тусовках ТП.

Буває по-всякому, щойно отримаєш наукову освіту замість релігії.

Кодерок 17.09.2020 12:17

Нанять синьора? Изи. По рекомендациям и на хороший баблос.

Хинты:
— если синьор не знает свою стоимость, а пытается выяснять всякие вилки и прочее — это не синьор
— если синьор не укажет свою примерную стоимость сразу, при первом контакте (телефонном?) — это не синьор
— бери того из синьоров, кто больше запрашивает (при прочих равных)

П.С. Собеседовать синьоров незачем, т.к. они сами кого хошь отсобеседуют. Резюме, подтверждённого хорошими рекомендациями — достаточно.

Олексій Пєніє 17.09.2020 13:45

Хорошая попытка, не-прелюбодей Пульсифер

Кодерок 17.09.2020 13:48

У тебя нет рекомендаций с прошлых проектов? Значит, не насиньорил...

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

Олексій Пєніє 18.09.2020 01:58

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

Кодерок 18.09.2020 09:55

у скажи, почему сыр Parmezzio verde не употребляют с коньяком и грушами.

Без понятия. Я африканские ноу-нэйм сыры не ем и коняки не пью (предпочитаю синг-молт скоч).

Олексій Пєніє 20.09.2020 23:12

Тест провален ниже плинтуса. Утиная типизация прямо кричит слово «нищeбрoд».

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

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

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

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

Oleksandr Merkulov asterisk guru 26.09.2020 02:52

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

Andrio Skur 26.09.2020 23:53

без понятия

Что мне делать если Я технарь который часто юзает это слово?

Олексій Пєніє 27.09.2020 22:42

Попробуй сделать полнотекстовый поиск в написанной тобой документации и комментах в коде. Результат мне не говори, это так сказать «познай себя» :)

Andrio Skur

anonymous 17.09.2020 19:10

-

Roman Sheremeta Software Engineer (Golang) в Influ2 17.09.2020 20:35

ще не п’ятниця, а на ДОУ вже такі коменти.....

Олексій Пєніє 18.09.2020 01:59

В цього персонажа завжди п′ятниця, це троляка з околиць «Дамбасу».

Кодерок 18.09.2020 10:09

ще не п’ятниця, а на ДОУ вже такі коменти

Тебе синьора или поговорить?

Roman Sheremeta Software Engineer (Golang) в Influ2 18.09.2020 12:00

мені

синьора

але я бачу тільки

поговорить

anonymous 18.09.2020 12:32

-

Олексій Пєніє 20.09.2020 23:28

Это эвфемизм к слову «допрос». Собеседование в Украине это именно допрос. Всё сказанное вами может и будет использовано против вас.

anonymous

anonymous 21.09.2020 09:46

-

Олексій Пєніє 21.09.2020 15:31

Дыба существенно снижает ТТХ двигателя галеры.

anonymous

wife of an acrobat 17.09.2020 12:12

В когось були такі ситуації і як ви з них виходили?

1. Відмовляєшся з очевидних причин
2. Якщо тебе все ще напрягають це зробити, пишеш офіційного листа на менеджмент, хто відповідальний в вас там за ці всі речі, де детально розписуєш суть проблеми:
— тебе попросили провести інтерв’ю на Senior-позицію
— але так як ти сам зараз на Middle-позиції, ти можеш не знати нюансів роботи на цій позиції в зв’язку з відсутністю досвіду і пропустити якісь специфічні для Senior-рівня речі, які можуть виявитися критичними в майбутньому
— так як ситуація «найняли Senior-a, але не того/не по тому, що потрібно» несе в собі купу ризиків і може створити купу проблем в майбутньому аж до можливого фейлу проекту, то наполегливо рекомендуєш врахувати це все і знайти більш досвідченого інтерв’юера, щоб мінімізувати ймовірність вищевказаних проблем, або хай офіційно підписуються під цим, що вони це все розуміють і приймають, але іншої кандидатури нема
3. Зазвичай +/- адекватний менеджмент обере перший варіант, і проблема вирішена
4. Якщо все-таки варіант 2, тоді спокійно проводиш інтерв’ю наскільки можеш і не переймаєшся. Якщо вийде все-таки, що Senior не такий і щось там було не враховано на співбесіді і на тебе наїжджають з цього приводу, показуєш той лист, де ти їх попереджав про це все, відповідно, всі їх претензії переправляєш на менеджмент, який офіційно дав добро на таку акцію — хай розбираються з ним.

Roman Sheremeta Software Engineer (Golang) в Influ2 17.09.2020 20:39

Вище вже відписав, що питання гіпотетичного характеру і задав його з цікавості.
Але не прописасв це в пості з самого початку, мій фейл.

Хоча практично погоджуюсь з вами, особливо цікавий останній пункт

wife of an acrobat

Luci 19.09.2020 18:05

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

3. Начинаешь искать новую работу.

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

wife of an acrobat

wife of an acrobat 20.09.2020 00:16

Власне, щоб він не «отпи*делся»:
— я запропонував провести, він не заперечував
— мені ніхто про проблеми співбесіди міддлом сініора не озвучував
— ми на той момент не мали більше нікого підходящого(мали, влом було шукати)
— я подумав, що це хороший тренінг для софт скілів
і т.п. лист і пишеться

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

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

Никчемное, оправдание на будущее, но лучше, чем ничего.

Цілком нормальний дупохрон, мета тут не оправдання — оправдуватись ні в чому і ні перед ким — а всього лише уникнути ситуації, коли ти залишишся єдиним крайнім в результаті, розділити частину відповідальності за деяке сумнівне рішення

Luci

Luci 20.09.2020 00:31

Молодой еще, наивный :-)
Объяснить почему это так не работает, или будешь набивать собственные шишки? ;-)

wife of an acrobat

wife of an acrobat 20.09.2020 14:17

Ну хз, довелось пропрацювати пару років в великій бюрократичній продуктовій корпорації з доволі чіткою вертикальною структурою і процедурами, і там такий підіхід в принципі працював, щоправда, по більш робочим питанням — позаплановий реліз, критичний фікс на проді без тестів, робити так, а не інакше, спочатку це, а потім інше і т.п. На все це потрібен був коментар відповідального ПМа, в окремих випадках напр. позапланових релізів які могли серйозно вплинути як на інших клієнтів-користувачів системи, так і на зміну завантаженості (потребували майже весь день роботи 1 QA) команди — head of PMO нашого субцентру. Пару раз і самому доводилось писати листи/коменти «где объясняешь что по данным причинам» з своєї сторони, що якесь певне запропоноване рішення не найкраще/не можливе — вроді як не звільнили тоді.
Тому пояснення би не завадило, бо поки що не бачу в чому проблема, коли для задачі якій «результат гарантировать не можешь» по цілком об’єктивним причинам — співбесіда мідлом сініора, написання джуном архітектури фреймворка і т.д. — не повідомити про можливі ризики з своєї сторони (тим більш коли ініціатор задачі про них не в курсі) і частину відповідальності делегувати на нього. Я не кажу що при цьому треба свідомо бокопорити чи віднестись до цього пофігістично — ні, лише щоб не залишитись єдиним крайнім в результаті

Luci

anonymous 17.09.2020 11:53

-

anonymus ps 17.09.2020 19:17

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

anonymous

Roman Sheremeta Software Engineer (Golang) в Influ2 17.09.2020 20:37

Сначала убедиться, что он не ниже твоего левела. Потом убедиться что выше.

Так, це релевантно.

Примеры кода,

Не дуже зрозумів. Я ж мідл левел, знаю, як писати якісний код відносно мідл рівня, але не знаю, який код є якісним на сеньйор рівні. Як можна це перевірити? Чи просто той код сніппет, що не дуже зрозумілий, вважати за сеньйорський? :)))

anonymous

Леголас Трандуилович 17.09.2020 21:05

Якісний код він однаково якісний на всіх левелах взагалі то.

Roman Sheremeta Software Engineer (Golang) в Influ2 18.09.2020 01:02

Окей, я погоджуюсь.
Тоді перефразую: як оцінити сеньйорський код, якщо сам ти ще таке не писав? (маю на увазі якісь специфічні чи глобальні задачі для С-левела)