Зачем подгонять проект под вакансию
Потому что нанимающие сравнивают буквально. Если в вакансии нужен определённый набор технологий, а у вас в проекте другой, вас отсеют раньше, чем прочитают описание, — даже если по сути вы справитесь.
Это не придирка. У человека сорок откликов и час времени: он ищет совпадения.
Как читать вакансии
Возьмите пять-семь вакансий, на которые хотите откликаться, и выпишите требования в таблицу. Через полчаса станет видно:
- Что встречается везде. Это обязательный минимум. Именно на этом должен быть ваш проект.
- Что встречается через раз. Приятное дополнение, добавьте если легко.
- Что упомянуто один раз. Не гонитесь.
Обычно в основе оказывается язык, один фреймворк, база данных и что-то для развёртывания. Этого набора хватает.
Как это применить
Стек берите из пересечения. Не тот, что моднее, а тот, что просят.
Область тоже учитывайте. Идёте в компанию, которая делает сервисы для бизнеса, — сделайте что-то с учётом, отчётами и правами доступа, а не игру.
Покажите то, что просят проверять. Если в вакансиях упоминают тесты — напишите тесты. Если контейнеризацию — разверните в контейнере. Это дешевле, чем кажется, и снимает сразу несколько вопросов.
Чего не надо делать
Не пишите проект под каждую вакансию отдельно — не хватит жизни. Достаточно одного проекта на основном стеке, который закрывает большинство требований.
И не раздувайте список технологий ради галочек. Три технологии, которыми вы правда владеете, лучше десяти, про которые вы читали.
Что писать в отклике
Свяжите проект с требованиями напрямую: «в вакансии нужны такие-то вещи — вот проект, где я делал именно это, ссылка». Одна фраза, которая экономит читающему время и резко повышает шанс, что ссылку откроют.
Что добавляет вес
Если проект командный и ваш вклад подтверждён — с указанием, с чем именно вы работали, — совпадение по технологиям перестаёт быть словами из резюме. Оно становится проверяемым: видно, кто это подтвердил и на чём вы там правда работали.
Хватит читать — пора делать
На CohortX можно найти команду под пет-проект и получить тот самый опыт, о котором спрашивают на собеседовании.
Похожие статьи
- Presenting a repository so people actually look at itNaming, structure, commit history, what to hide and what to pin — the small things that decide whether your code gets opened.
- Как оформить репозиторий, чтобы его смотрелиНазвание, структура, история изменений, что скрыть и что закрепить — мелочи, которые решают, откроют ваш код или нет.
- A README that makes people open the projectWhat to put in your repository's README, in what order, and why without it nobody looks at the code.