wehub-resource-sync
185 lines
9.5 KiB
Markdown
185 lines
9.5 KiB
Markdown
# Режим: oferta — Повна оцінка A-F
|
||
|
||
Коли кандидат вставляє вакансію (текст або URL), ЗАВЖДИ видати 6 блоків:
|
||
|
||
## Крок 0 — Визначення архетипу
|
||
|
||
Класифікувати вакансію за одним з архетипів (див. `_shared.md`). Якщо гібрид — вказати 2 найближчих. Це визначає:
|
||
|
||
- Які proof points пріоритизувати в блоці B
|
||
- Як переписати summary в блоці E
|
||
- Які історії STAR готувати в блоці F
|
||
|
||
## Блок A — Резюме ролі
|
||
|
||
Таблиця з:
|
||
|
||
- Визначений архетип
|
||
- Domain (platform/agentic/LLMOps/ML/enterprise/backend/frontend/devops)
|
||
- Function (build/consult/manage/deploy)
|
||
- Seniority
|
||
- Формат роботи (віддалено/гібрид/офіс)
|
||
- Розмір команди (якщо вказано)
|
||
- Оформлення (ФОП / КЗпП / ГПД / Дія City — якщо вказано)
|
||
- TL;DR в 1 реченні
|
||
|
||
## Блок B — Збіг з CV
|
||
|
||
Прочитати `cv.md`. Створити таблицю: кожна вимога JD → точні рядки CV.
|
||
|
||
**Адаптовано під архетип:**
|
||
|
||
- Якщо FDE → пріоритизувати proof points швидкої поставки та клієнтської роботи
|
||
- Якщо SA → пріоритизувати системний дизайн та інтеграції
|
||
- Якщо PM → пріоритизувати product discovery та метрики
|
||
- Якщо LLMOps → пріоритизувати evals, observability, pipelines
|
||
- Якщо Agentic → пріоритизувати мульти-агент, HITL, оркестрацію
|
||
- Якщо Backend → пріоритизувати highload, мікросервіси, масштабування
|
||
- Якщо DevOps/SRE → пріоритизувати інфраструктуру, CI/CD, моніторинг
|
||
|
||
Розділ **прогалин** зі стратегією закриття кожної:
|
||
|
||
1. Це hard blocker чи nice-to-have?
|
||
2. Чи може кандидат продемонструвати суміжний досвід?
|
||
3. Чи є портфоліо-проєкт, що закриває цю прогалину?
|
||
4. Конкретний план закриття (фраза для супровідного листа, швидкий проєкт тощо)
|
||
|
||
## Блок C — Рівень і стратегія
|
||
|
||
1. **Рівень у JD** vs **природний рівень кандидата для цього архетипу**
|
||
2. **План "продати senior без обману"**: конкретні фрази, адаптовані під архетип, досягнення для акценту, як позиціонувати досвід
|
||
3. **План "якщо знизять рівень"**: прийняти якщо компенсація справедлива, домовитися про перегляд через 6 місяців, чіткі критерії зростання
|
||
|
||
## Блок D — Компенсація та попит
|
||
|
||
Використовувати WebSearch для:
|
||
|
||
- Актуальні зарплати за роллю (DOU.ua/salaries, djinni.co/salaries, Glassdoor, Levels.fyi, Blind)
|
||
- Репутація компанії щодо компенсації
|
||
- Тренд попиту на роль
|
||
- **Валюта**: уточнити USD чи UAH; для ФОП — net чи gross
|
||
|
||
Таблиця з даними та цитуванням джерел. Якщо даних немає — сказати про це замість вигадування.
|
||
|
||
**Специфіка України:**
|
||
|
||
- Зарплати в українському ІТ переважно в **USD** (навіть для ФОП)
|
||
- Для ФОП 3-тя група: net ≈ gross × 0.95 (5% єдиний податок) + ЄСВ (~1760 грн/міс)
|
||
- Для штатних: net ≈ gross × 0.77 (ПДФО 18% + військовий збір 5%)
|
||
- Врахувати бенефіти: медстрахування, навчання, обладнання
|
||
- Оформлення: КЗпП/Дія City дають більше гарантій, ніж звичайний ФОП
|
||
|
||
## Блок E — План персоналізації
|
||
|
||
| # | Розділ | Поточний стан | Пропонована зміна | Чому |
|
||
| --- | ------- | ------------- | ----------------- | ---- |
|
||
| 1 | Summary | ... | ... | ... |
|
||
| ... | ... | ... | ... | ... |
|
||
|
||
Топ 5 змін CV + Топ 5 змін у LinkedIn/DOU для максимального збігу.
|
||
|
||
## Блок F — План співбесід
|
||
|
||
6-10 історій STAR+R, прив'язаних до вимог JD (STAR + **Рефлексія**):
|
||
|
||
| # | Вимога JD | Історія STAR+R | С | З | Д | Р | Рефлексія |
|
||
| --- | --------- | -------------- | --- | --- | --- | --- | --------- |
|
||
|
||
Стовпець **Рефлексія** фіксує, що було вивчено або що можна було б зробити інакше. Це сигнал сеньйорності — джуніори описують що сталося, сеньйори витягують уроки.
|
||
|
||
**Банк історій:** Якщо `interview-prep/story-bank.md` існує, перевірити, чи є там ці історії. Якщо ні — додати нові. З часом це формує банк з 5-10 майстер-історій для будь-якого питання на співбесіді.
|
||
|
||
**Підібрані й обрамлені за архетипом:**
|
||
|
||
- FDE → акцент на швидкості поставки та клієнтській роботі
|
||
- SA → акцент на архітектурних рішеннях
|
||
- PM → акцент на discovery та trade-offs
|
||
- Backend → акцент на highload, масштабуванні, надійності
|
||
- DevOps → акцент на автоматизації, інцидентах, reliability
|
||
|
||
Включити також:
|
||
|
||
- 1 рекомендований кейс (який проєкт представити і як)
|
||
- Питання-пастки та як на них відповідати (напр.: "Чому пішли з попереднього місця?", "Чому вирішили змінити стек?")
|
||
|
||
---
|
||
|
||
## Пост-оцінка
|
||
|
||
**ЗАВЖДИ** після генерації блоків A-F:
|
||
|
||
### 1. Зберегти звіт .md
|
||
|
||
Зберегти повну оцінку в `reports/{###}-{company-slug}-{YYYY-MM-DD}.md`.
|
||
|
||
- `{###}` = наступний порядковий номер (3 цифри, zero-padded). Щоб виділити цей номер атомарно та уникнути станів гонки, ви ПОВИННІ виконати `node reserve-report-num.mjs` для резервування номера (stdout поверне `{###}`), записати звіт, а потім виконати `node reserve-report-num.mjs --release {###}` для звільнення маркера (sentinel).
|
||
- `{company-slug}` = назва компанії: lowercase, пробіли замінити на `-`, прибрати спецсимволи (наприклад, `Acme Corp` → `acme-corp`)
|
||
- `{YYYY-MM-DD}` = поточна дата
|
||
|
||
**Формат звіту:**
|
||
|
||
```markdown
|
||
# Оцінка: {Компанія} — {Роль}
|
||
|
||
**Дата:** {YYYY-MM-DD}
|
||
**Архетип:** {визначений}
|
||
**Бал:** {X/5}
|
||
**Легітимність:** {tier}
|
||
**URL:** {посилання на вакансію}
|
||
**PDF:** {шлях або "очікується"}
|
||
|
||
---
|
||
|
||
## A) Резюме ролі
|
||
|
||
(повний вміст блоку A)
|
||
|
||
## B) Збіг з CV
|
||
|
||
(повний вміст блоку B)
|
||
|
||
## C) Рівень і стратегія
|
||
|
||
(повний вміст блоку C)
|
||
|
||
## D) Компенсація та попит
|
||
|
||
(повний вміст блоку D)
|
||
|
||
## E) План персоналізації
|
||
|
||
(повний вміст блоку E)
|
||
|
||
## F) План співбесід
|
||
|
||
(повний вміст блоку F)
|
||
|
||
## G) Чернетки відповідей на форму
|
||
|
||
(тільки якщо бал >= 4.5 — чернетки відповідей для форми відгуку)
|
||
|
||
---
|
||
|
||
## Витягнуті ключові слова
|
||
|
||
(список з 15-20 keywords з JD для ATS-оптимізації)
|
||
```
|
||
|
||
### 2. Зареєструвати в трекері
|
||
|
||
Для **нового** запису не редагувати `data/applications.md` напряму. Замість цього записати один TSV-рядок у `batch/tracker-additions/{num}-{company-slug}.tsv` з 8 або 9 колонками через табуляцію:
|
||
|
||
```
|
||
{num}\t{date}\t{company}\t{role}\t{status}\t{score}\t{pdf_emoji}\t[{num}](reports/{num}-{slug}-{date}.md)\t{note}
|
||
```
|
||
|
||
- `{num}` = наступний порядковий номер (ціле число, обчислити з `reports/`)
|
||
- `{status}` = `Evaluated`
|
||
- `{score}` = формат `X.X/5` (наприклад, `4.2/5`)
|
||
- `{pdf_emoji}` = `✅` або `❌`
|
||
- `{note}` = короткий коментар (опціонально, колонку можна опустити)
|
||
|
||
Потім виконати `node merge-tracker.mjs` для злиття в `data/applications.md`.
|
||
|
||
Для **існуючого** запису допустиме пряме оновлення в `data/applications.md` (статус, PDF, посилання на звіт).
|