Не буду говорить, что кого-то не хватает, однако и не могу сказать, что цифра в 400 кандидатов на одну вакансию реальная.
Я участвую в собесах в своей компании, и у нас были вакансии, которые по 2-3 месяца не могли закрыть, что не соответствует картине, которую мы видим на hh. И это не были нереальные вакансии, где просто "смотрят" кандидатов (а часть вакансий на хх именно такие, эйчары просто собирают базу), более того, в этих вакансиях не искали супер пупер сеньоров, а просто миддлов. И текст вакансии не был нереалистичным, я сама его проверяла и вырезала всякую чушь, не относящуюся к реальной работе.
Откликов довольно много, но там приходят реально странные резюме, где кандидат вообще не подходит под описание. Те что были более менее норм потом ещё раз отсеивались тех. специалистами (в том числе и мной), но там уже по другим причинам. В конце концов людей находили, но если бы эта цифра была более реалистичная, то вакансии закрывались бы гораздо быстрее.
А вот почему на кровельщика меньше откликов, чем на айтишные вакансии, тут я вижу ещё другую причину, люди работающие непосредственно руками используют другие каналы для поиска работы. У меня брат поваром работал, зайдёшь на хх, там 2,5 вакансии, походишь ножками по ресторанам, везде примут без проблем, т.е. реально вакансий на местах гораздо больше, чем на хх, а значит и откликаться там бессмысленно, потому что гораздо быстрее найти работу, просто походив и поспрашивая.
Вот ещё одна теория насчёт большого количества откликов на айти, реально часто вакансии дохлые, их либо не убирают после найма (если вакансия реальная) и продолжают набирать базу, либо они изначально тухлые. И в айти сейчас такая же ситуация, как с кровлей, проще поспрашивать знакомых, где есть реальные вакансии, чтобы точно понимать, что не в пустоту шлёшь.
Ну и конечно не будем забывать, что некоторые эйчары считают, что они гораздо лучше разбираются в том, кто реально подходит под вакансию и часто бреют норм кандидатов из-за каких-то своих приколов, что тоже способствует тому, что вакансия долго висит и набирает отклики.
Да ладно итшный бэкграунд, я вижу кейсы как пытаются войтивайти люди, которые даже базово не понимают как работать с техникой, вплоть до того что фразы "создать папку, открыть файл" вводят в ступор. Вот таким особенно сложно, вообще не понимаю что ими движет. Я сейчас пошла типа в айтишный колледж, в свое время вышку не дожала, 500 лет прошло, решила хоть средне-специальное получу, почему бы и нет. И вот там столкнулась с такими кадрами.
"Вышку не дожала" не потому что не справилась, а потому что работала полный день уже, и в универе несколько преподов не пошли навстречу и просто валили меня. Эмоционально в тот момент я не вытянула, поэтому отчислилась.
Далеко не во всех компаниях есть отдельная позиция архитектора, да что там про архитектора, редко где разделяют тим/тех лида. Так что я просто не ударялась в термины, обычно от сеньора ожидают, что он может что-то спроектировать или даже нести роли как и тех. лида, так и архитектора. Более того, в компаниях, где есть отдельные роли архитектора и тех. лида, от них все равно ожидают, что они будут выполнять дополнительно и бизнесовые задачи, и фиксить баги. Просто нагрузка в процентах распределяется, условно процентов 60-70 на бизнес, 30-40 на тех задачи. Наверное где-то есть идеальная компания, где архитекторы и тех. лиды занимаются исключительно техническими задачами, однако я таких не видела, да и это непродуктивно на самом деле, слишком частые регрессы будут.
Я лично вообще не понимаю боязни джунов и их обучения. Я учила трех джунов одновременно, будучи единственным нормальным разрабом - в этом варианте да, реально было тяжко, много времени уходило. Однако в идеальном варианте распределения для команды из 4-х человек, а именно джун/2 мидла/сеньор, получается очень хороший баланс. Есть джун на подхвате поделать простенькие задачки, поправить небольшие баги, сделать плановый рефакторинг по готовому решению. Есть 2 мидла на средние и срочные задачи. И есть сеньор на проектирование и какие-то долгие мутные задачи. Вот в таком варианте команда работает максимально эффективно и каждый занимается задачами, которые ему более менее интересны. И на одного джуна аж 3 специалиста, которые могут ему помочь и подкинуть задачку, распределенная нагрузка.
Почему нет подтверждения, есть, я писала об этом в сообщении, что присутствует несколько людей что снижает субъективность оценки. При аттестации присутствуют 2 технических специалиста, руководитель и эйчар. Технические специалисты оценивают харды, эйчар софты, руководитель общее впечатление и performance.
При оценке мы руководствуемся матрицей компетенций, но она довольно большая, и как указано в статье, владеть всем нереально. Так что при технической оценке мы сосредотачиваемся на сильных сторонах человека, и оцениваем общую техническую подготовку и развитие.
Также дополнительно смотрим задачи, насколько они сложные, самостоятельно ли человек их решает, насколько ему нужна помощь в повседневных задачах. В этом помогает просмотр джиры и гитлаба, обратная связь руководителя.
И ещё перед аттестацией формируем опросы, и все люди, кто коммуницирует с этим человеком, заполняют его, оставляя обратную связь. Там вопросы про комфорт в общении, инициативу, сроки, качество выполнения задач и т.д.
В нашей компании тоже есть матрица компетенций, но с ней по факту не очень удобно работать, при проведении аттестаций больше полагаемся на то, что присутствует несколько людей, что позволяет убрать субъективный фактор
А тут вижу очень классные идеи, во-первых её удобно читать засчет правильной ориентации (у нас в колонках грейды, в строках компетенции, что усложняет чтение)
Во-вторых очень прикольная фишка со специализацией, что чем дальше человек продвигается по таблице, тем уже знания, это очень круто
Но вот подтверждение каждой отдельной компетенции с такими условиями (задача или собес) уже выглядит слегка муторно, слишком много придётся общаться для подтверждения на мой взгляд, далеко не все компетенции можно выразить напрямую в задачах, особенно когда идёшь выше
Спасибо за статью, было познавательно, обязательно презентую такой подход)
UPD: для тех, кто считает что это лишняя бюрократия, вы наверное никогда не сталкивались с проблемой предвзятости начальника/лида к вам, или с непониманием как вам получить повышение. Подобные системы грейдирования прозрачны и объективно, и есть за что зацепиться, если заслуженное повышение не дадут
UPD2: тоже есть проблема с людьми, которые давненько получили высокий грейд ещё от начальников и которые уже не соответствуют текущим требованиям, что делать с этим - хз
Я пишу на Vue, и релиз Nuxt 3 также больно отразился на текущем проекте, все сырое, какие-то экспериментальные фичи, большинство пакетов непонятно как адаптировать. У нас на проекте использовался Nuxt 2, как решение для SSR, сейчас все проекты приводим к Vue 3, и обновляться до Nuxt 3 ради Vue 3 - это просто какая-то жесть. По сути новая версия Nuxt - это уже какой-то другой фреймворк. Мы отказались от Nuxt, и SSR реализовали с помощью vite-plugin-ssr (вместе с переходом на vue 3 также переходили с webpack на vite). Т.е. от использования полноценного фреймворка пришли к использованию доп. либы, которую можно контролировать и в которой гораздо меньше магии и непонятных релизов.
Была бы доступна опция composable, я бы использовала её, но так как её нет, я сделала другое решение, которое хотя бы снаружи будет знакомо другим фронтам из команды (с помощью доп. функций)
Но также другим людям, которые прочитают мою статью, и которые хотели использовать классы в проектах - возможно будет более предпочтительный вариант без composable по их каким-то личным предпочтениям
Смысл об этом спорить? Я проектировала решение для проекта, на котором я работаю. Там версия Vue 2.5, composable нет впринципе, а класс мне понадобился сейчас до предполагаемого обновления на Vue 3
Ну как, сам по себе интерес - это не плохо. Но я лично довольно часто вижу джунов, которые хотят и рыбку съесть и.. Они хотят сразу и фронт и бэк, хотя ни в одном еще даже базово не разобрались. Именно джуны чаще всего приходят с просьбой "А можно я какие-то задачи во фронте/бэке поделаю?", хотя работают по другую сторону. И вот это вызывает негатив, так как обучаться на 2 фронта сложно и плохо сказывается на процессе, совершенно разный подход, разные правила, такой джун просто запутается и начнет косячить везде.
Да, можно использовать reactive для версии vue 2.7+, я показала решение для проектов, где нет reactive или где весь проект написан на Options Api и разработчики не хотят смешивать стили.
Для Vue 3 я вижу решение по-другому, так что когда я до неё дойду, я сделаю апдейт своего решения.
Я не работала плотно с Pinia, но своей сути это не меняет. Это стейт-менеджер, его цель иная - глобально распространять данные. Моя цель состоит не в этом, а в сервисах, у которых больше требований к реализации и они по определению не могут быть глобальными.
Есть очень трудозатратные сервисы, поэтому важно, чтобы они создавались только в момент когда нужны, и удалялись из памяти когда не нужны.
Есть сервисы, которые должны откатываться к изначальному состоянию, и класс ты можешь просто пересоздать и привязаться к новому экземпляру, а стейт нет.
Есть сервисы, которые должны существовать в нескольких экземплярах одновременно, что также не способствует основной цели стора.
Просто в данной части статьи я сосредоточилась на том, как спроектировать класс, чтобы ничего не поломалось, потому что нет смысла во всех этих дополнительных экземплярах, если это просто будет невозможно нормально встроить.
Пока я исследовала возможности классов в компонентах, я обнаружила, что есть чёткие требования, как должна быть организована та или иная функциональность, чтобы данные не терялись - так что в этой части я сосредоточилась на этих требованиях.
Подскажите пожалуйста, каким образом система реактивности Vue 3 решит такие проблемы, как сохранение реактивности, валидация, защита данных (т.е. запрет на изменения)?
Несмотря на то, что я показываю решение на Vue 2, но суть этой конкретной части сводится к тому, как спроектировать класс так, чтобы с ним было удобно и безопасно работать. И те примеры организации работы с данными подходят на самом деле для любой версии Vue.
Конкретно то, как класс встраивается - про это я писала в UPD, что так он был встроен для показа примеров, это не лучшее решение. Но это база, на чем строится уже моё решение.
Любопытно, тоже был опыт поиска работы на частичную занятость по личным обстоятельствам, но у меня все прошло гладко. Нашла место работы, где нормально к этому отнеслись и на нормальную ставку. Но я ещё искала проектную деятельность, а в результате нашла более менее постоянное место работы. Может вам попробовать поискать временные вакансии?
Я например сейчас работаю на проекте, где использован Vuex, и другие зависимости вводить соответственно не очень. Плюс в нативке как никак разобраться можно без дополнительных запросов в гугл.
В целом я знакома с mobx, и работала с ним на реакте. Вроде как есть реализация под Vue, надо будет глянуть, как они это сделали.
Насчёт того, что приходится помнить особенности фреймворка, согласна. У меня была идея сделать декораторы, чтобы объявление свойства в классе могло выглядеть как-то так:
Для бизнеса "скрипт для автоматизации рутины" имеет такую же ценность как знание SQL у фронта, то есть никакое. А вопрос зарплаты тем более не зависит от навыка разработчика, потому что бизнес никогда не поймёт, хороший разработчик или нет (тем более рядовой, чья функциональность и скорость зависит в том числе от команды и процессов). Зарплата зависит только от наглости и умения себя подать.
У меня был знакомый который ещё в доковидные времена зарабатывал около 500к в месяц, думаете потому что он что-то знал? Он ничего не знал, просто умел себя подать, правда он вылетал конечно после испытательного срока, но это ему не мешало находить новую работу.
Я была хорошим (не отличным) спецом на зарплате до 50к 2 года. Когда я научилась себя правильно подавать, и просто стала более наглой, я апнула свою з/п в 3 раза за пару месяцев (мне дали несколько повышений подряд).
UPD: эта ситуация была несколько лет назад, и все дальнейшие повышения з/п работали точно также, хоть у меня и хороший навык, но сильно большее влияние играет то, что я знаю себе цену, и могу это аргументировать, чем какие-то конкретные достижения.
Не буду говорить, что кого-то не хватает, однако и не могу сказать, что цифра в 400 кандидатов на одну вакансию реальная.
Я участвую в собесах в своей компании, и у нас были вакансии, которые по 2-3 месяца не могли закрыть, что не соответствует картине, которую мы видим на hh. И это не были нереальные вакансии, где просто "смотрят" кандидатов (а часть вакансий на хх именно такие, эйчары просто собирают базу), более того, в этих вакансиях не искали супер пупер сеньоров, а просто миддлов. И текст вакансии не был нереалистичным, я сама его проверяла и вырезала всякую чушь, не относящуюся к реальной работе.
Откликов довольно много, но там приходят реально странные резюме, где кандидат вообще не подходит под описание. Те что были более менее норм потом ещё раз отсеивались тех. специалистами (в том числе и мной), но там уже по другим причинам. В конце концов людей находили, но если бы эта цифра была более реалистичная, то вакансии закрывались бы гораздо быстрее.
А вот почему на кровельщика меньше откликов, чем на айтишные вакансии, тут я вижу ещё другую причину, люди работающие непосредственно руками используют другие каналы для поиска работы. У меня брат поваром работал, зайдёшь на хх, там 2,5 вакансии, походишь ножками по ресторанам, везде примут без проблем, т.е. реально вакансий на местах гораздо больше, чем на хх, а значит и откликаться там бессмысленно, потому что гораздо быстрее найти работу, просто походив и поспрашивая.
Вот ещё одна теория насчёт большого количества откликов на айти, реально часто вакансии дохлые, их либо не убирают после найма (если вакансия реальная) и продолжают набирать базу, либо они изначально тухлые. И в айти сейчас такая же ситуация, как с кровлей, проще поспрашивать знакомых, где есть реальные вакансии, чтобы точно понимать, что не в пустоту шлёшь.
Ну и конечно не будем забывать, что некоторые эйчары считают, что они гораздо лучше разбираются в том, кто реально подходит под вакансию и часто бреют норм кандидатов из-за каких-то своих приколов, что тоже способствует тому, что вакансия долго висит и набирает отклики.
Да ладно итшный бэкграунд, я вижу кейсы как пытаются войтивайти люди, которые даже базово не понимают как работать с техникой, вплоть до того что фразы "создать папку, открыть файл" вводят в ступор. Вот таким особенно сложно, вообще не понимаю что ими движет. Я сейчас пошла типа в айтишный колледж, в свое время вышку не дожала, 500 лет прошло, решила хоть средне-специальное получу, почему бы и нет. И вот там столкнулась с такими кадрами.
"Вышку не дожала" не потому что не справилась, а потому что работала полный день уже, и в универе несколько преподов не пошли навстречу и просто валили меня. Эмоционально в тот момент я не вытянула, поэтому отчислилась.
Далеко не во всех компаниях есть отдельная позиция архитектора, да что там про архитектора, редко где разделяют тим/тех лида. Так что я просто не ударялась в термины, обычно от сеньора ожидают, что он может что-то спроектировать или даже нести роли как и тех. лида, так и архитектора. Более того, в компаниях, где есть отдельные роли архитектора и тех. лида, от них все равно ожидают, что они будут выполнять дополнительно и бизнесовые задачи, и фиксить баги. Просто нагрузка в процентах распределяется, условно процентов 60-70 на бизнес, 30-40 на тех задачи. Наверное где-то есть идеальная компания, где архитекторы и тех. лиды занимаются исключительно техническими задачами, однако я таких не видела, да и это непродуктивно на самом деле, слишком частые регрессы будут.
Я лично вообще не понимаю боязни джунов и их обучения. Я учила трех джунов одновременно, будучи единственным нормальным разрабом - в этом варианте да, реально было тяжко, много времени уходило. Однако в идеальном варианте распределения для команды из 4-х человек, а именно джун/2 мидла/сеньор, получается очень хороший баланс. Есть джун на подхвате поделать простенькие задачки, поправить небольшие баги, сделать плановый рефакторинг по готовому решению. Есть 2 мидла на средние и срочные задачи. И есть сеньор на проектирование и какие-то долгие мутные задачи. Вот в таком варианте команда работает максимально эффективно и каждый занимается задачами, которые ему более менее интересны. И на одного джуна аж 3 специалиста, которые могут ему помочь и подкинуть задачку, распределенная нагрузка.
На связи девушка, сеньор, тех. лид, что-то там ещё, программирую руками, вы видимо истинно мужским местом 😉
Почему нет подтверждения, есть, я писала об этом в сообщении, что присутствует несколько людей что снижает субъективность оценки. При аттестации присутствуют 2 технических специалиста, руководитель и эйчар. Технические специалисты оценивают харды, эйчар софты, руководитель общее впечатление и performance.
При оценке мы руководствуемся матрицей компетенций, но она довольно большая, и как указано в статье, владеть всем нереально. Так что при технической оценке мы сосредотачиваемся на сильных сторонах человека, и оцениваем общую техническую подготовку и развитие.
Также дополнительно смотрим задачи, насколько они сложные, самостоятельно ли человек их решает, насколько ему нужна помощь в повседневных задачах. В этом помогает просмотр джиры и гитлаба, обратная связь руководителя.
И ещё перед аттестацией формируем опросы, и все люди, кто коммуницирует с этим человеком, заполняют его, оставляя обратную связь. Там вопросы про комфорт в общении, инициативу, сроки, качество выполнения задач и т.д.
В нашей компании тоже есть матрица компетенций, но с ней по факту не очень удобно работать, при проведении аттестаций больше полагаемся на то, что присутствует несколько людей, что позволяет убрать субъективный фактор
А тут вижу очень классные идеи, во-первых её удобно читать засчет правильной ориентации (у нас в колонках грейды, в строках компетенции, что усложняет чтение)
Во-вторых очень прикольная фишка со специализацией, что чем дальше человек продвигается по таблице, тем уже знания, это очень круто
Но вот подтверждение каждой отдельной компетенции с такими условиями (задача или собес) уже выглядит слегка муторно, слишком много придётся общаться для подтверждения на мой взгляд, далеко не все компетенции можно выразить напрямую в задачах, особенно когда идёшь выше
Спасибо за статью, было познавательно, обязательно презентую такой подход)
UPD: для тех, кто считает что это лишняя бюрократия, вы наверное никогда не сталкивались с проблемой предвзятости начальника/лида к вам, или с непониманием как вам получить повышение. Подобные системы грейдирования прозрачны и объективно, и есть за что зацепиться, если заслуженное повышение не дадут
UPD2: тоже есть проблема с людьми, которые давненько получили высокий грейд ещё от начальников и которые уже не соответствуют текущим требованиям, что делать с этим - хз
Я пишу на Vue, и релиз Nuxt 3 также больно отразился на текущем проекте, все сырое, какие-то экспериментальные фичи, большинство пакетов непонятно как адаптировать. У нас на проекте использовался Nuxt 2, как решение для SSR, сейчас все проекты приводим к Vue 3, и обновляться до Nuxt 3 ради Vue 3 - это просто какая-то жесть. По сути новая версия Nuxt - это уже какой-то другой фреймворк. Мы отказались от Nuxt, и SSR реализовали с помощью vite-plugin-ssr (вместе с переходом на vue 3 также переходили с webpack на vite). Т.е. от использования полноценного фреймворка пришли к использованию доп. либы, которую можно контролировать и в которой гораздо меньше магии и непонятных релизов.
Была бы доступна опция composable, я бы использовала её, но так как её нет, я сделала другое решение, которое хотя бы снаружи будет знакомо другим фронтам из команды (с помощью доп. функций)
Но также другим людям, которые прочитают мою статью, и которые хотели использовать классы в проектах - возможно будет более предпочтительный вариант без composable по их каким-то личным предпочтениям
Смысл об этом спорить? Я проектировала решение для проекта, на котором я работаю. Там версия Vue 2.5, composable нет впринципе, а класс мне понадобился сейчас до предполагаемого обновления на Vue 3
Ну как, сам по себе интерес - это не плохо. Но я лично довольно часто вижу джунов, которые хотят и рыбку съесть и.. Они хотят сразу и фронт и бэк, хотя ни в одном еще даже базово не разобрались. Именно джуны чаще всего приходят с просьбой "А можно я какие-то задачи во фронте/бэке поделаю?", хотя работают по другую сторону. И вот это вызывает негатив, так как обучаться на 2 фронта сложно и плохо сказывается на процессе, совершенно разный подход, разные правила, такой джун просто запутается и начнет косячить везде.
Да, можно использовать
reactiveдля версии vue 2.7+, я показала решение для проектов, где нетreactiveили где весь проект написан на Options Api и разработчики не хотят смешивать стили.Для Vue 3 я вижу решение по-другому, так что когда я до неё дойду, я сделаю апдейт своего решения.
Я не работала плотно с Pinia, но своей сути это не меняет. Это стейт-менеджер, его цель иная - глобально распространять данные. Моя цель состоит не в этом, а в сервисах, у которых больше требований к реализации и они по определению не могут быть глобальными.
Есть очень трудозатратные сервисы, поэтому важно, чтобы они создавались только в момент когда нужны, и удалялись из памяти когда не нужны.
Есть сервисы, которые должны откатываться к изначальному состоянию, и класс ты можешь просто пересоздать и привязаться к новому экземпляру, а стейт нет.
Есть сервисы, которые должны существовать в нескольких экземплярах одновременно, что также не способствует основной цели стора.
Просто в данной части статьи я сосредоточилась на том, как спроектировать класс, чтобы ничего не поломалось, потому что нет смысла во всех этих дополнительных экземплярах, если это просто будет невозможно нормально встроить.
Пока я исследовала возможности классов в компонентах, я обнаружила, что есть чёткие требования, как должна быть организована та или иная функциональность, чтобы данные не терялись - так что в этой части я сосредоточилась на этих требованиях.
Подскажите пожалуйста, каким образом система реактивности Vue 3 решит такие проблемы, как сохранение реактивности, валидация, защита данных (т.е. запрет на изменения)?
Несмотря на то, что я показываю решение на Vue 2, но суть этой конкретной части сводится к тому, как спроектировать класс так, чтобы с ним было удобно и безопасно работать. И те примеры организации работы с данными подходят на самом деле для любой версии Vue.
Конкретно то, как класс встраивается - про это я писала в UPD, что так он был встроен для показа примеров, это не лучшее решение. Но это база, на чем строится уже моё решение.
Некоторые новички думают, что после N МЕСЯЦЕВ работы, человек постигает дзен)
Не ругайтесь за капс, писала с телефона, не знаю как отсюда жирный шрифт сделать
UPD: 5 лет прошло, а N месяцев все не прошло :(
Согласна, поэтому я это описала в блоке "меня всему научат") так как в нашей профессии самообучение остаётся главной движущей силой
Это довольно частая ситуация, когда джуны видят проблему тяжелее, чем она есть, поэтому иногда необходим хотя бы намёк, что гуглить-то.
Любопытно, тоже был опыт поиска работы на частичную занятость по личным обстоятельствам, но у меня все прошло гладко. Нашла место работы, где нормально к этому отнеслись и на нормальную ставку. Но я ещё искала проектную деятельность, а в результате нашла более менее постоянное место работы. Может вам попробовать поискать временные вакансии?
Вы можете посмотреть во 2-й части моей статьи, как даже с синглтон классом делать данные реактивными в компонентах
Я например сейчас работаю на проекте, где использован Vuex, и другие зависимости вводить соответственно не очень. Плюс в нативке как никак разобраться можно без дополнительных запросов в гугл.
В целом я знакома с mobx, и работала с ним на реакте. Вроде как есть реализация под Vue, надо будет глянуть, как они это сделали.
Насчёт того, что приходится помнить особенности фреймворка, согласна. У меня была идея сделать декораторы, чтобы объявление свойства в классе могло выглядеть как-то так:
Тогда в этих декораторах можно было бы зашить Vue-специфичную логику. Но в нативном JS декораторы ещё не въехали в стандарт, вот в TS - это возможно.
Для бизнеса "скрипт для автоматизации рутины" имеет такую же ценность как знание SQL у фронта, то есть никакое. А вопрос зарплаты тем более не зависит от навыка разработчика, потому что бизнес никогда не поймёт, хороший разработчик или нет (тем более рядовой, чья функциональность и скорость зависит в том числе от команды и процессов). Зарплата зависит только от наглости и умения себя подать.
У меня был знакомый который ещё в доковидные времена зарабатывал около 500к в месяц, думаете потому что он что-то знал? Он ничего не знал, просто умел себя подать, правда он вылетал конечно после испытательного срока, но это ему не мешало находить новую работу.
Я была хорошим (не отличным) спецом на зарплате до 50к 2 года. Когда я научилась себя правильно подавать, и просто стала более наглой, я апнула свою з/п в 3 раза за пару месяцев (мне дали несколько повышений подряд).
UPD: эта ситуация была несколько лет назад, и все дальнейшие повышения з/п работали точно также, хоть у меня и хороший навык, но сильно большее влияние играет то, что я знаю себе цену, и могу это аргументировать, чем какие-то конкретные достижения.