Кваліфікація та стандарт рвіня знань програміста. Чи потрібно?

Так склалося, що довелося мені змінити місце постійного проживання (ні, не те, що ви відразу подумали, а якраз в зворотному напрямі — зі заходу на... центр, точніше з Рівне в Київ). У Львові я працював в одній не дуже великій та і не малій фірмі, мав 10 років стажу практичного програмування, займав позицію Senior Frontend Developer, володію знаннями (майже) повного LAMP стеку технологій, та багато чого, що до цього прикладається — від шаблонів проектування до способів захисту від ХLL атак, фреймворків від Angular JS або Knockout JS до ZendFramework та Yii, від AJAX до XHProf і роботи з сокетами і т.і.

Отже, приїхав я в столицю, виписав декілька об’яв, що називалися Frontend Developer, JavaSript Developer та пішов на співбесіди. Відразу хочу попередити, що роботу я знайшов, отже це я пишу не для того, щоб пожалітися на свою долю, а для того, щоб з’ясувати думку шановного товариства.

Отже, співбесіда № 1. Ну, хто, що, навіщо..... якийсь невеликий тестовий приклад..... нічого особливого. Але коли я якось до слова сказав, що окрім GET, HEAD и POST міжсерверних запитів існують ще й PUT, TRACE, CONNECT, LINK, та ще декілька інших, мій співбесідник був, здається, досить здивованим, бо..... він такого не знав. А був він Frontend Team Lead досить немаленької Team, в досить немаленькій конторі.

Співбесіда № 2. Проводить дівчинка-рекрутер. Ну, це зрозуміло. Але 4/5 слів в моєму резюме їй, здається, були зовсім незнайомими. Потім, вже з бесіди в технічним спецом, я зрозумів чому — їх резюме називалося JavaSript Developer, але насправді вони шукали —як я зрозумів з запитань, що він мені ставив — явного Junior, ну, можливо, не нульового, а десь на другому-третьому році. Вони так і сказали — досвід від 2 років.Мабуть для них це основний критерій переходу від Junior до Middle? Тому і питання були на рівні Junior.

Співбесіда №N. Вакансія називалася «Web Developer», перераховані — абсолютно стандартні скілзи. Шлю резюме, отримую запрошення, іду. Ситуація зворотня. Поговорили, побалакали, один одного зрозуміли, знайшли спільну мову, начебто все добре. Аж тут — бац. «Ви повністю відповідаєте нашим вимогам. Ваша посада буде Middle, а отже і зарплатня буде відповідна». Я не проти такої зарплатні, але навіщо на співбесіді довбатися до рівня знань Senior/Team Lead, коли тобі потрібен (чи може гроші є тільки на) Middle?

Взагалі то я дуже поблажливо відношусь до всяких «титулів» і до того, як мене будуть називати — мені все рівно. Але виникає питання. Чи існують якісь уставлені вимоги до спеціалістів того чи іншого рівня. Бож на цих співбесідах HR імітують бурхливу діяльність. Губиться час спеціалістів, і не маленький, причому з обох боків. А чому? А тому, що кожен разуміє під Junior чи Senior те, що він хоче, і це може ніяк не співпадати з тим, що під цими словами розуміє кандидат, або навіть розуміють інші роботодавці. I що TeamLead це не просто той, що пропрацював на цій фірмі N-років, а системний архітектор — не той, хто крім JavaScript вивчив ще і PHP.

Я розумію, що в кожної контори можуть бути свої особисті потреби, щось має більше значення, щось менше. Але чи не розумніше було установитися, що для рівня «А» спеціаліст має знати те, те і ось це, а для рівня «В» — його знання мають обов’язково включати ще и «ось це, та от такий досвід». А вже потім особливі потреби кожної фірми просто додавати до цих стандартів, на них і саме них зосередившись на співбесіді. Та й багато хто з кандидатів не гаяли б свої зусилля, ходячи по завчасно програшних співбесідах. Всі б економили час, нерви, в кінцевому вигляді — гроші. Кожен сам би міг об’єктивно визначити свій рівень. В разі бажання — підтягнути ті чи інші питання, а не так як зараз — дивитися на «зарплатомір» з бажанням отримати зарплатню гуру на підставі «n-років досвіду», але маючи реальні знання юніора? А може супротив вижванню таких «стандартів», або краще сказати — «загальнопройнятих норм рівня знань» — є лише острахом за те, що вони можуть «вивести когось на чисту воду»?

Отже питання — стандарт рвіня знань, умінь та навичок для кожної градації розробника. Наприклад для такої спеціалізації, як «Web-розробка». Чи можливо? Чи доцільно? Чи вплине це і на якість проектів, і на якість умов праці, і на зарплатню, і на перспективи професійного зростання розробника?

