🪴 Сад Знаний

Search

SearchSearch

Что Джуну Без Опыта Показать На Собеседовании Вклад В Open Source Или Пет-Проекты Хабр

Jan 15, 2025, 4 min read

Что Джуну Без Опыта Показать На Собеседовании: Вклад В Open Source Или Пет-Проекты / Хабр

rw-book-cover

Metadata

  • Author: Артур
  • Full Title: Что Джуну Без Опыта Показать На Собеседовании: Вклад В Open Source Или Пет-Проекты / Хабр
  • Category:#articles
  • Document Tags: career foss
  • Summary: Привет! Меня зовут Артур Домбровский, и я наставник и соавтор курса «Java-разработчик» в Яндекс Практикуме. Зарабатываю на жизнь программированием уже более 7 лет, из которых больше трёх провёл в…
  • URL: https://habr.com/ru/companies/yandex_praktikum/articles/725694/

Highlights

  • Идеальная тема для интервью. Все изменения в проект с открытым исходным кодом, внесённые кандидатом, публичны и видны всем. Их корректность проверена сообществом с высокими требованиями к качеству кода, этой библиотекой или сервисом пользуются люди. Внесённые изменения требовали работы мысли, о которой мне захочется поговорить во время интервью. Мне интересно, почему было принято такое решение, какие альтернативы были рассмотрены, как была найдена причина данного бага. (View Highlight)

  • Вторая проблема — необходимость удостовериться, что показанный пет-проект хотя бы работает. Хорошо, если его хотя бы можно потрогать, но бэкендеры часто не хотят тратить время и силы на фронтенд, а бэкенд — скрытая от глаз часть айсберга. В результате пет-проекты превращаются в работу в вакууме. Проект в лучшем случае запущен единожды, а в худшем — это просто код на GitHub. В результате проверить его работоспособность становится проблематично. (View Highlight)

  • Как правило, начинающий разработчик не обладает достаточными навыками, чтобы создать такой проект полностью самостоятельно. Скорее всего, это будет воплощение созданного кем-то учебного проекта или туториала. Даже при наличии оригинальной идеи большая часть технических решений будет выбрана по принципу «так было написано». (View Highlight)

  • Идеальное замещение реального опыта работы. Open source даже лучше реального опыта, потому что то, что делал кандидат, доступно для просмотра, а не скрыто в приватных репозиториях и под кипами NDA. Тот факт, что за этот код не заплатили, меня мало волнует. (View Highlight)

  • Требует большей глубины навыков. И эти навыки будут ближе к коммерческой разработке: взаимодействие с инфраструктурой, запуск проекта, тестирование, создание пулл-реквеста, отработка замечаний. Как правило, внесение изменений требует обоснования, которое невозможно без глубокого понимания механизмов работы проекта и вовлечённых технологий. Это один в один то, чем занимаются разработчики в реальных проектах. (View Highlight)

  • Обязательно включайте в резюме проекты с открытым исходным кодом. Это реальный опыт работы, просто за него не заплатили. С моей точки зрения, open source будет смотреться на порядок весомее, чем портфолио из очередных CRUD-сервисов. (View Highlight)

  • Дальше клонируйте этот репозиторий, попытайтесь воспроизвести проблему и решить её. Даже если решить не получится, вы прокачаете свои навыки. Даже первые несколько шагов — склонировать репозиторий и запустить его — уже хороший опыт, похожий на реальный проект. Об этом можно рассказать на собеседовании. (View Highlight)

  • Возможно, имеет смысл отправиться в средние по популярности проекты — там будет меньше конкуренции и больше простых нерешённых задач. Если репозиторий за один день лайкнули 500 раз, то вокруг него крутится много контрибьюторов. Новичку лучше выбрать менее конкурентный проект. (View Highlight)

  • В open-source-проектах джуну важно показать максимальную самостоятельность. Пройдя весь этот путь, он покажет, что знает, что такое Git, умеет создать pull request и достаточно знает про Java, чтобы запустить проект и внести в него какие-то значимые изменения. А если он чего-то не знал, то самостоятельно нашёл решение. Это максимум, который я могу требовать от джуна. (View Highlight)

  • Правильно сформулированный вопрос в IT состоит из таких пунктов: (View Highlight)

  • Вопросы, заданные в таком формате, демонстрируют уважение к отвечающим: (View Highlight)

  • С моей точки зрения (только с моей, не с позиции Amazon или Wise), джун — это самостоятельный разработчик, которому можно отдать на откуп компонент с довольно чётко прописанным ТЗ. А дальше, при минимальной помощи и поддержке от других членов команды, он должен довести работу до конца. Это человек, которому я могу сказать, в каком месте у нас баг, при каких условиях он появляется, и попросить решить. Джун сделает пусть не идеальное, но самостоятельное решение. Если не сделает, то это не джун, а человек, который ещё только учится. (View Highlight)

  • Перейти из стадии «просто учится» в джуны можно как раз с помощью open source. Такие проекты — это доказательство, что человек стал самостоятельным. Следующей ступенью эволюции будет мидл — специалист, которому можно поручить дизайн компонента, работающего на уровне всего проекта. А следующая ступенька — уже синьор. Он видит много сервисов и может работать над их взаимодействием, над всей системой. Это довольно условные разграничения, но самостоятельность нужна в любом случае. (View Highlight)

  • У джунов же горящие глаза и рудиментарные навыки, а будет ли из них толк — становится понятно через полгода. И часто оказывается, что толка не будет. Чем больше продемонстрируете доказательств вашей самостоятельности, тем лучше для вас. (View Highlight)

  • Выводы (View Highlight)

    • С точки зрения работодателя, наём — это риск. Дорогой риск. Поэтому в найме false positive лучше, чем false negative. Лучше не взять потенциально хорошего программиста, чем нанять плохого. (View Highlight)

📂 Articles | Последнее изменение: 23.11.2024 16:34

Graph View

Backlinks