USCIS Policy Manual: «judging the work of others» — как понять критерий и почему внутреннее ревью кода компании не подходит

Что USCIS понимает под «Judging the Work of Others»

В логике USCIS формулировка judging the work of others означает не общий профессиональный авторитет, а наличие у заявителя функции оценки чужой работы, которая имеет самостоятельное значение и подтверждается документально. Речь идет о ситуациях, где специалист не только производит собственный результат, но и анализирует, проверяет, ранжирует, допускает, отклоняет, утверждает или иным образом влияет на судьбу результата, созданного другими.

Этот критерий важен для USCIS, так как он показывает уровень признанной экспертизы, доверия к суждению заявителя и его позицию в профессиональной иерархии. Иными словами, критерий оценивает то, насколько третьи лица или институты полагаются на его оценку при принятии решений.

В иммиграционной практике США этот сюжет обычно возникает там, где USCIS оценивает опыт, квалификацию, уровень самостоятельности и профессионального влияния заявителя через его реальные обязанности. Это особенно заметно в кейсах O-1 и EB-1, когда петиция строится на доказательстве того, что специалист находится выше уровня рядового исполнителя. Если из документов видно, что человек регулярно выступал в роли рецензента, члена жюри, технического оценщика, reviewer для конференций, judge на хакатонах, эксперта в grant review panel или официального экзаменатора, это поддерживает тезис о признании его компетенции извне.

Здесь важно не смешивать два разных явления. Внутреннее качество работы и формализованная оценка работы других — не одно и то же. Внутри компании разработчик может смотреть pull request коллеги, оставлять комментарии, участвовать в code review, обсуждать архитектурные решения или проверять соответствие стандартам команды. Сам по себе такой процесс обычно воспринимается USCIS как часть обычного производственного цикла. Он показывает, что специалист вовлечен в работу команды, но не всегда доказывает, что ему была поручена именно оценочная функция в смысле критерия.

Иное дело — когда из доказательств следует, что заявитель имел официальную или квазиофициальную роль, в рамках которой его суждение влияло на следующий этап процесса. Классические признаки здесь:

заявитель входил в состав жюри, review committee, selection panel или экспертного совета;
его оценка использовалась для отбора победителей, участников, докладов, проектов, публикаций или кандидатов;
он обладал полномочием рекомендовать допуск, отклонение или доработку результата;
его review было частью формализованной процедуры, а не неформального командного обсуждения;
имеются документы, подтверждающие, что именно его экспертное мнение учитывалось при принятии решений.

Именно поэтому внутреннее peer review кода компании часто не работает как сильное доказательство по этому критерию. Если review — это стандартная обязанность senior engineer или team lead в рамках delivery process, USCIS нередко видит в этом обычную операционную функцию, а не отдельный показатель экстраординарного статуса. Чтобы такое доказательство имело вес, нужно показать больше, чем участие в ревью: например, что заявитель был официально назначен technical approver, release gate owner, architecture review board member, security sign-off authority или членом внутренней комиссии, без решения которой продукт, релиз или проект не мог двигаться дальше.

Ключевой вопрос для анализа всегда один: заявитель просто помогал коллегам улучшить результат — или его оценка имела формальное значение и последствия для допуска, отбора, утверждения либо отклонения чужой работы.

Важнейшее различие проходит по линии последствий оценки. Если комментарии в ревью носят консультативный характер и остаются частью горизонтального взаимодействия в команде, это слабая позиция. Если же заявитель действует как признанный оценщик, и его заключение влияет на решение организации, комитета, издателя, организатора конференции, инвесткомиссии или иного института, доказательство становится существенно сильнее.

USCIS смотрит не на ярлык, а на содержание. Назвать функцию «review», «mentorship», «technical oversight» или «quality gate» недостаточно. Офицер анализирует фактическое описание обязанностей и сопоставляет его с документами: invitation letters, appointment letters, committee rosters, reviewer guidelines, judging criteria, internal policies, decision logs, подтверждения от организаторов, письма от работодателя и иные материалы, из которых видно, что именно делал заявитель, в каком процессе, по каким правилам и с каким эффектом.

Поэтому в хорошей петиции вопрос ставится не так: «заявитель ревьюил код». Корректная постановка иная: был ли у заявителя подтвержденный мандат оценивать работу других, и свидетельствуют ли документы о том, что его экспертное суждение использовалось как основание для дальнейших решений. Если ответ на этот вопрос расплывчатый, USCIS обычно квалифицирует такой опыт как обычную часть основной работы, а не как выполнение критерия judging the work of others.

Практический вывод: для USCIS значение имеет не терминология компании, а конструкция доказательства. Чем яснее показаны формальная роль, процедура оценки, объект оценки, критерии отбора и последствия решения, тем выше шанс, что officer увидит именно judging the work of others, а не стандартную рабочую коммуникацию внутри команды.

