Почему компании не могут пройти собеседование с айтишником

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

Сначала рекрутеры играют в «кто первым вилку назовёт», а потом округляют глаза на средненький рыночный рейт. Есть постоянство в этом мире :)

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

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

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

Почему компании не могут пройти собеседование с айтишником

Да нет у них никаких проблем, все они "могут". Перефразируя Карлина, "HR is fine, the devs are f***d". О чем говорит тот факт, что самые дебильные практики в HR спокойно живут уже десятилетиями? О том, что всем и так норм. Большинство из нас побухтит на хабре, а на деле все равно покорно пройдет первичный собес, где эйчар будет сбивчиво по бумажке читать вопросы а ля "что такое полиморфизм". А потом мы пойдем писать алгоритм Дейкстры на вакансию, где нужно перекладывать джейсоны. Реально переломить ситуацию можно массовым бойкотом контор, где вращают деревья на доске и вот это все. Вот, чем стоило бы заниматься небезызвестному Профсоюзу вместо написания истеричных пассажей.

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

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

• Имеет ли человек вообще опыт с агрегацией чего-либо, не только перекидывание джейсонов

• Понимает ли какие есть косяки с памятью и скоростью и почему нельзя просто сразу всё выполнить

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

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

• И да - кандидаты обычно умещаются как раз в 40 строк, но эти строки и шаги улучшений говорят о многом

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

По итогу на следующем этапе имеем как минимум двух человек, округляющих глаза друг на друга

Терпеть не могу хайринг на аутсорсе. Было такое на прошлой неделе, кстати. Я обычно первые 7-8 минут трачу, чтобы рассказать о проекте, чтобы человек понимал, почему дальше будут те или иные вопросы. Рассказываю, вижу чем дальше, тем больше недоумения в глазах. Спрашиваю - что не так? Выясняется, что человек ищет вакансию только под Ангуляр и ничего больше не рассматривает, а у нас Ангуляр ни на одном из 150 проектов не используется и в описании вакансии не упоминается. Извинился, разошлись. HR объяснить мне, где у него голова, так и не смог. Видимо её нет.

Зачем задавать вопрос «что такое цикл» человеку с десяткой лет профильного опыта?

Вы как-то исходите из предположения, что все люди в мире адекватны.

Отвечая на вопрос "заяем задавать базовые вопросы?". Потому что у кандидата 10 лет может быть в смежном стеке, а написать в cv он забыл. Потому что, может быть он занимался однотипными задачами и знает только один фреймворк, а на любой вопрос про базовое строение языка плывёт. Потому что он 10 лет сидел и занимался одним и тем же или просто его работа в компании не была никому интересна и он не развивался. Потому что резюме может быть в конце-концов чужим (было и такое в практике). Поэтому базовые навыки проверяются всегда. Знаешь - молодец, потратили на это 5 минут, пошли дальше. Опять же, случай из недавних, у человека 11 лет опыта, причём по резюме выглядит солидно. Но ответы на вопросы про процессы или архитектуру - ноль (ответы вида "я не знаю") и при попытке посмотреть навыки кодинга человек не может написать нормально перебор коллекции. Неожиданно, но бывает и такое.

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

Во-первых, мы опять же не знаем историю появления этого репозитория - чужой он, свой, написан самим человеком или с помощью, всё равно придётся по нему разговаривать. Поэтому оффлайн это не заменит. Во-вторых, оффлайн задача это проверка умения работать самостоятельно - вот тебе гугл, вот задача, которой нет в гугле в прямом виде, составь из всех производных нужное решение. Если человек в оффлайн не способен решить базовые задачи - нагуглить и синтезировать - то как он будет дальше работать? В-третьих, это экономия времени нанимающего (да, извините, это так). Чтобы просто открыть репо- нужно 5 минут, да. За них вы успеет увидеть кодстайл конкретного одного проекта и всё. А вот чтобы сделать выводы о качестве решения, нужно будет перешерстить несколько репо (обычно шлют ещё и несколько ссылок), найти более-менее сложный, разобраться в задаче, которую решает это приложение, понять архитектурные решение, прикинуть узкие места, пройтись по коду, найти эти узкие места, понять как человек это решил, наметить вопросы... Полчаса на репо. А у тебя 15 таких резюме в день, и в каждом n репосов. Сорри, но нереально.

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

Задачки с литкода на кручение деревьев

Я не совсем понимаю смысл этих задач.

О существовании структур, алгоритмов и задач на них я узнала на собесе с Контуром, когда они меня попросили решить одну из задач, до этого 6 лет в программировании я как-то обходилась без них.

С дизайнерами тож весело, ui/ux в частности. Три студии из 4х говорят: портфолио ок, резюме ок, давайте ещë тестовое сделаем. Вот у нас новый проект такой есть, но интерфейса нет там, разработайте, плз, с нуля финальный дизайн ui. И ничего, что это самый сложный и напряжëнный этап работы, с кучей итераций. Где-то неделя адовой работы, с паром из ушей и без гарантий успеха в этот срок. Некоторые студии годами не могут решить этот вопрос. Ну или можно быстро накидать красивую, но бессмысленную шляпу, аля дриббл. Что тож такой себе вариант. Если попытаться объяснить это работодателю, описать этапы, трудозатраты на каждый этап, выходят два варианта. 1. мы не торопим), 2. Неловкая ситуация из серии "А как быть тогда?". Вобщем мне проще вежливо отказаться. Кстати, если отправить незаконченный результат, со словами, что вот этот объëм работы занял столько то времени (скажем 3 дня), может последовать фидбэк из серии "программист оценивает дизайн, или наоборот". Я так однажды читая фидбэк, чуть лоб себе не разбил фейспалмом)

У меня на полном серьёзе по телефону спросили чем отличается хаб от свитча. Я просто не поверил своим ушам и объяснил своими словами. Оказалось что ответ про первый и второй уровень OSI вполне прокатил))