После 10 лет коммерческой разработки автор Habr / Карьеры пересобрал для себя привычный спор про hard и soft skills: оказалось, что они не живут в разных коробках. Для русскоязычной IT-аудитории это не философия с конференционного бейджа, а вполне рабочий вопрос: как оценивать senior-разработчиков, техлидов и инженеров, которые теперь всё чаще решают задачи вместе с нейросетями.
Как пишет Habr / Карьера, автор сначала видел сильного разработчика почти как универсального бойца: алгоритмы, архитектура, оценка инфраструктуры, понимание требований, способность вести задачу. После работы техлидом фокус сместился: коммуникативные навыки стали выглядеть важнее, но формула «soft важнее hard» тоже не выдержала проверки реальными проектами. В его примерах техническая экспертиза не исчезает за вежливой коммуникацией, а коммуникация не спасает, если инженер не понимает рисков системы.
Первый кейс — большой редизайн планшета для пиццерий, где нужно было не просто обновить интерфейс, а поменять логику подготовки ингредиентов. Система должна была рассчитывать пики спроса для конкретной точки, подбирать объёмы заготовок, учитывать загрузку сотрудников, разные контейнеры, единицы измерения и сырьё. Отдельно планировали подключить весы, чтобы данные о продукте попадали в систему без ручного ввода. Автор, будучи техлидом, быстро сказал, что в ожидаемые сроки команда не уложится. Коллега ответил мягче: мол, посмотрим. По ощущениям автора, именно спокойная реакция была воспринята лучше.
Спустя год весь объём действительно не был готов, но автор честно не превращает это в медаль «я же говорил». Проект продолжался, условия менялись, он сам позже ушёл из компании. Главный вывод тоньше: технический риск он увидел, вероятно, верно, но подал его слишком резко. Чтобы заметить сложность расчётов и интеграции, нужны hard и soft skills одновременно: инженерная насмотренность помогает увидеть проблему, а нормальный разговор — сделать так, чтобы эту проблему услышали и начали обсуждать как общий риск, а не как личный отказ.
Второй пример выглядит почти буднично: внешний сервис шлёт данные на backend через вебхук, команда сохраняет их в базу. На бумаге — принять запрос, записать JSON, разойтись пить кофе. В реальности потребовались согласования с архитектором и DevOps: как компания принимает внешние запросы, нужен ли отдельный публичный сервис, где должна жить логика сохранения, какую базу выбрать. Обсуждали PostgreSQL, DynamoDB и MongoDB. В итоге остановились на одном сервисе за существующим gateway и PostgreSQL, а состояние решения продолжают проверять на ежемесячных встречах.
Этот эпизод хорошо показывает, почему спор про hard и soft skills часто ломается на практике. Выбор базы данных — техническое решение. Аргументы архитектора и DevOps — тоже технические. Но без способности объяснить свою позицию, услышать ограничения платформы и взять ответственность за результат задача не двигается. Формальная роль лида для этого не нужна: даже обычный инженер быстро оказывается в зоне, где код — только часть работы, а остальное состоит из договорённостей, ограничений и последующего сопровождения.
Есть и обратная сторона: хорошая техническая реализация не гарантирует продуктовый результат. В одной из команд автор делал расчёт среднего расхода ингредиентов для автозаказа. Данные были, вычисление работало, идея закрывала понятную боль менеджеров, которые могли забыть заказать продукты. Но дальше продуктовая договорённость не сложилась, интеграция с поставщиками не поехала, а от всей задумки остался только расчёт. Это важная поправка к популярному образу senior-инженера, который якобы должен «просто взять и довести всё до конца». Ответственность за свой участок не равна полномочиям на весь бизнес-процесс.
Отдельный слой — собеседования и ожидания. Автор заранее спрашивал о дежурствах и услышал, что они в основном приходятся на рабочее время. После выхода оказалось, что чем больше сотрудник доступен для дежурств, тем лучше. Формально ответы не обязательно противоречат друг другу, но для кандидата разница заметная: одно звучит как нормальный режим, другое — как ожидание расширенной доступности. Навык задавать вопросы полезен, но он не гарантирует, что обе стороны вкладывают в слова один и тот же смысл.
На этом фоне нейросети не отменяют техническую подготовку, а скорее меняют её цену и форму. Автор признаёт, что сейчас часто разбирается в рабочих задачах с помощью AI и может быстрее входить в незнакомые темы. Но именно базовые знания помогают проверять ответы модели, видеть слабые места решения и не принимать уверенный текст за архитектуру. Для разработчиков вывод неприятно практичный: hard и soft skills больше не стоит продавать как два отдельных пункта в резюме. Рынок всё чаще будет смотреть на связку — понимаешь ли ты систему, можешь ли объяснить риск и способен ли жить с последствиями выбранного решения.