После поста про матрицу компетенций, решил сформулировать более детально (именно упор на человеческие скиллы). Что главные признаки - не в знании технологий, а в трёх простых вещах.

1. Делится ли решением или просто закрывает тикет? Разница между хорошим и выдающимся инженером - в этой привычке.

📷Обычный инженер решит проблему, закроет заявку и пойдёт дальше.

📷Ценный инженер после решения: 1. Запишет в Confluence инструкцию - “Если такое-то устройство не поднимает L2TP, проверить сначала A, B и потом C”. 2. Скинет ссылку на инструкцию в общий чат. “Коллеги, если столкнётесь - я сделал статью по решению этой проблемы, вот ссылка”. 3. Предложит добавить мониторинг параметра, чтобы проблема не повторилась. Почему это важно… Такие люди не просто “чинят”. Они улучшают среду вокруг себя. Один такой инженер со временем повышает уровень всей команды.

2. Как ведёт себя, когда не знает ответа? Момент истины наступает не когда всё идёт по плану, а когда инженер заходит в тупик.

Три типа реакций: 📷Паника + тишина. Пропадает на час, потом выныривает с фразой “Галя, всё сломалось, стало только хуже”. 📷Тишина + гугление. Молча сидит 3 часа, перебирая англоязычные форумы 10-летней давности. 📷Конструктивный запрос. Через 20–30 минут пишет в чат. “Коллеги, я проверил A и B, но проблема в C. Кто сталкивался?” или “Я не работал с этим, есть у кого пример или документация?”.

Почему это важно! Вторая реакция - норма для миддла. Третья - признак зрелости. Первая - красный флаг.

3. Что говорит о своих прошлых ошибках? Спросите на собеседовании - “Расскажите про ваш самый крупный косяк”. И слушайте.

Токсичная позиция: “Меня подставили”, “Виновата документация”, “Меня не предупредили”. Человек ищет внешнюю причину.

Здоровая позиция: “Я не проверил бэкап перед миграцией, и мы потеряли полдня. После этого я написал чек-лист, по которому мы сверяемся перед работами”. Человек анализирует свою роль и создаёт процесс, чтобы ошибка не повторилась.

Почему это важно! Ошибки неизбежны. Но то, как человек с ними работает, показывает, будет ли он проблемой или активом для команды.

Итог: Технологии меняются. Сегодня нужен Ansible, завтра - Terraform, послезавтра что-то новое. Научить команду новой технологии можно за месяц. А вот привить культуру делиться знаниями, просить помощи и извлекать уроки из ошибок - это работа на годы. Именно на таких “мягких” качествах строится сильная, устойчивая команда, которая не разбегается после первой же серьёзной аварии.