Job Description Writing Guide for Engineering Managers

Написання опису роботи інженера-програміста (JD) є одним з найважливіших — і найчастіше погано виконаних — комунікаційних завдань для інженерного менеджера. Добре написаний JD приваблює правильні кандидати, фільтрує погано підходящі заявки, і сигналізує про якість вашої інженерної культури. Погана JD або загальна, вводяча в оману, або наповнена жаргоном. У цьому підручнику показано, як написати ефективні JD англійською мовою.

---

Опис роботи

Опис роботи слугує трьом аудиторіям:

1. ** Кандидати ** — допомагає їм самостійно вибирати, чи брати участь у програмі, чи ні, на основі реальної інформації
2. ** Команда найму ** — підбирає співбесідників за тим, що ви шукаєте
3. ** Ваша організація ** — забезпечує послідовне визначення ролі

JD також є маркетинговим документом — для кандидатів з декількома пропозиціями, якість вашого JD сигналізує про якість вашої команди.

---

Структура опису роботи

1. Назва посади

Заголовок має бути точним і мати можливість пошуку.

** Хороший опыт: **

• Використовуйте стандартні для галузі посади: * Інженер сервера *, * Інженер програмного забезпечення персоналу *, * Інженер надійності сайту *, * Інженер даних *
• Вкажіть ступінь старшинства: * Старший*, * Персонал*, * Головний*, * Молодший*
• Додатково додайте технологію, якщо вона є центральною: * Старший інженер Go Backend *

Не робіть цього

• Внутрішні кодові імена: “Level 4 IC” (без значення для кандидатів)
• Надмірні назви: “Full Stack Ninja”, “JavaScript Wizard”
• Неоднозначний рівень: «Інженер» без сигналу про старшинство

---

2-й. Про роль (2-4 речення)

Коротке, чесне резюме того, що робить ця роль - не маркетингова копія.

Шаблон:**

“Ми шукаємо старшого інженера, щоб приєднатися до команди платежів в Acme Corp. Ви будете розробляти і будувати послуги обробки платежів, які обробляють 50 млн євро щоденних транзакцій, тісно співпрацюючи з продуктом і інфраструктурою. Це старша роль IC зі значною сферою впливу на архітектуру системи і практику команди. ”

** Що включати: **

• Команда / область продукту
• Що інженер буде будувати або володіти
• Обсяг (старший інженер, технічний керівник, менеджер, тощо)

---

Відповідальність

Список того, що людина насправді зробить. Використовувати пункти. Використовувати активні дієслова у теперішньому часі.

** Дієслова: **

• • Розробка і впровадження… *
• Власть и поддержание…
• • Співпрацюйте з [X], щоб… *
• *Відповідає за технічне керівництво… *
• • Визначити і впровадити… *
• • Внесіть свій внесок у… *
• Ментор молодших інженерів по…
• • Участвуйте в дежурной ротации… *

** Приклад (старший інженер сервера): **

- Design, implement, and maintain backend services for the Payments platform
- Lead technical design for new features and review designs from other engineers
- Own operational reliability for your services — participate in on-call rotation
- Collaborate with product managers and designers to refine requirements
- Mentor mid-level engineers through code review and pair programming
- Contribute to engineering-wide practices: code standards, tooling, processes

Анти-патерни: ❌ “Будь відповідальним за розробку сервера” — занадто неочевидно ❌ Перелік 15+ обов’язків — кандидати припиняють читати ❌ “І інші обов’язки, як це передбачено” — сигналізує, що JD не було продумано

---

Вимоги

Відокремити ** потрібні ** навички від ** хороших для здобуття ** навичок. Це має більше значення, ніж більшість менеджерів розуміють — дослідження показують, що чоловіки звертаються, коли вони відповідають 60% вимог; жінки, як правило, звертаються тільки тоді, коли вони відповідають 100%. Покладання занадто багато пунктів у розділ « обов’ язкові » відштовхує хороших кандидатів.

** Структура: **

## Requirements (Must Have)
- 4+ years of experience in backend software engineering
- Proficiency in at least one of: Go, Java, Kotlin, Python
- Experience designing and operating distributed services in production
- Strong understanding of databases (relational and/or NoSQL)
- Experience with RESTful API design

## Nice to Have
- Experience with payment systems or financial services
- Familiarity with Kafka or other event streaming
- Experience with Kubernetes and container orchestration
- Knowledge of PCI DSS requirements

** Мова для вимог: **

• • « 4+ років досвіду роботи у… » * — вкажіть рівень досвіду, а не лише роки
• “Вміння…” — для основних навичок
• • “Знайомство з…” * - для вторинних або хороших навичок
• • “Досвід проектування і експлуатації…” * — визначає досвід виробництва, а не лише знання

Не робіть цього ❌ Рік досвіду з певними технологіями (* “5+ років досвіду React” ) - React не існує так довго для деяких технологій; це карає зміну кар’єри ❌ Вимоги до освіти (“Bachelor of Science in Computer Science required”) — якщо не дійсно потрібні ❌ Жаргонні акронімі без пояснення (“Містить CQRS, DDD, SAGA, ACID, CAP”) ❌ Суб’єктивні вимоги (“захоплюється технологіями”*, “розробник-рок-зірка”)

---

5-й. Що ви будете робити з цим (Tech Stack)

Будь ясно про технологічний стек - кандидати повинні розуміти, з чим вони будують.

** Приклад: **

## Tech Stack
- Languages: Go (primary), Python (tooling, ML pipelines)
- Infrastructure: AWS (ECS Fargate, RDS PostgreSQL, SQS)
- Observability: Datadog, PagerDuty
- CI/CD: GitHub Actions, ArgoCD
- Data: Kafka for event streaming, Redis for caching

