Почему в персонализации резюме нет никакого смысла.

Уверен вы долго слушали людей которые говорили противоположное, но на моей стороне математика))

Итак возьмем за условия:

1) Вероятность что резюме увидят - одинаковая для обеих случаев так как канал одинаковый

2) Вероятность заинтересовать рекрутера, если он увидел резюме. Для обычного резюме давай поставим 3%, вероятность для подготовленного резюме Х - эту вероятность мы будем трекать что бы понять при каком значении она дает результат лучше рассылки

3) Время потраченое на работу:
отправить резюме - 30сек
персонализированое резюме - возьмем разбивку 5мин, 15мин, 30мин (тестируем паралельно с вероятностью Х)

4) Цена нашего часа работы - 25$

На графиках результат 4х Стратегий. Как видим даже при затрате всего 5 мин на резюме, его эффективность должна вырасти с базовых 3% до 33%, что в реальной жизни почти нереально. Но это можно взять за базис - все что требует больше 5мин времени 100% бесполезно.

Как видими вариант просто масс рассылок - самый выигрышный. А если его еще и автоматизировать дабы не тратить 30сек то и подавно.

Что еще может улучшить - качество исходного базового резюме. Ведь даже если вы его подымите с 3% до 5% эффективности - это увеличит результативность в 1.66 раза.

ДИСКЛЕЙМЕР: Все это верно при условии если вам все-равно где работать

на

В истории S3 есть момент, который архитекторы иногда пересказывают как "AWS придумала новый consensus algorithm". Я бы формулировал точнее: AWS не раскрывала публично новый алгоритм уровня Raft или Paxos, но в 2020 S3 получил strong read-after-write consistency для GET, PUT и LIST без заявленного ухудшения performance и без глобальной координации. И вот инженерно это намного интереснее самого названия алгоритма. ([Amazon Web Services, Inc.][1])

Представим наивную distributed storage. Есть 3 replica, запись подтверждаем после W=2, чтение делаем с R=2. Тогда:

W + R > N
2 + 2 > 3

Кворумы обязательно пересекаются хотя бы в одной replica, поэтому можно определить актуальную версию. Но за consistency платим coordination latency: если RTT до replica 1, 3 и 12 мс, запись зависит уже не от быстрейшей машины, а минимум от второй успевшей подтвердить.

На масштабе S3 проблема становится жестче. Нельзя просто посадить миллиарды ключей на один consensus group - leader превратится в bottleneck. Значит, coordination domain надо дробить, маршрутизацию делать локальной, а metadata и версии объектов обновлять так, чтобы независимые ключи практически не мешали друг другу.

Именно здесь архитектура выигрывает у "более быстрого алгоритма". Если миллион независимых ключей распределить между 10000 coordination groups, средняя область конкуренции уменьшается примерно:

1 000 000 / 10 000 = 100 ключей на group.

Теперь consensus остается локальным, а throughput масштабируется горизонтально.

В итоге S3 получил сильную консистентность при сохранении региональной изоляции, а приложениям больше не понадобились отдельные слои вроде S3Guard только ради согласованного представления данных. Позже conditional writes позволили еще и переносить optimistic concurrency control непосредственно в S3 вместо внешних lock-сервисов. ([Amazon Web Services, Inc.][1])

Для меня это хороший пример зрелой distributed architecture: настоящий прорыв часто не в том, чтобы придумать "Raft быстрее Raft", а в том, чтобы уменьшить область, внутри которой consensus вообще необходим.

[1]: https://aws.amazon.com/blogs/aws/amazon-s3-update-strong-read-after-write-consistency/?utm_source=chatgpt.com "Amazon S3 Update – Strong Read-After-Write Consistency | AWS News Blog"

#заметкиархитектора #история

Головне не в житті не вийти на себе)

#жартипроандрія

Після 2014 року я вперше по справжньому побачив, як в Україні працює технологічна допомога армії.

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

Я пояснив, що це матиме величезну похибку. Камуфляж, погане освітлення, трофейна форма, закрите обличчя, нестача нормальних даних. Сказав, що помилка легко перевищить 25 відсотків.

Мені відповіли: нормально, нас влаштовує.

