По контексту понимается, что вошел в профессию сразу на должность лида на проекте :)

Не совсем так :) Скорее волей случая оказывался в правильных проектах в правильное время и очень хорошо нахватался полезного опыта. Оттуда получил возможность погрупплидить, хорошо себя проявил и дальше получил возможность повести проект. Быстро, да, очень часто обучался в процессе. Но всё было по честному, без кумовства и прочих шорткатов.

Работая в большой компании можно очень долго ходить по проектам и реально получать новый опыт и знания.
Если же возможности ограничены, то да, удерживать сотрудника чисто ради удовлетворения потребностей бизнеса — это не круто. С другой стороны, если человеку не нравится, то он всегда волен поменять место работы.

Скорость обучения у всех разная, а опыт набирается не годами, а решением определенных задач

С тезисом абсолютно согласен. Другое дело, что в повседневной работе среднего сотрудника возможности освоить или попробовать что-то новое появляются далеко не каждый день.

Зачем с ней бороться? Есть вполне объективные показатели. Если чувак отработал у Вас пол года трейни и его захантили на мидла то он мидл. Если нет то все ок и он у вас останется. Где вообще проблема?

Я вот прямо не могу согласиться, что этот показатель объективный... Если кто-то кого-то нанял на позицию мидла — это значит, что в данной конкретной компании в данный конкретный момент данный конкретный человек подошёл под местное понятие «мидл». Объективно это никак не влияет на экспертизу или профессиональный опыт человека.

К чему эти сопли?:) Как много кандидатов у Вас подошли с просьбой рейза с ~1к до ~2.5 к и скольким вы его заапрувили не паря мозг своими перформанс ревью и knowledge evaluation.

Если бы зарплата поднималась без «перформанс ревью и knowledge evaluation» — все бы получали миллон в месяц и в ус не дули. Подобные способы оценки нужны как раз для того, чтобы понять, может ли человек по принятой в компании шкале получать запрошенный доход.

У меня есть однокурсник который за 3.5 года дошел до тим лида и открыл свою контору:)

У меня был однокурсник, который свой путь в IT вообще начал с открытия конторы :) Это не показатель...

В Украине, конечно же! Правильное замечание.

Здравствуйте!
Из конференций вне компании я выступал на Nix Multiconf.
Свежее выступление можно глянуть вот тут

Начало на 2:47:07 (с телефона ссылка на таймстемп не копируется).

Категорически плюсую к тому, что нас этому не обучают.

Это глобальная проблема ребят из Украины, которые работают с американцами и прочими заграницами. У них на той стороне очень развита культура подачи и презентации, но при этом работа может делаться абы как. А у нас всё с точностью до наоборот! Работа, как правило, делается отлично, но часто не презентуется вообще, а тихо отдается заказчику.

Если будет желание глянуть запись онлайн выступления — она тут youtube.com/watch?v=qkUCzvP-5mg?t=10098

Статья очень сжато передает смысл лекции, которую можно найти на ютуб канале NIX. Общий посыл скорее мотивационный, чем технический, тест дизайн туда просто не уместился, т.к. была задача раскрывать самые банальные понятия с самых «низов», а времени было в обрез.

Научиться программировать за пару часов и правда, конечно же, не получится. Но вот посмотреть базовый курс языка и попробовать автоматизировать какие-то проверки через готовую библиотеку или не сложный фреймворк — вполне реально за один-два рабочих дня.

Вообще сложно с этим согласиться. Если QA инженер поверхностно вникает в происходящее, то и правда разницы практически не будет. Но если тестировать приложение как условный серый ящик, то знание архитектуры полезно для поиска потенциальных проблем.