Сеньоры

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

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

Кажется, проблема лежит глубже, и все смешалось в кучу.

О многомерности вопроса собеседований

Тут можно очень много говорить, но в целом, вопрос в определениях. Люди рассуждают о собеседованиях, не задав уточняющие вопросы (как на собеседовании к задачам).

Во-первых, какие бывают области разработки ПО? Вспомним миры Джоэла Спольски. Уже это будет давать разные требования к собеседованиям.

Во-вторых, что за компания? Стартап, big tech, галера, веб-студия, интернет-магазин, или контора с IT-отделом, где основной бизнес другой?

В-третьих, что такое сеньор? В комментариях к посту верно отметили, что в сеньора смешивают все архитекторов, ведущих программистов, узкоспециализированных специалистов и так далее.

Далее, какие цели и какого собеседования? Бывают собеседования для поточного набора, бывают поиски звезд, бывают поиски людей с конкретными навыками работы и опытом в технологии, и так далее.

О роли пути в профессию

И, конечно, не стоит забывать про культуру. Знаете, в музыке или в науке есть особое разделение на своих и остальных. Типа, есть у тебя образование профильное и стандартный путь, или нет (в музыке это выражается в обучении более 10-15 лет: ДМШ училище консерватория, к примеру). И мне, имеющему опыт без музыкального образования выступления на сцене с профессиональными музыкантами, хорошо знакомы вопросы ты что заканчивал / у кого учился, которые выделяют своих от остальных.

Программисты получают образование в области CS. Нередко многие из них проходят отбор через олимпиады, где решают специализированные задачи. Учат тонну матана и разных других дисциплин в том числе уже набившие оскомину структуры данных и алгоритмы.

Думаю, немалая часть противостояния лежит в том, что часть программистов имеют профильное образование и считают тру программистами тех, кто прошел схожий с ними путь. А другая часть самоучки (вспомним знаменитое Google: 90% of our engineers use the software you wrote (Homebrew), but you cant invert a binary tree on a whiteboard so fuck off.).

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

Какие предварительные выводы?

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

Считайте, как поступление в вуз все сдают математику и физику, готовятся к экзаменам (и потом успешно забывают к концу учебы тут, правда, замечу, что поступал до ЕГЭ и у нас в каждый вуз были свои типовые задачи и по ним готовились отдельно). Возможно, за этим есть A/B тесты бизнес-подхода к набору, где алгоритмы наиболее эффективно определяют качества человека (способен ли тупо физически выучить все, может ли думать так, как думают будущие коллеги), который будет успешен в компании.

Если в компании АльфаБетаГамма (название выдумано) работают с Джавой и нужно знание нюансов всего стэка, то будет разумнее спрашивать пет-проекты или нюансы по технологии, ибо нужен будет опыт.

При этом, если зарплата хорошая и поток большой нубов из-за большой суммы да, поставят на входе задачи типа напишите пузырек, чтобы не тратить время (собеседование минимум полдня подготовка + созвон + вернуться обратно в рабочий режим) на тех, кто решил попытать удачи (на Хабре уже была статья про войти в айти, и не одна).

Если же в компанию ДельтаДзета (название тоже выдумано) берут по рекомендации архитектора на серьезную должность, то с ним пообщаются по профессии, с уважением, и не будут задрачивать на дебильных задачах.

Однако, если в вышеописанных случаях происходит то, что всегда происходит человеческий фактор типа внутренней политики то либо усталый программер на силой навязанном ему собеседовании будет валить кандидатов, либо будет валить потенциальных конкурентов, либо что-то еще.

Немного о пользе алгоритмов

Я по образованию инженер-робототехник, и у меня были некоторые курсы, которые есть у программистов, но далеко не все. И изначально всегда относился со скепсисом к алгоритмам, ибо первая реакция, когда кто-то пишет, кто не читавший Кнута не есть программист, негативная.

Со временем, изменил свое отношение, и считаю, что это как школа. Ты тупо впитываешь знания, полученные лучшими умами за прошлые десятилетия. Чтобы понять, и если потом нужно будет быстро нагуглить или написать самому. Стал испытывать удовольствие, когда прорешал N задач на Codewars, и прочитав на русском + проработав упражнения отличной книги Питон и алгоритмы (всем рекомендую, есть еще на английском).

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

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