Почему «внутреннее ревью кода» часто не проходит как «judging the work of others»

Один из самых частых ошибок в петициях по O-1 и EB-1 — попытка выдать обычное внутреннее code review за доказательство критерия judging the work of others. На уровне фактов это выглядит убедительно: инженер регулярно проверяет pull requests, оставляет замечания по архитектуре, безопасности, производительности, стилю и качеству кода, влияет на то, что попадет в production. Но для USCIS этого обычно недостаточно, если из доказательств не следует, что заявитель действительно формально оценивал работу других специалистов и имел для этого установленный мандат.

Типичный кейс выглядит так: заявитель участвует в процессе разработки как senior engineer, staff engineer или tech lead, просматривает PR коллег, предлагает правки, указывает на нарушения стандартов и может рекомендовать доработку. Однако финальное решение о принятии изменений принимает engineering manager, architect, repository owner, designated approver или другой сотрудник, обладающий правом merge approval. В такой конфигурации заявитель, по сути, выступает как сильный технический рецензент внутри операционного процесса, но не как лицо, которое осуществляет формальное оценивание чужой работы с последствиями для итогового результата.

Для USCIS здесь важна не сама интеллектуальная сложность комментариев, а характер полномочий. Критерий не сводится к тому, что специалист способен замечать ошибки или давать экспертные замечания. Нужно показать, что его привлекали именно в качестве судьи, ревьюера, члена отборочной комиссии, эксперта или иного лица, чья функция состояла в оценке работы других по определенным правилам, с понятным статусом и с влиянием на исход решения.

Где проходит граница между обычным code review и qualifying judging

Внутреннее peer review в инженерной команде чаще всего рассматривается как стандартный элемент SDLC: контроль качества, соблюдение coding guidelines, архитектурная согласованность, снижение технического долга. Это нормальная часть обязанностей senior-level разработчика. Даже если замечания заявителя серьезно влияют на качество продукта, USCIS может квалифицировать такую активность как ordinary work duty, а не как отдельную функцию по оценке работы других специалистов.

Ключевая проблема в том, что peer review по стандартам разработки не равно formal judging. Когда инженер комментирует PR, он может анализировать фрагмент кода, но это еще не означает, что он выполняет роль официального оценщика. Если он не наделен правом утверждать, отклонять, ранжировать, присваивать итоговую оценку или формировать решение, обязательное для команды или организации, USCIS часто видит в этом обычное внутреннее взаимодействие коллег.

Практический вывод: формулировка уровня «reviewed code of teammates and provided technical feedback» почти всегда слабая. Она описывает участие в разработке, а не judging. Сильнее работает только та конструкция, где доказано, что заявитель был назначен оценивать чужую работу в рамках формализованного процесса и его позиция влияла на допуск, отбор, публикацию, acceptance или иное итоговое решение.

Почему отсутствие approval authority разрушает аргумент

Самый частый провал — отсутствие ясного описания approval authority. Если из письма работодателя, организационной схемы, policy document или workflow не видно, что именно заявитель имел право финально одобрить, отклонить или блокировать результат, доказательство становится уязвимым. USCIS оценивает не только факт участия, но и институциональную роль заявителя в процессе.

Если инженер лишь оставляет комментарии, а другой сотрудник:

принимает решение о merge;
подтверждает соответствие архитектурным требованиям;
решает, может ли изменение попасть в release;
утверждает performance rating исполнителя;
несет ответственность за финальный acceptance,

то именно этот другой сотрудник выглядит как лицо, осуществляющее формальную оценку. Заявитель в таком кейсе остается участником рабочего процесса, даже если его мнение уважаемо и практически значимо.

USCIS особенно настораживает ситуация, когда в доказательствах заявитель описан как «one of the reviewers» без объяснения, кто имел последнее слово. Если последнее слово принадлежало не заявителю, критерий обычно проседает.

Почему технические замечания по PR сами по себе не доказывают judging

Комментарии в pull requests обычно касаются качества реализации: naming, test coverage, edge cases, scalability, security, readability, backward compatibility. Это экспертная работа, но она направлена на улучшение продукта, а не обязательно на формализованное оценивание автора работы. USCIS может рассматривать такие материалы как подтверждение высокой квалификации заявителя, но не как доказательство отдельного критерия judging the work of others.

Проблема усугубляется, если из evidence не следует:

по каким формальным критериям оценивалась работа других;
был ли у заявителя официальный статус reviewer, evaluator, judge или panel member;
носила ли оценка регулярный, структурированный характер;
имела ли она последствия для допуска, отбора, acceptance, promotion, certification или выпуска результата;
была ли эта функция отделена от обычных инженерных обязанностей.

