Мы провели обширное исследование среди программистов и их руководителей. Собрали требования к senior-разработчикам топовых компаний, возможности и пути к развитию до этого уровня, сгенерировали всевозможные инсайты и лайфхаки и трансформировали их в данную статью. Об всем этом и пойдет дальше речь.
Senior, who the f… is Alice Senior?
Анализ описания вакансий на hh и требований, которыми поделились руководители в очных беседах, показал — единого подхода к определению уровня senior нет. В одной компании это тот, кто способен сам спроектировать сложный модуль, в другой — подключиться к доработке отдельных решений, в третьей — тот, кто просто круче остальных. Внутри самих компаний требования также существенно отличаются у руководителей, тимлидов, HR и самих программистов.
В результате разработчики получают ряд проблем: без адекватного определения требований нет четкого видения карьерного пути и шагов развития. Вопросы: “Какой уровень у меня сейчас? Зарабатываю ли соразмерно ему? Много ли мне нужно апгрейдить до следующей ступени?” — мы слышим повсеместно.
Вместо планомерного развития приходится решать стандартные задачи, ждать внимания руководства, осваивать фреймворки, не понимая, продвинут ли они карьеру вперед. Советуем: при входе в компанию или прямо сейчас — узнавайте о требованиях не только к текущему уровню, но и к максимально высокому. Так вы получите перспективное видение развития и можете соотносить с ним каждый шаг.
Оценка программиста — дело рук самого программиста?
Ваше развитие зависит от того, на каком этапе вы сейчас. Но как это оценить? Это вторая проблема.
Из проведенных опросов были получены несколько инсайтов: 70% программистов уровней junior-middle пытаются оценить себя самостоятельно. Парадокс: чем ниже уровень оцениваемого, тем больше он оперирует собственными представлениями.
На начальных этапах отсутствует глубина знаний и широта кругозора — картина весьма ограничена. И такая оценка завышает представление о своем уровне в 86% случаев.
Рекомендуем: как можно раньше переключайтесь от “внутренних” способов оценки (собственное мнение, опыт) на “внешние” — сами запрашивайте фидбэк от руководителя, атакуйте наиболее опытных коллег, сравнивайте задачи и способы их решения, ходите на собеседования в топовые компании, где уровень требований выше и тестовая база лучше и т.д. Оценку руководителя обязательно нужно объективизировать результатами из альтернативных источников, чтобы не попадаться в ловушку ограничений текущих возможностей и требований компании/отдела/проекта.
Но есть путь короче. Мы сами сформировали список требований топовых компаний для senior-специалистов. И обнаружили серьезный лаг, который образуется между уровнями middle и senior.
Если вы не знаете, куда идете, то скорее всего окажетесь где-нибудь не там
Мы собрали требования и обнаружили, что не только хороший код превращает junior-специалиста в middl-а. На уровне junior программист должен освоить все необходимые технологии и способность в принципе решать типовые задачи, научиться писать код грамотно и быстро. На уровне middle-разработчика уже обязательны культура кода, способность мыслить глубже и шире, реализовывать более крупные задачи самостоятельно и уметь применять различные инструменты разработки.
Различие между middle и senior существенно тоньше. Именно здесь у разработчиков образуется лаг, преодолеть который самостоятельно под силу не всем. Это целый ряд навыков и личностных качеств, которые подразумеваются, но о которых никто не говорит четко: ответственность за большую часть разрабатываемой системы, менторство, способность самостоятельно формулировать и предлагать оптимальные технические решения, коммуникативные навыки и т.д.
Итак, кто же такой super-Senior? Чтобы формализовать требования, нам пришлось пройтись по максимуму и собрать воедино все, что предъявляют компании уровня Яндекс, Luxoft, Mail.Ru Group и даже Google в открытых источниках. А также верифицировали эту информацию в беседах с руководителями разработки именитых компаний.
Hard Skills
1. Чистота кода;
2. Верхнеуровневые Hard Skills:
- Знание алгоритмов и структур данных (это база, без которой никуда);
- Знание принципов ООП;
- Знание современных фреймворков (и чем длиннее список, тем лучше; регулярное пополнение приветствуется);
- Понимание принципов проектирования, основных архитектур (самостоятельно проектирует систему/модуль как хедлайнер проекта, либо участвует в проектировании крупных систем; минимально — решает объемную задачу с учетом текущей архитектуры проекта);
- Знание паттернов проектирования (вовремя распознать и применить, а не изобретать велосипед; в широком смысле — это общение в команде на одном языке для быстрого нахождения решения или оценки решения коллег);
- Опыт взаимодействия как с реляционными, так и NoSQL СУБД, построения к ним запросов, навыки оптимизации и управления;
- Понимание принципов организации тестирования, владение юнит- тестированием, в идеале — переход на автоматизированное тестирование вместо ручного;
- Владение хотя бы одной системой контроля версий (чаще всего нужна конкретная, в зависимости от требований компании).
Soft Skills и профессиональный кругозор
Те самые загадочные требования, отчаянно недооцениваемые самими программистами. Зачастую в компании руководство и HR оперируют понятием “командности” и “ответственности”, но никак не формализуют ни их критерии, ни их проявления в жизни. Как следствие — 90% разработчиков не упоминали эти аспекты как важные для развития.
- Понимание гибких методологий разработки, способность с ними работать и адаптировать их под специфику проекта;
- Наставничество: умение брать под свое крыло junior-ов, новичков, а иногда и всю команду в случае острой необходимости;
- Способность находить и предлагать технологии, инструменты для наилучшей реализации, грамотная оценка комплекса задач;
- Навыки работы в команде: выработка договоренностей, принятие командных решений, поддержание отношений, нацеленность на командный результат, следование общим интересам;
- Уровень личностной ответственности — принятие ответственности в сферах: целей и планов, профессиональных взаимоотношений, руководства, карьерного развития.
Идею проверить себя на владение всеми перечисленными блоками нам подарила тотальная скудность инструментов оценки чего-либо, кроме уровня владения языками на российском рынке. Для нужд нашего исследовательского проекта мы составили пробную версию теста для 3х языков, которая помогает быстро сориентироваться в текущем уровне, а также освещает сильные и слабые стороны.
Подводя итог, оценивать себя адекватно с использованием максимального количества внешних ресурсов крайне важно. Дабы избежать классической проблемы на рынке труда — “ожидания разработчиков vs. реальность компаний.” Когда разработчики оценивают свои навыки и их стоимость выше, чем это готовы делать компании. А также надеются на быстрый взлет и развитие, чего в такой мере не происходит (подробнее — в следующей статье).
P.S. В первоначальной версии статьи мы предлагали пройти тест всем желающим. Однако, мы не ожидали такого мощного наплыва респондентов. И были вынуждены были закрыть тест, чтобы быть способными обработать текущие ответы и результаты тем, кто оставил контактные данные. Просим заполнивших тест набраться терпения :)
Комментарии (125)
Paramid
21.11.2018 00:04пытался пройти тестирование по ссылкам в конце статьи: после каждого ответа ERR_CONNECTION_RESET
TimeLab Автор
21.11.2018 00:05Спасибо, что обратили внимание! Очень странно, такой ошибки не возникало в процессе. Иногда бывает, что нет связи с сайтом опросника, попробуйте через какое-то время пройти еще раз.
Source
22.11.2018 01:53Очень странно, такой ошибки не возникало в процессе.
Только вчера обсуждал фундаментальный недочёт в подготовке программистов в плане софт-скилов, который приводит к этому классическому ответу "У меня работает/работало" xD
Как думаете, кому-то кроме Junior'ов допустимо пользоваться таким ответом?Druu
22.11.2018 02:13А в чем вы видите проблему такого ответа?
kozzztik
22.11.2018 11:45потому что это совершенно не важно что и как работает у программиста. Работать должно у клиента.
Druu
23.11.2018 06:28А проблема ответа-то в чем?
Мне, кажется, вот этот ваш ответ гораздо хуже ответа "а у меня работает".kozzztik
23.11.2018 11:37Проблема в том, что это никому не нужная информация не имеющая реального отношения к делу.
Druu
23.11.2018 11:49Почему же? Она имеет вполне отношение к делу, в частности: "Иногда бывает, что нет связи с сайтом опросника, попробуйте через какое-то время пройти еще раз.", а то, что "у нас работает" — это причина, по которой человек решил что проблема именно в отсутствии связи или чем-то подобном.
Какое же это "не имеет отношения к делу"?kozzztik
23.11.2018 11:55Так и какое клиенту дело, что на машине разработчика работало/работает? Ему это чем поможет? Оно не работает у него, и только это его заботит.Единственное к чему она имеет отношение — к выяснению технических деталей инцидента. Но люди, которым этот ответ обычно дают, к такому выяснению обычно сами не причастны.
И да, «попробуйте еще раз через 5 минут» это допустимый ответ. «Выясняем, сообщу вам через час», тоже допустимо. А вот «у меня работает» это классический ответ по которому можно понять что работаешь с недостаточно квалифицированным человеком.VolCh
23.11.2018 12:16А чем разработчик поможет клиенту, если у разработчика работает, а у клиента не работает? Гадать на кофейной гуще? Дать рецепт «снести ОС, отформатировать все диски, установить с нуля конкретную версию ОС, установить программу согласно документации и больше на компьютер ничего не ставить?»
Люди, ответственные за выяснение технических деталей инцидента, должны выяснить эти детали, воспроизвести «не работает» и отправлять разработчику полное описание того в какой именно конфигурации окружения не работает. Да, бывают плавающие баги, но ответ разработчика «не могу воспроизвести „не работает“» вам понравится больше чем ответ «у меня всё работает»?
VolCh
22.11.2018 13:14Допустимо всем при наличии процессов синхронизации дев-окружений со всеми остальными и выполнением всех действий по ним со своей стороны. Как абстрактный пример — если я внёс изменения в какой-то список пакетов для установки на сервере, а кто-то накатал остальные артефакты на сервер, но шаг установки пакетов пропустил «для скорости, всё равно раз в год меняется список», то вполне нормальный ответ.
Sipidronov
21.11.2018 12:06После прочтения списка софт-скилов (особенно про «взять под крыло всю команду») возник вопрос: а что в этой парадигме остается тим-лиду? Или позиция тим-лида окончательно откатилась в менеджерскую сферу и с командой-аджайлами-проектированием уже никак не связана?
worldmind
21.11.2018 12:28Видимо сеньёр это звание, а тимлид это должность.
Sipidronov
21.11.2018 12:32Вряд ли. Потому как ему в довесок же еще будет всевозможное представление команды внешнему миру и пр. И в то же время выше в «жестких» скилах сказано, что нужно и фреймворки когда-то изучать =)
Т.е. вряд ли без ущерба для здоровья можно совмещать тимлида и супер-синьора. Либо я таки чего-то не понимаю.shai_hulud
21.11.2018 13:03Так и есть. Жуткие штрафы за мульти-классовость. Видел лично, много раз, что совмещение менеджера со специалистом не бывает без ущерба роли «менеджера» или «специалиста».
TimeLab Автор
21.11.2018 13:13Давайте так: если софт-скилл-часть у специалиста хорошо прокачана, то, скорее всего, он и сам не будет против совмещения — захочет двигаться дальше. Если прямо плохо, то скорее всего, у него будут те или иные сложности в работе. Зависит от степени сложностей, конечно. Мы для себя принимаем, что хорошему профессионалу достаточно среднего значения. А по тесту мы видим, что ему проще и лучше бы развить, а что несовместимо с его собственными желаниями роста
shai_hulud
21.11.2018 14:18Чудес не бывает. Будет средний специалист и хороший менеджер. Либо средний менеджер и хороший специалист.
И как бы средний специалист это вредитель на большом проекте, средний менеджер это вредитель на любом проекте.kozzztik
22.11.2018 01:07тут дело не столько в мультиклассовости, а в том что тимлид решает вопросы на другом уровне. Он оперирует архитектурой, и крупными блоками, не закапываясь в мелкие детали. Делает он это по прежнему руками (к примеру архитектор обычно уже нет). Тем не менее в детали обычно закапываются другие, за исключением случаев требующих особой квалификации или знаний. Это просто более высокий уровень абстракции, а не другой класс работы.
Хотя конечно, от компании зависит. Бывает по всякому.
worldmind
21.11.2018 13:39Пункт про фреймворки вообще странный, если человек концепции понимает, то нет никакого смысла изучать все фреймворки про запас.
Sipidronov
21.11.2018 15:02Я придерживаюсь мнения, что «изучать фреймворки» полезно для поиска новых концепций (e.g. ECS, Sagas — из последнего для меня). Но в то же время есть фреймворки достаточно устоявшиеся и их специфику лучше знать.
satahippy
22.11.2018 10:20Что такое ECS и Sagas?
Sipidronov
22.11.2018 14:34ECS: habr.com/post/343778
Саги: habr.com/company/avito/blog/418235
Не уверен, лучшие ли это статьи — просто для пояснения нашел
TimeLab Автор
21.11.2018 12:34Отличный вопрос, спасибо. Действительно, в последние годы мы явно видим именно такую тенденцию — руководители и CEO уходят функциями на уровень развития компании и направлений, больше занимаются кросс-функциональными вопросами и стратегиями, а тимлидам отходит все больше функций операционного менеджмента, ну а продвинутые senior-ы — все больше рулят технической стороной дела и помогают тимлидам. Так что возможностей для роста каждого — все больше) Было бы желание и способности
Sipidronov
21.11.2018 12:37Такие ощущения и были, да. Вот только «возможностей для роста» я тут не вижу — просто «растянули» существующие позиции.
Ну, и в качестве отвлеченного замечания: это что же, теперь синьор еще и людей любить должен?!!!TimeLab Автор
21.11.2018 12:45Скорее, это некое расслоение внутри большого уровня «Senior»: тот, кто может любить людей и ориентируется на вертикальную административную карьеру прокачивает софт-скиллы и все больше перенимает функций тимлида, чтобы со временем им стать. Те, кто ориентируются на развитие по технической части, тоже особо не могут себе позволить нелюбить людей, потому что Тех, к примеру,-лид и Архитектор тоже должны уметь с людьми конструктивно работать. Ну, а если уровня крепкого Senior достаточно, то, как минимум, все равно нужно хорошо взаимодействовать в команде, конструктивно договариваться и брать на себя ответственность за довольно большой кусок своей работы. Ответ — все равно «да», вопрос только дозы любви)
Sipidronov
21.11.2018 12:48О, не, конечно, «не любить людей» — это я утрирую =) Просто мне кажется для поддержания здорового климата в команде нужно что-то большее, чем просто «способность к конструктивному диалогу по необходимости».
Про расслоение — понял, интересно. Спасибо.
TimeLab Автор
21.11.2018 12:35Кстати, во многих крупных/продвинутых компаниях выкристаллизовалось и направление скрам-мастера отдельное. Если Senior-у ориентироваться на эту ветку развития, то придется изучать методологии плотнее. И все равно: тот же набор софт-скиллз как база останется и там.
VolCh
21.11.2018 15:40Ему хард-скиллы сеньора зачем?
TimeLab Автор
21.11.2018 15:48А это их база, они изначально разработчики и развиваются как разработчики. Доходят до какого-то заметного уровня и, если хотят развиваться дальше таким путем, перестают качать хард. Но при этом до Senior-то уровня они уже добрались
VolCh
21.11.2018 16:00Я к тому, что, по-моему, на скрам-мастера можно хоть с джуна начинать учиться, а может даже лучше вообще не иметь технического бэкграунда, чтобы, например, не занимать подсознательно ту или иную сторону в разгоревшемся споре.
TimeLab Автор
21.11.2018 16:37Можно, только никто не будет джуна серьезно воспринимать. Чтобы стать скрам-мастером и команда приняла в таком качестве надо сначала себя спецом здорово показать. Иначе никакое руководство не будет поддерживать и вкладываться в развитие. Будут говорить: скрам — прекрасно, а когда кодить нормально начнешь? У нас пока что все-таки движение очень линейное
VolCh
21.11.2018 17:57Скрам-мастер не является членом команды разработки, его функции чисто менеджерские.
Sipidronov
22.11.2018 14:32А вот даже и не менеджерские =D Его задача фа-си-ли-ти-ро-вать аджайл практики в команде, простиоспади.
VolCh
22.11.2018 16:31Главное суть — управлять людьми, говорить им что делать и что не делать :)
Sipidronov
22.11.2018 16:35+1В том-то и беда. Мастер не может указывать, что делать. Он подсказывает, как ту или иную практику аджайла лучше сделать здесь и сейчас (e.g. борду организовать поможет, ретроспективу\постмортем в конструктивном русле поможет сдержать).
На психоаналитиков похожи, на мой взгляд =DVolCh
22.11.2018 19:12«Что делать» не в плане какие задачи пилить, а что делать во время митингов, например.
VolCh
21.11.2018 14:43Тимлиду — заниматься мотивацией команды
Sipidronov
21.11.2018 15:05Да-да, об этом и речь. Все дальше тим-лиды уходят от работы В команде в сторону работы С командой (i.e. внешне по отношению к команде). Лишь бы не перестали говорить на одном языке с инженерами =)
VolCh
21.11.2018 15:42Вот честно, не очень понимаю зачем :) Была у нас, как говорится кроссфункциональная команда и тимлидом был дизайнер (а я техлидом или даже архитектором) — вполне дружно жили
OnelaW
21.11.2018 18:08Есть такое понятие как наставничество. Вот оно как раз относится к софт. Умение быть хорошим наставником полезный навык.
Sipidronov
21.11.2018 18:11Это мне? Про тим-лида? Можно как-то перефразировать — я не уверен, что правильно понял ответ.
OnelaW
22.11.2018 10:43Да, ответ вам.
Просто авторы различных книжонок и рекомендаций вкладывают в софт скилс под управлением, в первую очередь навык наставничества. Не знаю откуда пошла эта мода но в здоровых коллективах оно выстраивается естественно. В каждой команде есть старожил который расскажет подробно о всех явных и не явных процессах в компании.
kozzztik
21.11.2018 13:18посмотрел требования к super senior, и даже не понял, это о senior или junior? «понимание принципов ООП», «шаблоны проектирования», «система контроля версий», это все от джунов требуют. Остальные форумлировки оставляют желать лучшего. Вот если взять все эти формулировки и перенести их в резюме, я бы не смог классифицировать его между middle и senior. Тут же фокус не в том чем владеть, а на каком уровне. Для мидла вполне себе нужно уметь развернуть, настроить и поработать с NoSQL, тем более что одно дело поработать с редисом, а другое — с эластиком. Для сениора уже недостаточно просто «иметь навыки управления», он уже должен всю внутреннюю механику понимать, и желательно в деталях.
По проблемам с софт скилами, тут мне кажется основное дело вот в чем. Как правило требования к ним растут не линейно. По факту обычно сидит человек кодит себе, никого не трогает, качает свои хард скилы. А в один прекрасный день к нему приходит менеджер и говорит, теперь ты будешь тимидом. Что это такое, как это делать, никто не объяснит. На курсы тоже не отправят. Вот тебе проблемы, разгребай. И дальше начинают прилетать проблемы. Ты чего своих не менторишь? А что надо было? И в том же духе. Сверху начинают сыпаться одни только проблемы, получается негативное закрепление. В итоге большая часть говорит, что нафиг мне такое счастье? Кодил себе и все хорошо было. Нафиг качать эти софт скилы, от них проблемы одни.
А качать их это хорошо, правильно, и классно. Просто далеко не везде.Aingis
21.11.2018 13:39«… это все от джунов требуют» — не все, но в Яндексе требуют, это да. И тесты всех заставляют писать. Ну, может от стажёров не так сильно требуют.
Формулировки ужасные. «Грамотная оценка комплекса задач» — это что имеется в виду? «Я посмотрел на задачи, они сложные?»
«Принятие ответственности в сферах: целей и планов, профессиональных взаимоотношений, руководства, карьерного развития» — ответственность это хорошо, но о чём здесь речь? Вот допустим человек считает, что достоен повышение, а руководство отказывает. Что тогда? Ответственно сменить работу? Или не сменить и ответственно гребсти на галере? И это ещё простой вопрос. А если коллега, скажем, упёртый, сложный в общении? Или с планами? Планировать за руководство?
Ощущение от всего этого описания и теста, что Сеньор — этакая палочка-выручалочка: придёт и молча исправит всё. Даже то, что вне его сферы ответсвенности.kozzztik
21.11.2018 13:53«Принятие ответственности в сферах: целей и планов, профессиональных взаимоотношений, руководства, карьерного развития» — ответственность это хорошо, но о чём здесь речь?
ну тут мне как раз понятно, тут формулировка размытая, ибо в разных компаниях это очень разная деятельность. Но это как раз менторство, аттестации, индивидуальные планы развития, вот это все. Тут даже для одной компании сложно внятно сформулировать, а уж для рынка и вовсе никак лучше не скажешь.
Ощущение от всего этого описания и теста, что Сеньор — этакая палочка-выручалочка: придёт и молча исправит всё. Даже то, что вне его сферы ответсвенности.
Ну вроде так и есть. Разве нет? По опыту чего-то такого от сениоров и ждут.TimeLab Автор
21.11.2018 14:18Размытые формулировки еще не беда. Проблема в том, что в большинстве случаев ни в требованиях, ни внутри компании ими открыто не оперируют, но по ним оценивают и «отказывают». Мы вытаскиваем их на свет божий) В статье мы привели лишь названия критериев в двух софт-скиллз блоках. В интерпретации к тесту мы даем более развернутое представление о каждом критерии и степени его развития. Чтобы сделать это здесь потребовалась бы отдельная статья
TimeLab Автор
21.11.2018 14:05Действительно, проблема разной оценки специалиста самим специалистом и руководителем нередко случается. Поэтому мы и считаем, что важно не только выяснять по каким конкретно критериям руководитель отказывает, но и воспользоваться как можно бОльшими альтернативными источниками оценки по этим критериям. Потому что, с одной стороны, сам специалист может не видеть дефицитов (особенно если скиллы по этим критериям крайне слабо развиты — это классика), а с другой — и у руководителя могут быть свои причины не продвигать сотрудника.
Если senior — это супер-профессионал высокого уровня, то он, безусловно, выручалочка) Не зря у него и статус, и ЗП соответственные. Хотя, конечно, не волшебник. Тут перегибать не стоит.Aingis
21.11.2018 14:40Выручалочка, но только в области своей компетенции. Да, он может сделать технически хороший продукт, но он не спасёт компанию, если её учредитель, скажем, сделает что-то, что её утопит (в виду сокращения финансирования, например), или продажники накосячат, или юристы всё профукают, или ещё что-то случится. Он может говорить, убеждать, но это вне его сферы ответственности. А тот же опрос явно составлен с перекосом на «командную ответственность» безо всякого контекста. Когда ответственны все — не ответственен никто.
kozzztik
21.11.2018 16:32Ну вообще это отдельный актуальный и не раскрытый в статье вопрос. На самом деле сейчас от сениоров многие ждут не просто технических решений. От них ждут технических решений на уровне бизнеса, т.е. в том числе иногда и бизнес решений.
Другими словами нужен инженер который не просто пишет код, а делает продукт, а код это уже второстепенно. И сфера компетенции в таком случае естественным образом значительно размывается.
Правда разные компании находятся на разных стадиях осознания процесса. Кто-то явно понимает и открыто об этом говорит, а кто-то выстраивает непонятные абстрактные формулировки, за которыми можно только догадываться.TimeLab Автор
21.11.2018 17:28Полностью согласны! Чем выше уровень, тем больше бизнес-ожиданий накладывается. И там границы ответственности провести сложнее. Однако во все времена, чем большими факторами человек оперирует, чем шире поляну видит: целый продукт, продуктовая линейка/направление, компания и бизнес-сфера, их возможности/ограничения + все вариации технологических решений под это — тем выше он будет цениться.
kozzztik
21.11.2018 22:51Ну тут дело не только в высоте позиции. Есть еще такая штука как уровень развития компании (я сейчас про спиральную динамику и бирюзовые организации). По мере продвижения самой компании уровни ответственности начинают размыватся на всех уровнях иерархии. Как, впрочем, и сама иерархия.
VolCh
21.11.2018 14:52> Вот допустим человек считает, что достоен повышение, а руководство отказывает. Что тогда? Ответственно сменить работу? Или не сменить и ответственно гребсти на галере?
Узнать причину отказа, выяснить что нужно сделать (грубо, какие скиллы прокачать), чтобы не отказали в следующий раз, оценить стоит ли овчинка выделки в данной компании и принять решение либо качать тут, либо качать в другом месте (грубо, курсы тимлидов), пока оставаясь тут работать, или качать в другом месте и работать в другом месте. А может в другом месте уже сочтут, что достаточно прокачен.Aingis
21.11.2018 15:44Тут главный вопрос статьи в том, чтобы можно было понять подходит человек или нет. И как по таким критериям оценить эту «ответственность»? Спрашивать кандидата что он будет делать в такой ситуации? Так это из извечных вопросов, на которые все знают правильный ответ, и никто в здравом уме не будет отвечать искренне (если уже не забили на собеседование по каким-то причинам).
P.S. А на вопросы про причины отказа ответят просто: «не тянешь» (вар.: «долго делал») или «софт-скиллов не хватает», без конкретики конечно же.VolCh
21.11.2018 15:58+1Далеко не все знают правильные ответы на вопросы типа «Полчаса до конца рабочего дня, приходит критикал баг с высшим приоритетом. Начинаете разбираться, прошло 25 минут, но даже локализовать не получилось. Ваши действия?». Хотя бы потому что в разных компаниях или даже у разных руководителей разные понятия об ответственных действиях в данной ситуации.
Если без конкретики, то надо валить, если реально хочешь повышения. Возможно не сразу, а найдя что-то взамен предварительно, причём прямо на собеседованиях спрашивая «сейчас я пришёл сеньором, но через год вижу себя в вашей компании тимлидом. Вот вы меня поизучали, допустим делаете оффер и я его принимаю — скажите, что мне конкретно нужно ещё изучить-освоить чтобы при открытии такой вакансии вы её мне предложили? У вас внутренние курсы или типа того есть для этого? » На удивление, часто рассказывают. Ну или отвечают так, что даже если оффер будет, то принимать его не станешь.kozzztik
21.11.2018 16:36вот кстати да, пример реально жизненный. У нас на собеседованиях редко, но спрашивают так, и мы честно все рассказываем.
И кстати факт такого вопроса обычно идет добавляет свой плюсик к итогам собеседования.
TimeLab Автор
21.11.2018 16:04Ответственность, пожалуй, самая сложная тема. Мало кто умеет ее оценивать. Мы по этому блоку (внешний-внутренний локус контроля по-психологически) приводим в тесте и интерпретациях вполне конкретные критерии и их расшифровку. Некие ориентиры это показывает — в каких направлениях человек более склонен брать на себя ответственность, а в каких -сливать или ожидать от других. У нас, конечно, очень краткая версия — но и собеседования никто не отменял.
Aingis
21.11.2018 18:43«Внешний-внутренний локус контроля по-психологически» — это здорово, но как вы обрабатываете случай гиперответственности? (То есть ответственности за пределами реального влияния.) А она ведь прямой путь к конфликтам.
TimeLab Автор
21.11.2018 18:54ХМ, гиперответственность — это когда человек захватывает слишком много ответственности на себя и уже несколько в ущерб окружению. Этакий герой, который тянет на себе все до чего может дотянуться, и стонет от натуги. При этом остальные либо расслабляются (зачем напрягаться, герой сам все сделает), либо раздражаются, потому что им достается меньше и они не растут. Кажется, Вы имеет ввиду что-то другое. Например, когда вменяют в ответственность то, что делать не хочется или кажется, что лежит на чужой территории? Так?
Aingis
22.11.2018 15:55Кажется, Вы имеет ввиду что-то другое. Например, когда вменяют в ответственность то, что делать не хочется или кажется, что лежит на чужой территории? Так?
Нет. С чего вы взяли?
kozzztik
21.11.2018 22:52Пока по личной практике гиперответственность это скорее плюс. Она конечно создает некоторые неудобства, но они с лихвой окупаются плюсами.
VolCh
21.11.2018 23:21Гиперответственность — работа на износ. Ну и плюсы у неё появляются, по-моему, только если рядом чья-то безответственность.
kozzztik
22.11.2018 00:04Ну как тут было уже в комментариях, при росте в должности зоны ответственности обычно размываются. Тоже происходит при развитии компании в сторону самоорганизации. А при росте в должности, в компании растущей в сторону самоорганизации — размытие идет в квадрате. И обычно людей надо учить тому, как правильно в такой среде жить. И это не просто. Гиперответственных учить не нужно, даже наоборот, на них в этом вопросе нужно положится. Они сразу себя чувствуют в такой среде как рыба в воде.
А вот работа на износ, это да. С любопытством наблюдаю за такими. Пока вроде никто из тех за кем наблюдаю не сгорел за несколько лет. Но кто знает.
Aingis
23.11.2018 10:42Ха, пришли результаты. Правильно, никак.
Вы старательно разграничиваете ответственность за рабочий процесс и результат с Вашим руководством. Не берете на себя больше, чем достаточно для Вашей позиции. А зря. Чем больше ответственности Вы разделяете с руководством, чем более высокоуровневый взгляд (помимо техничного решения задач) показываете — тем более ценным сотрудником Вы становитесь.
То есть идеальный сеньор по мнению авторов: тот, который не соблюдает субординацию, лезет не в своё дело и навязывает своё мнение. Тест дурацкий, что было понятно с самого начала.
P.S. Ещё ответили, что у меня слабые знания языка. Ага, сразу. Я точно знал ответы на все вопросы по языку. Скорее всего, где-то в тесте ошибка.VolCh
23.11.2018 12:19Причём тут «не соблюдает субординацию»? Дать предложение непосредственному начальнику или стейкхолдеру, который ставит задачу, субординацию не нарушает.
TimeLab Автор
21.11.2018 13:58Чтобы оценить уровень важно понять не только senior специалист или нет. Поэтому, как правило, компаниями даются задания для разных уровней — попроще и посложнее. А в последнее время, читая требования к вакансиям junior, мы и сами удивляемся — насколько много от них сейчас требуют. Здесь мы привели обзор всех требований. А тест укомплектовали заданиями разной степени сложности, чтобы видеть «оттенки» уровней.
Ну а ситуация «ты будешь лидом!», к сожалению, встречается. Из-за дефицита человеческих ресурсов, особенно, на верхнем уровне. Хотя у компании всегда есть выбор: например, нанять тимлида с рынка по соотвестующим критериям. Мы делали или так, или помогали развиваться: у нас была целая программа тренингов развития всех нужных навыков.kozzztik
21.11.2018 14:14+1ну просто формулировать надо точнее. А то «что такое синиор» и дальше набор требований не поймешь к какой позиции, что вроде и миддл тоже подходит. Весьма очевидно что этот набор должен по сути отвечать на вопрос «в чем разница между мидлом и сениором», и он на него не отвечает.
Ситуация «ты будешь лидом» не просто встречается. Это повсеместная практика. Что бы не быть голословным — я довольно долго искал в Питере компанию, в которой этот вопрос был бы решен. И мне оказалось проще найти ее за пределами Питера, и привести ее на рынок, чем найти. А это уже по факту означает что можно считать что это не решено в городе вообще нигде.
И дело не в наличии ресурсов. И мало всегда и везде, это в принципе лимитированная вещь. Дело в подходе. Нужно что бы к моменту, когда человеку придет время стать лидом, у него в голове уже должны быть необходимые опыт и знания. Видение. Он уже должен понимать что такое команда, что с ней делать, шарить в методологиях управления, и много чего еще. И при этом у него еще желательно должен быть какой-то маломальский опыт в этом. Для этого в компании должна быть очень продвинутся система роста людей и управления, работающая на опережение. А у нас обычно реактивное управление, никто ничем не занимается, пока петух не клюнет. Заранее даже на шаг не думают.
«опыт, это такая штука, которая приходит сразу после того, как была нужна».VolCh
21.11.2018 14:57Маломальский опыт компании могут давать свои сеньорам относительно просто: разорвав основные прямые коммуникации между лидами(или ПМами) с джунами/мидлами, переведя последних в подчинению сеньорам, образовав мини-команды на 2-3 человека,
kozzztik
21.11.2018 16:40ну прям разрывать прямые коммуникации это так себе решение, саботажем отдает. Но да, так или иначе должна работать цепочка — лид работает с сеньорами, сеньоры с мидлами, мидлы с джунами, мидлы и джуны со стажерами.
Но вот что бы это прямо реально работало нужно много условий. Нужна налаженная система менторинга, планов развития, аттестаций, бюджетов на обучение (как финансовых так и временных) и так далее. Нужна постоянная подпитка системы снизу, при том желательно со стажировки. В очень небольшом количестве компаний все это есть, и в еще меньшем количестве это не просто формальность, а реально работающий инструмент.VolCh
21.11.2018 18:22Речь исключительно о получении небольшого опыта управления и делегирования сеньорами. Например, команда из двух сеньоров, миддлов и джунов, а лид собрался на повышение через несколько месяцев. Лид работает с сеньорами, ставит им все задачи, а те либо сразу переназначают на своего миддла или джуна, возможно дополнительно что-то объяснив, либо декомпозируют задачу, что-то делая самостоятельно, что-то делегируя. У кого лучше получится, тот и будет новым лидом :)
Вообще слышал совет такой: придя на руководящую должность, которая не является пределом твоих мечтаний, нужно с первого дня готовить себе заместителя из числа подчинённых. Это в том числе поможет убрать такое препятствие в карьере как: «да, ты потянешь эту должность, но я тебе её не дам, потому что на твоё место мне поставить некого, некому руководить твоей командой»TimeLab Автор
21.11.2018 18:46Когда компания переходит на стратегический уровень управления, на уровень прогнозирования бизнеса она начинает делать это и с персоналом: всегда на каждой ключевой должности должен быть #2. Руководитель на недельной страт.сессии? Рулит тимлид. Руководитель в отпуске, тимлид заболел — рулит самый крутой Senior или архитектор или тех.лид. Мы всегда исповедовали такой принцип. При нем компания вообще без руководителей отделов (хоть всех сразу) может спокойно проработать 2 недели. Иногда в операционном ключе — даже лучше))
VolCh
21.11.2018 19:04Чтобы сеньор смог рулить у него должно быть хоть какое-то понимание как и зачем рулить :) Нередко это лучше поручить сеньору с самым крутым пониманием этого, а не самому крутому по техскиллам, который их имеет, потому что людей сторонится и всё свободное от работы время совершенствуется в них.
Похвально, жаль что не все это исповедуют де-факто, даже если де-юре у всех замы есть.kozzztik
21.11.2018 22:57мы это дополняем размазывая ведение проектов по всей шкале. Даем небольшие простенькие проекты вести регулярам. Тогда к сеньору он уже вполне готов заменить лида на время.
kozzztik
21.11.2018 22:55+1Как по мне, это надо делать в любом случае, независимо от должности и собственных амбиций. Это позволяет спокойно уйти в отпуск недели на три или заболеть сосредоточившись на себе, а не на том, что там с проектом.
Ну и опять же, если вдруг придется уходить (всякое бывает, например сделали предложение от которого сложно отказаться) можно уйти со спокойной совестью не отрабатывая месяца полтора.
TimeLab Автор
21.11.2018 20:56Чтобы оценить уровень важно понять не только senior специалист или нет. Поэтому, как правило, компаниями даются задания для разных уровней — попроще и посложнее. А в последнее время, читая требования к вакансиям junior, мы и сами удивляемся — насколько много от них сейчас требуют. Здесь мы привели обзор всех требований. А тест укомплектовали заданиями разной степени сложности, чтобы видеть «оттенки» уровней.
Ну а ситуация «ты будешь лидом!», к сожалению, встречается. Из-за дефицита человеческих ресурсов, особенно, на верхнем уровне. Хотя у компании всегда есть выбор: например, нанять тимлида с рынка по соотвестующим критериям. Мы делали или так, или помогали развиваться: у нас была целая программа тренингов развития всех нужных навыков.
Electrohedgehog
21.11.2018 13:37Поймался на любопытство, прошёл тест. Ответ пришлём на почту.
Отличная компания сделала этот тест. Я думаю, в их коллективе хорошо относятся к сексуальным меньшинствам. Ну и разными другими достоинствами они тоже не обделены.TimeLab Автор
21.11.2018 14:11Наша компания, безусловно, толерантна.
Поэтому мы понимаем недовольство «ответом на почту») Для целей нашего проекта нам достаточно неавтоматизированной обработки результатов. Здесь мы привели наш тест в качестве примера и практической иллюстрации приведеных требований. Но все же поделимся интерпретациями со всеми, кому будет интересно.
inno
21.11.2018 13:57+1мне нравится очень краткая характеристика сениора: усталый, дорогой и предвзятый.
superhimik
21.11.2018 14:47Почему автор статьи нарушает правила и использует нецензурную лексику?
TimeLab Автор
21.11.2018 14:50Это Вы про цитату из песни?
superhimik
21.11.2018 14:57я про слово «f@ck»
TimeLab Автор
21.11.2018 15:01Уж больно песня была популярная, мы не удержались) Однако, спасибо за наблюдение, внесли правку
VolCh
21.11.2018 15:00> потребление fuck считается непристойным и расценивается как оскорбление в официальных, политических и культурных кругах. С другой стороны, данное слово может быть воспринято спокойно и даже ожидаемо в неформальном общении, или же в либерально настроенных культурных группах.
Что-то ничего про цензуру, и даже вряд ли можно сказать, что тут собрались официальные, политические и культурные круги.superhimik
21.11.2018 15:01-2В случае, если автор не удалит это слово из статьи, я пожалуюсь на нарушение правил.
Closius
21.11.2018 18:36+2Я например не могу по памяти написать оптимальный алгоритм быстрой сортировки. Не могу даже быстро написать оптимальный алгоритм опрееления простоты числа. Банально потому, что не сталкиваюсь с этим и использую более высокие абстракции. Алгоритмы знаю, могу на словах рассказать как что должно работать, но написать быстро не могу.
Однако, я работаю в одной большой международной компании в ресерч отделе. Разрабатываю инфраструктуру (архитектуру и приложения, в том числе непосредственное написание приложений, клиент серверных и стендалон) для работы с инженерными данными и автоматизацию инженерных задач. Почти всегда мои предложения принимаются и мое начальство (забугорное) и тим лиды оценивают его как годное.
Вопрос: кто я?
Спрашиваю это к тому, что некоторые тесты, которые присылают компании в качестве предварительного этапа для отбора кандидатов, я не могу пройти, так как не хватате времени.TimeLab Автор
21.11.2018 19:06Такой эффект у Senior (потери скорости решения более простых задач), действительно, случается. В этом одна из проблем оценочных методик, особенно когда компания пытается оценить разработчика по 1-2 однотипным задачам. Поэтому, на наш взгляд, при оценке все-таки важно дать более широкий охват (разные блоки в тесте). Если кандидат прошел самые сложные задания и «так себе» — более простые, то это повод задуматься для работодателя, уточнить что-то на собеседовании. Ну а если нужен, к примеру, Junior+ и средний Middle, чтоб все горело в руках и быстро решались типовые задачи, то такие задания имеют право на жизнь
kozzztik
21.11.2018 23:03Ха, да, было такое на собесе. Приходишь собеседоваться на тимлимлида, говорят очень нам нужен тимлид. И первый вопрос — реализуйте три алгоритма сортировки за ограниченное время. Чето там пытаешься вспомнить, накорябаешь. А они смотрят, качают головой, нет, на лида не тянете. И не понимаешь, это лыжи не едут, или как.
Было это кстати в одной очень известной компании. Выходишь такой и думаешь, ну и хорошо что не взяли.TimeLab Автор
21.11.2018 23:39Это как раз то, почему мы все же не рекомендуем на высоком уровне «забывать» про базовые хард-скиллы. Потому что, по-факту, в компаниях все равно на них смотрят, какого бы уровня вакансия не была. Меряют так серьезность отношения разработчика к своей подготовке. И часто никакой балансировки по степени сложности заданий, что усугубляет картину.
kozzztik
22.11.2018 00:01А это вообще базовый хард скилл? Может для джуна да. Для школьника-олимпиадника, тоже да. Для тимлида? Я не могу это быстро сделать не потому что у меня мозги не варят. Я не могу это быстро сделать, потому что это знание не пригодилось мне ни разу за десять лет практики и целую кучу проектов самых разных видов. Мне даже сложно себе представить, где в современной разработке это может быть полезно.
Может быть, был бы я Си разработчиком (без плюсов, чистый Си), мне бы это и пригодилось. Но я питон разработчик. Любая ручная реализация сортировки заведомо медленнее чем [].sort() тупо из-за расходов на интерпретацию, другими словами никакой практической пользы не имеет.
Ну или для джуна или миддла еще приемлемо смотреть на «серьезность подготовки» по всякой ерунде. А если мы говорим о том, что даже старший разработчик должен иметь понимания бизнеса, то это уже не найм раба на галеру, где преданность в глазах должна быть. Это практически равноправная сделка, что уже говорить о ведущих разработчиках, которые частенько весь бизнес вывозят. Там подготовку по другим параметрам смотрят — погуглил ли он о компании, насколько меткие вопросы задает, внимательно ее изучает. И чем выше, тем больше вообще стоит вопрос — кто кого вообще собеседует. Начиная с определенной квалификации (особенно если есть чем ее подтвердить), то собеседование вообще наизнанку выворачивается.Hixon10
22.11.2018 00:25Сначала нужно дать определение, что такое Тимлид в рамках конкретной компании. Это может быть, как Программист-звезда, так и Менеджер с техническим бэкграундом.
Было бы странно, если бы Программист-звезда не знал базовый computer science.
«Мне cs не нужен, всё уже есть в языке» — а потом можно посмотреть на одну из больших корпораций, например Одноклассники, где пишут, например, свои надстройки над базами, языками, виртуальными машинами и другим. А тут уже оказывается, что все алгоритмы придётся писать руками, а не брать из языка.kozzztik
22.11.2018 00:40А чего странного, в том что у человека не отскакивает от зубов то, что ему никогда не пригодится? В наше время разработчик-звезда и так должен знать столько всего, что ему реально нужно. Нужно и на низком уровне понимать, и на высоком, и сто пятьсот архитектур, баз данных самых разных. Нужно и в менеджмент уметь, и методики управления понимать, и в бизнес контексте понимать. Быть и немного психологом до кучи. Список длинный.
Не странно ли при всем при этом спрашивать у людей то, что реально никогда не пригодится, и делать это ключевым критерием отбора? По мне так это откровенно не адекватно.
arcman
22.11.2018 11:38+1Отличный комментарий!
Действительно чем выше уровень специалиста тем он больше нужен компании чем она ему.
Поэтому уже специалист начинает присматриваться к компании, смотреть подойдет ли она ему, будет ли ему интересно и насколько полезный опыт он получит.
Соответсвенно и собеседуется уже не работник, а компания, и если представитель компании начинает с ходу задавать глупые вопросы, то собеседование такая компания уже не пройдет.
ads83
22.11.2018 23:06Я далек от уровня тимлида, и тем более не собеседовал никого на такую позицию, поэтому мое предположение может показаться глупым.
Я предполагаю, что тимлид также должен уметь объяснить, почему знания алгоритмов ему необязательны для своей работы. Хорошо так объяснять, с аргументами. Потому что (как мне кажется) важным навыком тимлида является умение убеждать/уговаривать в том числе собеседника, который абсолютно уверен в своей правоте. А еще тимлиду важно понимать, где он может задавить авторитетом, где включить свое хорошее понимание темы, а где использовать «софт-скиллы», т.е. умение убалтывать.
<мечтательно> Когда меня будут собеседовать на тимлида и я услышу аналогичный вопрос… Я должен буду понять, смогу ли ответить и если нет — доказать, почему незнание конкретно этого аспекта позволяет мне претендовать на должность. Причем оценку «знаю-не знаю» и поиск аргументов в случае «не знаю» я должен осуществить быстро.
Повторюсь, это взгляд снизу, если где неправ — поправьте.kozzztik
22.11.2018 23:37Не могу сказать что такая мысль меня не посетила в тот момент. Там было несколько других аспектов, которые наводили на мысль, что с собеседованием вообще что-то пошло не так. Так что я пообщался с HRом на тему не забыли ли они чего. Но вроде как нет, это «особенность политики найма». Бодаться с политиками найма крупных компаний при входе я нашел и неуместными и бесперспективными. Ну и честно говоря не уверен что хотел бы работать с командой, которую отбирали подобным образом.
К тому же по слухам зарплаты там были не особо высокие, да и в итоге на собеседования по сумме ушло больше 8 часов(только к ним), продолжать не похоже что имело смысл.
Sartor
21.11.2018 21:04+1Тест на 50% состоит из плохо сформулированных вопросов. Я уже молчу за оформление кода в виде пережатых картинок. На часть вопросов в принципе невозможно ответить объективно. И правильный ответ должен быть — «невозможно правильно ответить». Под конец вообще какой-то психологический портрет.
TimeLab Автор
21.11.2018 21:23-1Задания разного уровня сложности разрабатывались коллегиально Senior-ами крутых корпораций для оценки разного уровня специалистов. Команда посчитала, что правильные ответы среди предложенных есть. Хотя, конечно, у каждой компании есть своя специфика: задачи, которые она решает или не решает вовсе. И тут мнения могут различаться, а компания вправе в тесте выставлять свои требования.
Sartor
21.11.2018 21:54+1Ну во-первых, я точно не поверю что все они согласились. А второе — ответы не просто должны быть правильные, а ясные и однозначные. Размер таблицы — «средний», это 1к или 1кк? Для меня большая это 1ккк, а средняя — 1кк, но это лично моё мнение, оно точно не совпадает со всеми. Что значит клиент — другой «узел сети»? Какой сети, внутри дц или города или планеты Земля?
titbit
22.11.2018 00:27Очень обидно, что всех программистов почему-то считают обязанными знать всякие web-технологии, но при этом забывают про все остальные, коих намного порядков больше. Мир программистов не заканчивается frontend'ом и backend'ом, даже несмотря на текущую популярность этих направлений. Главное, на мой взгляд — умение учиться и учить других, объяснять свои мысли и код самим кодом, комментариями, документацией. Широта кругозора важна для общего понимания вещей, но при этом надо уметь быстро погружаться в конкретику. И неважно, очередной это новомодный фреймворк или протокол связи с интерферометром.
arcman
22.11.2018 11:48По вашей классификации выходит, что Senior это венец развития для технического специалиста. Куда тогда ему развиваться дальше?
Как с вашей классификацией соотносятся позиции Tech Lead, Architect (Solution/Technical/Enterprise), Principal, CTO/CIO, VP of technology?
Куда вы отнесете Senior QA, Senior DevOps и какие к ним будут требования?
Им тоже нужно знать алгоритмы и ООП?TimeLab Автор
22.11.2018 11:58Уровень Senior — это плацдарм для целого веера позиций: тимлид, техлид, архитектор, скраммастер, менеджер по продукту (сейчас все больше любят их с техническим бэкграундом если это ИТ-продукт), и даже видим все больше вакансий аналитиков с программистским бэкграундом… Это всего на одну ступеньку дальше. Однако, на этих позициях ждут, прежде всего, Senior-ов. Мало кто пригласит в техлиды, тимлиды и т.д. специалиста среднего уровня (не знаю таких случаев).
VolCh
22.11.2018 13:25Вполне могут пригласить на позицию тимлида миддла из этой команды, не дошедшего до сеньоров этой команды по хард-скиллам, но превосходящего их по софт, особенно если он и так является неформальным лидером команды.
VolCh
22.11.2018 13:22+2Как для чисто технического, разработчика, пожалуй, венец кроме исключительных случаев.
Все перечисленные позиции всё больше в сторону работы с людьми, финансами и другими ресурсами. Все перечисленные должны, грубо, обладать примерно одними техскиллами (пускай в прошлом), но с каждой ступенькой всё больше должны иметь разнообразных навыков работы с людьми, как минимум, навыки управления командами и навыки «продажи» своих технических идей бизнесу.
megasuperlexa
22.11.2018 11:58опять «знание принципов ООП», опять «знание паттернов». Это требования к senior в 2018? а где UML тогда уж
TimeLab Автор
22.11.2018 12:09Ну что сказать, ничего не выдумываем — в компаниях это must. Логика такая: даже оперной диве не должно быть чуждо сальфеджио, гонщик способен прокатиться на жигулях ну и т.д. Однако, если спрашивают только ООП и паттерны, уточните все же, Senior ли нужен. Корректно уточнять требования и объяснять свою позицию же никто не запрещает.
Coast
22.11.2018 18:34Не претендую на 100% истиность, но имхо сеньёрить можно исключительно в конкретном месте(либо в отрасли), когда у тебя уже есть свита(тестировщики и джуниоры). Если ты солист, то каким бы талантливым не был — просто физически не получишь свой левел ап, сколько бы паттернов не знал.
Меняя работу(не дай бог отрасль) — первые пол года по любому уйдут на знакомство с предметной областью, корп.культурой и местными порядками, изучение проектов и т.д.
Людей сразу под реализацию идей тоже вряд-ли дадут, потому ты как бы будешь middle+ с перспективой.VolCh
22.11.2018 19:15Во многих компаниях сеньор — это не руководитель мини-команды, а рядовой разработчик, просто проскиллованный. Разница между сеньором и джуном визуально не наблюдется, оба берут таски и пилят, уточняя что-то у коллег, если не ясно.
TimeLab Автор
23.11.2018 00:22Один из знакомых руководителей тоже говорил, что разницы визуальной никакой. Что джуны пилят практически те же задачи, что и синьоры, просто за ними нужно приглядывать. И что джуны хорошие вообще должны уметь все. Но это была небольшая компания и небольшой отдел разработки, с неЯндексовским все-таки уровнем задач
VolCh
23.11.2018 01:03Я не про задачи даже, и даже не про приглядывать. Я про то, что часто команды не имеют иерархической структуры, они «плоские» — и джуны, и сеньоры в прямом подчинение у тимлида, и никаких тестировщиков, и вообще никого у них в подчинении нет — тестировщики или вообще в отдельной команде, или так же подчиняются лиду.
shai_hulud
Есть такая классификация программистов:
junior — легкие задачи решает сложно, сложные решить не может.
middle — легкие задачи решает легко, сложные сложно.
senior — все задачи решает легко.
TimeLab Автор
Да, подход частично имеет смысл. Хотя тут вопрос в том, что считать легким, а что — сложным (в Яндексе, в хостинге и в веб-студиях это будут задачи разного уровня).
Итого: не всегда в легкости и сложности задач дело.
kozzztik
мне больше нравится такая классификация:
Middle — может выполнить проект в одиночку, без «оркестра»
Junior — не может
Senior — не будет.
В оригинале это шутка на баше, но по мне вполне себе реальный подход.
zagayevskiy
Какой-то маленький проект, видимо:)
kozzztik
В этом и шутка, что совсем не обязательно. И senior как раз это понимает, потому без оркестра делать не будет )
VolCh
Не факт. Могут предложить проект на год и более в одно (или практически одно) лицо и миддл с радостью за него ухватится, если для него это первый шанс построить проект с нуля. Вполне возможно, что после такого проекта он уже может считаться сеньором. В том числе и потому что больше за такое не возьмётся :)
zagayevskiy
В моем мире проект, который можно сделать за год-два-три в одно лицо, не может быть большим.
VolCh
Ну для вашего мира пускай десять лет будет :)
zagayevskiy
А что, есть примеры, когда один разработчик пилит коммерческий проект за 10 лет(подчеркиваю, не пилит его полгода, а потом ещё 10 лет поддерживает, а проект от начала до вменяемого состояния занимает 10 лет) и бизнес это устраивает?
VolCh
Запускает за полгода-год MVP, а потом его развивает.
sic
Я бы перевернул, и хуже не особо получается:
junior — все задачи решает легко (но в основном неправильно)
middle — сложные задачи решает легко (в основном костылями), легкие сложно (архитектуру там свою напридумать, потренировать новые фичи языков и фреймворков)
senior —
cложные задачи решает сложно, а легкие легкорешает больше проблем, чем создает в настоящем и в перспективеDruu
А Что такое "сложная/легкая" задача и что такое "легко/сложно" решается?
То есть задача либо решается (и тогда она легка) либо не решается (и тогда она сложная). Разве тут есть средние варианты?