Тобто система може вбивати своїх, і це для когось прийнятна статистика. Я подивився на них і сказав, що в такому лайні участі не братиму.

Наприкінці 2022 і на початку 2023 року ми вже працювали над системами візуальної навігації, розпізнавання і автоматичного наведення. Технологія була. Люди були. Можна було робити реальні речі для армії.

А потім почалася не інженерія, а українська система.

Після спілкування з генералітетом у мене склалося дуже просте враження: якщо конкретна людина не бачить особистої вигоди, їй часто байдуже, наскільки корисна технологія для країни. Серед військових теж вистачало реакції в стилі: а що з цього буде нам. Ті, хто реально підтримував, були, але їх було недостатньо.

Потім пішли погрози, спроби забрати напрацювання і речі, після яких питання технологій уже відійшло на другий план.

І все це в країні, де був колосальний запас інженерного досвіду. Люди, які працювали з радіолокацією, ракетною технікою, авіацією, космосом, складними системами керування. Фахівці, знання яких під час війни мали б збирати по країні вручну і давати їм усе необхідне для роботи.

Замість цього багато хто доживав своє життя нікому не потрібним.

Я знаю розробників, які після 2022 року приходили з командами, прототипами, досвідом і готовністю працювати. І дуже часто вони розповідали одну й ту саму історію. Їх зупиняла не фізика, не математика і не відсутність технологій. Їх зупиняли кабінети.

Мене найбільше бісить саме це.

Україна десятиліттями була країною сильних програмістів та інженерів. Ми робили складний софт для світових компаній, ракети, авіацію, радари, космічну техніку. Потенціал є.

Але потенціал нічого не вартий, коли рішення приймають не спеціалісти, а люди, для яких головне посада, контроль і власна вигода.

Можна скільки завгодно говорити про технологічний прорив. Але поки наверху сидять люди, яким важливіше від'їсти собі сраку, ніж дати працювати тим, хто реально щось уміє, країна з колін не підніметься.

Мораль проста. Найважчий legacy в Україні написаний не на C++ і не на COBOL. Він сидить у кабінетах і вперто не хоче рефакторитись.

#спогадирозробника

Есть компании, где покупку сервиса за $500 нужно обосновать через ROI.

Но правило, которое ежедневно бесит 5000 сотрудников, может существовать десять лет просто потому, что "у нас так принято".

Опоздание на две минуты. Зеленый Slack. Обязательные часы в офисе. Бессмысленные митинги. Timesheets с точностью до 15 минут.

Самое интересное, что многие из этих правил можно посчитать.

И внезапно оказывается, что компания может экономить десятки тысяч долларов на "дисциплине", одновременно теряя сотни тысяч или миллионы на продуктивности, увольнениях, потере доверия и репутационных рисках.

Я попробовал представить корпоративный микроменеджмент как обычную математическую задачу.

Получился Corporate Bullshit Ratio.

И некоторые правила этот тест явно не проходят.

https://www.linkedin.com/pulse/%D0%BA%D0%B0%D0%BA-%D0%BD%D0%B5%D0%B7%D0%B0%D0%BC%D0%B5%D1%82%D0%BD%D0%BE-%D1%83%D0%B3%D1%80%D0%BE%D0%B1%D0%B8%D1%82%D1%8C-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B0%D0%BD%D0%B8%D1%8E-andrii-nikishaiev-ua-fergf

Стоимость - это тоже non-functional requirement.

Мы привыкли проектировать системы вокруг привычных SLO:

Availability: 99.95%
P99 latency: 200 ms
Throughput: 10k RPS

Но рядом почти никогда нет еще одной строки:

Cost: $0.00012/request

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

Почти каждое улучшение надежности имеет цену.

Reliability растет.
Latency снижается.
Capacity reserve увеличивается.

И вместе с этим обычно растет cost.

Можно держать огромный запас мощности, replicas базы в нескольких AZ, дорогой storage, кэшировать все подряд и писать гигантские объемы telemetry. Система будет надежной.

Но правильный вопрос архитектора - не "можем ли мы сделать еще надежнее?", а "сколько дополнительной надежности мы покупаем за каждый дополнительный доллар?"