Если у кандидата сильный GitHub — нужно ли его тестировать? ❓ На первый взгляд кажется, что сильный GitHub-профиль снимает все вопросы: открытые репозитории, аккуратная история коммитов, продуманная структура проектов, участие в open-source — все это формирует ощущение зрелости и инженерной состоятельности. Но именно здесь и возникает методологическая ловушка, потому что GitHub демонстрирует результат работы, но практически не раскрывает процесс принятия решений, который и определяет реальный грейд специалиста. 1️⃣ GitHub показывает артефакты Он фиксирует финальное состояние системы, но не показывает, какие альтернативы рассматривались, какие компромиссы были приняты и осознавал ли разработчик долгосрочные последствия выбранной архитектуры. Мы видим код, но не видим контекст: ограничения по срокам, влияние продуктовых требований, давление легаси, сложность интеграций. А именно контекст зачастую отличает Middle от Senior, поскольку уровень определяется не объемом написанного кода, а качеством инженерного мышления в условиях ограничений. 2️⃣ GitHub не позволяет достоверно оценить зону ответственности кандидата Оценка профиля всегда субъективна: ➖Кто писал большую часть кода? ➖Это самостоятельная работа или командная? ➖Какова роль кандидата в проекте? ➖Насколько проект соответствует реальному уровню сложности? Без стандартизированной методики GitHub превращается во впечатление. А оно — плохой инструмент для определения грейда. 3️⃣ Переносимость навыков Человек может быть сильным в создании изолированных сервисов, но испытывать затруднения при работе с распределенной архитектурой, высокими нагрузками или сложной доменной логикой. Эти различия редко видны по публичным репозиториям, зато проявляются мгновенно, когда разработчик сталкивается с задачей, требующей анализа чужого кода, поиска скрытых зависимостей и оценки рисков масштабирования. Поэтому тестирование — это не попытка «проверить очевидное» и не недоверие к портфолио, а способ перевести субъективное впечатление в измеряемую модель компетенций.