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

Нещодавно провів кілька інтерв’ю для джуніор-спеціалістів і попросив фідбек в менеджерів про себе, як інтерв’юера.
Сказали, що в цілому ок, але й вказали на те, що треба виправити, звісно ж.
Але один з менеджерів сказав цікаву штуку, яка мене змусила задуматись — Подумай, як би ти інтерв’ював людей на Senior-позицію і вище, при тому що ти зараз на Middle-позиції.

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

Можна по-простому: гуглиш «Top-100 interview questions for Senior position» і питаєш по списку. Але якось не комільфо.

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

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

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

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

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

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

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

охх...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

без понятия

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

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

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

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

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

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

мені

синьора

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

поговорить

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

як оцінити сеньйорський код, якщо сам ти ще таке не писав?

В смислі не писав? Якщо вимоги до коду синьйора і мідла однакові і ти мідл, то як же ти прихитрився такий код не писати?

маю на увазі якісь специфічні чи глобальні задачі для С-левела

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

з кодом так: чим він простіший і нудніший — тим кращий

Тим простіше бачити, що саме читати НЕ ТРЕБА, гарний код читається «по діагоналі».

Підписатись на коментарі