Що думає шановне товариство?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Отже питання — стандарт рвіня знань, умінь та навичок для кожної градації розробника. Наприклад для такої спеціалізації, як “Web-розробка”. Чи можливо?
Честно говоря, не представляю себе адекватный генерализованный способ оценки...
1. Компании и проекты очень разные, требующие совершенно разных навыков. Со своими взглядами на “сеньорность”, “миддловость” и т.д. Как упорядочить требования и привести это к общему знаменателю, трудно представить.
2. Такой универсальный метод оценки кандидата должен быть быстрым. Соответственно, это должно быть анкетирование или тест, наверное, дополненный практическим заданием (и чтоб все было приведено под общий стандарт). Но тут дело в том, что на такой общеизвестный экзамен соискатели быстро “натаскиваются”, соответственно, он может не отразить реальные знания и умения.
Чи доцільно? Чи вплине це і на якість проектів, і на якість умов праці, і на зарплатню, і на перспективи професійного зростання розробника?
Сомнительно как-то... Сразу вспоминаются совковые “слесари четвертого разряда”, “специалисты высшей категории”, народные и заслуженные артисты и прочая бюрократия, часто расходящаяся с реальностью чуть более, чем полностью.

Я вот одно скажу, все эти грейды от лукавого. Если кратко говорить-просто ваша лычка на конкретном проекте в конкретной конторе на конкретного же заказчика.
У нас чехарда идет от того, что все завязано на аутсорс, и грубо говоря, разработчика надо продать за определенное бабло. Вот и начинаются пляски папуасов на тему синьор/мидл/лид. Степень соответствия грейда/бабла/знаний определяется тараканами заказчика и жадностью вас и нанимателя.
Т.е. нельзя сказать что будучи мидлом в одной конторе на определенном проекте в соседней конторе вас не оценят как синьора, а в конторе на расстоянии квартала-как джуна. Стандартизация как таковая тут невозможна. Надо учиться проходить собеседования в том числе и продавать себя дороже.
Ибо по факту в больше половины случаев реальные навыки мало значимы в сложном деле поддержки и развития системы которая n лет в продакшене поддерживается силами индусских братьев.
Это жизнь.

Як на мене у вас просто низькі знання у галузі пошука роботи %)
Беруть тих, кого треба конторі і працюють ті, хто виконує що треба і задовольняє керівництво. І інколи хочуть зекономити при наймі — треба свій інтерес не соромитись пильнувати. Звання ж — то таке.
Як на мене, то звання йдуть не по тех. рівню, а по «що може зробити сам».
Джун — може сам виконувати завдання, якщо хтось розкаже, як.
Мідл — може сам виконувати завдання без пояснень.
Сеніор — може сам ставити завдання.
Лід — може сам з 0 створити проект.
Таке просто не вийде стандартизувати. Бо це дуже відносні поняття. З одного боку потрібна кваліфікація і на різні проекти вона різна. З іншого — потрібна самостійність та відповідальність. І вона теж, насправді, залежить від проекту, але вже зовсім не так.

Лід — може сам з 0 створити проект.
Один в поле не воин.
Из всех лычек лид/архитектор — самые неоднозначные. Лид — был такой советский термин “руководитель группы”. Более правильно раскрывает смысл данной роли. В идеале опытный(!) сотрудник имеющий авторитет среди членов группы и умеющий находить язык с менеджментом, сотрудниками и представителями бизнеса. Уровень его знаний не столь важен, точнее скорее важна широта, чем глубина. Ну и опыт наступания на грабли в прошлом, что бы избегать этих граблей в настоящем.
Архитектор — еще более слабо понимаемая роль. С моей точки зрения — очень опытный разработчик с широким кругозором, его задача подключатся к проекту на этапе “начала разработки после выработки требований к продукту”, что бы перевести требования бизнесовые в функциональные, придумать высокоуровневое решение, выбрать технологии, провести декомпозицию и.т.д. Видит решение в целом и понимает куда оно движется. Скорее пишет документы и раздает задачи, чем разрабатывает реально. После — “скрипач не нужен” особо и может подключатся по мере появления серьезных изменений в системе. Хотя, на практике, частенько присутствует на проекте и выполняет роль “отвечающего на все вопросы”.
Эти две позиции имеют слабое отношение к разработке, крайне сложно подобрать на них людей со стороны на основании каких то технических собеседований.

Сам тут в смысле, что раздавать указания тем, кто с ним — будет только он сам. Не обязательно он это делает, скорее может. Ну и да, там ещё менеджерство, но он по-моему таки отличается от ПМ именно тех. знаниями.

Описанные проблемы в посте лишь часть истории.

