Тут ещё вопрос, кого кем считать. Сейчас всё чаще просто по стажу идёт подгон. Так мидл почти в любом случае будет через года два-три из середнячка-джуна. А когда наймом занимаюсь, часто вижу с опытом в 3 года и всё ещё джуны, которые знают не многим больше меня, когда я только-только начинал. До мидла то многие растут. Но на 1 мидла, ощущение, что 10 джунов на мидловой позиции. А джунов вообще без счёта, да сейчас не редко они уже и много знают, т.к. много всего надо изучать, но с другой стороны и мало, потому что глубина никакая, много пробелов. Может мало фундамента? Раньше глубокие, а то и полные знания на сеньора нужны были. А сейчас что? Поболтать то часто не о чем. Умеешь кое-как тяп сделать - значит сеньор) Самого спрашивают - так то же самое. И ещё больше нетерпения к тем, кто знает больше тебя, но за то не знает новую фичу X в фреймворкке Z от позавчера. Ну, реально, сеньоров встречаю не так уж часто.
Я в галере работал, где были почти все джуны, и всего несколько спецов, которые могли бы считаться мидлами или сеньорами лет 10-15 назад. Для заказчика то по разному. Многих гордо звали мидлами и даже сеньорами внутри компании, но сейчас всех так зовут просто по стажу или желанию. Реально глубоких знаний у таких сеньоров нет, а мидлы ваяют лютое непотребство, как только надо сделать шаг в сторону от привычного + почти все попадают в стандартные ошибки новичков. Да, работы было много, и много именно разгребать косяков, тушить пожары, обучать, договариваться. Но выгода была, в т.ч. за счёт низких зарплат и плохих условий труда. И это не эникей 1С и прочее, а сфера развлечений, игр, мобилок, сайтов с беком. И даже там джуны справлялись при некотором контроле, а то и сами делали кое-как, не вытягивая только некоторые аспекты. Джуны обучали джунов. Делать это эффективно, конечно, не получалось. Но "и так сойдёт" работало - дёшево и сердито же)
А галеры такие есть в несколько уровней. Есть и много хуже по уровню, и много лучше. И везде то же самое со званиями.
Я таких умников видел мало) Чаще только болтать могут, но не делать. Можно внедрить KPI. Только продукты разные бывают. На каждый нужен свой. Все пытались внедрять ещё 10+ лет назад. Тогда ещё встречались очешуенные метрики по подсчёту количества строк кода и премии за них же) И даже про обратное слышал, т.е. меньше строк кода - больше премия. Вот только пока такие умники пилят систему KPI их конкуренты уже продают продукт. В моей сфере это пол года. А через пол года новый продукт, уже другой, к которому и метрики нужны будут новые. Или может ты тут готов ответить за свои слова показав мастерство и указав метрики для всей IT?
Тогда, весьма вероятно, что вы наткнётесь на те же грабли, которые были в других подобных сервисах. Ваш сервис будут использовать для таких целей скрытно, и вы даже далеко не сразу это поймёте. А какая-то из целей(комбинация) станет пристанищем для тех кто ищет именно таких отношений.
Если, конечно, популярность сервиса будет достаточно высокой. На сколько знаю, чтобы решить эту проблему делают премодерацию из человеков, а иначе не выходит.
Но понятно, что если сроки поплыли, либо они были не релеванты - то дело явно не в методологии
Ровно наоборот. Если она применялась правильно и оказалась не эффективна, то дело в методологии.
а потом оно вместе не собирается
Это вообще у меня редкая проблема. Каждый спринт - должен быть рабочий продукт и фичи в рамках спринта.
когда за плечами 20+ лет, можно промазнуться со сроками
Ну даже если с опытом в 20+ промахи, то что уж говорить про менее скилловых рядовых разрабов?
Нет особого контекста. Просто скрам для Agile разработки ПО не подходит. И поэтому провалы по срокам я вижу везде. А смириться с таким положением дел и рулить тем, что есть, не могут. Особенно низкоскилловые управленцы/владельцы/манагеры.
А про типовые говорю, т.к. есть сфера с 1С, где делают на платформе много раз повторяемые вещи. Там все считают работу в часах... Но! Тратят на часовую работу в один раз 20 минут, а другой 90, фактическое время постоянно скачет. Т.е. оценка всё так же наобум.
В целом, пожалуй не соглашусь с частью "не осознали". Таких не осознавших почти все, а вылетают далеко не все. К концу ВУЗ-а чётко знали что будут делать - треть в лучшем случае. Ещё треть так и не знала. По специальности не горело примерно 80-90%.
Насчёт трояков иногда и так. Но всё же не сильно любого и любой специальности.
Впервые меня занесло на микроэлектронику. 45 человек в группе на старте, 10 на втором курсе. У половины не прошедших долг по программированию, у половины долг по матану. У четверти по химии, как и по физике. Причины, которые я вижу: химия была в объёме 2 лет умещена в урезанный годовой курс(меньше пар, меньше практики, больше теории, нужно сдать 2 лабы за 1 пару). Матан преподавал г*****, беседуя о птичках, а потом оказалось часть лекций не была даже не дочитана. Программирование в принципе было сложным - лекции становились полезными уже после того как научишься код писать, а курсач в виде вывода динамического графика переходного процесса, при этом пар меньше, чем в аналогичной ситуации у IT специальности, а спрос такой, что ошибкой считалась неоптимальная программа как по памяти во время выполнения, так и по объёму кода. А вот физика была что надо! После того 1 курса ЕГЭ сдавали на 100 баллов при минимальной подготовке, хотя ранее было около 50 у всех.
А если преподу не понравится(в т.ч. тем, что не занёс, это тоже традиционно по разному), то ты не сдашь на 3 с минимальным желанием. Придётся изучать примерно на 5 ради той же тройки, не редко рискуя сдавать уже комиссии.
Мы же об оценках в т.ч. и объективности. Нельзя просто сказать - исследуй это. Нужны сроки. И они всегда есть на каком-то уровне проекта. И они очень часто не работают ожидаемо на любом не типовом проекте)
Что делает аналитик/дизайнер? Очевидно копают вперед.
Дизайнер исследует и получает +- полную картину объёма работ. Это вообще самый плохой пример. Даже в геймдеве предсказать объём выходит крайне точно, на месяцы вперёд с ошибкой в неделю. Проблема может быть только с не достаточно опытными, но дешёвыми дизайнерами.
Аналитик не знает ситуацию, но так же имеет представление. И сроки исходят так же из представления. Он является постановщиком и передаёт задачи вниз. И в случае чего, за сроки работы программистов не отвечает, а часть анализа благополучно сливает на конечных исполнителей - программистов. Анализ того, что и как должно быть в целом же более-менее постоянен. Т.е. можно ошибиться в некоторых аспектах, в некоторых недоработать, пропустить что-то. И они ошибаются и сроки так же едут. Только вот ошибка при поверхностном анализе так же велика. И многие проекты так же затягиваются и/или выполняются не полностью) Т.е. проблема с аналитиками такая же и не решается. Помню в ВУЗ-е ещё про интеграцию длиной аж в 10+ лет говорили! А план в 2 был, и оставался примерно таким же все годы) ----- В нашем примере берётся скрам, из него выдёргиваются спринты, пытаются как-то прикрутить, оно не работает. "Не особо умный" менеджер бесится, руководители бесится. Сделать ни черта не могут, в худшем случае винят разрабов и на этом конец) Пару раз видел как команды/компании валятся из-за этого. Сейчас такого поменьше стало, но раньше было частым явлением.
Тут не про трекер времени, а про оценку срочного(т.е. у которого есть дедлайн) проекта. Проблема в том, что надо это не только ПМ-у, но и всем отвечающим за проект в целом. А они просираются из-за своих ошибок, но видят в этом ошибку программистов. Иногда начинается с установки оценки, а заканчивается тем, что сроки не сходятся и в ответе за сроки оказываются программисты, лиды, а не менеджер. ----- Вот как раз одна из основ скрама - инструмент со спринтами и менеджментом задач. Убрать краеугольный камень скрама - получить хромую лошадь. Многие то не могут это заставить работать в принципе, и получается урод, что только маскируется под скрам, а на деле является старой концепцией с 5 ногой.
Я там писал как сам нанимаю) Уже на уровне мидла литкод не работает вообще.
Ну кстати не такой уж плохой фильтр. "Свой" – это вообще полезный критерий для построения команды. С "чужими" работать как-то сложнее.
В целом, это удобно для быстрой работы, но для слабых команд. Дело в том, что абстрактные "чужие" - это те, у кого компетенции не сходятся внутри команды. Т.е. он знает то, что вы не знаете, либо то же, но с иной стороны. А нанимая таких же людей компетенции не увеличиваются. Впрочем, не редко они и не нужны) Тут главное не путать социальное и навыки. Потому как несходимость по социальной составляющей не решается, в отличии от рабочих навыков.
Да, такой подход весьма хорош для джунов и отчасти мидлов. Люди со знанием теории и без практики не смогут это делать вообще или хотя бы эффективно. А любой человек с реальным опытом в год уже +- спокойно справится. И почти никакого стресса) Но малый объём проверки, компетенции будут не выяснены. Впрочем, если они не особо важны, то и ладно
PS: возможно, что я несколько завышаю требования по мидлам. Считаю, что сейчас рыночек даёт это звание авансом) Т.е. опытным джунам.
ВУЗ тоже не по щелчку. А хороший ВУЗ вообще проблемно. Если со школой не повезло, то куда проще любой вариант сразу. И в хороший колледж/техникум попасть проще, чем в хороший ВУЗ.
Ментора сейчас найти не проблема. Проблема с доверием тут есть. И вот ВУЗ проблем с недоверием не испытывает, отчего легко попасть в плохой ВУЗ.
После ВУЗ-а всё так же, как после 16 или 18. Взрослым человек становится не от учёбы и не от возраста.
Не наблюдается, т.к. система работает, получает финансирование, перераспределяет его на IT. Государству нужны дешёвые IT, оно их получает как умеет. Для человека это значения не имеет.
Я знаю на личном опыте, какое качество выдаёт даже не плохой ВУЗ, что выше среднего. И колледж такой же. Разницы, кстати, особо и нет. Из преподов там я всего один раз встречал человека прям хорошего программиста уровня Senior. Это качество достигается за год интенсивной работы при не плохих стартовых знаниях(не по программированию). И вот потом уже эффект от ВУЗ-а был бы в разы лучше. Без умения писать/читать программы обучение в ВУЗ-е не несёт значимой пользы, которую как раз ВУЗ должен давать.
Из своего опыта. Как 0, т.е. всегда. Пилишь игру, получается плохо, переписываешь. Так повторяется до хорошего результата. Получается плохо в любом случае. Дизайн кривой - переписываешь. Поменяли геймплей(а это по ходу разработки норма) - переписываешь. Иногда под релиз уже нет времени переписывать, тогда неудачные решения просто удаляются. Какой объём будет и как будет работать толком никто не знает. Потому как игры ещё нет, дизайн со старта целиком в работе. Даже если 2 часть, очень похожая на первую.
1) Надо быстро, команда маленькая изначально, не успеваешь в срок, но вытягиваешь качество, делаешь конфетку. В результате получаешь по шапке, часть команды потребуют уволить и все без премии. И пох, что игра на 1 месте в сторе с миллионами продаж, что на много лучше других команд. 2) Финансирование по ходу проекта прекращается по независящим причинам. Нужен новый инвестор, но игры ещё нет - надо либо выпускаться, либо новый инвестор. В любом случае игра должна быть готова уже вчера. Я так в 1 проект с 3 крупными издателями... хотел бы сказать поработал, но они так ни черта и не сделали! Обидно, ведь каждый требует своих изменений, впендюрить свой суперкрутой велосипед и т.п., а в результате время потрачено впустую. 3) Проекты длятся очень мало, но слишком велики, чтобы сделать быстро. То же тестирование в отрасли не особо прижилось, т.к. долго. Местами можно и нужно, но проще потерять даже 5-10% пользователей и сделать гораздо быстрее, очевидные ошибки будут поправлены в любом случае. А баги мб потом поправят, если деньги будут. Длина проекта в 6 месяцев - нормально. В 2 года на ~ ААА - более чем. Нет, может быть и много дольше, но это обычно растянутое переписывание) 4) Изначальная идея и оценка не соответствует тому, что в итоге требуется. Потому что проверить идею и реализацию сразу не выходит. Прототипы помогают и позволяют найти хорошее. Но это хорошее умирает чаще(не интересно игрокам при расширении прототипа), чем живёт. Хотели обычный платформер. Довольно примитивная штука же? Что там делать даже 1 прогеру пол года? А получилось так, что переписывали всё прямо до релиза. А игра поменяла концепцию по ходу разработки пару раз. А релиз остался там же, где был.
Так то оно в теории так. На деле это смотрел и даже несколько применял, как раз в рамках теста - была попытка решить проблему таким способом, для чего задачу прямо в процессе разбирали на части. Буквально в тот же день и выяснили, что это не работает, записав решение нескольких задач на условные несколько часов. Выходили цепочки в несколько задач для решения, чаще 3-5, но порой и цепочки в несколько десятков. Изредка совсем простые в 1 шаг, типа багов, которые уже знали как починить, а если не знаешь - то же самое. Каждую надо описать как задачу, согласовать, затем Заново делать, т.к. из контекста уже выпадаешь. Ну и смысл? По скраму, как уже писал, вообще работать невозможно, т.к. нужен новый спринт на каждую задачу в цепочке
Ну вот лид. Литкод не пользую. Стресса полно на собесе, задаю вообще базовые вещи, ни черта не знают, не могут обсуждать темы по программированию - очень часто. При этом явно сами пишут код, хоть и плохой, но работающий(у них). Проверять реверс строки не вижу смысла даже на джуновую вакансию, т.к. она не даст ответа о компетенции. Если решит, то и что? Этого всё равно мало. А если не решит, то за 15 минут можно задать вопросов на много больше, которые скажут куда больше. Можно, например, дать прочитать код и поспрашивать по нему. Это куда быстрее. А тестовые вот подойдут для первичного отсева.
Для мидла простые задачи уже не подойдут. А сложные делать долго и время может быть сильно неопределенно + появляется специфика. И тут действительно сложно, потому как компания то мб и сэкономит, потребовав ТЗ, но соискателю это зачем? Это уже полноценная работа на день, а иногда и неделю-две. А ведь нормально сделать без контекста очень сложно, а по качеству кода всё равно будут определять уровень. Чтобы была приписка, типа, реши любым способом, не важно качество - такое всего раз видел. Чтобы была готова среда для написания - ни разу. Ну конечно, это же работать надо, потратить пару дней на подготовку) А меж тем стартануть проект, просто пустой, но запускающийся, у меня уйдёт как раз 1-2 дня. Как и среду скачать/настроить пару дней.
А ещё выше уровнем вовсе бесполезны, и литкод, и тестовые. Тут нужно уже на словах решать задачи, может даже десятками-сотнями за час. Что-то вроде блица. Иначе скорость просто не достаточна для оценки. Мы же хотим не своё эго потешить, а узнать о возможностях кандидата? Если так, то темы должен выбирать кандидат
Проблема часто в том, что многие наниматели и сами не далеко ушли от кандидатов. Не так уж редко иду на собес, а там лид не может обсуждать проект в технической реализации, даже если зацепишься за что-то. Всё больше налегают на какие-то редкоиспользуемые мелочи. А как насчёт проектирования поговорить? Вообще ни разу не было именно такой постановки на собесах) ООП ограничивается - "а знаешь ли ты принципы ***?" Ну и о чём с такими работать?) На деле это работает не как фильтр знаний/умений, а как фильтр вовлечённости в сферу - если человек изучил, то "свой", а не мимокрокодил. Только из-за этого совпадения это всё ещё работало. До курсов)
Кстати, именно "свой" - определяющее в таких компаниях. Т.е. если делаешь как им хочется, говоришь, что им хочется, то добро пожаловать. И пофиг, что они называют DTO моделью в MVC/MVP, а свой процедурный стиль ООП. Вопросы стиля кода поднимать в таких вообще нельзя - это сразу крест)
1) Сам задаю вопросы, очень много вопросов. Заранее предупреждаю, что на большинство кандидат может не ответит, и что даже такой результат - это нормально. Но каждый ответ это небольшой +. Да и если кандидат не отвечает несколько раз подряд - сильно дизморалит, так что ещё и поддержка нужна. Спрашиваю не по синтаксису, а как сделать то-то или то-то. Что можно сделать с тем-то и тем-то? Как работает то и другое? Может особенности работы чего-то, знаешь? Что-то ещё подобное знаешь? А про то знаешь? Как сделать то и почему? И по таким вопросам реально за пол часа пробежаться по всему курсу программирования верхами, а несколько пропуская можно и за 15 минут. После универа знания могут быть на уровне что-то слышал по всем темам - это уже хорошо. 2) Ещё за пол часа углубится в дебри и особенности. Тут я не спрашиваю как и что делается. Я спрашиваю о чём человек знает. Спрашиваю, чтобы определить границы того, что он не знает о своём не знании, а так же найти то, что я не знаю. Всё нужное, в т.ч. как сделать, программист найдёт сам - это обычная рабочая задача. Вопрос только, увидит ли он проблему, или спокойно рекурсией будет парсить мегабайты+ данных. И, что характерно, так и выходит - отсутствие знаний не мешает программировать, а вот пустое самомнение и повторение стековерфлоу без понимания работы и даже попыток понимания, приводит к проблемам. На уровень мидла требую как минимум уметь общаться на техническом языке. Обсуждать всё, что касается работы. И ведь большая часть не может это делать полноценно, потому как опыт работы в команде весьма мал, ну или большой только условно, т.к. опыта обсуждений решений там мб вообще нет. 3) А на высокий уровень уже по другому. Если ранее я веду разговор, задаю вопросы и всячески "пытаю" на разный лад, пытаясь выяснить, что же знает человек, то тут наоборот, спрашиваю о различном опыте, пытаясь получить диалог об абстракциях, обсудить опыт проектирования, решений, обосновать их.
Самая большая проблема - вообще не подготовится, потому что запара, проблемы и т.д. Это сложнее даётся. И, походу, так почти у всех)
PS: Всего раз просили спроектировать на словах что-то. Вроде, "А как бы ты сделал?" именно по проектированию системы. И... диалога не было. Зачем? Как я думаю, они просто не в состоянии сами его были поддерживать и такой конкурент им не сдался) Никто не знает как нанимать спецов высокого уровня, кроме банального - отсеять кого придётся и доверится тем, кто останется
Ну вот честно говоря, у меня почти все задачи RnD полностью или с элементами. И, кмк, элементы встречаются всегда в работе программиста. Для начинающих это любая задача с вопросом "как?", коих... все. Потом становится всё лучше, но появляются сторонние проблемы. Баги IDE, системы, фреймворков и т.д. Чем дальше, тем больше таких проблем. И решает эти проблемы тот у кого опыта больше вырулить на опыте и общих знаниях, т.к. другие просто не справятся за адекватные сроки. Я одинаковых задач то знал буквально по пальцам руки. Даже если называются одинаково, то делались принципиально по разному через год.
PS: сам я в геймдеве больше работал. Может в других сферах и иначе, но что-то сомневаюсь, что там простая перегонка json-чиков для кодеров.
Вот эти самые несколько слов, которые толком ничего не значат: "если узнает то-то" и содержат ошибку. Ты не знаешь, что узнаешь в процессе изучения материалов и проверки гипотез. И не можешь этого знать в принципе. Так и выходит, что планирование возможно только ближайшего шага, или просто полагаясь на интуицию и известные величины(вроде известных частей прототипа).
Только исследование, как правило, включает в себя десятки гипотез, до исчерпания идей. По сути, каждая новая гипотеза - новое исследование. Какие именно будут гипотезы невозможно узнать, пока не дойдёшь до них.
Проработка для оценки гипотез почти = проверке гипотезы во множестве случаев, т.е. дешевле сразу код писать. Фактически это то же программирование, но без собственно кода, что ещё сложнее и подвержено большому кол-ву ошибок.
Кстати, если делать по скраму, то "поставить более конкретные задачи на другие исследования" = новому спринту, что = полной потере гибкости. Если делать иначе - это уже не скрам. Цепочка гипотез растянется на годы работы, вместо дня
А я вот уже близко к тому возрасту, ценность физкультуры в целом понимаю. И я прекрасно знаю, что физра бесполезна. Т.к. у меня был предмет по медицине, несколько прикладной для сферы и жизни вообще, который вполне сходится с новыми знаниями, полученными позже по медицине.
И из этих знаний в полной мере выводится, что это просто профанация, способ заработать и т.п. Никакого отношения к поддержке физического состояния это не имеет. Просто потому, что противоречит этим целям с самого начала - привязке нагрузки к времени пары и расписанию. Зарядка нужна, а длительные и резкие физнагрузки лучше чем без зарядки, но так же и вредны. Так же, в большинстве, не говорят о том как правильно получать эти нагрузки, и даже не поправляют, когда человек что-то делает не правильно. Ну и какой в них смысл, когда у человека и так высокая нагрузка и нет свободного времени, а обучения то и нет?
К реальной поддержке можно отнести, например, перерывы во время пар. У нас их, обычно, не делали. Хотя в правилах было указано делать)
Потому как основа - программирование. Вокруг основы уже должны быть различные знания. А много всякого без программирования - пустая трата времени и ресурсов. Причём, программирование должно быть на 1-ых курсах, а уже потом всё прочее. А там ровно наоборот) Школы же программированию толком не учат. И что толку учить правила SOLID, если ты с сортировкой то еле-еле совладал? То же касается других подходов. Их нужно практиковать, а не тупо заучивать.
Замечу так же, что в основном вылеты идут на первых курсах, когда к, и так высокой нагрузке, из-за новизны добавляется 100500 различных предметов. И хорошо изучить это самое "много всякого" чаще всего и не удаётся.
1+) Вышка мне дала не мало знаний по системам и концепциям. По мне так, большинству в группе было абсолютно всё равно, для них эти предметы чисто зубрёжка и вообще не важно.
2+) Широкий кругозор. Тут действительно дало не мало знаний и заполнило не мало пробелов. Наиболее полезны были не проограммирование, а предметы поблизости к IT: безопасность, устройство компьютера, безотказность и т.д.
3+) Короткие нагруженные базовые курсы по безопасности, медицине(в контексте деятельности), защите прав, русскому, где толком зачётов то и не было, а вот полезных знаний много. Знаю, что многие считают их бесполезными. По мне так просто не умеют применять или применяют не замечая.
4+) Системность знаний. Условный список того, что надо вне сферы деятельности. А они как раз и нужны для продвижения выше мидла, а получить самостоятельно крайне сложно. В отличии от знаний непосредственно по программированию, ты не узнаешь нужны ли они тебе, и вообще не узнаешь об их существовании сам. Я не встречал ни у одного наставника список знаний для обучения, столь же хороший как в ВУЗ-е. Это касается в первую очередь знаний вне основной сферы кодинга. Так, например, я встречал очень много мидлов, которые не понимают концепцию двойного рукопожатия(handshake) - для них это магия, не смотря на то, что они тоже учились в ВУЗ-е.
+-) Получение Очень глубоких знаний в какой-то либо сфере(как ни странно, для меня там это стало химией, которую я толком и не помню уже, было на другой специальности). Это то самое, когда по итогу можешь больше, чем знаешь. В самом ВУЗ-е далеко не факт, что получится. А можно и сразу в профе. Скорее тут наставник нужен. Ну или годы с неясным результатом.
А вот пресловутых связей, контекста, языковой среды, особое мышление, я не вижу вообще. Тут реально надо везение со связями. Контекст среды обучения на работе куда круче - там полно профи с самым разным опытом, в т.ч. вне профы. И у них можно учиться! Языковая среда - это вообще нечто эфемерное, т.к. в каждой компании она своя. И то же в различных ВУЗ-ах Мышление даётся с практикой, или после некоторой "планки" понимания. Практика в ВУЗ-ах часто не даёт даже минимум(в хороших минимум и чуть выше выходит). Как можно говорить о SOLID, если человек толком код не трогал? По выпуску могу сказать, что никто не знал что это, но половина заучила определения. То же самое с тупым заучиванием паттернов, схем и т.д. Что-то об абстракциях - это как на иностранном пытаться объяснить. Разве что тервер, теория игр, графы и т.п. дают понимание.
Польза то есть. Но какой ценой? Это не просто 5 лет на обучение. Это годы потраченные на изучение того, что уже никогда не понадобится. Такая низкая эффективность приводит к потере смысла так учиться при наличии альтернатив
А какие ситуации? Я вот думал поехать за гранку и говорили диплом не плохо бы... Но чёт так и не пригодился. В РФ ни разу не нужен был. Ну вот сейчас дают как бы бронь. Но не всегда помогает и тоже как-то мимо. Было нужен диплом в одном место устроится, так место такое, что даже хорошо, что нельзя - не свернёшь на опасный курс)
Тут ещё вопрос, кого кем считать. Сейчас всё чаще просто по стажу идёт подгон. Так мидл почти в любом случае будет через года два-три из середнячка-джуна.
А когда наймом занимаюсь, часто вижу с опытом в 3 года и всё ещё джуны, которые знают не многим больше меня, когда я только-только начинал. До мидла то многие растут. Но на 1 мидла, ощущение, что 10 джунов на мидловой позиции. А джунов вообще без счёта, да сейчас не редко они уже и много знают, т.к. много всего надо изучать, но с другой стороны и мало, потому что глубина никакая, много пробелов. Может мало фундамента? Раньше глубокие, а то и полные знания на сеньора нужны были. А сейчас что? Поболтать то часто не о чем. Умеешь кое-как тяп сделать - значит сеньор) Самого спрашивают - так то же самое. И ещё больше нетерпения к тем, кто знает больше тебя, но за то не знает новую фичу X в фреймворкке Z от позавчера. Ну, реально, сеньоров встречаю не так уж часто.
Я в галере работал, где были почти все джуны, и всего несколько спецов, которые могли бы считаться мидлами или сеньорами лет 10-15 назад. Для заказчика то по разному. Многих гордо звали мидлами и даже сеньорами внутри компании, но сейчас всех так зовут просто по стажу или желанию. Реально глубоких знаний у таких сеньоров нет, а мидлы ваяют лютое непотребство, как только надо сделать шаг в сторону от привычного + почти все попадают в стандартные ошибки новичков. Да, работы было много, и много именно разгребать косяков, тушить пожары, обучать, договариваться. Но выгода была, в т.ч. за счёт низких зарплат и плохих условий труда. И это не эникей 1С и прочее, а сфера развлечений, игр, мобилок, сайтов с беком. И даже там джуны справлялись при некотором контроле, а то и сами делали кое-как, не вытягивая только некоторые аспекты. Джуны обучали джунов. Делать это эффективно, конечно, не получалось. Но "и так сойдёт" работало - дёшево и сердито же)
А галеры такие есть в несколько уровней. Есть и много хуже по уровню, и много лучше. И везде то же самое со званиями.
Я таких умников видел мало) Чаще только болтать могут, но не делать. Можно внедрить KPI. Только продукты разные бывают. На каждый нужен свой. Все пытались внедрять ещё 10+ лет назад. Тогда ещё встречались очешуенные метрики по подсчёту количества строк кода и премии за них же) И даже про обратное слышал, т.е. меньше строк кода - больше премия. Вот только пока такие умники пилят систему KPI их конкуренты уже продают продукт. В моей сфере это пол года. А через пол года новый продукт, уже другой, к которому и метрики нужны будут новые. Или может ты тут готов ответить за свои слова показав мастерство и указав метрики для всей IT?
Тогда, весьма вероятно, что вы наткнётесь на те же грабли, которые были в других подобных сервисах. Ваш сервис будут использовать для таких целей скрытно, и вы даже далеко не сразу это поймёте. А какая-то из целей(комбинация) станет пристанищем для тех кто ищет именно таких отношений.
Если, конечно, популярность сервиса будет достаточно высокой. На сколько знаю, чтобы решить эту проблему делают премодерацию из человеков, а иначе не выходит.
Ровно наоборот. Если она применялась правильно и оказалась не эффективна, то дело в методологии.
Это вообще у меня редкая проблема. Каждый спринт - должен быть рабочий продукт и фичи в рамках спринта.
Ну даже если с опытом в 20+ промахи, то что уж говорить про менее скилловых рядовых разрабов?
Нет особого контекста. Просто скрам для Agile разработки ПО не подходит. И поэтому провалы по срокам я вижу везде. А смириться с таким положением дел и рулить тем, что есть, не могут. Особенно низкоскилловые управленцы/владельцы/манагеры.
А про типовые говорю, т.к. есть сфера с 1С, где делают на платформе много раз повторяемые вещи. Там все считают работу в часах... Но! Тратят на часовую работу в один раз 20 минут, а другой 90, фактическое время постоянно скачет. Т.е. оценка всё так же наобум.
В целом, пожалуй не соглашусь с частью "не осознали". Таких не осознавших почти все, а вылетают далеко не все. К концу ВУЗ-а чётко знали что будут делать - треть в лучшем случае. Ещё треть так и не знала. По специальности не горело примерно 80-90%.
Насчёт трояков иногда и так. Но всё же не сильно любого и любой специальности.
Впервые меня занесло на микроэлектронику. 45 человек в группе на старте, 10 на втором курсе. У половины не прошедших долг по программированию, у половины долг по матану. У четверти по химии, как и по физике. Причины, которые я вижу: химия была в объёме 2 лет умещена в урезанный годовой курс(меньше пар, меньше практики, больше теории, нужно сдать 2 лабы за 1 пару). Матан преподавал г*****, беседуя о птичках, а потом оказалось часть лекций не была даже не дочитана. Программирование в принципе было сложным - лекции становились полезными уже после того как научишься код писать, а курсач в виде вывода динамического графика переходного процесса, при этом пар меньше, чем в аналогичной ситуации у IT специальности, а спрос такой, что ошибкой считалась неоптимальная программа как по памяти во время выполнения, так и по объёму кода.
А вот физика была что надо! После того 1 курса ЕГЭ сдавали на 100 баллов при минимальной подготовке, хотя ранее было около 50 у всех.
А если преподу не понравится(в т.ч. тем, что не занёс, это тоже традиционно по разному), то ты не сдашь на 3 с минимальным желанием. Придётся изучать примерно на 5 ради той же тройки, не редко рискуя сдавать уже комиссии.
Мы же об оценках в т.ч. и объективности. Нельзя просто сказать - исследуй это. Нужны сроки. И они всегда есть на каком-то уровне проекта. И они очень часто не работают ожидаемо на любом не типовом проекте)
Дизайнер исследует и получает +- полную картину объёма работ. Это вообще самый плохой пример. Даже в геймдеве предсказать объём выходит крайне точно, на месяцы вперёд с ошибкой в неделю. Проблема может быть только с не достаточно опытными, но дешёвыми дизайнерами.
Аналитик не знает ситуацию, но так же имеет представление. И сроки исходят так же из представления. Он является постановщиком и передаёт задачи вниз. И в случае чего, за сроки работы программистов не отвечает, а часть анализа благополучно сливает на конечных исполнителей - программистов. Анализ того, что и как должно быть в целом же более-менее постоянен. Т.е. можно ошибиться в некоторых аспектах, в некоторых недоработать, пропустить что-то. И они ошибаются и сроки так же едут. Только вот ошибка при поверхностном анализе так же велика. И многие проекты так же затягиваются и/или выполняются не полностью) Т.е. проблема с аналитиками такая же и не решается. Помню в ВУЗ-е ещё про интеграцию длиной аж в 10+ лет говорили! А план в 2 был, и оставался примерно таким же все годы)
-----
В нашем примере берётся скрам, из него выдёргиваются спринты, пытаются как-то прикрутить, оно не работает. "Не особо умный" менеджер бесится, руководители бесится. Сделать ни черта не могут, в худшем случае винят разрабов и на этом конец) Пару раз видел как команды/компании валятся из-за этого. Сейчас такого поменьше стало, но раньше было частым явлением.
Тут не про трекер времени, а про оценку срочного(т.е. у которого есть дедлайн) проекта.
Проблема в том, что надо это не только ПМ-у, но и всем отвечающим за проект в целом. А они просираются из-за своих ошибок, но видят в этом ошибку программистов. Иногда начинается с установки оценки, а заканчивается тем, что сроки не сходятся и в ответе за сроки оказываются программисты, лиды, а не менеджер.
-----
Вот как раз одна из основ скрама - инструмент со спринтами и менеджментом задач. Убрать краеугольный камень скрама - получить хромую лошадь. Многие то не могут это заставить работать в принципе, и получается урод, что только маскируется под скрам, а на деле является старой концепцией с 5 ногой.
Я там писал как сам нанимаю) Уже на уровне мидла литкод не работает вообще.
В целом, это удобно для быстрой работы, но для слабых команд. Дело в том, что абстрактные "чужие" - это те, у кого компетенции не сходятся внутри команды. Т.е. он знает то, что вы не знаете, либо то же, но с иной стороны. А нанимая таких же людей компетенции не увеличиваются. Впрочем, не редко они и не нужны) Тут главное не путать социальное и навыки. Потому как несходимость по социальной составляющей не решается, в отличии от рабочих навыков.
Да, такой подход весьма хорош для джунов и отчасти мидлов. Люди со знанием теории и без практики не смогут это делать вообще или хотя бы эффективно. А любой человек с реальным опытом в год уже +- спокойно справится. И почти никакого стресса) Но малый объём проверки, компетенции будут не выяснены. Впрочем, если они не особо важны, то и ладно
PS: возможно, что я несколько завышаю требования по мидлам. Считаю, что сейчас рыночек даёт это звание авансом) Т.е. опытным джунам.
ВУЗ тоже не по щелчку. А хороший ВУЗ вообще проблемно. Если со школой не повезло, то куда проще любой вариант сразу. И в хороший колледж/техникум попасть проще, чем в хороший ВУЗ.
Ментора сейчас найти не проблема. Проблема с доверием тут есть. И вот ВУЗ проблем с недоверием не испытывает, отчего легко попасть в плохой ВУЗ.
После ВУЗ-а всё так же, как после 16 или 18. Взрослым человек становится не от учёбы и не от возраста.
Не наблюдается, т.к. система работает, получает финансирование, перераспределяет его на IT. Государству нужны дешёвые IT, оно их получает как умеет. Для человека это значения не имеет.
Я знаю на личном опыте, какое качество выдаёт даже не плохой ВУЗ, что выше среднего. И колледж такой же. Разницы, кстати, особо и нет. Из преподов там я всего один раз встречал человека прям хорошего программиста уровня Senior. Это качество достигается за год интенсивной работы при не плохих стартовых знаниях(не по программированию). И вот потом уже эффект от ВУЗ-а был бы в разы лучше. Без умения писать/читать программы обучение в ВУЗ-е не несёт значимой пользы, которую как раз ВУЗ должен давать.
Из своего опыта.
Как 0, т.е. всегда. Пилишь игру, получается плохо, переписываешь. Так повторяется до хорошего результата. Получается плохо в любом случае. Дизайн кривой - переписываешь. Поменяли геймплей(а это по ходу разработки норма) - переписываешь. Иногда под релиз уже нет времени переписывать, тогда неудачные решения просто удаляются. Какой объём будет и как будет работать толком никто не знает. Потому как игры ещё нет, дизайн со старта целиком в работе. Даже если 2 часть, очень похожая на первую.
1) Надо быстро, команда маленькая изначально, не успеваешь в срок, но вытягиваешь качество, делаешь конфетку. В результате получаешь по шапке, часть команды потребуют уволить и все без премии. И пох, что игра на 1 месте в сторе с миллионами продаж, что на много лучше других команд.
2) Финансирование по ходу проекта прекращается по независящим причинам. Нужен новый инвестор, но игры ещё нет - надо либо выпускаться, либо новый инвестор. В любом случае игра должна быть готова уже вчера. Я так в 1 проект с 3 крупными издателями... хотел бы сказать поработал, но они так ни черта и не сделали! Обидно, ведь каждый требует своих изменений, впендюрить свой суперкрутой велосипед и т.п., а в результате время потрачено впустую.
3) Проекты длятся очень мало, но слишком велики, чтобы сделать быстро. То же тестирование в отрасли не особо прижилось, т.к. долго. Местами можно и нужно, но проще потерять даже 5-10% пользователей и сделать гораздо быстрее, очевидные ошибки будут поправлены в любом случае. А баги мб потом поправят, если деньги будут. Длина проекта в 6 месяцев - нормально. В 2 года на ~ ААА - более чем. Нет, может быть и много дольше, но это обычно растянутое переписывание)
4) Изначальная идея и оценка не соответствует тому, что в итоге требуется. Потому что проверить идею и реализацию сразу не выходит. Прототипы помогают и позволяют найти хорошее. Но это хорошее умирает чаще(не интересно игрокам при расширении прототипа), чем живёт. Хотели обычный платформер. Довольно примитивная штука же? Что там делать даже 1 прогеру пол года? А получилось так, что переписывали всё прямо до релиза. А игра поменяла концепцию по ходу разработки пару раз. А релиз остался там же, где был.
Так то оно в теории так. На деле это смотрел и даже несколько применял, как раз в рамках теста - была попытка решить проблему таким способом, для чего задачу прямо в процессе разбирали на части. Буквально в тот же день и выяснили, что это не работает, записав решение нескольких задач на условные несколько часов. Выходили цепочки в несколько задач для решения, чаще 3-5, но порой и цепочки в несколько десятков. Изредка совсем простые в 1 шаг, типа багов, которые уже знали как починить, а если не знаешь - то же самое. Каждую надо описать как задачу, согласовать, затем Заново делать, т.к. из контекста уже выпадаешь. Ну и смысл? По скраму, как уже писал, вообще работать невозможно, т.к. нужен новый спринт на каждую задачу в цепочке
Ну вот лид. Литкод не пользую. Стресса полно на собесе, задаю вообще базовые вещи, ни черта не знают, не могут обсуждать темы по программированию - очень часто. При этом явно сами пишут код, хоть и плохой, но работающий(у них). Проверять реверс строки не вижу смысла даже на джуновую вакансию, т.к. она не даст ответа о компетенции. Если решит, то и что? Этого всё равно мало. А если не решит, то за 15 минут можно задать вопросов на много больше, которые скажут куда больше. Можно, например, дать прочитать код и поспрашивать по нему. Это куда быстрее. А тестовые вот подойдут для первичного отсева.
Для мидла простые задачи уже не подойдут. А сложные делать долго и время может быть сильно неопределенно + появляется специфика. И тут действительно сложно, потому как компания то мб и сэкономит, потребовав ТЗ, но соискателю это зачем? Это уже полноценная работа на день, а иногда и неделю-две. А ведь нормально сделать без контекста очень сложно, а по качеству кода всё равно будут определять уровень. Чтобы была приписка, типа, реши любым способом, не важно качество - такое всего раз видел. Чтобы была готова среда для написания - ни разу. Ну конечно, это же работать надо, потратить пару дней на подготовку) А меж тем стартануть проект, просто пустой, но запускающийся, у меня уйдёт как раз 1-2 дня. Как и среду скачать/настроить пару дней.
А ещё выше уровнем вовсе бесполезны, и литкод, и тестовые. Тут нужно уже на словах решать задачи, может даже десятками-сотнями за час. Что-то вроде блица. Иначе скорость просто не достаточна для оценки. Мы же хотим не своё эго потешить, а узнать о возможностях кандидата? Если так, то темы должен выбирать кандидат
Проблема часто в том, что многие наниматели и сами не далеко ушли от кандидатов. Не так уж редко иду на собес, а там лид не может обсуждать проект в технической реализации, даже если зацепишься за что-то. Всё больше налегают на какие-то редкоиспользуемые мелочи. А как насчёт проектирования поговорить? Вообще ни разу не было именно такой постановки на собесах) ООП ограничивается - "а знаешь ли ты принципы ***?" Ну и о чём с такими работать?) На деле это работает не как фильтр знаний/умений, а как фильтр вовлечённости в сферу - если человек изучил, то "свой", а не мимокрокодил. Только из-за этого совпадения это всё ещё работало. До курсов)
Кстати, именно "свой" - определяющее в таких компаниях. Т.е. если делаешь как им хочется, говоришь, что им хочется, то добро пожаловать. И пофиг, что они называют DTO моделью в MVC/MVP, а свой процедурный стиль ООП. Вопросы стиля кода поднимать в таких вообще нельзя - это сразу крест)
1) Сам задаю вопросы, очень много вопросов. Заранее предупреждаю, что на большинство кандидат может не ответит, и что даже такой результат - это нормально. Но каждый ответ это небольшой +. Да и если кандидат не отвечает несколько раз подряд - сильно дизморалит, так что ещё и поддержка нужна. Спрашиваю не по синтаксису, а как сделать то-то или то-то. Что можно сделать с тем-то и тем-то? Как работает то и другое? Может особенности работы чего-то, знаешь? Что-то ещё подобное знаешь? А про то знаешь? Как сделать то и почему? И по таким вопросам реально за пол часа пробежаться по всему курсу программирования верхами, а несколько пропуская можно и за 15 минут. После универа знания могут быть на уровне что-то слышал по всем темам - это уже хорошо.
2) Ещё за пол часа углубится в дебри и особенности. Тут я не спрашиваю как и что делается. Я спрашиваю о чём человек знает. Спрашиваю, чтобы определить границы того, что он не знает о своём не знании, а так же найти то, что я не знаю. Всё нужное, в т.ч. как сделать, программист найдёт сам - это обычная рабочая задача. Вопрос только, увидит ли он проблему, или спокойно рекурсией будет парсить мегабайты+ данных. И, что характерно, так и выходит - отсутствие знаний не мешает программировать, а вот пустое самомнение и повторение стековерфлоу без понимания работы и даже попыток понимания, приводит к проблемам. На уровень мидла требую как минимум уметь общаться на техническом языке. Обсуждать всё, что касается работы. И ведь большая часть не может это делать полноценно, потому как опыт работы в команде весьма мал, ну или большой только условно, т.к. опыта обсуждений решений там мб вообще нет.
3) А на высокий уровень уже по другому. Если ранее я веду разговор, задаю вопросы и всячески "пытаю" на разный лад, пытаясь выяснить, что же знает человек, то тут наоборот, спрашиваю о различном опыте, пытаясь получить диалог об абстракциях, обсудить опыт проектирования, решений, обосновать их.
Самая большая проблема - вообще не подготовится, потому что запара, проблемы и т.д. Это сложнее даётся. И, походу, так почти у всех)
PS: Всего раз просили спроектировать на словах что-то. Вроде, "А как бы ты сделал?" именно по проектированию системы. И... диалога не было. Зачем? Как я думаю, они просто не в состоянии сами его были поддерживать и такой конкурент им не сдался) Никто не знает как нанимать спецов высокого уровня, кроме банального - отсеять кого придётся и доверится тем, кто останется
Ну вот честно говоря, у меня почти все задачи RnD полностью или с элементами. И, кмк, элементы встречаются всегда в работе программиста.
Для начинающих это любая задача с вопросом "как?", коих... все. Потом становится всё лучше, но появляются сторонние проблемы. Баги IDE, системы, фреймворков и т.д. Чем дальше, тем больше таких проблем. И решает эти проблемы тот у кого опыта больше вырулить на опыте и общих знаниях, т.к. другие просто не справятся за адекватные сроки. Я одинаковых задач то знал буквально по пальцам руки. Даже если называются одинаково, то делались принципиально по разному через год.
PS: сам я в геймдеве больше работал. Может в других сферах и иначе, но что-то сомневаюсь, что там простая перегонка json-чиков для кодеров.
Вот эти самые несколько слов, которые толком ничего не значат: "если узнает то-то" и содержат ошибку. Ты не знаешь, что узнаешь в процессе изучения материалов и проверки гипотез. И не можешь этого знать в принципе. Так и выходит, что планирование возможно только ближайшего шага, или просто полагаясь на интуицию и известные величины(вроде известных частей прототипа).
Только исследование, как правило, включает в себя десятки гипотез, до исчерпания идей. По сути, каждая новая гипотеза - новое исследование. Какие именно будут гипотезы невозможно узнать, пока не дойдёшь до них.
Проработка для оценки гипотез почти = проверке гипотезы во множестве случаев, т.е. дешевле сразу код писать. Фактически это то же программирование, но без собственно кода, что ещё сложнее и подвержено большому кол-ву ошибок.
Кстати, если делать по скраму, то "поставить более конкретные задачи на другие исследования" = новому спринту, что = полной потере гибкости. Если делать иначе - это уже не скрам. Цепочка гипотез растянется на годы работы, вместо дня
А я вот уже близко к тому возрасту, ценность физкультуры в целом понимаю. И я прекрасно знаю, что физра бесполезна. Т.к. у меня был предмет по медицине, несколько прикладной для сферы и жизни вообще, который вполне сходится с новыми знаниями, полученными позже по медицине.
И из этих знаний в полной мере выводится, что это просто профанация, способ заработать и т.п. Никакого отношения к поддержке физического состояния это не имеет. Просто потому, что противоречит этим целям с самого начала - привязке нагрузки к времени пары и расписанию. Зарядка нужна, а длительные и резкие физнагрузки лучше чем без зарядки, но так же и вредны. Так же, в большинстве, не говорят о том как правильно получать эти нагрузки, и даже не поправляют, когда человек что-то делает не правильно. Ну и какой в них смысл, когда у человека и так высокая нагрузка и нет свободного времени, а обучения то и нет?
К реальной поддержке можно отнести, например, перерывы во время пар. У нас их, обычно, не делали. Хотя в правилах было указано делать)
Хороший колледж, хороший курс, ментор, работа. При самостоятельном изучении, а не когда тебя тянут - любой вариант лучше
Тут всё же ответа нет. Понятно, что даёт некоторые возможности. Но нужны ли они? Нет. А какие реально нужные вещи были, что из-за этого стоит?
Потому как основа - программирование. Вокруг основы уже должны быть различные знания. А много всякого без программирования - пустая трата времени и ресурсов. Причём, программирование должно быть на 1-ых курсах, а уже потом всё прочее. А там ровно наоборот) Школы же программированию толком не учат. И что толку учить правила SOLID, если ты с сортировкой то еле-еле совладал? То же касается других подходов. Их нужно практиковать, а не тупо заучивать.
Замечу так же, что в основном вылеты идут на первых курсах, когда к, и так высокой нагрузке, из-за новизны добавляется 100500 различных предметов. И хорошо изучить это самое "много всякого" чаще всего и не удаётся.
1+) Вышка мне дала не мало знаний по системам и концепциям. По мне так, большинству в группе было абсолютно всё равно, для них эти предметы чисто зубрёжка и вообще не важно.
2+) Широкий кругозор. Тут действительно дало не мало знаний и заполнило не мало пробелов. Наиболее полезны были не проограммирование, а предметы поблизости к IT: безопасность, устройство компьютера, безотказность и т.д.
3+) Короткие нагруженные базовые курсы по безопасности, медицине(в контексте деятельности), защите прав, русскому, где толком зачётов то и не было, а вот полезных знаний много. Знаю, что многие считают их бесполезными. По мне так просто не умеют применять или применяют не замечая.
4+) Системность знаний. Условный список того, что надо вне сферы деятельности. А они как раз и нужны для продвижения выше мидла, а получить самостоятельно крайне сложно. В отличии от знаний непосредственно по программированию, ты не узнаешь нужны ли они тебе, и вообще не узнаешь об их существовании сам. Я не встречал ни у одного наставника список знаний для обучения, столь же хороший как в ВУЗ-е. Это касается в первую очередь знаний вне основной сферы кодинга. Так, например, я встречал очень много мидлов, которые не понимают концепцию двойного рукопожатия(handshake) - для них это магия, не смотря на то, что они тоже учились в ВУЗ-е.
+-) Получение Очень глубоких знаний в какой-то либо сфере(как ни странно, для меня там это стало химией, которую я толком и не помню уже, было на другой специальности). Это то самое, когда по итогу можешь больше, чем знаешь. В самом ВУЗ-е далеко не факт, что получится. А можно и сразу в профе. Скорее тут наставник нужен. Ну или годы с неясным результатом.
А вот пресловутых связей, контекста, языковой среды, особое мышление, я не вижу вообще. Тут реально надо везение со связями.
Контекст среды обучения на работе куда круче - там полно профи с самым разным опытом, в т.ч. вне профы. И у них можно учиться!
Языковая среда - это вообще нечто эфемерное, т.к. в каждой компании она своя. И то же в различных ВУЗ-ах
Мышление даётся с практикой, или после некоторой "планки" понимания. Практика в ВУЗ-ах часто не даёт даже минимум(в хороших минимум и чуть выше выходит). Как можно говорить о SOLID, если человек толком код не трогал? По выпуску могу сказать, что никто не знал что это, но половина заучила определения. То же самое с тупым заучиванием паттернов, схем и т.д. Что-то об абстракциях - это как на иностранном пытаться объяснить. Разве что тервер, теория игр, графы и т.п. дают понимание.
Польза то есть. Но какой ценой? Это не просто 5 лет на обучение. Это годы потраченные на изучение того, что уже никогда не понадобится. Такая низкая эффективность приводит к потере смысла так учиться при наличии альтернатив
А какие ситуации? Я вот думал поехать за гранку и говорили диплом не плохо бы... Но чёт так и не пригодился. В РФ ни разу не нужен был. Ну вот сейчас дают как бы бронь. Но не всегда помогает и тоже как-то мимо. Было нужен диплом в одном место устроится, так место такое, что даже хорошо, что нельзя - не свернёшь на опасный курс)