PRO HH по-новому

Когда пошел смотреть вакансии, то мой процесс поиска на HeadHunter выглядел довольно стандартно:
1⃣ открываю вакансию,
2⃣ читаю описание,
3⃣ примеряю требования на себя и думаю: «Пожалуй, стоит откликнуться».
4⃣ иногда понимаю, что не дотягиваю, и просто закрываю вкладку.

Теперь каждую интересную вакансию я сначала отправляю своему боту. Он анализирует текст вакансии, сравнивает его с моим резюме и выдает заключение. Не просто «подходит / не подходит», а объясняет, почему стоит откликаться или лучше не тратить время.

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

Изначально я делал этого бота для себя, чтобы сократить количество бессмысленных откликов. Но одна голова хорошо, а две лучше.

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

Поэтому хочу сказать большое спасибо всем, кто помогает его развивать. 🥰

Если тоже хотите попробовать, то просто поставьте «+» в комментариях под этим постом.

Кстати, если вы уже пользуетесь ботом, можете приглашать коллег и друзей. Сейчас каждому доступно 3️⃣ проверки в день, а каждый приглашенный добавляет еще три ежедневные проверки. В итоге выигрывают все: и тот, кто пригласил, и тот, кто получил доступ.

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

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

----

✌️ПРО СА| 🆕НЕКСТ СА

PRO бота для оценки резюме

Всем привет! 👋

Спасибо за обратную связь, которую вы оставляете в боте, и за то, что пользуетесь!

На основе ваших комментариев вот что изменилось в боте:
➕ добавил возможность использовать ранее загруженное резюме;
➕ добавил настройки /settings, чтобы вы могли выбирать размер сопроводительного письма и подпись;
➕ провел калибровку оценок резюме, теперь оценка еще ближе к действительности и стабильна.

Ботом пользуются уже не только аналитики и мы приближаемся к 100 пользователям. 🔥

Напоминаю, что попасть в бота можно двумя путями:
1️⃣ поставить "+" под этим сообщением
2️⃣ получить реферальную ссылку от тех, кто уже пользуется (это расширяет ваши лимиты использования).

Отзывы и комментарии оставляйте в боте. Они анализируются для улучшения бота.

Приятного использования ✌️

PRO требования: EARS

Иногда требование выглядит вполне понятно для аналитика, но разработчик и тестировщик читают его по-разному.

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

Для таких случаев существует EARS (Easy Approach to Requirements Syntax) - подход к формулированию требований через несколько типовых конструкций.

Например:

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

Здесь явно указаны событие и ожидаемое поведение.

В EARS используются несколько основных шаблонов:
➖Всегда
➖При событии
➖При определённом состоянии
➖При нежелательном условии.
➖Для опционального поведения

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

По сути - это один из инструментов, который помогает превратить «системе нужно уметь...» в проверяемое системное требование.

--

✌️ ПРО СА|🆕 НСА 2.0

PRO стандарты интернета или Почему вилка не лезет в розетку, а сайт открывается везде

Обычная ситуация: прилетел в другую страну, достал зарядку, а вилка не лезет в розетку. Никто не виноват: когда-то просто не договорились, как эта вилка выглядит. Типов розеток в мире 15, и переходник ты покупаешь в аэропорту.

А вот с интернетом договорились. Любой сайт открывается в любом браузере, хоть в Токио, хоть в Твери, потому что правила записали заранее. Эти записанные правила и называются RFC.

Три вещи, которые экономят аналитику время:

1⃣ Статус написан в шапке. Не каждый RFC это стандарт. Internet Standard проверен годами и работающими реализациями, а Experimental и Informational ни к чему не обязывают, хотя выглядят точно так же.

2⃣ Документ не меняют. Нашли ошибку, выпускают новый номер, а в шапке старого появляется Obsoleted by. Поисковик легко отдаст отменённый: спецификация HTTP так переезжала дважды, из 2616 в 7230-7235, оттуда в 9110-9112.

3⃣ MUST, SHOULD, MAY. Готовая шкала обязательности: обязан, желательно, можно. Работает только запись заглавными, строчное must это обычный текст.

Чего не было в ролике: как сослаться на RFC в требовании

Формулировка, которая заканчивает спор на груминге:

«Сервис ДОЛЖЕН возвращать ошибки в формате RFC 9457 (Problem Details for HTTP APIs). Поля type и title обязательны, коды ошибок домена передаются в расширенных полях.»

Три правила такой ссылки:

➖ Номер, название и раздел: RFC 9110, §15.5.1, а не «по стандарту HTTP». Иначе разработчик и тестировщик прочитают её по-разному.
➖ Перед вставкой открой шапку и убедись, что документа не касается Obsoleted by. Ссылка на отменённый документ хуже, чем отсутствие ссылки: она выглядит обоснованной.
➖ Занеси решение в глоссарий проекта. Тогда второй раз этот спор не начнётся.

Шпаргалка: что искать по номеру

✔️ HTTP: 9110 (семантика, коды, заголовки), 9112 (HTTP/1.1)
✔️ JSON: 8259, точечные правки JSON Patch: 6902
✔️ Ссылки: 3986, дата и время: 3339
✔️ Авторизация: 6749 (OAuth 2.0), токены: 7519 (JWT)
✔️ Ошибки API: 9457, email-адрес: 5322, UUID: 9562

Где смотреть: rfc-editor.org (статус, Obsoleted by, errata) и datatracker.ietf.org (история правок и черновики).

А на какой стандарт чаще всего ссылаешься ты или все на экспертном мнении?

----

✌️ ПРО СА| 🆕 НСА 2.0