Вообще все выглядит как 2 больших пула: один пул свободных разработчиков, которые ищут работу, а второй пул работодателей, которые ищут разработчиков. На весь этот замес усадили девочек HR-ок чтобы они хоть как-то упорядочили все это.

И вот одна за другой происходят встречи где название в резюме ~= названию вакансии, ну и традиционно ±1 уровень ранга. Дальше начинается самое интересное.

Не знаю как в других языках, но мне почему-то кажется что у front-end’ов объем вечеринки самый масштабный: одни хотят паттерны на изусть чтобы знали, другие хотят гуру-css-анимации (правда стесняются об этом написать и пишут просто css), третьи пул фреймворков js нужен, а остальные вообще нативный js хотят.

Кстати, одна из HR-ок писала в вакансии English: Fluent, на мое резонное замечание мол “где вы в Украине fluent’а искать собрались?” сказала что нужно чтобы человек смог кое-как поговорить с французом на английском.

И я не думаю что в этом всем уместно рассуждать про

критерій переходу від Junior до Middle
дивитися на “зарплатомір” з бажанням отримати зарплатню гуру
Happy end настает когда компания и разработчик находят друг друга, а титулы и з/п это уже нюансы.

ко всему сказанному можно еще отнести вариант, когда позиция горячая, не могут найти хорошего специалиста и выбирают из тех, кто есть. А человек этот к примеру говорит — я пойду работать на такую-то зп (тут у каждого свои запросы), компания соглашается на его пожелания, но выходид завтык с зп. Зп вроде как у синьора, а сам он мидл по факту, ну не нашли они синьора. Пишут ему должность синьора, т.к. в компании есть вилка зарплатная по разным левалам.

Я таких примеров знаю достаточно :-)

Моніторю потребі рінку ІТ праці, тому можу поділтися зі свого досвіду.

Junior — знає мову программування, достатній рівень знань для написання простих скриптів
Middle — впевнено программує складні срипти, розбирается у багатьох техноліях
Middle Strong — ціе підвид Middle, але його часто запрошую як Senior, бо це той самий Senior, тільки він більше користуется довідниками, тому працює повільніше і повініше освоює новітні технології.
Senior — Middle, котрий вкурсі нових розробок, вміє ними користуватись та єфективно використовувати
Lead — Senior с зі схиленням у менеджмент великої кількості людей, бути вкурсі всіх ІТ новинок, та ефективно їх застосовувати — його робота.

Моніторю потребі рінку ІТ праці, тому можу поділтися зі свого досвіду.

Junior — знає мову программування, достатній рівень знань для написання простих скриптів
Middle — впевнено программує складні срипти, розбирается у багатьох техноліях
Middle Strong — ціе підвид Middle, але його часто запрошую як Senior, бо це той самий Senior, тільки він більше користуется довідниками, тому працює повільніше і повініше освоює новітні технології.
Senior — Middle, котрий вкурсі нових розробок, вміє ними користуватись та єфективно використовувати
Lead — Senior с зі схиленням у менеджмент великої кількості людей, бути вкурсі всіх ІТ новинок, та ефективно їх застосовувати — його робота.