---

6-й. Про команду

Описати, як працює команда — розмір, структуру, практику. Кандидати вибирають команду так само, як і роль.

** Приклад: **

“Команда платежів складається з 7 інженерів, 1 ЕМ і 1 ПМ. Ми дотримуємося гнучких практик з двотижневими спринтами і щотижневим переглядом архітектури. Половина команди віддалена. У нас є сильна культура документації і проводимо бездоганну пост-мортну експертизу після інцидентів»

---

7-й. Компенсація та вигоди

Будь прозорою. Диапазони зарплат у JD все частіше очікуються (і законно вимагаються в деяких регіонах). Сховати їх - це марнувати час.

** Приклад: **

«Заробітна плата: €80,000 – €110,000 залежно від досвіду. Переваги включають: приватне медичне страхування, 2000 євро щорічного бюджету навчання, віддалений доступ з опціональним доступом до офісу в Празі, 25 днів PTO

---

Мовні традиції

Активні, конкретні дієслова

Weak	Strong
be responsible for	own, lead, drive, design, build
work on	implement, develop, maintain
help with	contribute to, support, enable
have experience in	proficiency in, strong background in

Інклюзивний контрольний список мов

• Уникайте гендерної мови («він або вона» → «вони»)
• Уникайте культурно- специфічних ідіом (« рок- зірка », « ніндзя », « інстинкт вбивці »)
• Використовуйте * “досвід у” * замість * “досвід у” * для неосновних вимог
• Не виключайте занадто багато вимог (* « має працювати під час запуску » *)

---

Інженерні помилки роблять і менеджери

Копирование и вставление из другого JD

Результатом є загальні, не надихають описи, які не відображають вашу справжню роль або команду.

Перебільшення інструментів, недооцінка результатів

“5 років Kubernetes” має менше значення, ніж “досвід роботи з контейнерними сервісами в масштабі виробництва.”

Не включая команду по найму

JD повинна відображати те, що респонденти насправді оцінюють — невідповідність призводить до непослідовних інтерв’ю.

Занадто високі вимоги до стажу

• « Потрібно старший рівень » * для ролі, яку можуть добре виконувати молодші або середні інженери — зменшує кількість кандидатів без жодної причини.

---

Practice

Розширте свій словник з найму та управління за допомогою ** Набір вправ з англійської мови для інженерного менеджера ** і перегляньте всі ресурси за допомогою ** Інженерно-технічний інститут **.

Невідомі мови: мова, що не має офіційного статусу

Написання опису роботи інженерного менеджера не просто про перелік технічних навичок; це про передання очікувань, сприяння захопленню і залучення правильного таланту. Для розробників, які створюють свій професійний словник англійської мови, це може здатися неймовірно пригнічуючим. Нюанси формулювання - особливо навколо зворотного зв’язку про продуктивність, співпраці і стратегічного напрямку - можуть бути значною перешкодою для входу. Давайте розглянемо деякі конкретні проблеми, з якими стикаються носії мови, для яких англійська не є рідною, і запропонуємо практичні стратегії для поліпшення.

Однією з ключових областей є уникнення надмірно прямої або потенційно критичної мови. Фрази на кшталт «Вам потрібно поліпшити свій код» майже гарантовано викликають оборону. Замість цього, розгляньте можливість конструктивного відгуку. Наприклад, під час коментаря щодо перегляду коду у зв’ язку з запитом на звантаження ви можете сказати: « У цьому розділі можна було б додати пояснення щодо взаємодії з шаром бази даних. Можливо, додавання короткого пояснення потоку даних збільшить його читабельність і зможе полегшити підтримку. » Цей пункт зосереджено на * роботі *, а не на безпосередньому оціненні вміння розробника. Аналогічно, у повідомленнях Slack, де обговорюються пріоритети проекту, не вказуйте « Ви не дотримуєтесь терміну ». Замість цього спробуйте: « Давайте обговоримо, як ми можемо змінити часову шкалу для цієї функції, щоб вона відповідала загальним цілям спринту. Чи можемо ми переглянути сферу дії або, можливо, делегувати деякі завдання?” Використання таких фраз, як “досліджуємо”, “як ми можемо підійти”, і “чи можемо ми розглянути” демонструє дух співпраці і запрошує до обговорення, а не видачі наказу.

Іншою поширеною пасткою є використання надмірно формальної мови, яка відчувається неприродною на робочому місці. Хоча точність важлива, прагнення до розмовної ясності завжди буде краще резонувати з потенційними кандидатами. Замість написання «Команда потребує вміння в гнучких методологіях», ви можете сказати: «Ми працюємо в гнучкому середовищі і заохочуємо співпрацю та ітераційний розвиток». Під час написання PR-описів, зосередьтеся на * тому, * чого * зміна досягає, а не просто детально * як *. Наприклад, замість « Впроваджено новий механізм кешування », скористайтеся « Покращено швидкодію програми за допомогою введення шару кешування, щоб зменшити навантаження на базу даних під час періодів пікового використання ». Таким чином ви зможете підкреслити реальні переваги роботи.

Нарешті, пам’ятайте, що словниковий запас формується через постійне навчання і практику. Заохочуйте розробників читати внутрішню документацію, брати участь у обговореннях команди і активно шукати зворотній зв’ язок щодо їх письмового спілкування. Не вагайтеся запропонувати підтримку — коротке пояснення ідіомного виразу або запропонована альтернативна фраза може бути надзвичайно цінною для підвищення впевненості і покращення загальної ясності. Створення культури відкритого спілкування має надзвичайно важливе значення; створення простору для питань і ніжних виправлень значно сприяє успіху вашої команди.