Глава 08. GitHub и технические следы
Как пользоваться этой главой
Используйте главу как границу безопасности для технического сорсинга. Она помогает найти релевантный сигнал и написать уважительное сообщение, но не превращает нетехнического рекрутера в рецензента кода.
Запомнить одной фразой
Публичный технический след помогает задать хороший вопрос, но не доказывает уровень инженера без профессиональной оценки.
Если у вас задача
| Если у вас задача | Идите в раздел | Что получите |
|---|---|---|
| Понять, что можно использовать | Что можно выводить безопасно | Список допустимых сигналов |
| Не сделать неверный вывод | Чего нельзя выводить уверенно | Границы интерпретации |
| Подготовить калибровку | Чеклист | Вопросы для технического эксперта |
| Написать кандидату бережно | Уважительное сообщение | Формулировку без самоуверенности |
Быстрая карта главы
- Найдите публичный профессиональный факт.
- Отделите факт от интерпретации качества.
- Запишите, что должен проверить технический эксперт.
- Используйте факт только для релевантного контакта или калибровки.
Минимальный старт
За 30 минут выберите 5 технических профилей и для каждого запишите одну безопасную строку:
"вижу публичный факт X; он может быть релевантен роли Y; качество и уровень должен проверить Z".
Если такой строки нет, не используйте источник как основание для контакта.
Принцип
GitHub помогает находить технических кандидатов и писать более релевантно, но не дает нетехническому рекрутеру права оценивать качество кода.
Что можно выводить безопасно
- Человек использует определенные языки программирования.
- Есть публичные проекты или вклады в проекты.
- Возможен интерес к техническому домену.
- Есть README, документация, примеры или обсуждения задач.
- Есть участие в проектах с открытым кодом.
Чего нельзя выводить уверенно
- Качество production-разработки.
- Качество командного взаимодействия.
- Уровень кандидата по количеству stars.
- Текущий уровень по старой активности.
- Готовность к контакту через публичный технический профиль.
Чеклист
- Какие языки программирования повторяются?
- Репозитории личные, учебные, корпоративные или с открытым кодом?
- README понятны и релевантны?
- Активность свежая?
- Есть вклад в релевантные проекты?
- Есть ли проект, который честно связан с ролью?
- Что должен проверить технический эксперт?
Безопасная интерпретация
"У кандидата есть публичная работа по Python и инструментам работы с данными, включая репозиторий про оркестрацию рабочих процессов. Я не оцениваю качество кода, но тема релевантна для калибровки с руководителем data engineering."
Уважительное сообщение
Сэм, добрый день.
Нашел ваш публичный проект про оркестрацию рабочих процессов, когда изучал профили data
engineering.
Не буду делать вид, что оцениваю качество кода, но сама тема связана с ролью про надежные
data pipelines и качество данных.
Если актуально, могу отправить короткий бриф.
Пример
Публичный репозиторий можно использовать как повод для релевантного контакта: сначала назовите наблюдаемый факт, затем свяжите его с задачей роли и предложите короткий следующий шаг. Не делайте выводов о качестве работы только по активности или числу звезд.
Самопроверка
Сможет ли другой сорсер отделить факт из технического профиля от собственной гипотезы о качестве кандидата?
AI-подсказки главы
Полный промпт для безопасного чтения технических следов находится в Приложении G. Перед передачей результата техническому эксперту удалите неподтвержденные выводы и личные данные.
Что забрать из главы / куда перейти дальше
Заберите дисциплину осторожной интерпретации: технический след - повод для вопроса, а не финальная оценка. Если вы готовы писать кандидатам, переходите к Главе 9, чтобы собрать сообщение без давления.