Без этих элементов USCIS логично делает вывод: заявитель просто выполнял задачи, типичные для опытного разработчика внутри компании.

Типовые слабые места в доказательствах

По этому сюжету петиции часто проваливаются не потому, что заявитель вообще ничего не оценивал, а потому что доказательства не доводят историю до юридически значимой конструкции. На практике слабыми оказываются следующие блоки:

Нет описания полномочий. Письмо ограничивается фразами о том, что заявитель «reviewed code» или «provided feedback», но не говорит, мог ли он утверждать, отклонять или требовать обязательных изменений.
Нет критериев оценки. Не объяснено, по каким стандартам и в рамках какой процедуры оценивалась работа других инженеров.
Нет регулярности. Отсутствуют данные о периодичности: сколько ревью проводилось, в каком объеме, на протяжении какого периода, в отношении каких команд или специалистов.
Нет влияния на итог. Не показано, что мнение заявителя влияло на release decision, acceptance, promotion, бонус, performance assessment, admission в программу или иной конечный результат.
Нет формализации роли. Не представлено назначение в review committee, governance board, architecture review panel, hiring panel или иную структуру, где оценка чужой работы является официальной функцией.

Если evidence состоит только из скриншотов комментариев в GitHub, GitLab или Bitbucket, это почти всегда недостаточно. Такие материалы показывают факт технического взаимодействия, но редко доказывают юридически значимую роль оценщика.

Почему USCIS часто относит это к обычным инженерным обязанностям

С точки зрения USCIS внутреннее ревью кода — естественная часть работы senior developer, staff engineer, engineering lead или architect. Чем выше уровень специалиста, тем более ожидаемо, что он проверяет работу коллег. Поэтому само по себе участие в PR review не выделяет заявителя как лицо, специально привлекаемое для judging. Напротив, это может подтверждать, что он был ценным и опытным инженером, но именно в рамках своей основной должности.

Это особенно заметно в компаниях с mature engineering process, где review обязателен для всех изменений и распределен между несколькими участниками команды. В такой модели ревью не выглядит как исключительное экспертное привлечение. Оно выглядит как стандартный operational workflow. А критерий judging the work of others требует большего: внешнего или внутреннего, но именно формализованного оценивания, где заявитель действует не просто как коллега, а как уполномоченный оценщик.

Что USCIS ожидает увидеть вместо общего описания PR review

Если заявитель все же пытается опереться на внутренние review-функции, доказательства должны отвечать на три вопроса: кто назначил, по каким правилам оценивал, какие последствия имело его решение. Без этой связки narrative остается на уровне «experienced engineer gave feedback», а не «served as a judge of others’ work».

Поэтому внутреннее ревью кода часто не проходит именно из-за недоказанности формального статуса и властных полномочий, а не из-за недостатка технической глубины. Для USCIS важно не то, насколько сложные комментарии заявитель писал в PR, а то, был ли он в процедуре тем, кто оценивал чужую работу с институционально признанным весом.

Если финальное решение принимал manager, architect или designated approver, а заявитель только рекомендовал изменения, безопаснее не строить критерий judging исключительно на таком опыте. В большинстве дел это слабая опора и частый источник RFE.

Как правильно упаковать доказательства (и что изменить в документах компании)

По критерию judging the work of others USCIS оценивает не общее участие в командной работе, а наличие у заявителя отдельной, распознаваемой функции оценки чужого результата. Для офицера принципиально важно увидеть три слоя одновременно: формальную роль, реальные действия по оценке и последствия этой оценки для других специалистов, релиза, архитектуры или допуска результата в продакшн. Если в пакете есть только общие формулировки вроде «reviewed code», «provided feedback», «collaborated with engineers», критерий обычно не закрывается.

Задача упаковки доказательств — перевести внутренние процессы компании на язык USCIS: кто именно оценивал, по каким стандартам, что мог одобрить или отклонить, и как это влияло на дальнейшую работу команды. Внутреннее ревью кода само по себе часто выглядит как обычная производственная функция senior-специалиста. Поэтому документы должны показывать не просто участие в peer review, а оценочную компетенцию с правом влияния на решения других.

Какие документы и сведения нужно собрать

Базовый пакет должен строиться вокруг документов из США или документов американского работодателя, которые подтверждают практику оценки чужой работы именно в рамках корпоративных процессов.