Рано или поздно, начинается граница, для которой нужно иметь некий запас знаний и навыков (например, в играх математику, работу с графами, памятью, рекурсией и тд; в data science, как хорошо недавно писали линейную алгебру, статистику + системы аналитики), которые придется освоить.

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

Привет, Хабр! Меня зовут Женя. Десять лет назад я стартанул агентство аутсорс-тестирования Кавычки. У нас в компании нет и никогда не было деления тестировщиков на джунов, мидлов и сеньоров. Хотя были попытки. Расскажу, почему так получилось и как можно жить без грейдов.

Спойлер: жить не тужить

Disclaimer

Многие IT-компании используют грейды (они же градации, ранги, классификации и т. д.) такой способ поиска, оценки и мотивации людей. Окей, система выглядит вполне логичной. Если ты мидл ты должен знать вот это, уметь вот это, а твоя зарплатная вилка вот такая. И было бы всем счастье, если бы это действительно работало.

Еще на старте я понял, что в моей компании с грейдами не срастется. Сколько бы я с этим не сталкивался, они не оказывались чем-то внятным, кроме как строчкой в резюме. Здесь все-таки стоит сделать небольшую пометку: мы занимаемся аутсорс-тестированием и работаем с разными проектами. В нашем случае грейдирование оказалось бесполезным. Возможно, компаниям, которые развивают только свой продукт силами внутренней команды, эта история подойдет.

Внедрять грейды или отказаться от них каждый решает сам. Я на личном опыте убедился, что без них можно круто развиваться и расти. И хочу рассказать, как построить работу в команде без градаций и что от этого ждать. Если кому-то мой опыт будет полезен отлично. Для этого и пишу. Если нет тоже сойдет.

Откуда ноги грейды растут или немного лирики

К 20 веку корпорации стали больше интересоваться методами эффективного управления командой. Тогда не существовало единой и понятной схемы, как определить взаимосвязь между ценностью, которую сотрудник приносит в компанию, и его зарплатой. Был такой психолог и владелец консалтинговой компании Эдвард Хэй. Когда он в очередной раз оценивал сотрудников клиента, его светлую голову посетила идея разработать методику, позволяющую рассчитывать эти показатели.


Непонятная схема или пример подстановочных таблиц (по Hay Job Evaluation and Profile Method)

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

В IT система грейдов по классике состоит из трехуровневой модели джун, мидл и сеньор. Правда, встречаются и более замороченные варианты: джуниор+, мидл+, мидл++ для знатных приверженцев грейдов. Часто компании формируют необходимый перечень навыков и подстраивают грейды под себя. Как итог на рынке много джунов, мидлов и сеньоров, но все они разные. И из-за этого и появляются запросы на грейд уровня + или ++. Потому что хрен ты сможешь оценить специалиста точно в указанные рамки. И вот здесь начинается Адъ и Израиль.

Что не так с грейдами

Первое, чо я понял их не существует

Когда я начал нанимать ребят в штат, то все чаще сталкивался с одной и той же ситуацией. На собеседование приходит человек с большим опытом на прошлом месте он был на позиции сеньор. Он хочет за свою работу высокую з/п, ведь он сеньор. Тогда я прошу его рассказать, за что он хочет такие деньги, что он умеет? В итоге понимаю, что знаю гораздо больше, но работаю за меньшие деньги. И опыт на тот момент у меня был небольшой около 5 лет. Тогда кто я, если обладаю большим объемом знаний, чем сеньор в тестировании? Может быть, дурак, который дёшево себя продает? Или, получается, что объективных градацией для меня просто не существует. Возможно, уровень сеньор должен определяться тем, что человек может решить любую задачу, потому что он не только имеет опыт, но и склад ума к solving problems. Посмотрим на это ниже.

Но я же мидлили нет?

Есть еще одна боль с этими классификациями. Тестировщики на позициях джуниор, мидл, сеньор, работая в одной компании, как правило, сидят на одном продукте. В рамках одного продукта сложно прокачать разносторонние навыки. Если тестировщик работает с приложением только на десктопе, то он заточен под тестирования этого приложения. И да, возможно, в этой области он очень хорош знает инструменты, подходы, как проверить производительность и т. д. Но если понадобится сделать то же самое в вебе или в мобильном приложении будет больно. Потому что нет знаний о вебе, о мобильном, о клиент-серверной архитектуре и тп. Ну и кто же он тогда? Джун?



