init
This commit is contained in:
commit
d295c7f139
1527 files changed
+270726
No files matched your search
@@ -0,0 +1,184 @@
|
||||
# Режим: 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, посилання на звіт).
|
||||
Reference in new issue
Block a user