Detailed resume с описанием не только должностей, но и конкретных оценочных обязанностей. Недостаточно написать «conducted code reviews». Нужно фиксировать: оценка архитектурных решений, acceptance/rejection pull requests, approval before deployment, review of technical design documents, performance evaluation of junior engineers, go/no-go recommendations.
Letter(s) от руководителя, директора, engineering manager, product leader, где по каждой роли расписано: какие материалы заявитель проверял, по каким критериям, имел ли право approve/reject, какие решения принимались на основании его оценки.
Подтверждение ролей и ownership: org chart, team charter, responsibility matrix, RACI, escalation matrix, committee membership, описание governance-процессов, где видно, что заявитель был reviewer, approver, gatekeeper или acceptance authority.
Примеры решений, где заявитель именно judged/approved: design review outcomes, pull request approval with blocking comments, architecture sign-off, acceptance notes, QA exception approvals, security or reliability review decisions, documented rejection of an implementation.
Внутренние регламенты, SOP, engineering handbook, release policy, design review policy, если в них указано, что определенный класс решений требует approval конкретной роли, которую занимал заявитель.
История изменений и следы одобрения: Jira, GitHub, GitLab, Bitbucket, Confluence, review tools, release management systems. Лучше не в виде сырых логов, а в виде отобранных, поясненных exhibits с аннотацией, что именно доказывает каждый скриншот или запись.
Материалы по наставничеству и оценочным функциям, если заявитель менторил инженеров не в учебном, а в оценочном формате: calibration notes, promotion input, technical growth assessments, probation feedback, readiness assessments for task ownership.

Чек-лист: что должно быть в доказательствах

Название роли заявителя и период выполнения оценочных функций.
Какие именно результаты чужой работы он оценивал: код, архитектура, дизайн-документы, acceptance criteria, release readiness, quality gates.
Кто были объекты оценки: разработчики, подрядчики, junior/mid/senior engineers, cross-functional teams.
Какие критерии применялись: security, scalability, coding standards, performance, reliability, compliance with architecture, release readiness.
Была ли у заявителя возможность потребовать доработку, отклонить решение, заблокировать merge, не допустить релиз, вернуть документ на пересмотр.
Были ли его выводы обязательными или materially influential для других.
Какие конкретные кейсы показывают его judgment, а не просто участие в обсуждении.
Как компания формально закрепляла эти полномочия: job description, manager letter, internal policy, role matrix.
Какие последствия имела его оценка для других сотрудников или команд.

Ключевая логика USCIS проста: если из документов нельзя понять, что заявитель оценивал чужую работу по понятным стандартам и его вывод влиял на допуск, переработку или отклонение результата, офицер, как правило, увидит в этом обычную операционную функцию, а не отдельный критерий.

Как писать detailed resume, чтобы он работал под критерий

Detailed resume не должен быть карьерным профилем в стиле LinkedIn. Его задача — показать, что оценка чужой работы была частью реальных обязанностей, а не ретроспективной интерпретацией под петицию. Поэтому формулировки нужно строить вокруг действия, объекта оценки, стандарта и результата.

Слабо: «Participated in code reviews for backend services».
Сильно: «Reviewed and approved pull requests submitted by backend engineers for payment infrastructure; evaluated compliance with reliability, latency, and security standards; required revisions or blocked merge when implementation did not meet production-readiness criteria».
Слабо: «Mentored junior developers».
Сильно: «Assessed technical output of junior engineers, provided documented readiness determinations for independent ownership of services, and recommended whether work met team standards for deployment and long-term maintenance».

Для IT, мобильной разработки, AI/ML и фаундерских ролей особенно полезно показывать не только code review, но и оценку design proposals, model quality, experiment validity, release acceptance, architecture compliance, vendor deliverables. Чем выше уровень результата, который заявитель оценивал, тем сильнее выглядит критерий.

Как должно выглядеть письмо от руководителя или менеджера

Письмо руководителя — один из ключевых документов, но именно здесь чаще всего делают две ошибки: пишут абстрактно и подменяют факты красивыми выводами. Письмо должно быть фактическим, привязанным к процессам компании и подтверждаемым другими документами.

Структура сильного письма обычно выглядит так:

Кто подписант, его должность, как он знает работу заявителя, в какой период взаимодействовал.
Какую позицию занимал заявитель и где эта позиция находилась в структуре команды.
Какие именно чужие результаты заявитель оценивал на регулярной основе.
Какие критерии применялись при оценке.
Какие полномочия были у заявителя: approve, reject, require revision, sign off, recommend acceptance, block release.
Какие были последствия его оценки для других сотрудников, продукта, релиза или архитектуры.
2–4 конкретных примера, где заявитель принял решение по чужой работе.

Хорошая формулировка в письме не просто утверждает, что заявитель «judged the work of others», а расшифровывает механизм:

что именно он проверял;
по каким стандартам;
какие выводы делал;
кто обязан был учитывать его вывод;
что происходило после approve или reject.

Самая частая причина слабых manager letters — язык «под рекомендацию», а не «под доказательство». USCIS не интересует общее мнение руководителя о высоком уровне специалиста. Офицеру нужны проверяемые факты: функция, процесс, критерий оценки, полномочие, пример.