Что мы получаем:

• Система грейдов негибкая и необъективная

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

• Грейд ничего не говорит о настоящем уровне знаний

Сеньор может пытаться устроиться в другое место с более сложными проектами, но не пройдет даже на джуна. Потому что не обладает подходящими навыками.

• Грейды ограничивают

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

• Грейды всех путают

При поиске работы многие люди осознанно выбирают вакансии не по уровню знаний и навыков, а по размеру зарплаты, которая как бы соответствуют их грейду. Итог: разочаровываются обе стороны.

Окей, тогда как оценивать работу

Ну отказались мы от грейдов, чо дальше? Если работать по модели предоставления аутсорс-услуг, то нет смысла привязывать з/п к званию и стажу. Потому что в компанию приходят проекты с разным уровнем сложности, и работа над ними требует постоянного апгрейда навыков. Здесь логичнее смотреть на то, какие задачи может взять сотрудник, и сколько денег он принесет в компанию.

По каким параметрам оценивать сотрудника:

• количество задач, которые он может взять;
• уровень сложности, неопределенности и стоимость этих задач;
• востребованность навыков, которыми он владеет;
• общая прибыль компании.

Как это работает у нас: мы предоставляем клиенту команду тестировщиков на проект. Поэтому на собеседовании мы смотрим на навыки тестировщика и сопоставляем, на каких проектах можем их применить и под какие задачи. У нас есть диапазон з/п, в разрезе которого мы готовы обсуждать оклад. В этом диапазоне мы и определяем фикс в зависимости от проектов, на которых тестировщик сможет работать.

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

А что с мотивацией и ростом

Компания, которая не привязывает з/п к должности и стажу, дает большое пространство для развития. Хочешь расти и больше зарабатывать все в твоих руках: учись, бери новые проекты, работай над сложными задачами. Например, если наши тестировщики хотят поднять з/п, то мы с каждым обсуждаем: на какой проект для этого нужно пойти, какие задачи взять, чему научиться.

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

• Чтобы увеличить з/п, нужно постоянно учиться, прокачивать навыки.

Для этого компания должна помогать сотрудникам проводить внутреннее обучение и оплачивать курсы, сертификации, тренинги.

• Чтобы увеличить з/п, должна быть возможность взять новый проект или более сложный.

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

Человек учится, переходит на другой проект или берет еще проект, потому что на прошлом наладил все настолько хорошо, что его присутствие там требуется в меньшем объеме, и вместе с ним растет его з/п. Это же гораздо лучше и интереснее, чем сидеть, считать стаж, сдавать тесты на профпригодность и знания, которые ты потом никогда не будешь использовать. Или вовсе потерять интерес к профессии, упоровшись на одном проекте. А упарываясь на одном проекте, упираясь в потолок, люди будут покидать компанию.

Как-то все слишком красиво, где боль

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



Кому-то сложно работать без понимания, какой у него грейд. Без четкой инструкции, что нужно сделать; сколько проработать, чтобы добраться до нового уровня. И в этом нет ничего плохого такой тип мышления. Но я уверен, что без грейдирования и компания, и сотрудники могут достигнуть более крутых результатов, чем с ним. Потому что такой подход притягивает в команду целеустремленных и свободомыслящих людей. И они готовы действовать без каких-либо инструкций и рамок. К слову, на эту тему есть интересное исследование, что ждет компанию, которая откажется от жесткой иерархии и градаций. Возвращаясь к конфликту интересов, я вижу только два решения: либо найти компромисс и точки роста с помощью новых проектов и задач, либо попрощаться. Каждому свое.

Что еще важно или история про понты

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

Сказал а, говори б. Окей, вот история из жизни:

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

Ну хорошо, а на виндоус можешь это сделать? спросил я.
Нет, виндоус говно.
Ну подожди, а если задача такая будет, что ты будешь делать? не успокаивался я.
Я буду на линуксе это делать.

Занавес.

Ну вот как работать с человеком, который будет делать только то, что ему нравится? Как он будет развиваться и узнавать что-то новое? Какая мне разница сеньор он или не сеньор, если он не может сделать то, что нужно проекту?

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