У PERM рівень зарплати — це не «галочка» і не цифра, яку добирають наприкінці. Це логічний каркас справи: рівень має узгоджуватися з обов’язками, мінімальними вимогами, моделлю нагляду/самостійності та контекстом робочого місця. Коли вибір рівня зроблено слабко, справа рідко “ламається” через один рядок. Частіше документи починають описувати дві різні вакансії у ланцюжку PWD → оголошення → Notice of Filing → ETA-9089.
Дисклеймер: матеріал має освітню та інформаційну мету і не є юридичною консультацією. Практика та вимоги відомств змінюються. Для стратегії та документів у вашій конкретній ситуації зверніться до кваліфікованого імміграційного адвоката. Гарантій результату не існує.
Що це за гайд: це не інструкція з рекрутингу і не покроковий мануал з PWD. Це рамка прийняття рішень щодо wage level до старту рекрутингу — щоб не переписувати оголошення, не перезапускати строки та не пояснювати очевидні суперечності «senior duties + level 1 wage» потім.
Три правила, які запобігають більшості проблем із wage level
- Обов’язки важливіші за назву. “Senior” у тайтлі не гарантує Level 3–4, а “Engineer” не означає Level 1–2. Вирішальне — фактична робота.
- Мінімальні вимоги мають бути чесними. Не можна описати автономне “ownership” і водночас робити вигляд, що це entry-роль через занижені вимоги.
- Нульова толерантність до “дрейфу версій”. PWD, оголошення, NOF і ETA-9089 мають розповідати одну історію — без прихованих апґрейдів і пізніх правок.
Як DOL визначає wage level: обов’язки vs вимоги vs галузевий контекст
Wage level — це тест на правдоподібність: чи відповідає обраний рівень позиції, як вона описана? NPWC не “оцінює” компанію — він оцінює, як роль виглядає на папері: особливо перетин між тим, що працівник робитиме, які мінімальні вимоги заявляє роботодавець, і скільки самостійного судження/відповідальності випливає з опису. На практиці проблеми з рівнем майже завжди виникають через змішані сигнали у документах роботодавця.
Простою мовою: якщо в обов’язках є ownership, архітектура, рішення з ризиком, лідерство або “self-directed” робота — спроба подати роль як Level 1 — це не “економія”, а внутрішня суперечність. Вона потім проявляється як тертя в рекрутингу (оголошення не збігаються з PWD), переробка документів або проблеми з довірою при перевірках.
Три групи “сигналів”, які формують логіку рівня
- Обов’язки (duties): виконання під наглядом vs самостійне вирішення задач vs дизайн/ownership систем, стандартів або домену.
- Мінімальні вимоги (minimum requirements): degree/major, роки досвіду, обов’язкові навички/сертифікації, “must” очікування лідерства.
- Контекст (context): модель нагляду, регульоване середовище, складність робочого майданчика (включно з remote/hybrid і multi-location).
Чотири фреймворки вибору: junior / mid / senior / lead
Найшвидший спосіб уникнути пастки — узгодити історію про seniority до подачі ETA-9141. Мета — не “втиснути” роль у рівень, а зробити так, щоб обов’язки, мінімальні вимоги та профіль нагляду читалися як одна узгоджена вакансія. Використайте драбину нижче для калібрування (HR + hiring manager + counsel).
Junior (часто узгоджується з Level 1)
Виконує визначені задачі з тісним супроводом, обмежена автономія, регулярні чек-іни. Мінімальні вимоги зазвичай базові: стандартний degree та/або обмежений досвід. Ключ — навчання й виконання, а не ownership дизайну.
Mid (часто узгоджується з Level 2)
Самостійно веде чітко окреслені результати, вирішує типові/середні проблеми, координується з колегами. Мінімальні вимоги відображають стабільний практичний досвід. Вплив — у межах компонента, але не “задає напрям” для всього домену.
Senior (часто узгоджується з Level 3)
Проєктує рішення, веде складні рішення, менторить інших, працює з невизначеністю. Обов’язки показують незалежне судження й ownership складних компонентів/процесів. Мінімальні вимоги не можуть читатися як entry, якщо duties — senior.
Lead / Principal (часто узгоджується з Level 4)
Веде домен, задає стандарти, керує міжфункціональним ризиком і впливає на стратегію. “Lead” профіль важко узгодити з низькими мінімальними вимогами без втрати правдоподібності. Якщо бізнесу потрібен lead — файл має бути послідовним.
Таблиця: сигнали seniority, які часто конфліктують із низьким рівнем
| Сигнал в duties/requirements | Чому це “штовхає” рівень вгору | Як не створити пастку пізніше |
|---|---|---|
| Architecture / design ownership (задає стандарти, визначає напрям) | Передбачає незалежне судження та відповідальність за системні результати. | Або прийняти senior-наратив, або звузити duties до виконання за усталеним дизайном (тільки якщо це правда). |
| Обов’язкове менторство/лідерство | Вплив на інших працівників — не ознака entry-ролі. | Якщо mentoring “nice-to-have”, не робіть його “must”. Якщо must — узгоджуйте з відповідним рівнем. |
| Регульоване / високоризикове середовище (комплаєнс, безпека) | Часто вимагає доведеного досвіду та автономії через наслідки рішень. | Описувати duties конкретно; не додавати “важку” відповідальність без готовності бути послідовними в документах. |
| End-to-end ownership широкого обсягу | Зазвичай означає низький нагляд та самостійне пріоритезування. | Якщо робота реально розділена, зафіксуйте межі; якщо ні — не “притискайте” роль до entry-наративу. |
| Високий поріг досвіду (багато років / рідкісні навички / обов’язкові сертифікати) | Високі minimums погано узгоджуються з entry-історією. | Прибрати штучні бар’єри, якщо не критично; якщо критично — тримати їх послідовними в PWD, оголошеннях і ETA-9089. |
Red flag: “senior” роль у duties, але “entry” роль у мінімальних вимогах. Це класична пастка «senior duties, level 1 wage». Виправляйте на старті — до першого оголошення.
Оновлення wage year і вікна валідності PWD: де “ламається календар”
Команди часто планують PERM як пряму лінію: отримали PWD, запустили оголошення, подали ETA-9089. Насправді в таймлайні є крихкі “суглоби”: (1) wage data оновлюється за логікою “wage year”, і (2) PWD має вікно валідності. Якщо справа “пливе” — через зміну ролі, зміну робочого майданчика або затримки рекрутингу — ви можете отримати ситуацію, коли PWD вже не відповідає тій вакансії, яку фактично рекрутуєте, навіть якщо на старті все виглядало правильно.
Ключова думка: правильний PWD може стати проблемою, якщо “історія вакансії” змінюється після його видачі. Більшість спорів навколо wage level — це насправді спори про узгодженість: документи перестають описувати одну й ту саму роль.
Як виглядає “wage-year mismatch” на практиці
- Валідність PWD закінчується до подачі ETA-9089 → може знадобитися новий PWD і перезапуск календаря.
- Тихо змінюють duties або minimums (новий обов’язковий інструмент, новий досвід, ліцензія) → виданий PWD вже “про іншу роль”.
- Змінюється історія робочого місця (hybrid cadence, primary location, multi-location) → географія й wage data зв’язок зсуваються.
- Оголошення “покращують” роль для приваблення кандидатів → оголошення стають “старшими” за PWD, виникає суперечність.
Візуалізація — модель робочого процесу (не статистика частот). Найкращий захист — єдиний master-календар: дата видачі PWD + валідність, вікна оголошень, строки NOF та цільова дата подачі ETA-9089 з одним відповідальним координатором.
PWD → оголошення → NOF → ETA-9089: “alignment spine” без розривів
Думайте про PERM як про одну послідовну історію, повторену в різних форматах. Якщо на будь-якому етапі описується інша робота — інші вимоги, інша географія, інший рівень seniority — файл перестає виглядати як контрольований комплаєнс-процес і починає виглядати як набір неузгоджених артефактів. Вибір wage level — частина цієї історії: рівень має бути правдоподібним для duties та minimums.
PWD (ETA-9141) якір
Фіксує SOC, географію, wage level і логіку ставки. Далі все має залишатися узгодженим з цією “версією вакансії”.
Оголошення рекрутингу назовні
Оголошення не повинні “тихо” додавати обов’язкові вимоги або підвищувати seniority понад те, що підтримує PWD.
NOF (Notice of Filing) внутрішній контроль
NOF — внутрішнє повідомлення про ту саму позицію. Розбіжності з PWD або оголошеннями сигналізують “дрейф версій”.
ETA-9089 єдина істина
Фіксує фінальну версію позиції та minimums. Пізні правки (особливо “під кандидата”) — один із найдорожчих способів зламати узгодженість.
Таблиця: типові розриви узгодженості та як їх запобігати
| Де виникає розрив | Як це проявляється | Профілактика до рекрутингу |
|---|---|---|
| PWD vs оголошення | В оголошеннях з’явилися “must” вимоги, яких немає в PWD (ліцензія, мова, інструмент), або duties читаються суттєво “старшими”. | Заморозити канонічний пакет duties + minimums. Публікувати оголошення лише з нього. Будь-які зміни — через повторний review. |
| PWD vs географія | PWD прив’язаний до однієї локації, а фактична робота — remote/hybrid/multi-location з іншою історією primary worksite. | Спочатку зафіксувати worksite narrative (primary location, cadence, відомі альтернативи), потім будувати PWD та тексти. |
| NOF vs оголошення | NOF описує іншу версію вакансії (умови, локація, minimums), ніж оголошення. | Один master-набір текстів для NOF і оголошень; чек-лист, де HR підтверджує текстову ідентичність перед публікацією. |
| ETA-9089 vs все інше | 9089 додає вимоги або локаційні деталі пізно, щоб “підтягнути” під кандидата чи “посилити” роль після рекрутингу. | Політика “no late edits”. Якщо робота реально змінилася — чесний re-sync через оновлений PWD і коректний рекрутинг. |
Для remote/hybrid та multi-location кейсів ця “spine” особливо чутлива: географія тісно пов’язана з wage data. Якщо історія “де виконується робота” змінюється в середині процесу, узгодженість може зламатися навіть без злого наміру.
Помилки HR/менеджерів: «senior duties, level 1 wage» та інші пастки
Найдорожча помилка — не “цифра рівня”, а внутрішня неузгодженість: коли бізнес описує роль із senior-впливом, а HR намагається зробити її “junior” у minimums або текстах оголошень. Так з’являються дві версії вакансії: одна випливає з duties, інша — з minimums і wage level. У PERM дві версії — це майже завжди удар по строках.
Швидка діагностика: якщо hiring manager каже “людина володітиме доменом і прийматиме дизайн-рішення”, а документи читаються як “entry-level з мінімальним досвідом”, файл розповідає дві історії. Виправляйте до старту рекрутингу.
Таблиця: типові невідповідності та як їх виправляти без самообману
| Невідповідність | Чому це ризик | Чистіший шлях виправлення |
|---|---|---|
| Senior duties (ownership, архітектура, лідерство) + entry minimums | Документи описують різні роботи; пояснення потім виглядають як “підгонка”, а не планування комплаєнсу. | Або прийняти senior-наратив послідовно (включно з рівнем), або реально звузити роль і відобразити це всюди. |
| В оголошеннях “must” навички, яких немає в PWD | Схоже на штучне звуження ринку та ламає узгодженість PWD ↔ рекрутинг. | Публікувати оголошення з “замороженого” канону minimums. Якщо “must” справді необхідний — він має бути і в PWD, і в ETA-9089. |
| Історія worksite змінюється після PWD (remote/hybrid/multi-location) | Зсувається зв’язок географії та wage data; файл стає неузгодженим навіть без поганого наміру. | Зафіксувати worksite narrative рано. Якщо змінюється — трактувати як re-sync подію, а не косметичну правку. |
| Пізні правки “під кандидата” | Створює “дрейф версій” і підриває довіру до рекрутингового запису. | Правило “no late edits”. Якщо робота реально змінилася — коректний перезапуск інколи швидший, ніж латання. |
Чек-лист перед рекрутингом: зафіксуйте “історію вакансії” до першого оголошення
Пройдіть цей чек-лист у короткій робочій сесії (HR + hiring manager + counsel). Мета — отримати одну узгоджену “історію”: duties, minimums, worksite narrative та логіку рівня, які залишаються стабільними на всьому шляху PWD, оголошень, NOF і ETA-9089.
1) SOC-fit (duty-first): звірити SOC за обов’язками, а не за “маркетинговою” назвою.
2) Канонічні duties: 5–7 ключових пунктів, що відповідають реальності (без “lead” лексики, якщо роль її не несе).
3) Minimums заморожені: degree/major, роки досвіду, must-навички/сертифікати/мови — лише те, що справді потрібно на вході.
4) Узгоджений рівень seniority: junior/mid/senior/lead — duties і minimums мають читатися однаково (без “senior duties + entry minimums”).
5) Worksite narrative зафіксовано: primary location, hybrid cadence, поїздки, відомі альтернативні локації — одна історія всюди.
6) Власник календаря: дата видачі PWD + валідність, вікна оголошень, дати NOF, ціль ETA-9089 — один master-календар із відповідальним.
7) Тест “одна робота”: якщо прочитати duties + minimums + wage level, це виглядає як одна реальна робота, а не компроміс між версіями?
Пов’язані матеріали на сайті
- multi-location alignment spine — як remote/hybrid та multi-location історія впливає на wage data і чому “де виконується робота” має залишатися незмінним end-to-end.
- recruiting timeline & pitfalls — часові вікна, пастки документування та найчастіші точки, де PERM-рекрутинг зривається.
Офіційні джерела для wage data та правил
- DOL — Foreign Labor Certification Wages: https://www.dol.gov/agencies/eta/foreign-labor/wages
- FLAG — Prevailing Wages (NPWC / ETA-9141): https://flag.dol.gov/programs/prevailingwages
- FLAG — OFLC Wage Search: https://flag.dol.gov/wage-data/wage-search
- FLAG — Wage Data Downloads (wage years): https://flag.dol.gov/wage-data/wage-data-downloads
- BLS — OEWS tables: https://www.bls.gov/oes/tables.htm
- DOL — NPWC PWD policy guidance (PDF): https://www.dol.gov/sites/dolgov/files/eta/oflc/pdfs/npwhc_guidance_revised_11_2009.pdf
- eCFR — 20 CFR Part 656 (PERM regulations): https://www.ecfr.gov/current/title-20/chapter-V/part-656
- eCFR — 20 CFR 656.40 (Prevailing wage determination): https://www.ecfr.gov/current/title-20/chapter-V/part-656/section-656.40
