Меня одного раздражает волна нытья «джунов»-недоучек? Ну ладно бы люди, которых обманули на курсах, будто из них сделают итшников с охеревшей зпшкой, столкнувшись с реальностью, поняли бы что надо подтягивать навык и учиться дальше. Но нет, они ноют что к ним предъявляют сеньорские требования. Это не требования сеньорские, это вы тупые. Перестаньте, пожалуйста, тянуть индустрию ко дну, айтишник это, в первую очередь, инженер.
Серьезно, блять? То есть, вот такое - это норма для джуна? А такое, на минуточку, я встречаю в каждой третьей вакансии.
И нахуй кому то такой специалист? Кто в твоем коде разбиоаться должен если ты сам не понимаешь что пишешь?
Знакомо ))
Ну вот как бы ревью это еще и "Эй, придурок, молодец, ты вот это сейчас написал, а через полгода у тебя глаза на лоб полезут, когда попытаешься к этому вернуться. Поэтому вот это перепиши вот так, а это - вот так. А будешь лениться комментарии с docstrings писать, получишь пиздюлей".
Я один раз запилил фичу, которая используется гугловские АПИ, которые работают с гугловской почтой и таблицами. Когда эта хуйня на миллиард строк заработала, то я ей восхищался сильнее тех, кто мне ставил задачу. Они мне такие, как мол это работает, а я хз даже как объяснить. Нормально, говорю, работает. А потом пришли китайцы и забрали у нас проект. И вот как они с этим потом разбирались, я вообще не представляю) )
Требования в вакансиях в 90% пишут HR, вернее копипастят с одного шаблона который им один раз дал инженер, при этом не особо понимая суть и не отличая не то что стек технологий, но даже джуна от синьора.
Ниразу не видел, чтобы инженер писал описание к вакансии, тем более на регулярной основе.
Ошибаетесь. Я HR, пишу только то, что мне дают лиды+обсуждаю каждую вакансию с ними устно. К слову, hrов в ит любят хаять, мол вакансии плохо пишут, фидбек не дают, на сбс дебильные вопросы спрашивают, тесты подсовывают.... Так вот, я сейчас открою для кого то тайну, это не мы. Нам важно закрыть вакансию, т.к существует план закрытий, если его не выполняешь, тебя ебут со всех сторон начиная с лида того отдела, где открыта вакансия, заканчивая гендиром.Вот и выходит, что 95% всех проблем создают себе сами итшники.
Так вот я же и объясняю почему мы не даем фидбек: классическая ситуация, нашел кандидата, написал, созвонился, даже по видео поговорили. Кидаем тимлиду и на той стороне тишина... Начинаешь писать, ловить в офисе, получаешь ответ, что не нравится ( не конкретные причины, а просто вот так) ... На все это может уходить до недели реального времени. Если кандидат сам пишет мне все это время с вопросами, я всегда отвечаю, чаще всего честно, что вот такие вот мы тормоза... А если не пишет... Я вот считаю, что кидать отказ человеку в активном поиске, через неделю-полторы после разговора по телефону про который он скорее всего даже забыл, да еще с формулировкой "наш лид на тебя забил", это еще большее неуважение и дизмораль чем просто отсутствие ОС.
Если кратко, то hr часто сам не может получить фидбек от заказчика, и это массовая проблема.
Потому, я и пишу 95% проблем итшников они создают сами себе, ибо как только забираются чуть повыше миддла, то такое ощущение, мгновенно забывают какого это искать работу, не получать норм фидбек, и отвечать на дурацкие вопросы
Я, если что, синьор админ. И даже мне чаще всего этот самый фидбэк не дают, при поиске работы. Правда обычно я долго и не ищу её.
А чего вам мешает построить подбор на метриках и вносить(по согласованию) корректировки на этапах воронки с низкой конверсией? Тогда у вас будет аргументация, мол, нанимающий менеджер - долбоеб, вот вам цифирьки, давайте менять портрет кандидата или требования или коридор
Ничего. На самом деле сейчас так все и работают, есть crm типа estaff, huntflow и т. п. В которых ведется данная аналитика (самое простое, количество приглашений, встреч, офферов). Проблем несколько:
1. Не всегда есть возможность что то поменять; кандидат с неким набором скиллов хочет 200, а бизнес готов платить только 180. Пока до бизнеса доходит сей факт, кандидаты начинают хотеть уже 220
2.Человеческий фактор; в споре hr vs teamlead всегда побеждает лид, во всяком случае, в средних компаниях (там много моментов, и не всегда лид козел, но это реально долго дискутировать).
3.Технические ограничения; сейчас многие коллеги жалуются, что те инструменты аналитики которые предоставляют вышеуказанные программы не показывают всю картину, или их сложно вести (надо настраивать под компанию, а на это обычно нет сил, времени, навыков).
P. S.
В продолжение 3 пункта, в предыдущей продуктовой компании в которой я работал такой crm не было т.к. руководители отделов в принципе не желали с ней работатьработать (тут конечно косяк нашего отдела)
Блин, ну тут ещё надо понимать, что джун джуну рознь. Требования к джуну в space X очевидно будут соизмеримы с требованиями к сеньору в мелкой компании. Но то, что мелкие компании запросто могут подсмотреть эти требования и сказать "нам тоже надо такого джуна" это факт. В этом очень большая проблема для начинающих. Мало того, что демотивируют постоянно возрастающие требования, так ещё путаница с градациями и компетенциями даёт возможность маленьким царькам бесноваться.
Я бы больше поставила не на то, что смотрят требования больших компаний, а на то, что начальство покусала эффективная сова: а давайте требования напишем для мидла, назовем это джуном, будем ему платить в полтора раза меньше и спрашивать в полтора раза больше.
1. В спейс Х, как и в Тесле, нихуя не высокие зарплаты.
2. Причем тут компания, джун это определенный уровень знаний и опыта, в данном случае это человек просто знающий основы программирования и синтаксис, плюс небольшой опыт. И уж никак не умение ревьювить чужой код или заниматься менторством, это вообще бред и реально уровень крепкого мидла или даже синьора, а вообще такими вещами уже тим лид должен заниматься.
на картинке выше хотят джуна с опытом от 2-х лет.
ахуевшие ХРюшки просто тупорылые пёзды, ебашат, не вчтитываясь.
они ебашат то, что им высрет ведущий спец или лид. по крайней мере, в нормальной конторе ХР точно не будет заниматься самодеятельностью, ибо этот поиск стоит денег всей конторе, одна жалоба "у меня спец уже полгода ищется, хотя требования базовые", и если подтвердится версия пострадавшего, ХРу такой пизды вставят, что улетит быстро
а вот если сам лид такую хуйню гонит, то это просто признак того, что тебе туда не надо. да, это сокращает выборку вакансий, но лучше уж устроиться в что-то относительно приличное и не вспоминать, как это место работы наградило тебя ПТСРом, а дало ценный опыт и возможности развития
и то, что на скрине, явно из категории "ну его нахуй"
А что не так в вакансии?
Реализовывайте пет-проекты, пока нет большого опыта.
Учитесь. Покажите что вы хотите развиваться.
Никто вам авансом ничего не должен платить.
Вы приходите в дорогую относительно прочих профессий отрасль. Подумайте и ответьте себе - почему она дорогая?
А что не так в вакансии?
Вы серьезно?
Вы искренне считаете, что джун способен ревьюить чужой код и менторствовать, пусть даже по желанию?
Вы искренне считаете, что человек, способный хорошо спроектировать сложный продукт (указано в вакансии) это, блять, джун с джуниорской зарплатой?
Не говоря уж о "умение самостоятельно решать возникшие проблемы", хотя в нормальной команде джун как раз работает под присмотром и, в случае возникновения проблемы, ожидаемо будет обращаться за помощью, пусть даже в духе "я не знаю, как правильно решать: у меня есть вариант один, вариант два, какой из них оптимальнее?"
Ревью кода — это не только палки накидать, это ещё и образовательный процесс. Посмотреть как решалась задача более опытным коллегой.
В вакансии ни слова нет про «хорошо проектировать» есть упоминание практического опыта, который, внезапно, приобретается во время обучения.
Умение самостоятельно решать проблемы — это навык гуглить. А не тупо бежать за советом.
Это вакансия для Джуна а не практика для студента второго курса
Посмотреть как решалась задача более опытным коллегой.
Да, это ЕЩЕ и образовательный процесс, но это вторично. А первично - именно что накидать палок. Отрецензировать. А для этого нужно обладать навыками как минимум не ниже. Можно узнать, что может отрецензировать джун, который пусть даже сделал несколько пет-проектов, но без обратной связи, без понимания, где он совершал ошибки?
В вакансии ни слова нет про «хорошо проектировать»
А давайте не будем натягивать сову на глобус? Нигде в вакансиях не пишут "нам нужен человек, который именно ХОРОШО делает свою работу", но это всегда подразумевается.
А конкретно в этой вакансии требуется не просто практический опыт, а опыт работы над а) сложными проектами и б) над той их частью, которой джуны в команде не занимаются.
Умение самостоятельно решать проблемы — это навык гуглить. А не тупо бежать за советом.
Нет. Умение самостоятельно решать проблемы - это умение из всех вариантов выбрать оптимальный для решения конкретной задачи. Джун этим навыком не обладает, потому как раз он ищет несколько вариантов решения и приходит с вопросом "а какой из этих способов правильный здесь и сейчас и почему".
Простите, а причем тут тимлид, если его специфическая задача - это организация работы команды?
Он по уровню написания кода вполне может находиться на уровне сеньор-мидл+.
Нет, на этом уровне уже настолько размытые границы между градациями, что уверенный мидл вполне может быть вровень с сеньором и увидеть то, что в запарке проморгал сеньор.
А вот джун - нет, не сможет.
Именно. Не обязательно обладать навыками не ниже коллеги
Не совсем так.
Джун способен отследить только небольшую группу простых ошибок в коде сеньора. Потому что его навык СИЛЬНО ниже, чем у коллег.
Мидл справится неплохо, потому что его навык не принципиально уступает сеньоровскому, особенно если они давно работают в одной команде, и есть привычный шаблон этого процесса.
Должен ли джун присутствовать в процессе обсуждения? Да, вы все правильно написали, это элемент учебы. Но именно в качестве учебы, а не в качестве полноправного рецензента.
А претензия в том, что написанное в вакансии мной лично воспринимается именно так. Следующим пунктом после менторства (хоть обязательного, хоть необязательного) я это читаю как "это будет твоя задача, а не учеба, ты несешь ответственность за полученный результат". И вот если работодатель именно это имеет в виду, то да, это ни разу не джуниорская задача.
И вообще, лично мне сложно представить, что работодатель будет дрючить джуна за ревью.
Если почитать ветки выше про интервью, то, похоже, причин дрючить джуна может найтись такое великое множество... :D
Хорошо, напишите, пожалуйста, тогда список требований для мидла и для сеньора.
Потому что все мои коллеги убеждены, что джун - это готовый специалист для решения несложных, типовых задач под руководством наставника и не учавствующий в проектировании кроме как в качестве наблюдателя/задающего вопросы.
Так и есть, джун способен выполнять несложные задачи под наблюдением, мидл делает задачи посложнее с минимальным наставничеством, сеньер делает самое сложное и сам другим говорит что и как делать. Если человек пишет код так что сам нихера не понимает как он работает, то это не джун
Вы написали, что требования в вакансии заниженные.
Напишите, пожалуйста, требования к мидлу и сеньору.
Требования везде примерно одни и те же, разница в опыте и то что сеньер еще и архитектуру способен продумать. Если в компании используется определенный стек, то и джуны и сеньеры работают с этим стеком технологий
Я чет запуталась.
В вакансии от джуна требуется навык разработки архитектуры и применение этого навыка на практике.
Вы пишете, что это - задача сеньора (согласна).
Но при этом вы же пишете, что навыки для джуна занижены.
Не улавливаете никакого противоречия?
В вакансии написано "вместе с командой" это означает что джун должен понимать о чем речь и концепцию этой архитектуры которую придумает команда. Ничего сверхестественного от джуна не требуется
В вакансии требуется опыт проектирования и разработки сложных приложений.
Это явно на порядок выше, чем "просто понимать о чем речь".
Бля, ппц вы перескакиватель с темы на теу.
Пет проект не обязательно сложный.
Если джун в одну харю может на на высоком уровне спроектировать и реализовать сложный проект, он уже не джун. Это ваши слова
"разница в опыте и то что сеньер еще и архитектуру способен продумать"
Я не перескакиваю с темы, я говорю что имеет ввиду работодатель под этими требованиями в резюме. Срм на чистом пхп считается сложным проектом или нет? Это был мой пет проект который помог устроиться на вакансию джуна 10 лет назад. И сейчас он кажется ппц каким простым, хотя раньше я им гордился.
Я блять поражаюсь вам, вы нихера не умеете и считаете это проблемой работодателя. Проблема не в требованиях, проблема в том что вы им не соответствуете
я говорю что имеет ввиду работодатель под этими требованиями в резюме.
Если вы не умеете читать мысли, то вы не знаете, что имеет в виду работодатель.
Не совсем понимаю, что должен проиллюстрировать ваш личный опыт применительно к обсуждению вакансии.
Своими начальными проектами можно гордиться, но при этом даже 10 лет назад можно понимать, что они простые. Одно другому не противоречит.
Можете поражаться дальше, мне достаточно мнения об этой вакансии как о завышенной (а местами даже странной) от людей с опытом работы побольше вашего.
В целом, раз уж разговор свернул в сторону попыток перейти на личности и приведение личного опыта в качестве аргумента, то дальнейшая дискуссия бессмысленна.
хотя в нормальной команде джун как раз работает под присмотром и, в случае возникновения проблемы, ожидаемо будет обращаться за помощью
Круто. Мне вот на первой работе первым делом дали задачу вида "у нас никто не в курсе даже как эту хуергу собирать, но собери сам (у нас свободных людей нет), нам нужны изменения в этом проекте".
Серьёзно? Ты искренне считаешь, что джуну никогда не придётся участвовать в ревью? По-твоему, если джун устроился на джуна, то он им и останется? Или после того, как поймут что джун грейднулся, то его уволят, по причине: мы брали Джуна, а он зачем то дорос до миддла? или как по-твоему происходит рост в айти? По-хорошему, за год работы джун должен влиться в коллектив и принимать активное участие в разработке (и это не только коддинг).
А давайте все таки различать ревью и анализ чужого кода?
Ревью - это в первую очередь, на 90% проверка на качество/ошибки/уязвимые места. И только иногда это "о, как классно сделано! возьму на вооружение!" Для этого нужна квалификация не ниже чем у автора кода.
Анализ - это "Хм, а как это делают более опытные люди? Что это за странная конструкция, пойду погуглю-разберусь".
Так вот, джун способен на ревью разве что у стажерского кода. Но да, анализом он должен заниматься, это и правда отличный навык для него и хорошая политика компании.
Примерно то же самое с проектированием.
Да, он должен знать какие-то паттерны, должен пытаться неидеально это делать. При помощи наставников должен ходить по граблям и развиваться в этом направлении.
Но в вакансии требуют: а) опыт проектирования сложных проектов и б) применение этого опыта в текущей работе. Человек способный на это и на все остальное из вакансии, уже не джун.
Джун, который не умеет делать код-ревью, но у которого есть такая задача, будет смотреть, как это делают другие: на что обращают внимание, почему надо именно так и т.д. Плюс, можно погуглить и поспрашивать, как код-ревью делают более опытные спецы.
Это очень хорошая и полезная практика для роста.
Квалификация не ниже, чем у автора кода, необязательна.
- код может быть идеально написан, но конфликтовать с требованием приложения или логикой других фичей. Джун способен такое заметить
- джуну сегодня на код-ревью указали на ошибку или посоветовали подход получше, завтра он увидит похожее у миддла и сам это укажет на ревью
Код-ревью - это не прямые указания к действию, что плохого в том, что джун будет пробовать предлагать варианты? Тем более, этому надо учиться, и чем раньше начать, тем лучше. Не надо расти до синьора или ждать появления менее квалифицированных сотрудников, чтобы начать ревьювить
Я согласна с вашим подходом.
Но по отношению к вакансиям то, что вы описываете, обычно озвучивают в "условиях работы". Там часто бывает что-то типа "у нас принята практика группового код-ревью". И тогда понятно, что да, ты будешь сначала смотреть со стороны, возможно, проверять на какую-то мелочь типа ошибок в синтаксисе или табов/отступов (с чем, по-хорошему, могут и линты справиться), потом углубляться и расти.
А когда это требование к работнику да еще после пункта о наставничестве, это (по-моему) подразумевает именно твою личную работу по ревью чужого кода с полным пониманием этого процесса и ответственностью за результат своей проверки.
И вот в таком случае я категорически не согласна, что это адекватно позиции джуна.
Да вроде просто написано, что нужно будет принимать участие в код-ревью, без требования какого-то серьезного бэкграунда для этого. Чтобы не было для человека сюрприза, когда у него начнут сходу требовать ревью. Про менторство, конечно, странный пункт для джуна. Но с пометкой "по желанию", может, с прицелом на будущее.
Ревьювить все должны. И даже когда джун ревьювит сеньера польза есть, в большей степени конечно джуну.
Да хоть куда.
Человек, способный самостоятельно работать, участвовать в решении сложных задач на уровне архитектуры, брать на себя значительную долю ответственности и учить других ни в одной компании никогда не будет называться джуном.
А если человек делал всё это только в рамках учебных и личных проектов? То он уже мидл или ещё нет?
Это очень абстрактный вопрос.
Зависит от:
- наличия/отсутствия ментора, который тыкает в ошибки носом (а желательно даже двух, потому что тут как в медицине, два взгляда на диагноз лучше одного)
- от умения эти ошибки потом не забывать и не воспроизводить
- от прогресса сложности этих проектов
- от навыка анализа своего старого кода и запоминания, на какие грабли наступил в процессе, к чему привело вот это решение, а чему - вот это
- от навыка следить за новыми технологиями, а не пользоваться говном мамонта и каменным топором, потому что "ну я так когда-то научился и привык".
Имхо, если джун взял один сложный проект, херово его спроектировал, наговнокодил, не провел анализ, потом наклепал таких же еще пяток штук тупо для количества, то он все равно остался джуном.
Человек, не способный самостоятельно работать, не желающий участвовать в решении сложных задач, не готовый брать на себя ответственность, и не готовый делиться своими знаниями с коллегами, мне например не нужен.
Джун - это не стажёр.
То, что вам кто-то там не нужен, тем не менее не делает требования в вакансии джуниорскими. Вам нужен не джун, а специалист уровнем выше, даже если вы хотите называть его джуном и платить копейки
А джун да, это не стажер. Стажеру не платят.
Почему копейки? Мне нужны люди с зп выше рынка, но готовые и умеющие работать, а не рассказывать про свои трудности. И таких приличное количество. А весь мусор, который решил пойти в отрасль с посылами: научите меня, дайте денег, обижайте меня, не токсичен на меня и т.п., пусть работает где-нибудь в другом месте.
Мне нужны люди с зп выше рынка, но готовые и умеющие работать, а не рассказывать про свои трудности
И все это описание не джуна.
Ну и да, если это все джуновское, напишите тогда список для мидла и сеньора.
Это описание склада характера и подходов к жизни, а не к скиллам.
Джун/мидл/сеньор - это градации профессиональной подготовки. А умение работать/самостоятельность/желание развиваться не за чужой счёт, это личностные качества.
Тогда я не понимаю, почему вы спорите о личностных качествах в ветке про обсуждение профессиональной подготовки.
Чтобы все на пикабу узнали, какой вы дохуя бескомпромиссный и никому не позволите "развиваться за свой счет"?
Есть ветка обсуждения описания какой-то вакансии. В ней указаны вполне себе требования и к личностным качествам. Для меня, как человека, который сам ищет людей иногда, в этой вакансии нет чего-то странного. Особенно в отсутствии указанных вилок и собственно компании.
Я это написал. Вы мне начинаете рассказывать, что я не прав, что Джуны это бестолковые человечки, которых нужно водить по офису за ручку, пилить за них таски и платить как, например, инженеру схемотехнику с 15летним опытом. Мне кажется, что это вы спорите со мной, а не я.
Ну так и напишите в объявлении - "Да, у нас всё серьёзно, у нас это джун, но и денег дадим как мидлу". А если указать требования на мидла, назвать это джуном, а потом "ну смотря чо, смотря куда, смотря каво..." это - лукавство и виляние жопой. Фпесду. Вещи надо называть своими именами.
Эм, чел, ревьювить чужой код джуну, это все что сказать - школа наймет школьника проверять домашние работы других школьников и иногда заменять учителя.
Принимать решение об аппруве джун не может, конечно. Но принимать участие в код-ревью - почему нет? В нормальной команде ему голову не откусят, если напишет бред в комментах. Навыку код-ревью ведь тоже надо учиться.
Нельзя научиться ревьювить код ревьювя код. Это опыт написания кода в различных ситуациях, который дает понимание почему именно в данной ситуации применен данный подход, даже если менее опытному он покажется не самым удачным.
Как учатся джуны? Они смотрят, как что-то делают другие, задают вопросы, гуглят.
Тоже самое с код-ревью: джун посмотрел, как это делают более опытные спецы, на что обращают внимание и т.д и пытается сделать так же.
Синьор на код-ревью указал на проблему, джун запомнил, позже он может эту же проблему найти у других. Это часть процесса обучения.
Синьоры ревьювят синьоров, джуны могут успешно ревьювить джунов. Да и даже синьоров, если код идеальный, но есть логические несостыковки с другими фичами или требованиями. Такое джун вполне может заметить.
Джуны, как и любые другие учатся на своем опыте. Если бы можно было учиться смотря на чужой код, то после курсов все бы выходили синьорами.
Никто не предлагает ТОЛЬКО смотреть в чужой код. Писать свой и смотреть, как это делают более опытные. И смотреть, как ревьювят более опытные и пытаться делать это самому. Это отличная практика, помогающая учиться
Так смотреть как ревьювят опытные это не код ревьювинг, это ютуб просмотринг каналинга deep it...
Если бы это работало, то джунов бы не было, ибо в инете валом индусского кода, бери да ревьюв. Вот только НЕ РАБОТАЕТ такое. Код ревьювить получится только когда наберешься опыта и будешь понимать что, зачем и в какой ситуации можно применять. Если конечно речь не про просто проверку кода на правописание и опечатки (но это и фреймворк делает успешно)....
Ну допустим, один джун применил метод, который идеально тут подходит ввиду каких-то сопутствующих вещей, но при этом, по классике, это не самый рациональный подход. И что? Другой джун сможет это понять? Да нет, конечно, в лучшем случае, он просто скажет что тут нерациональный код и ситуацию придется разруливать тому же тимлиду, да еще и вести беседу на тему почему тут именно такой код. И самое ключевое, ввиду отсутствия опыта, этот проверяющий джун теперь везде и всюду будет применять такой метод, хотя возможно рационален он был лишь в одном этом случае. Ибо это все хуита. Код ревьювить можно лишь имея личный опыт.
Нихуя это не работает. Лучшее обучение - это опыт по поиску решения поставленных задач. Если бы кто-то обучался смотря на чужой код, то и опыт был бы не нужен, бери гитхаб, пройдись по всем выложенным кодам и вуаля ты мегасиньор.
Надеюсь, вы код ревьювите не так, как читаете комментарии.
Где я пишу, что для обучения достаточно только ревьювить код? А вы уже второй раз это оспариваете.
Повторюсь: обучение - это комплексный процесс. Комплексный - значит, состоящий из разных компонентов. И участие в код-ревью - один из этих компонентов.
"Реализовывайте пет-проекты, пока нет большого опыта."
Это просто вопрос отработки навыков и поддержки уровня. Это не про поиск работы, никому петы не усрались на рынке, где меньше 2 лет опыта -> пошёл нафиг
То есть пол года опыта и ты уже умеешь ревьювить чужой код? Круто, давай я тебя на позицию джуна найму с зарплатой джуна а ты будешь ревьювить чужой код и заниматься менторством, ну то есть тем чем у нас тим лид на зарплате синьора-помидора занимается.
Такие требования в вакансиях, чтобы отсеять самоучек со скиллбокса и иже с ним, у которых нет сильной вузовской базы, и которые не умеют самоорганизовываться и самообучаться. Никто в здравом уме не будет просить джуна менторить мидла или ревьюить код сеньора :) скорее они будут перепроверять друг друга код - джун джуна.
То есть выполнять работу тимлида за зарплату джуна и с опытом и знаниями джуна, который скорее наделает еще больше ошибок, чем что-то исправит)) Очень надежный план, точный как киргизские часы.
инженер должен проверять и перепроверять то что делает. в этом и заключается его работа. и данные термины достаточно размыты. Одно дело менторство сеньором джуна, другое джуном сеньора. как уже говорил - никто в здравом уме второго варианта не будет требовать. Тоже и про ревью
Так в том и дело, что указанное в вакансии это либо неверно сформированное, либо просто бред сивого эйчара.
джун может менторить такого же джуна, который чего то не допонял. Ревьюить код такого же джуна. в чём проблема? или джуны все под одну гребенку - одинаково подготовлены?
Нанимать джуна на конкретные задачи связанны обычно с рутинным ручным кодописанием и тратить половину его рабочего времени на бессмысленную деятельность по проверке чужого кода такого же джуна, это, повторюсь, план надежный и точный как часы Алтынпай из Киргизстана.
для этого есть автоматизированные системы проверки кода. ручным трудом то зачем заниматься? да и что то я не замечал, что все требования в вакансиях которые пишут применяются на практике. Тут отсев лоботрясов и скиллфакторщиков на лицо.
Потому что код джуна может проверятся синьором/тим лидом не на опечатки и мелкие ошибки, а в целом на оптимизацию и соответствие остальному коду, т.с. на соответствие общему пазлу.
Можно узнать что это за компания, где джуны проверяют код друг друга, а автоматика проверяет алгоритмы написания кода))))
последний доёб не понял? т.е. чел может писать индусокод и его возьмут джуном? культура программирования важна для начинающих даже больше чем сеньёру.
ну как бы новорожденные человеки тоже не сразу на ноги встают. джун на то и джун, что получает практический опыт сейчас. если опыта уже достаточно, это уже мидл
опыт надо было получать еще в институте на лабораторных. А на работу надо приходить и выполнять поставленные задачи. Если на любую задачу у тебя ответ - я не знаю, зачем учился?
Вуз дает тебе базу и обучает тому как расти профессионально дальше. Ваши курсы "кройки и шитья" не дадут таких знаний, только как обезьянка повторять.
Так что претензии вполне обоснованные от недоучки.
А на работу надо приходить и выполнять поставленные задачи.
у джунов должны быть соответствующие задачи, которые он может выполнить, и задачи на рост, которые может решить сам или с помощью ментора.
Если на любую задачу у тебя ответ - я не знаю, зачем учился?
Если у работника на любую задачу есть решение - он, не будь дебилом, на ставку джуна не пойдет.
опыт надо было получать еще в институте на лабораторных. Вуз дает тебе базу и обучает тому как расти профессионально дальше. Ваши курсы "кройки и шитья" не дадут таких знаний, только как обезьянка повторять.
вуз с лабораторными - в большинстве случаев такие же курсы кройки и шитья, пока вся эта база не подкреплена опытом реальной разработки. а уж какие в вузах топовые разрабы преподают - высшего класса просто (сарказм). аргумент огонь, конечно.
окей, проведем аналогию с тем же вузом - есть первокурсники, второкурсники и тд по порядку (ну, типа как интерн, джун, мидл и тд). в твоем понимании, если чел стал студентом - он должен уже знать/уметь все то-же, что и студент на последнем курсе? ну а хули "опыт надо было в школе получать на факультативах"
Разрабы не смогут преподавать, как раз таки. у них нету педобразования, методик преподавания, разработанного курса чтобы преподавать и миллиона других полезных навыков которые есть у перподов.
Вуз для того и создан чтобы учить с азов. Поэтому аналогия не верна в принципе. На работу ты приходишь чтобы продать свои знания, а не ждать что работодатель тебя всему научит.
Ну и даже если брать аналогию с вузом - то тебя туда и не возьмут если ты не подходишь по определенным знаниям. Для этого ты пишешь вступительные экзамены, пишешь ЕГЭ, а потом каждый семестр доказываешь что можешь учится и получать знания. Если не тянешь то выгонят, так же как и на работе - если не тянешь уволят по статье за профнепригодность.
Разрабы не смогут преподавать, как раз таки. у них нету педобразования, методик преподавания, разработанного курса чтобы преподавать и миллиона других полезных навыков которые есть у перподов.
Так вот оно самое важное! Фейспалмжпг. Чтобы что-то уметь на практике, а не на корочке - важнее работать на реальных проектах, обмениваться опытом с реальными разработчиками.
Преподаватели вузов могут по своими методикам преподать структуры данных и алгоритмы на псевдокоде. Т.е. то, что год от года не меняется. Но обучить кодить на всем зоопарке языков с их нюансами, фреймворками и разными библиотеками, которые быстро устаревают, а на их место по две новые приходят - неразработчики с педобразованием не смогут никогда, т.к. не успевают за развитием событий. Они именно что и преподают базовые знания и азы.
Все остальное джун получает не от преподавателя с педобразованием, а от коллег разработчиков, у которых больше опыта (и срать, что они не педагоги, они и без этого смогут сказать где ты наговнокодил). И этот опыт приходит на реальных задачах, с использованием конкретных инструментов, с разным подходом к разработке в разных компаниях и тд и тд и тд.
Поэтому я считаю, что базовые знания, полученные в вузе важны. Но это недостаточный аргумент, чтобы требовать от джуна уметь все и сразу - эти навыки получаются непосредственно во время работы.
А что он не так сказал? It это сложно, так было всегда. Я на первой работе ( в 2006м году) 3 месяца бесплатно сначала работал.
И что? Я на первой работе в 2012 тоже полгода бесплатно работала-училась.
Что не так сказал? Вот это: "Это не требования сеньорские, это вы тупые." Перевожу: "Проблема только в вас, в it-сфере все зашибись".
Я привела в пример довольно типичную вакансию с хх, где требования ну никак не джуниорские, а скорее мидл-сеньоровские.
В комментах куча людей отписалась про свой опыт неудачных собеседований.
То есть, проблема комплексная. Да, есть пул неподготовленных людей. И точно так же есть пул охреневших работодателей или некомпетентных собеседователей. Так что, частенько вой со стороны джунов вполне себе обоснован.
Здесь вопросы только к менторству и развитой культуре программирования. Другие два пункта норм.
Так я и пишу, что это странно. Его самого учить будут с пол-года минимум. А дальше сам будет учиться всю оставшуюся жизнь)
А чего тут сложного для джуна, еще и с двухлетним опытом? Давайте определимся в терминологии - джун, это готовый, но неопытный, начинающий специалист. Тот, кто прошел курсы(или даже обучение в учебном заведении, но без боевой практики) - это трейни. Вот он да - не может вполне знать культуру разработки или иметь опыт в боевом проектировании
В принятой в моем кругу терминологии джун - это человек, способный выполнить типичные, стандартные задачи под руководством мидлов/сеньоров. Он не участвует в разработке архитектуры кроме как на уровне "посмотреть, позадавать вопросы, почему именно так" и от него не требуют этого опыта на уровне сложных приложений. Маленькие и простые - да, возможно, и то необязательно. Он может и должен задавать вопросы, поэтому пункт "все решает самостоятельно" - мимо, джун не самостоятельная единица. Он не разбирается в технологиях на advanced level. Он не занимается менторством, даже по своему желанию, потому что ну он блять наменторствует, ага, даже по своему желанию.
Менторинг в скрине "по желанию", ну и кросс-менторинг под присмотром опытного специалиста возможен и в некоторых ситуациях оправдан - как минимум, качать можно и нужно не только хардскилы.
Джун может участвовать в обсуждении/разработке архитектуры как элемента обучения. Да, он не принимает решений по архитектуре, но на собесе с него это и не потребуют - а спросят что он знает про архитектуры на предыдущем месте работы. Если ему за два года было не интересно как оно все работает и почему - ему, скорее всего откажут.
Менторинг даже по желанию от джуна - это такое себе, а указан именно он, не кросс-менторинг.
Да, он не принимает решений по архитектуре, но на собесе с него это и не потребуют
В вашей компании - возможно, не потребуют. Но вот в вакансии я черным по белому читаю, что требуют. И именно это я считаю избыточным и неоправданным. Наравне с выше перечисленными пунктами.
Тогда вопрос к квалификации нанимающего менеджера. Решается пушем на основе анализа рынка со стороны грамотного рекрутера или ассессментом. Скорее всего это просто некорректная формулировка
Возвращаясь к вашему исходному посту: вот в том-то и дело, что к нанимающим, формулирующим и собеседующим сейчас столько претензий, что дело далеко не всегда в том, что приходит джун без навыков и требует странного (хотя да, бывает и так). Частенько этого странного требуют как раз от него, от чего он охуевает и жалуется абсолютно правомерно.
