Не знаю откуда у вас информация про дефицит, нас (в финтехе) при появлении вакансии заваливают резюме уровня мидл+ и выше так, что разгрести не успеваем. Сложно найти именно профессионала, а не 5+ лет оператор конфлюенса
А что делать, если все эти продукты написаны на разных фреймворках?
Я бы подумал, раз их написали на разных фреймворках, значит и связанности быть не должно? В противном случае лучше сменить архитектора.
Выход за рамки вью либы/фреймворка ограничивает использование его фичей. Так можно было и компоненты на чистом js+css написать и вставлять в контейнеры html.
А то что вы описали про встраивание виджетов других команд решается на уровне сборки микрофронтов, в т.ч. module federation.
Короче на мой взгляд пользы не видно, только проблемы с поддержкой + необходимость вкатываться для новых членов команды
Спасибо за список тем, добавлю кое что в свой чек лист.
Тоже имею приличный опыт найма на разные позиции и в разные компании, добавлю пару субъективных моментов по поводу найма опытных разрабов. Собес по фиксированным темам в текущих реалиях мне кажется не самым эффективным. При большом потоке за ограниченное время надо понять, что человек соответствует вакансии. Поэтому я стараюсь в первую очередь определить валидность опыта в резюме и глубину понимания того, чем он занимался на прошлом месте работы. Мне не так важен полный охват смежных тем, как то, насколько человек глубоко умеет копать. Если например в новом проекте будет стриминг видео, то он сможет сесть и освоить его также быстро, как делал с специфическими технологиями на прошлом проекте. И определяющий этап для меня уже не собес, а испытательный срок, на код ревью все становится на свои места.
Кстати если бы вы проводили у меня собес с опросом по всем этим темам, думаю на синьора я бы не прошел
Если в вашем коллективе допускается, что через пару дней новичка можно выпустить в свободное плавание и пусть делает как хочет, то это скорее свидетельствует о низких стандартах качества кода и фривольности в разработке
Наверное тут стоит уточнить, что новичок - это именно новый член команды, а не джун или стажер. Не совсем понял про свободное плавание, есть код ревью и командный код стайл. Фронт разраб через пару дней уже может начать красить кнопки и менять шрифты, не вижу тут какой то проблемы. Возникающие вопросы обсуждаются на созвоне с лидом, всё как обычно, и так было абсолютно во всех коллективах, от стартапов до энтерпрайзов и финтехов, на качество никто не жаловался.
В FSD нет абсолютно ничего сверхъестественного.
Я рассказываю про свой субъективный опыт и не претендую на истину. Я сидел с документацией и выступлениями авторов больше двух недель и пришел к выводу, что данная концепция вносит больше проблем и неопределенностей, даже если вынести за скобки то, что каждому члену команды придется изучить дополнительный уровень абстракций.
Организация файловой структуры в рамках используемых технологий фреймворков и сборщиков призвана упрощать разработку, в идеале чтобы каждый интуитивно понимал что за что отвечает, и получал удовольствие от разработки, а не ежедневный батхёрт на код ревью от споров с коллегами по поводу концепций.
Также является показательным, что вам уже на старте приходится отклоняться от правил и принимать некоторые допущения, натягивать концепцию на фреймворк. Любая стандартная файловая структура легла бы без этой головной боли.
В общем спустя время ждем честный фидбек, пока выглядит как работа ради работы.
Ничего не значащая деталь или немотивированный эйджизм?
Я отразил факты: молодые забили, более зрелые(в моральном и этическом плане) их прикрывают. Дальше кто хочет ущемиться, может натянуть ситуацию на либеральный термин
Так доделывают или они переносят?
Не вижу противоречий. Те таски, которые не горят для заказчика, переносят. Срочные передают другим разрабам, которые на связи и готовы подстраховать.
То есть их грузят чужой работой, а они безропотно везут ?
Не безропотно, люди недовольны и поднимают вопрос. Данная статья тоже не из пустого места родилась, пускай выводы, которые в ней делаются, многим неприятны.
Добавлю апдейт, на той неделе одного из оверемплоеров уволили в течении пары дней, по понятным причинам был оформлен по ИП. Второй начал было работать, но опять стал на пол дня пропадать, думаю отправится следом - дело времени.
Если это страница с калькулятором за деньги заказчика - то вполне. Если же страница, чтобы о ней написать на хабре, то лучше создать виджеты фичи и энтити
Имея за плечами n количество проектов, в том числе пару на fsd, так и не понял в чем его профит. История этой штуки выглядит как "мы изначально сделали плохо, потом попытались полностью переделать и стало чуть получше, но все равно сложно". Лично я считаю, что хорошая структура, это когда новый разраб через пару дней уже может делать новые фичи, с фсд так не работает.
Согласен с автором. Прямо сейчас наблюдаю в одной из команд как 2 молодых разраба постоянно переносят свои таски из спринта в спринт, некоторые уже 5+ раз (на них делается пометка), а лиды в команде точно такие, как описывают некоторые комментаторы - очень эмпатичные и чувствительные, не дай бог задеть чувства высококвалифицированных специалистов. Они даже не догадываются, как эти разрабы над ними угорают, когда рассказывают корешам, как у них получилось устроиться на две работы и обмануть систему.
Их работу доделывают более зрелые, и, видимо в их глазах, более наивные коллеги. Для которых ответственность и честность не пустой звук.
Неоднократно посещал собеседования от различных подразделений сбера из спортивного интереса, и таких схем там не было. В общем случае ~15-20 минут поверхностных тех. вопросов (интервьюер производил грустное впечатление), остальная часть - в уговорах выйти на работу именно к ним.
Кто то пишет про зп х2, не знаю на какие позиции такое есть, сейчас синьор разрабочики все предложения сильно ниже рынка, да еще и фулл офис, не представляю кто на такое соглашается
активно пытаются пылесосить самый низ рынка по конкретному грейду, большинство предложений вас бы не устроила по вилке
Не знаю откуда у вас информация про дефицит, нас (в финтехе) при появлении вакансии заваливают резюме уровня мидл+ и выше так, что разгрести не успеваем. Сложно найти именно профессионала, а не 5+ лет оператор конфлюенса
Я бы подумал, раз их написали на разных фреймворках, значит и связанности быть не должно? В противном случае лучше сменить архитектора.
Выход за рамки вью либы/фреймворка ограничивает использование его фичей. Так можно было и компоненты на чистом js+css написать и вставлять в контейнеры html.
А то что вы описали про встраивание виджетов других команд решается на уровне сборки микрофронтов, в т.ч. module federation.
Короче на мой взгляд пользы не видно, только проблемы с поддержкой + необходимость вкатываться для новых членов команды
Спасибо за список тем, добавлю кое что в свой чек лист.
Тоже имею приличный опыт найма на разные позиции и в разные компании, добавлю пару субъективных моментов по поводу найма опытных разрабов. Собес по фиксированным темам в текущих реалиях мне кажется не самым эффективным. При большом потоке за ограниченное время надо понять, что человек соответствует вакансии. Поэтому я стараюсь в первую очередь определить валидность опыта в резюме и глубину понимания того, чем он занимался на прошлом месте работы. Мне не так важен полный охват смежных тем, как то, насколько человек глубоко умеет копать. Если например в новом проекте будет стриминг видео, то он сможет сесть и освоить его также быстро, как делал с специфическими технологиями на прошлом проекте. И определяющий этап для меня уже не собес, а испытательный срок, на код ревью все становится на свои места.
Кстати если бы вы проводили у меня собес с опросом по всем этим темам, думаю на синьора я бы не прошел
Наверное тут стоит уточнить, что новичок - это именно новый член команды, а не джун или стажер. Не совсем понял про свободное плавание, есть код ревью и командный код стайл. Фронт разраб через пару дней уже может начать красить кнопки и менять шрифты, не вижу тут какой то проблемы. Возникающие вопросы обсуждаются на созвоне с лидом, всё как обычно, и так было абсолютно во всех коллективах, от стартапов до энтерпрайзов и финтехов, на качество никто не жаловался.
Я рассказываю про свой субъективный опыт и не претендую на истину. Я сидел с документацией и выступлениями авторов больше двух недель и пришел к выводу, что данная концепция вносит больше проблем и неопределенностей, даже если вынести за скобки то, что каждому члену команды придется изучить дополнительный уровень абстракций.
Организация файловой структуры в рамках используемых технологий фреймворков и сборщиков призвана упрощать разработку, в идеале чтобы каждый интуитивно понимал что за что отвечает, и получал удовольствие от разработки, а не ежедневный батхёрт на код ревью от споров с коллегами по поводу концепций.
Также является показательным, что вам уже на старте приходится отклоняться от правил и принимать некоторые допущения, натягивать концепцию на фреймворк. Любая стандартная файловая структура легла бы без этой головной боли.
В общем спустя время ждем честный фидбек, пока выглядит как работа ради работы.
Я отразил факты: молодые забили, более зрелые(в моральном и этическом плане) их прикрывают. Дальше кто хочет ущемиться, может натянуть ситуацию на либеральный термин
Не вижу противоречий. Те таски, которые не горят для заказчика, переносят. Срочные передают другим разрабам, которые на связи и готовы подстраховать.
Не безропотно, люди недовольны и поднимают вопрос. Данная статья тоже не из пустого места родилась, пускай выводы, которые в ней делаются, многим неприятны.
Добавлю апдейт, на той неделе одного из оверемплоеров уволили в течении пары дней, по понятным причинам был оформлен по ИП. Второй начал было работать, но опять стал на пол дня пропадать, думаю отправится следом - дело времени.
Если это страница с калькулятором за деньги заказчика - то вполне. Если же страница, чтобы о ней написать на хабре, то лучше создать виджеты фичи и энтити
Имея за плечами n количество проектов, в том числе пару на fsd, так и не понял в чем его профит. История этой штуки выглядит как "мы изначально сделали плохо, потом попытались полностью переделать и стало чуть получше, но все равно сложно". Лично я считаю, что хорошая структура, это когда новый разраб через пару дней уже может делать новые фичи, с фсд так не работает.
Согласен с автором. Прямо сейчас наблюдаю в одной из команд как 2 молодых разраба постоянно переносят свои таски из спринта в спринт, некоторые уже 5+ раз (на них делается пометка), а лиды в команде точно такие, как описывают некоторые комментаторы - очень эмпатичные и чувствительные, не дай бог задеть чувства высококвалифицированных специалистов. Они даже не догадываются, как эти разрабы над ними угорают, когда рассказывают корешам, как у них получилось устроиться на две работы и обмануть систему.
Их работу доделывают более зрелые, и, видимо в их глазах, более наивные коллеги. Для которых ответственность и честность не пустой звук.
Неоднократно посещал собеседования от различных подразделений сбера из спортивного интереса, и таких схем там не было. В общем случае ~15-20 минут поверхностных тех. вопросов (интервьюер производил грустное впечатление), остальная часть - в уговорах выйти на работу именно к ним.
Кто то пишет про зп х2, не знаю на какие позиции такое есть, сейчас синьор разрабочики все предложения сильно ниже рынка, да еще и фулл офис, не представляю кто на такое соглашается