Как переписать job description, чтобы критерий читался прямо из документа

Если текущий job description описывает только разработку, доставку функционала и collaboration, его нужно переработать так, чтобы оценочная функция была встроена в саму роль. Это особенно важно, когда компания хочет показать, что judging the work of others — не разовый эпизод, а часть должности.

В корректно переписанном job description должны появиться четыре блока.

Объект оценки: что именно заявитель проверяет — code submissions, architecture documents, technical designs, model outputs, release candidates, vendor implementations, test plans.
Критерии оценки: по каким стандартам идет проверка — scalability, security, maintainability, coding standards, compliance with platform architecture, production readiness, data quality, model performance thresholds.
Решение по результатам оценки: какие выводы и действия делает заявитель — approve, reject, request revisions, escalate, sign off, certify readiness, recommend acceptance or non-acceptance.
Последствия для других: как его решение влияет на работу других — merge allowed or blocked, design proceeds or returns for revision, release moves forward or is delayed, junior engineer receives independent ownership or remains supervised.

Практически это означает, что в job description нужно уходить от общих формулировок «ensures quality» и переходить к верифицируемым обязанностям.

Слабо: «Ensures code quality across the team».
Сильно: «Reviews and approves code submissions from team engineers against security, reliability, and maintainability standards; may require revisions or block integration until deficiencies are resolved».
Слабо: «Supports design review process».
Сильно: «Evaluates technical design proposals prepared by other engineers, determines whether designs satisfy platform architecture and performance requirements, and approves or returns proposals for revision before implementation begins».
Слабо: «Mentors junior developers».
Сильно: «Assesses the technical work product and readiness of junior engineers, provides documented feedback on whether deliverables meet team standards, and recommends whether engineers may assume independent ownership of production components».

Для фаундеров и technical executives полезно дополнительно описывать оценку чужой работы через governance-функции: approval of engineering plans, vendor deliverables review, architecture council decisions, product acceptance sign-off, security or AI model review boards.

Какие доказательства влияния особенно убедительны

USCIS обычно сильнее воспринимает не декларации о статусе, а следы того, что мнение заявителя реально запускало или останавливало действия других. Поэтому приоритет нужно отдавать evidence of impact.

Sign-off в процессах: документы, где без approval заявителя следующий этап не происходил — release sign-off, architecture sign-off, production readiness sign-off, acceptance approval.
Участие в design review или acceptance review с фиксированным решением: approved, approved with required changes, rejected, deferred pending revision.
Подтвержденное принятие или отклонение результатов: возврат pull request на доработку, отклонение дизайна, отказ в допуске к релизу, требование переработать ML pipeline или модель из-за качества/рисков.
Наставничество с оценочной функцией: не просто обучение, а documented assessment of performance, readiness, technical judgment, promotion or scope recommendations.
Комитеты, советы, review boards, где заявитель выступал назначенным reviewer/approver, а не обычным участником обсуждения.
Ownership над quality gates: если заявитель отвечал за критерии, по которым работа других считалась принятой или отклоненной.

Для мобильной разработки это могут быть acceptance decisions по release candidate, оценка соблюдения app architecture, performance и crash-free thresholds. Для AI/ML — review of model performance, bias/risk thresholds, data quality gates, approval of deployment readiness. Для платформенных и backend-инженеров — architecture compliance, scalability review, security and latency sign-off.

Наиболее сильная связка доказательств выглядит так: job description закрепляет оценочную функцию, manager letter объясняет, как она работала на практике, а внутренние артефакты показывают конкретные approve/reject действия. Если один из этих трех слоев отсутствует, пакет становится уязвимее.

Что менять в корпоративных документах заранее

Если компания понимает, что ключевые специалисты потенциально будут использовать этот критерий в будущем, разумно заранее привести внутреннюю документацию в порядок. Делать это нужно не под иммиграционное досье постфактум, а как часть нормальной governance-практики.

Обновить job descriptions так, чтобы оценочные функции были описаны прямо и конкретно.
Закрепить reviewer/approver roles в RACI, approval matrix, engineering handbook, release policy.
Формализовать design review, architecture review, production readiness review и acceptance review с понятными статусами решения.
Хранить артефакты решений: approved, rejected, revision required, exception granted.
Отделять peer collaboration от formal review authority — это две разные вещи, и USCIS это различие видит.
Документировать mentorship там, где она включает оценку готовности и качества чужой работы.

Такая подготовка особенно полезна для компаний в IT и AI, где senior-специалисты действительно выполняют оценочные функции, но корпоративные документы часто описывают это расплывчато. В результате сильный по фактам кейс выглядит слабым на бумаге.

Риски, из-за которых критерий разваливается