«А судьи кто?» ©
На первом этапе вам встретится рекрутер, задача которого — закрыть вакансию. При этом здесь вопрос не только в «получить бонус за позицию», но и в «в прошлый раз по резюме смотреть не хотели, а после собеседования с руками оторвали». Ведь, кроме тайтла, есть еще и набор специфических технологий/особенностей именно этого проекта. Поэтому, если кандидат хоть сколько-нибудь вероятен для закрытия вакансии, его будут подгонять под требования позиции ("если, конечно, они у вас есть«©).
Далее может быть техническое собеседование, и, как упоминалось в самом посте, собеседующий сам может обладать более скромной квалификацией по различным причинам. Отдельно хочется коснуться момента, когда задаются вопросы «джуну — синьорные» или vice versa. Если компания не очень маленькая, то с заключением о техническом собеседовании могут захотеть ознакомиться представители других тимов/проектов, — возможно, им такой человек подойдет. И это, кстати, как раз призвано экономить время специалистов с обоих сторон.
Идем дальше. Если компания аутсорсинговая, то важно, чтобы клиент «купил» кандидата. Будет ли это собеседование, просмотр резюме или просто невысокий риск завала работы — уже детали. Важно, что акцент смещается с «может» на «продает себя».

Даже если искренне подходить к желанию стандартизировать тайтлы, то появятся ощутимые вариации по языкам/фреймворкам/смежным технологиям, поскольку проекты разные. И если в одной ситуации говнокод — это показатель незрелости кандидата, то в другой — это проектные ограничения, где есть отдельная корректировка результатов статического анализатора на предмет что считать багом или пунктом на клинап, а что — участком кода «так надо». Конечно, определенное разграничение можно создать, но надо отдавать себе отчет в том, что границы довольно размыты. При чем это и в Украине, и зарубежом. Линейкой это, увы (или к счастью), не меряется, сплошной субъективизм.

Так что пока: «Улыбнись-ка на 20 баксов» © «Кучеряшка Сью»

Із власного досвіду можу сказати, що тут вся справа у конкретній компанії на яку подаєшся.

В одній мене маркували як сеньйора, в той час як в інші я був мідлом (подавався приблизно в один і той самий час).

З того, що я зрозумів, визначають твій рівень під поточний проект і вимоги. Можеш бути крутим у вебі наприклад, але недобираєш по секюріті, тоді тимчасово ставлять мідлом. Довчають те, чого не знаєш в security стеку і тоді дають сеньйора. Це як я бачив.

+ у кожної фірми є свої критерії. У деяких сеньйори слабші, ніж в інших.

Думаю, сертифікатів на рівні ніхто придумувати за таких умов не буде. Як вже правильно коментували раніше, працедавцю потрібні не знання а конкретні навики в тих речах, які вимагаються на конкретну вакансію.

ИМХО, проблема в том, что работодателю нужны ваши навыки, а не знания.

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

Если сравнить работу с браком, то сейчас все женятся, после получасового собеседования. Где «парень» и «девушка» просто рассказывают о себе. А как показывает практика жизни, даже если встречаться 3 месяца, разводы все равно случаются.

Но все же собеседование является плохим способом анализа навыков кандидата:
1) Люди без опыта могу выглядеть, как хорошие специалисты
Прочитать пару книг перед собеседованием. Студетны сдают экзамены по тому же принципу:
2) Крутые спецы могут завалить половину теории
Достаточно пару лет чем-то не пользоваться, как это сильно забывается. Приходится даже основные принципы ООП рассказывать своими словами.
3) Навыки так быстро не проверишь
Чтобы понять какие у человека навыки, как он понимает код, надо дать ему покодить в проекте не меньше месяца.
4) Человека проверить еще сложнее
Чтобы понять какой человек козел, надо съесть с ним пуд соли поработать с ним месяца три.

Кстати хорошая идея для стартапа — типа brainbench с элементами pearson vue,
Для начала на самые горячие специальности и грейды местного рынка, но с хорошей перспективой.

Спробуйте нагуглити пам’ятку до введення 12-бальної системи оцінювання в школі. Ви там ніде не знайдете «знає те й те, то ж 7 балів, а знає ще й те — це вже 8». Замість цього там буде: «вміє користуватись», «знає більшість фактів з підручнику», «вміє робити висновки» й аж до «знання значно виходять за рамки шкільної програми» на 12 балів. Тобто програма у всіх одна, успіхи — різні.
Також з джунами-мідлами-сеніорами, те, чим вони повинні володіти, у всіх однакове, але вищий рівень ще вимагає ще й відповідного досвіду, в тому числі менеджерського (здатність вести людей, тягнути джунів тощо), а нижчий дозволяє мати пробіли в знаннях.
Таким чином стандарт встановити можна, але він не буде технічним.

Немного не согласен. Оценка — это степень овладения материалов. А вот набор того что надо знать — это уже немного другое. Тут уместно, наверное, привести другую аналоги.
Математику изучают в школе. И оценивают по определенной шкале.
Математику изучают в школе. И оценивают тоже.
Математику изучают в университете. И тоже оценивают.
Понятно, что и везде оценка может быть одинакова. А вот то, что именно оценивается — весьма различно.
Примерно так-же и для квалификации программистов.Оценка знаний — условно конечно — для юниора, миддла и синьора — это разные вещи. Грубо говоря, для того-же JavaScript для разных квалификаций надо разные вопросы задавать. И тут автор топика прав — а где тот «список вопросов» для каждого уровня специалистов?

И тут автор топика прав — а где тот «список вопросов» для каждого уровня специалистов
dev.by/...gramming_matrix же

Вся проблема что даже в условиях полной жопы в стране на рынке есть дефицит разрабочиков.
Мэм о 23х летних сеньорах появился еще лет 4 назад наверно))
Добавить сюда повальный тренд — «а нахера учится в вузе, пойду после школы на работу. Все равно только штаны протирать» и получаем вот такую картину.
Многие наши 20ти летние стартаперы вешают себе ярлыки СЕО, СОО и т.д. хотя толком и не знают разницу этими аббревиатурами.
Тайтлы, квалификация и стандартны — все это очень относительно ИМХО у нас.

но вы не будете говорить что хотя бы от части НЕ правда про:
>"

Добавить сюда повальный тренд — «а нахера учится в вузе, пойду после школы на работу. Все равно только штаны протирать» и получаем вот такую картину.
"

Підписатись на коментарі