Полчаса назад закончилось очередное первичное собеседование, на котором HR задавал странные вопросы: работали ли вы с Kubernetes, работали ли вы с Postgres, работали ли вы с Redis и тому подобное. На собеседованиях я всегда отвечаю честно: с Postgres и SQL работал достаточно плотно, а Redis и Kubernetes знаю лишь теоретически — понимание есть, пару раз пробовал в песочнице, но полноценного опыта нет. В целом, мне кажется, что на определённом уровне для разработчика уже не существует «сложного нового инструмента»: вопрос лишь в глубине понимания, которая пропорциональна времени, проведённому с н��м.
Почему эти вопросы кажутся странными? Потому что непонятно, чего именно хочет HR. Уточнить уровень грейда? Он вряд ли поймёт это, ведь сам не разработчик. В итоге, чтобы пройти первый этап, нужно отвечать на всё «Да». Разберёмся что это значит:
Вы имеете большой опыт работы с ЯП, с основными его инструментами, разбираетесь в кэшировании, экспертно владеете SQL но не имеете опыта с Redis? Не проходите, т. к. разобраться с key-value RAM инструментом это, видимо, очень сложно для разработчика.
Или например вы знаете докер от начала до конца, создаёте контейнеры, docker-compose, возможно работали ещё с какими-либо системами контейнеризации/виртуализации, но так получилось, что не работали с Kubernetes. Тоже не проходите.
И более того, HR даже не понимает, что в его суждениях не так, он просто следует инструкции «Надо чтобы умел редис, кубер, постгрес». Можно предположить что будет, если бы назначили 2 этап собеседования с разработчиками, повезёт, чтобы попались толковые ребята, но часто бывает, что тебя собеседует старший разработчик, который и сам не очень компетентен. А бывает и такое, что в ходе разговора со «старшим программистом» над теоретической задачей ты предлагаешь объективно наиболее лучшее решение, а собеседник отказывается слышать о таком, потому что это не соответствует тому как его учили, не по канону это.
Был у меня аутсорс проект, на котором заказчик что‑то хотел сделать, ПМ и аналитик изложили всё совершенно по другому, понадобилось ещё 2 недели разбора, созвона, чтобы понять, что в итоге хотели делать то? На одном из созвонов пришлось ставить ультиматум: либо делаем всё нормально, либо не делаем совсем, на что ПМ в открытую высказал: да тебе не пофиг ли что делаем, давай, мол закроем задачу, а там дальше пусть сами разбираются. Можно закрывать глаза на это, если бы хоть минимально работающий продукт был, но там вообще ничего не работало.
Ну то есть безумие ситуации: Работник уговаривает надзирающего делать работу нормально, хотя наоборот должно быть. И с подобным я сталкивался, когда работал в большой компании, ПМ брал проект, забивал на него месяца на 3, то есть даже не знаешь, что какая‑то работа должна вестись по проекту. И спустя 3 месяца тебе предъявляют, почему ничего не сделано по проекту, и мол ты виноват.
Настолько всё стало абсурдом в IT‑трудоустройстве, наплыв непонятных людей, которые вообще к техническим специальностям отношения никакого не имеют. Вбухали денег в IT, так оно ведь лучше не стало, а наоборот.