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

Круто. А как решаете вопрос доверия кандидатов? Многие всё ещё ожидают живого человека на первом собеседовании — интересно как это влияет на конверсию в вашем случае?

Как работает живой HR: 1. Назначает зум на завтра. 2. Проводит успешное интервью. 3. Только сейчас продает вакансию.

Как работает робот: 1. Прямо сейчас озвучивант условия. 2. Через 3 минуты проводит интервью.

И кому верить? Ждать сутки и по зуму продавать себя человеку, кто в твой отрасли не работал.

Или сразу получить оффер и через 3 минуты пройти интервью с машиной, которая в миллион раз умнее тебя.

Верить машине глупо. Тут не нужно доверие. Надо верить в себя и свои навыки. Тогда получишь работу.

Человека можно обмануть, машину нет. Человек оценивает субъективно, машина без эмоций.

Робот - это инструмент. Более качественная анкета для оценки. Если прошел робота, то принят на работу. Роботу доверяют больше, чем субъективному мнению неопытной девочки.

По конверсии каждый может посчитать (примерно напишу). При работе с HR: Пришли завтра на интервью - 60% Прошли успешно - 30% Оффер понравился (на эмоциях) - 70% Итого - 12,67%

При Роботе: Понравился оффер 60% Пришли на интервью - 90%, так как моментальное и может отпугнуть только консерватизм и привычки проходить лично. Это единицы. И они вам не нужны, сложно им принять прогресс. Прошли успешно - 30% Итого 16,2%

И это примерные цифры, зависит от отрасли, мотивации и должности. Но в среднем примерно такие.

Вы говорите о примитивной разработке. Поручите ИИ написание кода с 60-ю джойнами в OLAP СУБД, где перед этим нужно определить десятки и сотни сущностей и атрибутов, определить партиционирование и дистрибуцию, просмотреть планы запросов, а потом выполнить бизнес-выверки и обсудить с бизнесом ошибки в бизнес-логике

так бд это как раз и есть примитив, с этими тасками клод справится. удачи запустить иишницу в академический код по типу LLVM, опенБЗДа (гнидукс не беру в расчет, там как как в половине компиляторов языков - мусор), интерпретаторы, OpenBLAS/MLAS, оптимизация вычислительных ядер путем отправления их в ассемблер, положить байты по регистрам, знать как написать SIMD-функции и где для 4-х инструкций минимум. вот это не примитивная разработка. обфускация кода, JIT компиляция, избегания лишних аллокаций, зирокопийность и другая инженерская красота.

Это как сказать.. Примитив.. Найдите там как уровень изоляции мешает группам тразацкций разных сервисов освобождать память явовским сборщикам мусора и вешает эти сервисы по памяти. Саму проблему признать не просто, ее же в дампах искать будут, а не в базе данных :) . А может ее и правда нет. Или не каждый день.

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

Нет ничего сложного в том, чему научился :) сложное как правило приходит как feedback от уже созданой когда то простой и понятной системы. :) Java это не про создание простых и понятных систем. Это как правило управление хаосом, где хаос - неизбежная часть системы вцелом :)

Мы говорим о разном. Вы - о сложной, но механике. А я говорю о логике - бизнес-аналитике в СУБД, а не о банальных объединениях. Вам нужно построить витрину по kpi разных департаментов корпорации для директора, например. У Вас на входе 60 таблиц по 100+ колонок каждая с именами типа "hgfju" или "86длядиректора". Документации нет, команды работали разные, многие уже ушли, спросить не у кого. Как Вы определите сущности и их атрибуты, если у Вас на вход 0? А дашборд гендир ждет вчера. В результате на бизнес-выверках (уверен, что Вы прекрасно в курсе, что это такое) выясняется, что Вы условно заджойнили 2 поля "зАмок" и "замОк", ошибочно догадываясь по абракадабре в именах таблиц и колонок в них. После чего у Вас не только ошибки в логике, но даже и в механике. Я специалист по кхд. Это бизнес-аналитика. И для меня СУБД - это не средство для хранения данных для какого-нибудь стороннего кода типа java, а собственно код, на основании которого принимаются порой стратегические решения в корпорациях. И порой начисляются премии сотрудников. Думаю, мы оба остались при своем мнении

Чтобы уж совсем было понятно то, о чем я написал - представьте, что Вы можете выполнить jit-компиляцию только после того, как узнаете, что у секретарши Ивановой, которая сейчас на сносях от тракториста Сидорова, заразившего ее сифилисом, зачесалась правая лопатка. Телефона Ивановой нет, а Сидорова задавил мотовоз после очередного запоя. Чтобы в кхд создать аналитику в СУБД, Вам нужно быстренько изучить где-то бухучет или логистику, или кадровый учет, или сталелитейное дело и т.д. При этом Вы общаетесь с кучей департаментов на их птичьем языке, где бухгалтер считает Вас, ИТ-специалиста, придурком и говорит с Вами через губу. Пока его сбивчивую речь не поймете, до хранимых функций или процедур даже не дойдете. Какая тут шаблонизация или ИИ? Тут безуспешное разгребание дерьма на этапе прототипирования, а часики-то тикают - гендир ждать не будет. Утром же планерка, и кому-то нужно срочно отчитаться о результатах работы транспортного цеха на ликероводочном заводе или АЭС

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

Нейронка хороша, когда есть возможность шаблонизации / подготовки паттернов. Раньше были макросы, потом какие-то роботы. Теперь ИИ. Все логично. Я тоже пишу годогенераторы, если задачи типовые. Но нетиповых задач кратно больше, поэтому читать ежедневный, простите, "высер" из серии "мы внедрили ИИ, теперь можно не брать кодеров" - это гипернепрофессионально. И по удару в пах сравнимо с "эффективными менеджерами" из недавнего прошлого. Которые тот же мир ИТ и начали разваливать. Сначала взвинтив зп, а потом всех отправив в свободное плавание

я поэтому не читаю ленту, а работаю) бред манагеров читать тоже не хочу

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