Комментарии 87
Ну а главным показателем качества рекрутинга является успешность компании —… это значит, что сотрудников он набирают правильно.компания может быть успешной и по инерции, например. или маркетологов они набирают правильно, а разработчиков — как получится. или ещё какая-либо причина.
если компания растёт, продвигает свои продукты на рынке и зарабатывает деньгиэто со своей колокольни далеко не всегда оценишь.
кроме того, успешность компании — это лишь один из критериев выбора работы. дурацкие вопросы на собеседовании и «плохое» собеседование в целом могут быть признаком не поставленных процессов, пренебрежительного отношения к работникам и т.п.
Пусть это и не идеальные способа, но брать первого, кто пришёл, без всякого собеседования — тоже не вариант.
В этом процессе главный нюанс заключается в том что интервьюируемые и интервьюеры это те же самые разработчики но в разные периоды своей карьеры. И доставшая всех "тупость хрюш" это ни что иное как тупые критерии заданные тимлидами.
Давайте посмотрим на корень зла. Почему адекватный разработчик может иметь проблемы при найме на работу:
- Общая предвзятость и стереотипы например к женщинам, старикам, таджикам, замкадешным, больным и инвалидам
- Нежелание тимлидов брать себе конкурентов (сейчас надеюсь подтянутся тимлидиы которые начнут рвать на себе тельняшку и говорить что они отвечают за проект и весь проект на них и они заинтересованы в квалифицированных кандидатах) как правило наиболее циничные так прямо и говорят: мне нужно на проект три мартыхи.
- Отсутствие реальных дополнительтных рабочих мест. Вопрос а зачем же выставлять вакансию? Причин может быть много: для рекртутеров это просто работа. Иначе могут навесить обязанности HR или офис-менеджера. Для фирмы — дополнительный показатель стабильности перед инвесторами и заказчиками. Ищут работников — значит развиваются, не принимают всех подряд- значит высокий уровень. Ну а если кто-то просто "понравится" то могут и взять.
Ну а для разрабтотчиков которые уже на борту это как бы возможность оторваться от весла и затрекать время на собеседование а по сути немного переключиться на другой вид работы.
Я при этом не разбираю тот вариант что по ту сторону стола могут оказаться психи которые получают положительные эмоции от неадекватного собеса.
Каждая сторона может ошибаться. Но отвечает за ошибку всегда та сторона которая приходит на собеседование и в конечном итоге бизнес который вырастит у себя взрыв Бонзо.
Но отвечает за ошибку всегда та сторона которая приходит на собеседованиеПочему же? Если нанимающая сторона ошибается и принимает плохого разработчика, то это обходится ей довольно дорого. Гораздо дешевле ошибаться в другую сторону.
Я об этом и сказал "и в конечном итоге бизнес который вырастит у себя взрыв Бонзо."
Однако как правило это напрямую не касается прокладки между бизнесом и разработчиками, по крайней мере пока бизнес не загнется.
Опять вернулся к этому Вашему комменту, т.к. не дает он мне никак покоя.
Ведь все не так, совсем не так.
1) Вы неявно пытаетесь склонить сбеседников к такой вот дихотомии
- либо мы отпускаем гайки и к нам проникают больше плохих разарботчиков
- либо мы затягиваем гайки и к нам проникает меньше плохих разработчиков но вместе с тем мы можем отсеять и хороших.
Это не совсем верная формулировка. Т.к. может существовать система отбора которая одновременно и отсеивает хороших разработчиков и пропускает плохих. И я как в начале треда заметил, что для этого есть хороший объективный стимул — нежелание тимлида иметь себе же конкурента в лице нанимаемого.
2) Вы ошибочно полагаете что прием плохого разработчика обходится для бизнеса дороже чем не прием хорошего. Мол де в первом случае на него будет потрачены деньги на время испытательного срока и время хороших разработчиков. В то же время якобы не прием хорошего разработчика это бесплатно. Так вот, это совсем не так. Начнем с того что как бы хорошо ни была система отбора может произойти два события :
- кандидат все же не готов к работе и это не было определено на собесе
- кандидат устраивает фирму но он сам по своей инициативе вскоре уходит.
Так что выхлоп средств так или иначе неизбежен.
То что Вы не приняли хорошего разработчика — это вот как раз очень большая потеря. Т.к. именно хорошие а не среднепроходные разработчики могут способствовать росту бизнеса. То есть это да, упущенная выгода и измерить ее невозможно.
1.
Т.к. может существовать система отбора которая одновременно и отсеивает хороших разработчиков и пропускает плохих.Ваш пример про тимлида мне кажется очень надуманным. Если компания поручает тимлиду наем персонала, то это скорее всего означает, что тимлид имеет достаточно большую ответственность в рамках поставленных задач. А значит его основные приоритеты не избавляться от конкурентов, а добиться выполнния задач. Вполне нормально, что для выполнения задач ему не нужны архитекторы в команду, но крепких разработчиков он не будет отсеивать просто так.
Несомненно, существуют места с очень высоким уровнем внутренней карьерной борьбы, где описанный вами сценарий возможен. Но, честно говоря, буду рад если меня отсеют на собеседовании в такое место. Это сэкономит мне кучу нервов.
2.
-кандидат все же не готов к работе и это не было определено на собесеОба этих случая я бы отнёс к категории приём плохого разработчика. Хороший разработчик для компании это не «абстрактиный хороший разработчик в вакууме», а разработчик, который принесёт конкретной компании конкретную пользу. Если компания приняла сотрудника, который никакой пользы принести не смог (вне зависимости от причин), то компания приняла плохого сотрудника. И задача собеседования — постараться такого не допустить. Всякие ненавидимые кандидатами дурацкие психологические вопросы часть этого. «Непрофильные вопросы» — тоже. Если человек не готов отвечать на вопросы, котьорые чуть-чуть выходят за рамки его потенциальных обязанностей, то это значит, что он не сможет работать, если ситуация чуть-чуть изменится.
-кандидат устраивает фирму но он сам по своей инициативе вскоре уходит.
Я не рекрутёр, но собеседования провожу. Перед собеседованием резюме обычно просматриваю, но не очень детально. Скорее сканирую, надеясь найти что-то знакомое, о чём можно будет поговорить. При этом вполне могу пропустить что-то, что кандидат считает очень важным. Бывает так, что закручусь и напоминание о собеседовании прилетает из календаря за 10 минут до начала. В этом случае на чтение резюме времени уже не остается.
Вообще формат резюме у всех настолько разный, что найти и обратить внимание на какую-то информацию там зачастую не просто.
Судя по вашим словам, действительно не читают))
Делаю такой вывод так как обычно начинают читать резюме при мне)) с удивлением обнаруживая какие-то детали которые судя по всему не ожидали там увидеть.
Вы не один. Прочитали ранее ваше резюме. Но забыли. На собеседовании — перечитали, чтобы вспомнить.
Вы далеко не один. Типично на собеседовании: нескольков десятков человек на место. Резюме всех — в голове не удержишь.
Уважаемые собеседующие, читайте пожалуйста резюме, если есть вопросы просто позвоните и спросите, пятиминутный звонок легко экономит 2-3 часа.
Кто ждёт, что кандидат с деятельностью компании ознакомится больше чем в вакансии написано?
Про препроцессоры простой вопрос же: хотят узнать насколько широк ваш профессиональный кругозор, слышали ли хотя бы об альтернативаз тому, что указали в резюме, с чем, видимо, пришлось работать на прошлых проектах.
Давайте разделим рекрутеров и собственно тех, кто проводит техническое собеседование.
Рекрутерам пофиг на то, что написано в резюме, у них другая задача — выдать поток кандидатов.
Те, кто проводит тех собеседование, в принципе заинтересованы отсеивать по резюме, но тут срабатывает два фактора.
Первый — банальная невнимательность. Когда на тебя идет вал резюме на отсмотр — легко что-то пропустить, позвать не того, например. А второй раз ты возвращаешься к резюме уже перед встречей. И тут тоже банально может не хватить времени посмотреть резюме заранее, ибо обязанностей хватает.
Второй — с опытом приходит недоверие к написанному, даже если там стоят явно какие-то условия. Потом выясняется, что "нет" не такое уж и "нет", или устарело, или для всех "нет", но для вас… Это реальность, и если я вижу хорошего кандидата, который, например, не хочет работать с нашим стеком — я все же отдам его рекрутерам на установку первого контакта, ибо см. выше. И это работает.
Или, например, "зачем вы меня, С++ программиста, зовете на вакансию PHP"… звучит логично, но только если не знать, сколько я видел таких программистов, решивших сменить стек, потому что им предложили.
Рекрутерам прямо поток не нужен. Если 90% отсекается на техинтервью почти с самого начала, то к рекрутерам будут претензии
Имхо, все максимально просто:
Рекрутера уволят за то, что он не провел собеседование? Естественно.
Рекрутера уволят за то, что он не прочитал что-то так? Да нет, он работает, он ничего.
Зачем читать, когда можно пожрать в столовке и поболтать с коллегой?
Так и с программистами — есть некоторые критерии качества, которые легко проверить, но гораздо важнее не качество, а разные психологические характеристики, которые никакой линейной шкалы измерений не имеют.
А психологические характеристики не сравнимы.
Во первых, сравнивать можно любые психологические характеристики, если критерии сравнения задает контекст. Это элементарно, например: ищете тимлида — интроверт не подойдет. Во вторых, ох…
Вы считаете, что на тимлида интроверт не подойдёт, а я тут не согласен. Для менеджера по продажам такое, наверное, верно.
Но не суть. Я хотел отметить то, что для большинства важных характеристик "универсальных критериев" не просто не существует, а их не может существовать. То есть проблема не в том, что кто-то недостаточно организовал процесс и не вычислил критерии, а в том, что такое вычисление в привычном понимании невозможно.
Хотя вот обучат скоро машинный интеллект прием сотрудников проводить. Как он будет решения принимать никто не объяснит, но зато будет универсально :)
Интроверт может оказаться лучшим тимлидом для команды интровертов. Если сможет организовать работу так, чтобы не было нужды во всяких изнурительных для интровертов организационных и социальных мероприятиях.
Что хочется — введения какой-то общей квалификации. Наподобие как у врачей или педагогов. И тогда напрягаться придется раз — при получении этой квалификации.
Во-вторых, общая квалификация существует. Есть разные там сертификаты. Но, к сожалению эта общая квалификация мало что значит. Потому-что компании нужен не человек, который знает определённый набор вещей, а человек который сможет эффективно работать. Эффективность работы только частично зависит от конкретных знаний.
Поделюсь, пожалуй, к какому варианту пришли в результате мы. И нарадоваться, на самом деле, не можем — после некоторых довольно чувствительных ошибок того периода, когда мы еще приходили на собеседование, зная о кандидате только то, что написано в резюме.
Мы даем домашнее тестовое задание средней сложности. «Мое время стоит денег» и прочая шелуха — отметается еще до первой переписки с ПМ. Вот прямо буквально «сразу нахрен».
Когда нам присылают решение (принимается репозиторий на GH / BB), его вскользь просматривает один из четырех ведущих специалистов. Если оценка ниже, чем ожидается (эта цифра варьируется в зависимости от того, насколько нам нужен человек вотпрямщас) — мы вежливо отвечаем, что, мол, извините. Пояснений к отказу не даем, потому что субъективная оценка одного, пусть и крутого, чувака — это не то, что хочется прямо выплеснуть в лицо соисканту, который старался, но не дотянул. Потеряли половину человекочаса, ну так и ничего страшного.
Если этот Робин говорит, что код годный, его смотрят уже все ведущие, оценивая плюсы, минусы, и выставляя общую оценку. Если большинство за — зовем поговорить (мы релоцируем публику, поэтому это может быть и скайп). Если нет — отправляем кандидату вежливое письмо, куда прописываем и причины отказа (минусы), и что понравилось (плюсы).
На собственно собеседовании мы уже не говорим про код вовсе. Ну, только если речь зайдет. На собеседовании мы продаем себя, а не наоборот. Если претендент уже на этом этапе, мы очень хотим его в команду, а посему — рассказываем, как у нас круто, и вообще. И смотрим немного на то, как он себя ведет (поведение ни разу не становилось причиной отказа, кстати, не знаю уж, то ли все профи ведут себя адекватно, то ли еще что). Это очень важно, что на собеседовании мы уже знаем, с кем имеет дело в профессиональном смысле, и можно порассуждать про архитектуру твиттера, или недостатки эрланга.
И обычно люди наше предложение принимают, даже если им придется переехать к нам из Аргентины (2 примера), Болгарии (1 пример), Кубы, Франции и т. п.
Такие вот дела. В общем, я абсолютно убежден, что домашнее тестовое задание — решает вопрос успешности собеседования на 80%.
Вот уж в самом деле, неоплачиваемые тестовые задания, которые требуют больше получаса времени — "сразу нахрен"
Вот уж в самом деле, неоплачиваемые тестовые задания, которые требуют больше получаса времени — «сразу нахрен»
Вопросы только в том:
1) Есть ли у вас достаточно количество предложений без таковых заданий?
2) Достаточно ли высокий уровень оплаты на этих предложених без таковых заданий?
Если ответ на оба вопроса «да», то тестовые задания можно посылать далеко и сразу.
Но, что-то мне подсказывает, что ответ на оба вопроса «да» только у меньшинства наших коллег.
Ну и мы, разумеется, охотно рассмотрим профиль нс гитхабе — вместо тааого задания.
Сейчас прежде чем мне дают задание вначале стараюсь их туда послать (я про гитхаб веду речь). Но не все соглашаются. Многим на это плевать. Их только своя задача интересует.
И вот решаю я задачу (кстати, наподобие до этого месяц назад делала, но та задача им не подошла). Да, она у меня занимает не час, а 2-3 часа. Т.к. она идет на создание архитектуры проекта. Время на подумать как лучше тоже тратиться. И тут выясняется, что в команде тимлид и один разработчик. И вот тут мне не понятны такие требования. Считаю, что они слишком завышены.
А вы какого уровня специалистов обычно набираете? Есть компании, где разный подход к набору джунов и слабых миддлов и к набору сильных миддлов и выше. Первым тестовое, чтобы на собеседования время не тратить
Ровно наоборот. С джунами мы только про жизнь разговариваем, и так ясно, что ничего внятного он кодом не напишет.
А вот если кто претендует на синьора и почему-то гитхаб у него пуст — явный повод не тратить время на собеседование до того, как взглянуть на код.
А вот расскажите, если я сеньор, работаю, с кучей предложений, почему у меня обязательно должено быть что-то на гитхабе?
Если вы сеньор, то наверняка уже участовали в техническом собеседовании со стороны нанимателя.
И, следовательно, не можете не знать какое огромное количество шлака идет на собеседования.
Сеньором вы станете в глазах нанимателя не ранее, как каким-либо способом сможете предъявить как-то, что вы сеньор. Вашим кодом, верительными грамотами, рекомендацией тех, кому доверяет работодатель… Верить вам просто потому что вы говорите, что вы крут — не разумно.
Пример из жизни:
Вакансия примерно такая, деталей не помню, но суть: «Администрирование Linux, командная строка, удаленные подключения». Оклад — чуть выше среднего по региону.
Идут на эту вакансию люди «я умею ставить Windows, слышал про какую-то Ubuntu, но она же похожа на Windows; ой, что такое маска сети и шлюз IP, нет не знаю» и т.п.
Поэтому нет смысла верить всем и сразу, кто просто пришёл «получать деньги»
Не обязательно доказывать своей репой на ГитХабе. Но хоть чем-то — да надо доказать.
А зачем мне что-то вам доказывать?
Если все так радужно, как вы рассказыаете, и вас все устраивает, — вы найдете миллион достойных работ и без нас. Но если вы почему-то захотите работать именно у нас, даже тут никто не станет воротить нос и все отнесутся с пониманием: вам придется всего лишь написать тест. Если вы и правда señor — займет он от силы часов шесть.
А если вы продолжаете считать, что тест — это унизительно, — тоже прекрасно, просто вы будете работать где-нибудь в другом месте. Win-win.
А вот если кто претендует на синьора и почему-то гитхаб у него пуст — явный повод не тратить время на собеседование до того, как взглянуть на код.
Я знаком с огромным количеством высококлассных специалистов, у которых на гите в открытом доступе ничего нет и это не повод усомниться в их компетенции.
В одной из компаний у меня попросили, просто, прислать пример моего кода. У них, кстати была, на мой взгляд, лучшая система найма, как для соискателей, так и для сотрудников.
Блиц опрос по языку программирования «да»-«нет» и на вменяемость психологом. Высылаете пример саоего кода.
Если проходите, опрос на категорию джун-милд-сеньор с техническим специалистом, опять же по телефону.
Если прошли, тогда уже личное собеседование о найме.
Конечно, главное, что у них в HR дипломированные психологи профессионалы, не просто «девочки». Причем их было человек 3-5 на 200 человек штата. Поэтому анкеты, вместо часов потраченных на отсеивание шлака и только собеседование уже на конкретную позицию.
И не нужны были тесты, т.к. все равно в каждой команде и компании свои стандарты, а от соискателя нужно только понимание и готовность их выполнять. А качество вливание в коллектив, все равно, лучше испытательного срока ничто не покажет.
Я знаком с огромным количеством высококлассных специалистов, у которых на гите в открытом доступе ничего нет и это не повод усомниться в их компетенции.
Ну, а для меня — повод. Как я уже сказал, это просто означает, что мы, наверное, не подходим друг другу; но у вас нет недостатка в предложениях, у нас — в желающих написать тестовое задание — так что никто не ушел обиженным.
в HR дипломированные психологи профессионалы
Люди будут работать в конечном итоге с нами, а не с дипломированными HR'-специалистами, так что нет. Неоднократно случалось, что HR (да, у нас они тоже дипломированные) — браковали кандидата, которого я лично потом отстаивал перд CEO, и — мы по нескольку лет работаем вместе, нарадоваться не можем.
Неоднократно случалось, что HR (да, у нас они тоже дипломированные) — браковали кандидата, которого я лично потом отстаивал перед CEO
Как известно самое интересное кроется в подробностях. Не думал что мнение коммитеров в крутые опенсорсные репозитарии могут так вот ненавязчиво перечеркнуть HR, которые действуют методами граничащими с оккультными мистериями.
За отстаивание специалистов — респект.
Я не только в OSS коммичу, мне еще приходится немного тут код для нужд бизнеса писать (правда, 60% мне удается отстоять и выложить в OSS :)
«Отстаивать» — это сильно сказано. Я изобрел формулировку: «когда мой голос будет рещающим при отборе в Sales, я буду полагаться на HR в вопросах комплектования Tech», и она пока работает.
нежелание тимлида иметь себе же конкурента в лице нанимаемого [из другой ветки]
За это тимлида надо выгнать и ославить на всех столбах. Я лично буду счастлив, если удастся сгрузить половину сложных рутинных задач и заняться тем, что у меня в должности написано (principal engineer — то есть, пишу код в уголочке без ТЗ, который, может быть, пригодится через год).
Если вы и правда señor — займет он от силы часов шесть.
Если Вы Гугл, то к вам наверное стадами тянутся сеньоры. Но если нет, то не так много желающих согласиться делать такое задание.
Вы в курсе, что вы не одни такие? Что у сеньора еще вас таких минимум штук 10. И вы думаете, что он всем будет по 6 часов (а скорее всего не меньше 10 часов) сидеть и делать задания? Тем более вы еще пишите, что если вас оно не устраивает, то нет обратной связи. Это просто супер — сидеть 6-10 часов работать, а в ответ тишина.
Именно об этом и идет речь. Когда ТЗ рассчитано на 1-2 часа это адекватное время. На него можно потрать свое свободное после работы время.
Мы не Гугл, но к нам тянутся.
у сеньора еще вас таких минимум штук 10.
Ну, в нашем стеке — в стране, где я работаю — больше нет компаний, в которых ведущий специалист — language core committer и более-менее известный в коммьюнити человек. Мы открываем много кода в OSS — для многих это тоже очень весомый плюс. А Гугл… ну, в 2020 в Гугл имеет смысл идти либо совсем зеленым джуном, либо Робом Пайком, зачем бы туда пойти крепкому профессионалу — я не могу взять в толк.
Когда ТЗ рассчитано на 1-2 часа это адекватное время.
Я считаю, что 10–12 часов, это адекватное время. Соискатели ищут работу, а не покупают сигареты — возможно (скорее всего) на годы. На этом фоне — инвестиция двенадцати часов не кажется такой ужж прямо невероятной тратой времени. Если вам так не кажется — ну что же, мы не подошли друг другу, не судьба, в этом нет ничего страшного.
вам придется всего лишь написать тест. Если вы и правда señor — займет он от силы часов шестьНе смог пройти мимо.
Правильно ли я понял, что еще до какого-либо собеседования, предполагаемый сеньор должен потратить целый день на решение некоей тестовой задачи? При этом этот рабочий день, в случае отказа, не оплачивается?
Быть может, это просто какая-то очень интересная компания, куда все толпами идут? Зашел в профиль, оттуда по ссылке — да нет, обычный форекс, ничего грандиозного.
Остался лишь один вопрос — вы ведь понимаете, что с таким подходом к вам идут далеко не сеньоры, даже если они говорят противоположное? Ну или я чего-то не понимаю в этом мире.
вы ведь понимаете, что с таким подходом к вам идут далеко не сеньоры, даже если они говорят противоположное
Ну, вам-то оттуда лучше видно, конечно.
Соискатели ничего не говорят. Они показывают профиль GH, или пишут тест. У нас вообще нет формулировки «señor / middle / junior» в предложении. Вообще. Потому что то, что вы называете señor, я, скорее всего, назову average / middle. Например, в 2020 в моем мире не бывает сочетания слов «сеньор» и «фуллстек» в одном резюме. Либо одно, либо другое. Невозможно действительно уметь правильно разрулить миллионы зависимых конкурентных потоков (гринтредов) в кластере и, одновременно, левой рукой создавать сложные компоненты в эмбере.
Но недостатка в кадрах нет, стабильно раз в несколько месяцев мы находим профи (в последнее время — преимущественно в Латинской Америке).
Ну или я чего-то не понимаю в этом мире.
Может быть, и не понимаете. Судя по всему наш стек далек от вашего, и основное, чего вы не понимаете, — это по каким ключевым словам нас находят соискатели. И это совсем не материальные плюшки (хотя они заметно круче среднего по стране, и это — приятный бонус, но люди идут к нам не за этим).
У нас вообще нет формулировки «señor / middle / junior» в предложении. Вообще.
Заглянул на сайт Кантокса. Увидел позиции
— R Developer/Data Scientist
— IT Support Engineer
— User Researcher Specialist (Fintech)
— Quality Engineer
— Ruby/Rails Software Engineer
— Senior Software Engineers (Ruby on Rails/Elixir)
Так что как минимум «Senior» там присутствует.
Ух ты, опять эйчары откатили. Да, признаю, на сайте есть (приложу сегодня усилия, чтобы убрали обратно). Возможно, это сделано для тех, кому впадлу подаваться на что-то, не имеющее титула, не знаю.
Но мы, справедливости ради, через сайт за последние три года никого и не нашли. Обычно, люди пишут мне напрямую.
меня вы всё-равно не возьмёте
Этого я утверждать без взгляда на тест / код не берусь. Если это, конечно, не «Не дожидаясь отказа, свою кандидатуру я снимаю сам» :)
Возможно, это сделано для тех, кому впадлу подаваться на что-то, не имеющее титула, не знаю.
В подавляющем большинстве случаев по личному опыту, если нет титула, то работодатели имеют в виду middle/regular позиции
Тут проблема в том, что я не очень понимаю это разделение в принципе. «middle/regular позиции» — это что значит?
«Мало, что умею, вряд ли буду полезен, но есть 5 лет стажа»? Что-то другое? Что?
У нас, к примеру, в команде нет людей, нуждающихся в присмотре, они что, все синьоры? Джун — понятно, опыта нет, рвение есть. А грань между мидлом и синьором для меня неочевидна вообще. А если она и есть — то это значит, что мидлы вообще никому нафиг не нужны. Если человек успешно вел проект, руководил тремя такими же мастерами и умеет не деплоить некомпилирующийся код — это еще и близко не синьор.
Более-менее общепринято, по-моему, что middle/regular не нуждается в присмотре, а senior могут успешно присматривать за junior.
не нуждается в присмотре, а senior могут успешно присматривать за junior
Ээээ…
Даже суперсиньоры нуждаются в присмотре, иначе не был бы изобретен механизм код ревью.
Если человек не нуждается в присмотре — он может присматривать за джунами.
Да и не брал я никакого горшка.
Яснее, в общем, не стало.
Вот хотел написать после слова "присмотр" в скобках "не путать с код-ревью", но поленился :)
И далеко не каждый, кто может работать сам, может эффективно руководить присматривать за другими.
С другой стороны, довольно часто "лычки" сеньора часто дают тому, кто очень хорошо работает самостоятельно.
Очень бы не хотелось, чтобы у вас сложилось впечатление, будто я цепляюсь к формулировкам — это и близко не так, мне правда самому хочется понять.
Что есть присмотр тогда? Советы? — любому нужны. Парное программирование? — любому нужно. Обмен опытом? «Ты этот таск не копай, ты вон тот копай»? Ежедневные отчеты? Что?
Потому что — повторю — я убежден, что присмотр нужен в равной мере всем. Для ситуации, когда присмотр не нужен (включая чем он там занимается вообще) — придуманы должности «principal engineer» и «distinguished engineer».
Если грубо, то присмотр это обсуждение реализации любой задачи до её начала, постоянная проверка промежуточных результатов (грубо говоря, постоянное код-ревью, несколько раз в день в идеале), объяснения какие-то почему так, а не иначе "у нас так принято", рекомендация литературы и проверки как она усвоена.
Потому что то, что вы называете señor, я, скорее всего, назову average / middle.
Забавно, что у меня полностью зеркальное мнение. Но спорить дальше не буду, так как у меня нет достоверных данных, а собственные ощущения к ним не припишешь.
Например, в 2020 в моем мире не бывает сочетания слов «сеньор» и «фуллстек» в одном резюме.
Фулстек — он тоже с ограничениями. В моей сфере это просто фронт и бек в одном лице. Без мобильных приложений, без админства, без разработки под микроконтроллеры и тд.
фронт и бек в одном лице
Я об этом и говорю. Я от человека, который говорит, что умеет бэкенд — жду адекватного решения задачи «вот этот эндпоинт теперь должен проверять введенное пользователем значение относительно данных, обновляемых со скоростью 10K/sec из постороннего источника».
Для решения этой задачи — нужно уметь обработать такой входящий поток с учетом back pressure, быстро по нему искать в кластере (да, тут ноды кластера становятся зависимыми, и им нужно научиться разговаривать друг с другом, не начать чудить при нетворк сплите, не затроллить логи, справляться с race conditions, и еще много чего).
Хорошо понимать системы, в которых миллионы конкурентных процессов, не так-то просто и вообще, а если еще фронт пописывать — так и вряд ли возможно в принципе.
Или вот еще хороший вопрос, например: как сделать апдейт системы без разрыва долгоживущих соединений. hot code upload — сам по себе не особенно прост (нет, просто ждать, пока старые соединения отвалятся — не вариант, после апдейта все вебсокеты должны использовать свежий код, но рвать соединение нельзя).
Я от человека, который говорит, что умеет бэкенд — жду адекватного решения задачи «вот этот эндпоинт теперь должен проверять введенное пользователем значение относительно данных, обновляемых со скоростью 10K/sec из постороннего источника».
Вы сейчас свою специфику натянули на всех бекендов. Не надо так. Не все пишут высокочастотных роботов, или что вы там делаете.
В подавляющем большинстве случаев нам не надо будет всё то, что вы описали. А что будет нужно, так это подобрать подходящую бд, продумать структуру данных и оптимизировать это дело — тогда она справится с подобной нагрузкой. А если справится база, справится и приложение — его оптимизировать обычно гораздо проще, в крайнем случае горизонтально.
А вот второй вопрос выглядит более интересным для любой предметной области, а не только вашей.
свою специфику натянули на всех бекендов
И да, и нет. Если мы говорим о чем-то, потенциально масштабируемом, то хорошо бы понимать, куда и как мы будем масштабироваться. Горизонтально — далеко не всегда подходящий вариант, и мне по-прежнему хочется, чтобы соискатели представляли себе альтернативы, и умели бы их готовить.
если справится база, справится и приложение
А вот это и вовсе неверно. База очень быстро становится узким местом на больших объемах, даже если вопрос просто в обслуживании банального голосования. change.org на какой-то из последних конференций рассказывал, как они боролись с всплеском голосов на чем-то активном #прямосейчас — и там никакая база не потянет эти самые 10K прилетающих в секунду голосов (без помощи приложения). Да даже если и потянет, не нужно бездумно нагружать базу в этом случае.
Разумеется. А мы увидим, что на человек способен в спокойной обстановке, вместо того, чтобы оценивать стрессоустойчивость и умение выучить алгоритмы.
Кстати, я, чтобы быть совсем честным перед соискателями, сам тоже выполнил это тестовое задание вечерком в свободное время.
Мы всегда очень внятно прогововариваем, что любые вопросы по ТЗ — исключительно приветствуются, у соискателей всегда есть наша почта, бо́льшая половина — задает уточняющие вопросы. Не нужно придумывать проблемы там, где их нет.
Кроме того, хорошо решенная другая задача — тоже будет рассмотрена на предмет того, как написан код. Причем, мы принимаем решения на любом языке, кроме совсем экзотики. Я недавно, например, код на лиспе так получил (но он не прошел дальше, это явно была попытка выпендиться, в лисп соискатель не умел совсем).
Прежде чем жаловаться на собеседование нужно спросить себя, а когда в последний раз вас не взяли в компанию вашей мечты?
Не слышал историй про неадекватное собеседование в сферический гугл в вакууме. Проблема в том что обыкновенные разработчики собеседуются в обычные компании просто для улучшения уровня жизни. Ни компания страстно не ищет именно вас, ни вы не считаете эту компанию работой мечты. Результат — обычное собеседование которое может быть ниже ваших завышенных ожиданий или выше — заниженных.
У меня одного сложилось впечатление, что статьи вида «меня не взяли, а собеседование — хреновое» встречаются в основном только в русскоязычной части интернета?
Конечно, там же все святые и какают только радугой.
А все говно только здесь?
На Хабре были даже переводы.
Например, переведенная статья-жалоба про собеседования с доской, на которой нужно сразу написать решение. Может, кто из завсегдатаев название вспомнит.
Стоит ли жаловаться на собеседования?