Интересно, что будет в смежных рынках труда. Например, если работал в медицинском AI и глубже уходишь в медицину. Или в материаловедение. Много кто из нас кодить пошёл как раз из смежной области.
Теоретически, как я понимаю, почему кодинг так хорошо решается агентами - есть относительно чёткий вариант дискриминировать качество решения тестами. Вводные и выходные параметры ограничены, методология/граф решения тоже более-менее стандартна и ограничена.
Но если задачи чуть сложнее и размытее для агента, возможен комбинаторный взрыв поиска решений. Наверное, не все задачи просто загнать в рамки можно.
DenysА как, нормально без того чтобы потом вычитать код этой самой нейронки? Я всё же вычитывать стараюсь, поэтому моя работа скорее похожа на тимлида у которого бесконечно производительный джун в подчинении - вычитать, направить когда надо, самому руками где-то подпилить (потому что объяснять дольше). И
Естественно, читаю и потом тестирую. В зависимости от задачи иногда выходит в 10 раз быстрее. Допустим, у нас много legacy codes, некоторый написан 20-25 лет назад, есть там и gui на древних технологиях (jsp, например какой-то). Я иногда беру тупо 5 файлов java в каждом по пару сотен и спрашиваю refactoring. Результаты очень приличные, многие с опытом никогда не сделают ничего подобного по качеству. С gui вообще просто пишу типа modernize, мне выдает с новыми технологиями со сохранением вызовов backend с современным дизайном. Я такое буду делать руками месяцами и не сделаю, я не супер frontend специалист. Не говоря уже там про задачи типа добавить фичу какую-то. Какие-то квери, документы все тупо генерю промтами. Правда, боюсь что скоро будет как с калькулятором, типа люди которые регулярно пользуются не могут в уме умножить 5*7.
Привет! Хотел спросить, можно ли рассказывать такую историю на вопрос "расскажи о своей ошибке"? Мне кажется, если ее не совсем правильно подать, то это может сыграть большим минусом.
Кратко: при удалении легаси поля в БД я не заметил один edge case, и из-за этого стало фейлиться создание новых подписок. Как плюс - могу рассказать про сам rollback и про работу в стресс ситуации.
S Привет. Можно, но осторожно. Я бы хотел от такой истории услышать не столько саму причину факапа сколько конкретные действия: - как разрулил кризис в моменте - честную рефлексию по разруливанию: что было хорошо, что было осознанным трейдоффом, где можно было лучше придумать - что сделал, чтобы ситуация не повторилась - как ты убедился, что новые меры эффективныM Если речь о бигтехе и L5+ позициях, то скоуп может быть маловат Но тут надо помнить, что история про удаление поля из БД - это не история про удаление поля из БД, это история про сигналы Интервьюер пытается понять: • Ownership: Какую ответственность вы взяли за проблему? • Impact: Насколько серьезными были последствия и что изменилось после ваших действий? • Scope: Это был локальный баг в одном сервисе или проблема, затрагивающая продукт, несколько команд или клиентов? Тут частая ошибка - оценивать историю через техническую составляющую, кандидату кажется, что интервьюер хочет услышать детали: как именно произошел баг, почему сломался edge case, как устроен rollback и т.д. На деле - это не то, что нужно интервьюверу, это про какую ответственность вы взяли; как действовали во время инцидента; как коммуницировали с командой и стейкхолдерами; какие изменения внесли, чтобы подобная ошибка больше не повторилась
Выглядит как хорошая история. Если в конце истории будет блок о выученных уроках - о том,как не повторить это. Они обычно проверяют несколько вещей - человек готов говорить , что он делает ошибки. Учится на своих ошибках. Если ещё сказать , как потом исправил процессы команды ( например ,добавил чек лист в документацию команды) , то это усилит историю.