Главный риск — попытка «докрутить» критерий формулировками, которые не поддержаны реальными процессами и документами. USCIS сопоставляет письмо, резюме, job description и внутренние материалы между собой. Если один документ говорит о праве reject, а в реальной системе заявитель выступал только как комментатор без полномочий, это создает прямую уязвимость.

Не заявлять полномочия approve/reject, если они не подтверждаются практикой компании.
Не подменять совместную разработку утверждением о judging, если у заявителя не было отдельной оценочной роли.
Не использовать шаблонные письма без конкретных примеров решений.
Не описывать внутреннее code review как самостоятельный judging criterion, если это обязательная рутина всех инженеров без differentiated authority.
Не допускать расхождений между HR-документами, письмами менеджеров и цифровыми следами в системах компании.

Если письма «завышают» полномочия заявителя, а корпоративная практика этого не подтверждает, офицер может прийти к выводу, что evidence is self-serving and inconsistent. На практике это часто заканчивается RFE, а при грубых несоответствиях — denial.

Правильная стратегия — не украшать факты, а доказать реальную оценочную функцию через структуру доказательств. Когда из job description, manager letter, RACI, workflow и конкретных артефактов следует, что заявитель проверял чужую работу по установленным критериям и его вывод влиял на действия других, критерий judging the work of others начинает читаться для USCIS как самостоятельный и убедительный.

Практический план действий: от анализа роли до ответа на RFE/пересборки кейса

Критерий judging the work of others в логике USCIS работает не как общее указание на seniority, а как проверка конкретной функции: заявитель должен выступать именно в роли оценщика чужой работы по понятным стандартам и в рамках процесса, где его оценка имеет самостоятельное значение. Для IT-специалистов ключевая ошибка — пытаться выдать за judging обычное исполнение управленческих или инженерных обязанностей: code review внутри своей команды, approval pull request по duty roster, участие в sprint ceremony, performance feedback подчиненным. Если из доказательств не видно отдельной экспертной функции, офицер делает предсказуемый вывод: это внутренняя операционная работа компании, а не judging в смысле Policy Manual.

Практически правильный подход состоит из четырех этапов: сначала нужно разложить фактическую роль по признакам USCIS, затем зачистить формулировки в корпоративных документах, после этого собрать пакет доказательств под конкретные вопросы офицера и, если уже пришел RFE или notice of intent, ответить адресно, без повторения исходной общей аргументации.

Шаг 1. Сопоставить фактические обязанности с критериями USCIS

Первый этап — не собирать документы, а квалифицировать саму деятельность. Нужно понять, есть ли у заявителя эпизоды или регулярная функция, которые можно доказуемо описать как оценку работы других лиц. Важен не титул, а конструкция процесса: кого именно оценивали, по каким критериям, для какой цели, с каким последствием.

Для технических специалистов USCIS обычно ищет четыре базовых признака:

заявитель оценивал чужую работу, а не просто выполнял совместную разработку;
оценка происходила в рамках формализованного процесса, а не как бытовое рабочее обсуждение;
у заявителя была распознаваемая роль судьи, reviewer, evaluator, panel member, technical assessor, advisory board member, committee reviewer;
оценка влияла на результат: отбор, награждение, публикацию, финансирование, найм, сертификацию, акселерацию, conference acceptance, grant decision, external competition outcome.

Если хотя бы два из этих признаков отсутствуют, критерий становится уязвимым. Внутреннее ревью кода чаще всего проваливается именно здесь: инженер проверяет соответствие style guide, безопасность merge, архитектурную совместимость и release readiness внутри собственной компании. Это важная работа, но обычно она не выглядит как независимое judging the work of others в понимании USCIS.

Для первичной квалификации удобно использовать следующую матрицу:

Доказательство: приглашение в жюри хакатона, demo day, startup competition, conference committee. Требуемый признак: наличие внешней экспертной роли и отдельного процесса оценки чужих работ.
Доказательство: письмо от организатора с описанием критериев оценки, scorecards, rubric, evaluation form. Требуемый признак: существование формализованных оснований оценки, а не неформального мнения.
Доказательство: список заявок, проектов, paper submissions, pitch decks, которые заявитель оценивал. Требуемый признак: конкретный объект judging и измеримый объем участия.
Доказательство: minutes committee meeting, confirmation of panel participation, email appointing applicant as reviewer. Требуемый признак: официальное назначение в роли оценщика.
Доказательство: документы, показывающие, что мнение заявителя учитывалось при принятии решения. Требуемый признак: материальность оценки для финального исхода.
Доказательство: публичная страница мероприятия, listing judges, advisory board roster. Требуемый признак: внешняя верифицируемость статуса judge/reviewer.
Доказательство: описание внутреннего code review в компании. Требуемый признак: обычно не закрывает критерий, если не доказана отдельная экспертная функция вне обычных job duties.
Доказательство: performance review подчиненных внутри своей org structure. Требуемый признак: само по себе слабо, потому что USCIS часто воспринимает это как обычную managerial duty, а не judging в требуемом смысле.

