Comments 13
Я сам не особо эксперт, но думаю могу добавить пару комментариев на этот счёт.
Как по мне измерять грейд числами, не совсем корректно, так как нельзя точно цифрами определить насколько человек ответственный, или насколько человек компетентен, это дело субъективное.
Постановка задачи отражает всеобщее представление о том, что "сеньор" — это здорово прокаченный "миддл".
«не количество навыков делает из мидла синьора, а образ его мышления».
С этим можно было бы вполне согласиться. Но что это значит? Это значит, что речь идёт о различии компетенций: у "миддла" и у "сеньора" разные области компетнции. Грубо говоря, у "миддла" область компетенции — это библиотеки, а у "сеньора" — архитектура. Это совершенно разные задачи! Вы (все) пытаетесь выстроить некую единую шкалу компететности, помещая на эту шкалу и "джуна", и "миддла", и "сеньора". А нужны просто специалисты под различные задачи. Младший программист — это ученик. Не следует ждать от него уже готовых навыков и умений. На на деле, мы видим, что на такие вакансии уже требуются готовые специалисты. Обыкновенные программисты — это те, кто, собственно, и разрабатывает для компании рабочий код. Младший программист не должен писать код для "прода". Он пишет код для самообучения. А, вот, старшему программисту нужно решать архитектурные задачи и по мере их решения предлагать собственные библиотеки, которые будут использоваться в разработке. Старшего программиста можно просто назначить. Просто кто-то обязательно должен заниматься архитектурными вопросами. Разработчикам ("милллам") некогда проводить исследования. Они работают в рамках жёсткой спецификации. Но кто-то должен сам создавать такие спецификации. И тут достаточно двух-трёх библиотек, чтобы взять какого-нибудь "миддла" и сделать "сеньором". Просто задачи разные. Трудно цифирьками измерить.
Текущие веса оптимизированы под экосистему C#/.NET.
Если нужно оценивать именно уровень компетентности в рамках какого-либо языка программирования и/или технологии, то здесь нужно, прежде всего, выделить саму структуру знаний. Есть синтаксис языка, если его семантика, есть типовые задачи и типовые подходы к решению данных задач, есть типовые приложения и технологии их построения, основанные на определённых библиотеках. Но! если у нас есть описание этой структуры, то мы можем построить на базе этой структуры обучающий курс и любого специалиста подтянуть до "сеньора". Весь вопрос в том, что мы хотим: мы хотим что-то там измерить или получить готового специалиста?
Проблема в том, что знание языка - это не единственный критерий. Я смотрю на то, что хотят от специалиста работодатели. Знание языка - это лишь один кирпичик из всей стены должностных обязанностей. И измерить я хочу все, что пишут работодатели, чтобы в первую очередь разраб, вышедший на рынок, понимал, что от него хотят и к чему быть готовым
Вы хотите измерить. А мне нужно освоить, овладеть. Мне нужен инструмент для успешного овладевания C#. Что бы иметь ясный курс и реально оценивать свой текущий уровень. Нужны какие-то задачи. Вот здесь мы изучаем язык. Вот здесь — рабочие инструменты. Вот тут — методологию создания приложений (определённого типа). А здесь — создаём законченные решения. И чтобы тебе в конце ещё и сертификат выдали, что ты всем этим действительно владеешь. (Вопрос, ещё и за какие деньги. Но сейчас вопрос о принципах.) Было бы очень удобно самостоятельно что-то изучать, но в определённой системе, да так. чтобы свой текущий уровень можно было предъявить любому потенциальному работодателю. (Поработали ещё немного, сделали собственными руками какую-нибудь СУБД, вот, уже, и "сеньор".))))
Мы с Вами говорим о разных вещах. Самостоятельное обучение сравнивать с коммерческой разработкой несколько неверно. Вы, конечно, можете выйти на уровень больших компаний по обеспечению, реализовав нужное окружение, построив чистую поддерживаемую архитектуру с использованием эталонов стека, но вы не сможете воспроизвести работу с требованиями, нагрузочное, интеграционное, элементарно smoke-тестирование. Коммерческая разработка - это большая ответственность, большая нагрузка и множество часов работы в рамках неопределенности, так как никогда не знаешь, что сделает пользователь или какую деталь упустили при анализе. Я пытаюсь выделить грейды именно для такой среды, чтобы тот же студент, вышедший на рынок и имеющий знания стека, соответствующих ожиданиям рынка, мог без страха откликаться на вакансии, понимая, что его ждет. А Вы пишете о "домашнем" последовательном обучении, которое может устареть через полгода из-за развития индустрии
А Вы пишете о "домашнем" последовательном обучении, которое может устареть через полгода из-за развития индустрии
В том-то и интерес — найти такую последовательность, чтобы не устарело. Изучать больше принципы и методику, а деталям реализации отводить своё узкое место. Так и измерять будет просто: человек принципы хорошо знает? Хорошо. А остальное можно и в справочнике узнать (или у LLM спросить).
Не представляю такую последовательность, включающую в себя конкретные навыки. Все достаточно быстро меняется и попытаться такое реализовать - упереться в обобщение и абстракцию, что на практике мало что даст
Есть общие вопросы: управление памятью, мнопоточность, ООП, пользовательский интерфейс, работа с базами данных. Да есть некоторые частности, вроде Linq и Entity Framework. Но это очень важные частности. Есть толстая тёмнобордовая книжка по C# (Нейгел и другие). Можно взять за основу. Для новичка это будет каркасом для целенаправленного обучения, а для компаний — способом измерить компетенции.
От слов к числам: как математически отличить Middle от Senior