По-хорошему разработка архитектуры в любом случае нужна. А на чем можно сэкономить и делегировать аишке, чтобы потом не дорабатывать LLM clean up инженером - уже под вопросом. Мы пришли к выводу, что чем больше "похожесть" решения целевого стека с исходным, тем проще, например, контроллеры nestjs отлично перегоняются через аишку в контроллеры спринга.
В первом случае код достаточно абстрактен, и поскольку действительно нет типов в js, то тут или уточнять промпт или руками править.
по второму - абстрактный код был взят для примера, но, так и быть, давайте пофантазируем, возможно, при получении обьектов из корзины они вычищаются, или, может быть, при создании заказа на событии ОРМ.
На собеседовании мы стараемся подобрать человека, у которого был бы достаточный опыт и знания, чтобы справляться с текущими задачами и проектами, требующими разработчика. Чаще всего нужны крепкие миддлы, которые возьмут на себя поддержку и разработку проектов. Реже мы ищем сеньоров — для решения вопросов архитектуры, выбора технологий и улучшения процессов. Иногда мы берём джуниоров «на вырост», если на собеседовании становится понятно, что у человека, несмотря на пробелы в знаниях, есть потенциал.
В переписывании легаси-кода нет ничего плохого: мы сами переписали и улучшили множество проектов, которые переходили к нам на поддержку. Но если кандидат с порога начинает ругать существующий код и пытаться всё переписать, игнорируя озвученные сроки и мешая рабочим процессам, то, скорее всего, эффективное сотрудничество не сложится. К сожалению, у нас уже были случаи, когда в такой ситуации приходилось расставаться.
Что касается напористости и экспертизы — мы, безусловно, приветствуем высокий уровень знаний и вовлечённость. Однако в силу нашей специфики команда не может состоять только из лидов и сеньоров. Кто-то должен терпеливо выполнять и рутинную работу — и это тоже очень ценно.
Речь не про доверительное общение, а про базовое уважение к тому, в чью команду вы планируете идти работать, только и всего. Да, конечно список субъективный — в самом начале статьи написано, что он основан на опыте)
По-хорошему разработка архитектуры в любом случае нужна. А на чем можно сэкономить и делегировать аишке, чтобы потом не дорабатывать LLM clean up инженером - уже под вопросом. Мы пришли к выводу, что чем больше "похожесть" решения целевого стека с исходным, тем проще, например, контроллеры nestjs отлично перегоняются через аишку в контроллеры спринга.
В первом случае код достаточно абстрактен, и поскольку действительно нет типов в js, то тут или уточнять промпт или руками править.
по второму - абстрактный код был взят для примера, но, так и быть, давайте пофантазируем, возможно, при получении обьектов из корзины они вычищаются, или, может быть, при создании заказа на событии ОРМ.
На собеседовании мы стараемся подобрать человека, у которого был бы достаточный опыт и знания, чтобы справляться с текущими задачами и проектами, требующими разработчика. Чаще всего нужны крепкие миддлы, которые возьмут на себя поддержку и разработку проектов. Реже мы ищем сеньоров — для решения вопросов архитектуры, выбора технологий и улучшения процессов. Иногда мы берём джуниоров «на вырост», если на собеседовании становится понятно, что у человека, несмотря на пробелы в знаниях, есть потенциал.
В переписывании легаси-кода нет ничего плохого: мы сами переписали и улучшили множество проектов, которые переходили к нам на поддержку. Но если кандидат с порога начинает ругать существующий код и пытаться всё переписать, игнорируя озвученные сроки и мешая рабочим процессам, то, скорее всего, эффективное сотрудничество не сложится. К сожалению, у нас уже были случаи, когда в такой ситуации приходилось расставаться.
Что касается напористости и экспертизы — мы, безусловно, приветствуем высокий уровень знаний и вовлечённость. Однако в силу нашей специфики команда не может состоять только из лидов и сеньоров. Кто-то должен терпеливо выполнять и рутинную работу — и это тоже очень ценно.
Речь не про доверительное общение, а про базовое уважение к тому, в чью команду вы планируете идти работать, только и всего. Да, конечно список субъективный — в самом начале статьи написано, что он основан на опыте)
Мы работаем в заказной разработке, у нее есть особенности в плане процессов.
Для нас важно, чтобы человек изначально понимал, что ему предстоит работа над проектами, а не развитие продукта.