Ключевой тест прост: если убрать название должности и оставить только описание действия, останется ли функция независимой оценки чужих работ? Если ответ отрицательный, критерий лучше не строить на таком факте без дополнительной переработки доказательственной базы.

Шаг 2. Провести внутренний аудит формулировок

После квалификации роли нужно проверить, как она описана в существующих документах. На практике кейс часто ломается не из-за отсутствия фактов, а из-за языка: компания пишет про leadership, mentorship, ownership и code quality, а USCIS ищет reviewer authority, evaluation criteria, selection role, panel decision-making.

Аудит нужно провести по четырем группам документов.

Recommendation letters. Письма должны показывать не общую ценность специалиста, а его функцию оценщика. Нужны формулировки уровня: applicant was invited to evaluate submissions, served on the selection panel, assessed projects against published criteria, provided scoring that informed finalist selection. Фразы уровня reviewed code, mentored engineers, maintained quality bar, approved implementations слишком размыты.
PR-описания и публичные био. Если в профиле сказано лишь engineering leader, senior mobile architect, AI tech lead, это не помогает критерию. Помогают упоминания judging panel, startup competition judge, external reviewer, technical committee member, hackathon evaluator, award selection board.
Performance documents. Внутренние performance reviews полезны только если из них видно отдельную оценочную функцию, выходящую за рамки штатной обязанности. Например: appointed to assess finalists in internal incubator reviewed by cross-functional panel. Если документ описывает только manager feedback или development coaching, он слабо работает.
Org chart и role definition. Эти документы должны подтверждать, что заявитель не просто peer reviewer в delivery chain, а лицо с выделенной authority to evaluate. Если по org chart видно, что applicant merely reviewed work of direct reports as part of supervision, USCIS может посчитать это обычным people management.

На этом этапе полезно составить таблицу аудита формулировок:

Фраза в документе: reviewed engineering work of team members. Проблема: неясно, было ли это judging или обычный рабочий процесс. Корректировка: formally evaluated submissions/proposals/projects created by other participants under defined criteria.
Фраза в документе: maintained code quality and approved pull requests. Проблема: выглядит как routine operational function. Корректировка: served as designated reviewer on a selection committee assessing external or cross-program technical entries.
Фраза в документе: gave feedback to engineers. Проблема: feedback не равен judging. Корректировка: scored candidates/projects/papers and recommended advancement based on specific standards.
Фраза в документе: participated in hiring discussions. Проблема: участие в обсуждении не показывает самостоятельную роль. Корректировка: was assigned to evaluate technical exercises/interview performances as a voting member of the hiring panel.

Самый частый источник RFE — письмо, где одновременно используются слова reviewed, advised, mentored, approved, но nowhere explained who was judged, on what criteria, and with what consequence. Для USCIS это не недостаток стилистики, а пробел в юридически значимом факте.

Шаг 3. Подготовить пакет доказательств под конкретный вопрос USCIS

Сильный пакет по judging строится не вокруг статуса заявителя, а вокруг четырех вопросов, которые офицер фактически задает в каждом деле:

Кто именно принимал финальное решение?
Какую часть этого решения оценивал заявитель?
Как часто или в каком объеме заявитель выполнял такую функцию?
На каких стандартах, rubric или профессиональных основаниях строилась оценка?

Под каждый вопрос лучше собирать отдельный блок доказательств, а не надеяться, что одно рекомендательное письмо закроет все сразу.

1. Кто принимал решение. Нужно показать архитектуру процесса. Если это конкурс, приложить правила, состав жюри, письмо организатора. Если это акселератор или grant review, показать committee structure, role descriptions, voting or recommendation mechanics. Если решение принимал не сам заявитель, это не проблема — проблема возникает, когда неясно, был ли его вклад частью официальной процедуры.

2. Какую часть решения оценивал заявитель. Необходимо выделить предмет оценки: technical feasibility, code quality of submissions, architecture robustness, ML methodology, product scalability, security posture, innovation merit. Чем уже и точнее описан участок оценки, тем правдоподобнее выглядит роль. Формула должна быть такой: applicant evaluated X for purpose Y using criteria Z.

3. Как часто и в каком объеме. Один разовый эпизод может сработать, но серия эпизодов работает лучше. Нужны цифры: number of submissions reviewed, number of competitions, dates of service, frequency per year, size of panel. Для IT-фаундеров и AI-инженеров хорошо работают повторяющиеся приглашения в хакатоны, startup demo panels, open-source grant reviews, conference program committees.

4. На каких основаниях. USCIS хочет видеть не субъективное впечатление, а профессиональный стандарт. Это могут быть published judging criteria, evaluation rubric, scorecards, technical review template, call-for-papers guidelines, investor selection matrix, hiring assessment framework. Если стандартов нет, их нужно реконструировать через свидетельские письма и приложенные образцы форм оценки.

Практически пакет доказательств стоит собирать в такой структуре:

обложка раздела с кратким legal summary, почему факт соответствует judging the work of others;
документ о назначении в роль judge/reviewer/panelist;
доказательства статуса самой программы, конкурса, комитета или review process;
материалы, показывающие критерии оценки;
доказательства объема работы: number of submissions, dates, agenda, committee roster;
пример результата: score sheet, recommendation email, selection memo, finalist shortlist;
рекомендательное письмо от организатора или chairperson, которое связывает все элементы в одну историю.

Если вместо формализованного judging есть только внутренняя переписка о code review, лучше не перегружать этим раздел. Большой объем слабых документов не усиливает критерий; он показывает офицеру, что заявитель подменяет требуемый признак обычной производственной деятельностью.

Шаг 4. Если уже получен RFE или notice: как отвечать адресно

RFE по критерию judging почти всегда означает, что исходный пакет не ответил на один из четырех вопросов выше. Ошибка заявителей — отправлять еще больше общих praise letters и снова писать, что applicant is a highly respected leader who reviews other engineers’ work. Это не устраняет замечание USCIS.

Адресный ответ на RFE должен быть построен по логике замечания офицера. Если офицер пишет, что evidence does not establish that the beneficiary judged the work of others in the same or allied field, ответ должен не повторять биографию, а закрывать конкретные пробелы:

Уточнить полномочия. Показать, как заявитель был назначен в роль оценщика, имел ли vote, recommendation authority, scoring function, admission authority или selection input.
Приложить конкретные примеры. Не «много раз оценивал проекты», а «served on the 2023 accelerator panel reviewing 42 startup applications; assessed technical architecture and scalability; scores informed selection of 8 finalists».
Устранить размытые формулировки. Заменить leadership vocabulary на adjudicative vocabulary: reviewed becomes evaluated, advised becomes scored or assessed, supported selection becomes served as voting reviewer если это соответствует фактам.
Разделить внутренние и внешние функции. Если в исходном пакете смешаны code review и judging panel activity, в ответе нужно ясно развести эти явления и опереться на более сильные эпизоды.
Подтвердить частоту и структуру. Добавить schedule, event pages, committee lists, screenshots, letters from organizers, rubric templates, dates and counts.

Технически хороший RFE-response по этому критерию обычно включает:

короткое сопроводительное правовое объяснение с цитированием применимого стандарта USCIS;
таблицу «RFE concern → submitted evidence → factual point established»;
одно-два новых сильных письма от лиц, которые администрировали процесс judging;
документы, подтверждающие роль заявителя, критерии оценки и влияние на итог;
при необходимости — отказ от слабых аргументов, которые только размывают кейс.

Если RFE показал, что исходная концепция была ошибочной — например, весь критерий строился на внутреннем review кода в рамках штатной работы, — иногда правильнее не пытаться «дожать» слабый нарратив, а пересобрать раздел полностью. Это означает выбрать только те факты, где есть внешний или хотя бы отдельно формализованный механизм оценки чужой работы, и перестроить доказательства вокруг него.

На практике офицера редко убеждает тезис «в нашей компании code review очень строгий, значит это judging». Для USCIS строгость процесса не равна юридически значимому judging. Решающее значение имеет не сложность ревью, а характер роли: независимая оценка чужих работ в формальном evaluative framework.

Чек-лист перед подачей или ответом на RFE

Понятно ли из документов, чью именно работу оценивал заявитель?
Виден ли формальный процесс, а не просто рабочее взаимодействие?
Подтверждено ли, что заявитель был назначен или приглашен в роль reviewer/judge?
Есть ли данные о критериях оценки и профессиональных стандартах?
Показано ли, как оценка заявителя влияла на отбор, награждение, прием, публикацию или иное решение?
Убраны ли из ключевых писем расплывчатые слова вроде mentored, advised, supported, reviewed, если они не раскрыты фактами?
Отделены ли слабые внутренние функции от сильных внешних или формализованных judging activities?

Если на любой из этих вопросов ответ отрицательный, риск RFE остается высоким. Критерий judging the work of others выигрывается не за счет общего авторитета специалиста, а за счет аккуратной сборки фактов: отдельная оценочная функция, формализованный контур, понятные критерии, конкретные примеры и язык документов, который не оставляет USCIS пространства квалифицировать такую деятельность как обычную внутреннюю работу компании.