Хороший код до Google не доведет

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

Мы провели обширное исследование среди программистов и их руководителей. Собрали требования к senior-разработчикам топовых компаний, возможности и пути к развитию до этого уровня, сгенерировали всевозможные инсайты и лайфхаки и трансформировали их в данную статью. Об всем этом и пойдет дальше речь.
image

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. В первоначальной версии статьи мы предлагали пройти тест всем желающим. Однако, мы не ожидали такого мощного наплыва респондентов. И были вынуждены были закрыть тест, чтобы быть способными обработать текущие ответы и результаты тем, кто оставил контактные данные. Просим заполнивших тест набраться терпения :)
Поделиться публикацией
Комментарии 218
    +7
    Есть такая классификация программистов:
    junior — легкие задачи решает сложно, сложные решить не может.
    middle — легкие задачи решает легко, сложные сложно.
    senior — все задачи решает легко.
      0
      Да, подход частично имеет смысл. Хотя тут вопрос в том, что считать легким, а что — сложным (в Яндексе, в хостинге и в веб-студиях это будут задачи разного уровня).
      • Senior все задачи могут решать легко, но уже не все задачи выполняют (для этого есть junior и middle)
      • Middle решают уже очень многие задачи (и легкие и сложные), но им не системно, кругозора для вариативности решений + особо крупные задачи решать еще не в состоянии
      • Хорошие Junior и Junior+ могут решать почти тот же набор задач, что и Middle, но не самостоятельно, а под надзором. И не оперируют полным набором факторов.

      Итого: не всегда в легкости и сложности задач дело.
        +20
        мне больше нравится такая классификация:
        Middle — может выполнить проект в одиночку, без «оркестра»
        Junior — не может
        Senior — не будет.
        В оригинале это шутка на баше, но по мне вполне себе реальный подход.
          0

          Какой-то маленький проект, видимо:)

            0
            В этом и шутка, что совсем не обязательно. И senior как раз это понимает, потому без оркестра делать не будет )
              +2
              Не факт. Могут предложить проект на год и более в одно (или практически одно) лицо и миддл с радостью за него ухватится, если для него это первый шанс построить проект с нуля. Вполне возможно, что после такого проекта он уже может считаться сеньором. В том числе и потому что больше за такое не возьмётся :)
                +1

                В моем мире проект, который можно сделать за год-два-три в одно лицо, не может быть большим.

                  0
                  Ну для вашего мира пускай десять лет будет :)
                    0

                    А что, есть примеры, когда один разработчик пилит коммерческий проект за 10 лет(подчеркиваю, не пилит его полгода, а потом ещё 10 лет поддерживает, а проект от начала до вменяемого состояния занимает 10 лет) и бизнес это устраивает?

                      0
                      Запускает за полгода-год MVP, а потом его развивает.
          +2
          Я бы перевернул, и хуже не особо получается:

          junior — все задачи решает легко (но в основном неправильно)
          middle — сложные задачи решает легко (в основном костылями), легкие сложно (архитектуру там свою напридумать, потренировать новые фичи языков и фреймворков)
          senior — cложные задачи решает сложно, а легкие легко решает больше проблем, чем создает в настоящем и в перспективе
            0

            А Что такое "сложная/легкая" задача и что такое "легко/сложно" решается?
            То есть задача либо решается (и тогда она легка) либо не решается (и тогда она сложная). Разве тут есть средние варианты?

              0
              Как правило из 10 задач, 9 легких и 1 сложная, которая в свою очеред сегрегируется в набор легких.
                0
                Как правило из 10 задач, 9 легких и 1 сложная

                Окей, а как определить какая из 10 — сложная? :)
                Та, что на большее количество часов?

            0
            пытался пройти тестирование по ссылкам в конце статьи: после каждого ответа ERR_CONNECTION_RESET
              0
              Спасибо, что обратили внимание! Очень странно, такой ошибки не возникало в процессе. Иногда бывает, что нет связи с сайтом опросника, попробуйте через какое-то время пройти еще раз.
                0
                Очень странно, такой ошибки не возникало в процессе.

                Только вчера обсуждал фундаментальный недочёт в подготовке программистов в плане софт-скилов, который приводит к этому классическому ответу "У меня работает/работало" xD
                Как думаете, кому-то кроме Junior'ов допустимо пользоваться таким ответом?

                  +1

                  А в чем вы видите проблему такого ответа?

                    +1
                    потому что это совершенно не важно что и как работает у программиста. Работать должно у клиента.
                      0

                      А проблема ответа-то в чем?
                      Мне, кажется, вот этот ваш ответ гораздо хуже ответа "а у меня работает".

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

                          Почему же? Она имеет вполне отношение к делу, в частности: "Иногда бывает, что нет связи с сайтом опросника, попробуйте через какое-то время пройти еще раз.", а то, что "у нас работает" — это причина, по которой человек решил что проблема именно в отсутствии связи или чем-то подобном.
                          Какое же это "не имеет отношения к делу"?

                            +1
                            Так и какое клиенту дело, что на машине разработчика работало/работает? Ему это чем поможет? Оно не работает у него, и только это его заботит.Единственное к чему она имеет отношение — к выяснению технических деталей инцидента. Но люди, которым этот ответ обычно дают, к такому выяснению обычно сами не причастны.
                            И да, «попробуйте еще раз через 5 минут» это допустимый ответ. «Выясняем, сообщу вам через час», тоже допустимо. А вот «у меня работает» это классический ответ по которому можно понять что работаешь с недостаточно квалифицированным человеком.
                              0
                              А чем разработчик поможет клиенту, если у разработчика работает, а у клиента не работает? Гадать на кофейной гуще? Дать рецепт «снести ОС, отформатировать все диски, установить с нуля конкретную версию ОС, установить программу согласно документации и больше на компьютер ничего не ставить?»

                              Люди, ответственные за выяснение технических деталей инцидента, должны выяснить эти детали, воспроизвести «не работает» и отправлять разработчику полное описание того в какой именно конфигурации окружения не работает. Да, бывают плавающие баги, но ответ разработчика «не могу воспроизвести „не работает“» вам понравится больше чем ответ «у меня всё работает»?
                                +1
                                Определенно больше понравиться, хоть он и по прежнему плох. Из ответа «не могу воспроизвести» следует, что он пытался воспроизвести и у него не получилось. Из ответа «у меня все работает» вообще ничего не следует.
                                Хороший ответ должен давать информацию по следующим аспектам:
                                1. Насколько плотно работают над проблемой?
                                2. Когда она будет решена?
                                3. Требуется ли что-то, для того что бы задача была решена или решена быстрее?
                                По сути это единственное что волнует клиента, и как следствие, должно волновать разработчика. Ответ «у меня все работает» не отвечает ни на один из аспектов, более того, создает впечатление негативных ответов. Похоже, над проблемой сейчас не производится никаких работ, и не похоже что кто-то что-то делал. Вариант «не могу воспроизвести», означает что по крайней мере кто-то что-то попытался сделать, но ситуация по прежнему не улучшается.
                                Идеальный ответ звучит так:
                                «Наши лучшие специалисты в настоящий момент плотно работают над этим, ожидаем решения в течении часа. Ребятам здорово поможет, если вы дополнительно предоставите следующую информацию:
                                1.…
                                2. ....»
                                  0
                                  Так и вижу, спрашивает у меня начальник «ну что там с тем багом?», а я ему «Наши лучшие специалисты в настоящий момент плотно работают над этим...». Вот не могу решить, какая его реакция будет на это — уволит или скорую вызовет.

                                  И варианты «не могу воспроизвести» и «у меня всё работает» означают почти одно и то же за исключением ситуаций типа «не могу воспроизвести, у меня комп сломался».

                                    0
                                    Ну в примере очевидно вариант ответа клиенту. По этому ощущение шизофрении при ответе начальнику нормально.
                                    Для ответа начальнику очевидно достаточно «сейчас работаю над этим». В случае критичности проблемы можно сказать «отложил остальные задачи, сейчас работаю только над этим».
                                    Ну и нужно понимать это это воображаемый пример который просто иллюстрирует как может звучать ответ, который отражает информацию по важным аспектам. Естественно его нужно допилить по месту.
                                      0
                                      По месту такой ситуации вообще не должно возникнуть. Не потому что багов не должно быть, а потому что разработчик по вопросам «у меня ничего не работает» обычно не должен с клиентами общаться. А начальнику или саппорту вполне нормально сказать (или написать в причине реджекта тикета) «у меня всё работает» и адекватные коллеги должны понять, что недостаточно информации для воспроизводства бага.
                                        +1
                                        Ну сейчас довольно можно вести прямой контакт между разработчиком и клиентом, сильно снижает уровень бюрократии и ускоряет коммуникацию.
                                        Ну и «такой ситуации не должно возникнуть» так себе логика. По ней и багов то быть не должно. Пони, радуга, рок-н-ролл.
                                          0
                                          Сомневаюсь, что обычный разработчик имеет подготовку для ситуаций типа «ниодногоразрыва».
                                            0
                                            а вы думаете откуда этот раздел про soft skills вырос. Лет десять назад такие вещи никого не волновали.
                                            У нас кстати говоря разработчики работают с заказчиком напрямую. И в нескольких конторах до того, где я работал это происходило в той или иной степени.
                                            Образ разработчика как нелюдимого тролля, говорящего не непонятном языке уходит в прошлое.
                                              0
                                              Раздел про soft skills явно вырос не из требований к сотрудникам первой линии по навыкам нейтрализации агрессии и прочей неадекватности клиентов.
                                                0
                                                В том числе. Там вообще большой список причин. Нынче разработчики это не только инженеры. Это еще и лицо компании, при том с разных сторон. И перед клиентом, и, например, перед рынком труда. По этому компании вкладываются в проведение мероприятий, отправляют своих инженеров спикерами. Ну и в командную игру нужно уметь. А так сложилось что это все довольно связанные вещи, и набор навыков для всего этого нужен плюс минус один и тот же.
                                                  +1
                                                  Я знаю несколько непоследних компаний, в которых разработчики обязательно ходят на переговоры пре-сэйловские и выступают перед заказчиками на ПСИ (приемо-сдаточные испытания), даже презентации могут сами готовить. Не все, конечно, шибко рады, но, как говаривали выше, границы стираются. Плюс много небольших проектов, где разработки сами себе Руководители проектов и спецы, никто им не выделит отдельного супер-спикера.
                                                    0
                                                    Сейчас наверное все аутсорсеры так работают. В продуктовых компаниях еще можно как-то от клиента изолироваться, а вот в аутсорсе не выйдет. Особенно в проектах с совмещенными командами или под прямым управлением заказчика.
                                                      0
                                                      В таком аутсорсе я воспринимаю заказчиков как членов команды разработки, а клиенты в данном случае — клиенты этого заказчика.
                                                        0
                                                        В таком аутсорсе — это в каком? По сути аутсорс один, а это просто разные формы контрактов. Как правило аутсорсинговые компании не ограничивают себя какой-то конкретной формой сотрудничества и всегда готовы идти на встречу заказчикам. По факту это означает что у одной аутсорсинговой компании в работе как правило находятся контракты всех видов, и чем крупнее — тем большее разнообразие можно встретить.
                                                          0
                                                          В таком, где совмещенные команды или команды под прямым управлением заказчика. Ну и как-то так получалось в моей жизни, что ни разу аутсорсинговые компании не предлагали мне идти к ним «работу работать» (хотя и слышал о таком подходе типа «выметаем с рынка всё что есть, а проекты потом найдём») в роли разработчика (лид или архитектор — отдельный разговор), а предлагали конкретный проект без продолжения сотрудничества после его окончания, ну типа «постараемся что-то подобрать, если будет», но ни о каких «бенчах» не сообщали. Да я и не согласился бы наверное давать обязательство работать на любом проекте «куда Родина пошлёт». Поэтому на таких проектах я аутсорсера воспринимаю не столько как работодателя, сколько как посредника, а работодатель — заказчик, а клиенты — клиенты заказчика.
                                                            0
                                                            Видимо они до вас просто не добрались ) Обычно выметают с рынка все что есть что бы посадить на реальные проекты, спрос большой (у нас к примеру открыты вакансии в нескольких городах, мы как раз такая компания). Собственно частенько в компаниях существует перманентный дефицит который закрывают субподрядчиками.
                                                            Компании без бенча — не уверен что их можно называть аутсорс компаниями. Вполне себе тянет просто на посредника или биржу труда.
                                                              0
                                                              Добирались компании, про которые я точно знаю, что бенч есть у них, но не на бенч мне предлагали, а конкретные проекты без описания того, что будет после — увольнение или бенч. Просто с предложениями «идите к нам — мы вам кучу всяких проектов дадим лет на 10 минимум, а не найдём — будете просто так деньги получать эти 10 лет» не обращались. :) А если бы обратились — не уверен, что согласился бы, ведь, как я понимаю, с бенча идёшь на проект, на который скажут, а не на который хочешь. Скажут «тыжпрограммист, разберёшься с кучей легаси и фреймворками, которые тебе не нравятся архитектурно»
                                                                0
                                                                Ну мы так даже конкретный проект обычно не предлагаем. Они у нас идут паровозами, и отправляются достаточно рандомно, так что на момент собеседования вообще сложно что-то сказать. Пока идет собеседование и найм, некоторые проекты можно и сделать успеть, даже такое бывает. Особенно если кандидат просит 1.5 месяца на переход.
                                                                А вот с выбором проекта это да, боль. Обычно куда поставят — туда поедешь, без вариантов. Это практически везде. Мы стараемся наверное больше остальных упарыватся подбирать проекты под людей, но сколько усилий не трать — гарантии получить проект не выходит. Но управление бенчом это тема для отдельного разговора.
                                                                  0
                                                                  Ну значит или мне везёт, или они как-то догадываются, что за такой режим работы я запрошу компенсацию намного выше той, что мне предлагают на конкретных проектах.
                                                                    0
                                                                    А что с управлением бенчом — ад? У меня нет особого опыта, есть только галлюцинации, что на бенчах сидят только средненькие миддлы и джуны (которых вообще трудно пристроить), и сложность только в том, чтобы с бенча их в проект какой угодно сбыть… Не так?
                                                                      +1
                                                                      там уйма противоречивых требований которые очень не любят складываться.
                                                                      К примеру — выпадает человек на бенч, подбираешь ему хороший проект, а он не стартует. Заказчик маринует месяц, потом второй, третий…
                                                                      Новички(кто только пришел в компанию) очень не любят сидеть на бенче. Поскольку ежели я вам так нужен, что вы меня наняли, как так что для меня проекта нет? А именно их сложнее всего пристроить.
                                                                      И да, на бенче чаще всего сидят миддлы и джуны, но именно им бенч меньше всего интересен и нужен — на бенч лучше всего сажать старших, что бы хоть передохнули между проектами, но их оттуда оттаскивают в первую очередь.
                                                                      Это только в общих чертах. При этом бенч довольно важная штука в профилактике выгорания, росте и развитии компании, и качество управления им имеет очень большое значение для компании. Но управлять им — реальный ад. Почти всегда выбираешь наименее отвратительное решение, удачные и верные ходы — большая редкость.
                                    0
                                    да да, чаще слышишь от клиента «у меня не работает», а что где как не работает — это он выразить не в силах…
                                    0
                                    Так и какое клиенту дело, что на машине разработчика работало/работает? Ему это чем поможет?

                                    Клиенту поможет совет попробовать еще раз через некоторое время. А "у меня работает" — лишь объяснение того, почему совет именно такой, а не какой-то другой. Просто чтобы клиент понимал, почему ему дали такой совет.


                                    И да, «попробуйте еще раз через 5 минут» это допустимый ответ.

                                    Так именно такой ответ выше и был дан.

                                      0
                                      Ну собственно речь о том, что «у меня работает» не может быть ответом. Может быть дополнительной информацией, пояснением к ответу, но самим ответом должно быть что-то другое. А иногда приходится сталкиваться с тем, что разработчик считает, что это может сойти именно за ответ.
                                        0
                                        Этот ответ означает «я пытался воспроизвести — не получилось». Ну и может иметься в виду «приходите, когда добудете от клиента больше информации», если разработчик считает, что проблема всё-таки в его коде, а не каком-нибудь (анти)вирусе, который что-то заблокировал.
                                          0
                                          Может. А может означать что ткнул пару раз, решил что муть какая-то и решил просто ничего не делать. А может там вся команда бьется над решением с привлечением смежных департаментов. Собственно это и значит что он не сообщает нужной вопрошающему информации. Вообще никакой кроме того, что судя по всему, что-то идет не так.
                                          «О Великий Думатель, я хочу услышать ответ четкий и ясный, дай нам ответ на главный вопрос» (с)
                                            0

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

                                              0
                                              Это значит что над ней по крайней мере работают. «у меня все работает» вообще ничего не значит.
                                                0
                                                Это значит что над ней по крайней мере работают.

                                                Поверьте, совсем не значит.

                                                  0
                                                  ну если разработчики напрямую врут, то тут есть проблемы посерьезнее некорректных формулировок.
                                                    –1

                                                    Почему же врет? Это все ваша интерпретация. "Мы усиленно работаем" = баг завели, он теперь в трекере (= в работе) и возможно даже не с минимальным приоритетом (= не просто работаем, а усиленно!). Все по-честному, и когда-нибудь до него у кого-нибудь дойдут руки.

                                                      0
                                                      Потому что если человек говорит «мы усиленно работаем», а на деле не делается ровным счетом ничего — это ложь как ни заморачивайся с интерпретациями. Все эти «ну он же в багтрекере есть» это пустые отмазки, а не интерпретации.
                                                        0
                                                        Это может быть не ложь, а заблуждение. Посмотрел на статус тикета, назначенного на другого человека, он активный и сообщаешь эту информацию.
                                                          –1
                                                          Потому что если человек говорит «мы усиленно работаем», а на деле не делается ровным счетом ничего — это ложь

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

                                                            0
                                                            Софистикой не страдайте. Когда к вам начальник придет и спросит что было сделано за неделю такой «усилинной работы» вы о чем отчитаетесь? «Мы баг в прогресс перевели»?
                                                              0
                                                              Софистикой не страдайте.

                                                              Какая софистика? Над багом работают — это факт. Что вас не устраивает? или пол "работать" следует понимать исключительно момент написания кода? А если человек, ответственный за этот баг, в этот момент задумался о чем-то или пописать отошел — то все, никто над багом не работает, вывсеврети?


                                                              Когда к вам начальник придет и спросит что было сделано за неделю такой «усилинной работы» вы о чем отчитаетесь?

                                                              Если ничего не сделано — то о том, что ничего не сделано. А о чем еще отчитываться? И к чему этот вопрос?

                                                                0
                                                                удивительно что такой простой факт — производится работа или нет у вас вызывает сложности.
                                                                Производство работы это процесс. Состояние бага в багрекере это не процесс. Либо кто-то работает над задачей, либо нет. Вы сами сказали — статус выставили, и «когда-нибудь до него у кого-нибудь дойдут руки». Это совсем не тоже самое что «задумался о чем-то или пописать отошел».
                                                                Либо работа реально реально производится, либо нет. Работа это любая деятельность направленная на решение проблемы, будь то написание кода, либо просто размышление над задачей или общение с закачиком, это не важно. Если работа не производится, а разработчик говорит, что «мы плотно работаем», то это ложь. Независимо от того какие там статусы в багтрекере. Перевод статусов в багтрекере не способствует решению задачи.
                                                                Либо работа реально производится и кто-то над ней работает и тогда все ок.
                                                                Если вы не понимаете таких довольно простых вещей, не вижу большого смысла с вами обсуждать более сложные аспекты коммуникации
                                                                  0
                                                                  Вы не отличаете ложь от заблуждения? Если разработчик видит статус у тикета, назначенного на qa «In analysis», то разве он не имеет полного права сказать «мы плотно работаем»?
                                                                    0
                                                                    отличаю, а вы? Таки между заблуждением и распространением заблуждений есть весьма заметная разница.
                                                                    И сказать то он может все что угодно, но за слова отвечать потом придется самостоятельно. В частности если вдруг язык повернулся отчитался что «плотно работаем» глядя чисто на статус тикета, неплохо бы пойти потом и проверить, что работа реально происходит.
                                                                      0
                                                                      Проверять чужую работу обычно в компетенции разработчика не входит (речь не про код ревью). Есть специально обученные люди, одна из задач которых состоит в том, чтобы статусы тикетов отражали реальное положение дел. Часто название их позиции содержит слово «менеджер» или «лид».
                                                                        0
                                                                        Люди, в чью компетенцию не входит проверять чужую работу и не отвечают о состоянии работ по задачам опираясь на статус тикета в багтрекере. Они и без багтрекера прекрасно знают работают они над задачей или нет.
                                                                          0
                                                                          Почему не отвечают? Я даже непосредственному начальнику отвечаю, что, например, такой-то багфикс в QA, хотя он сам может посмотреть. И вопрос не «ты работаешь или нет над багом», а «что с тем багом?»
                                                                            0
                                                                            Да, но давайте все таки вернемся к кейсу «мы плотно работаем» в том конкретном случае, когда на самом деле нет. Вы же не скажете «багофикс в QA, тестеры над ним активно работают» опираясь чисто на статус в багтрекере. Только в том случае если есть реальная информация, что они действительно над ним работают.
                                                                            Опираясь на статус багов отчитываются только те, у кого есть менеджерские обязанности(бывает и разработчики). Остальные отчитываются в основном только за себя (где обладают полной информацией), либо если обладают реальной информацией о других, в которой они точно уверены, например видели своими глазами.
                                                                              0
                                                                              Почему не скажу? Вполне могу сказать, если в целом знаю, что статусы соответствуют действительности в компании.
                                                                                0
                                                                                простите, а зачем? Очевидно в вашу компетенцию это не входит (раз в нее не входит проверка соответствия статуса таски реальному положению дел) и реальной информацией вы тоже не обладаете. Зачем говорить что над задачей плотно работают, если вы об этом реально не знаете и отношения особо не имеете?
                                                                                  0
                                                                                  «Мы открыты и прозрачны для клиентов».
                                                0
                                                Не «ничего не делать», а «отреджектить тикет с возможным(!) багом» на уточнение условий воспроизведения. Если в тикете есть условия воспроизведения фактические, то «пару раз ткнул» не по ним — повод задуматься об неполном или ненадлежащем исполнении задач. А если их нет или формально есть, но по ним баг не воспроизводится, то обычно попытки их воспроизвести, гадая на кофейной гуще — нецелевая трата ресурса разработчика.

                                                Естественно исхожу из ситуации, когда тикет с багом не приходит с комментарием от начальника типа «Бросить всё и исправить любой ценой, забив на все остальные задачи. Даю полномочия на прямой контакт с клиентом с целью получения условий воспроизведения и согласования пути решения»
                                                  0
                                                  заявить «у меня все работает» и «уточнять условия вопроизведения», «отреджектить тикет» это таки две большие разницы. Это может происходить одновременно, а может и не происходить. Тикет может висеть открытым годами, и по нему не будет ничего не происходить, потому что «у меня не воспроизводится», где подразумевается «фиг знает что с ним делать». Весьма распространенная ситуация. Видел такое в разных компаниях, в том числе крупных и известных.
                                                    0
                                                    Реджект «У меня не воспроизводится»/«у меня всё работает» подразумевает, что тикет висит на ответственном за сбор дополнительной информации об инциденте.
                                                      0
                                                      Как я уже написал выше, совсем не обязательно подразумевает. Это также может подразумевать «фиг знает что с ним делать, займусь пока чем то поважнее, может потом в голову чего придет».
                                                      Это вообще все что угодно может подразумевать. Сама фраза, как я уже сказал, не несет ровным счетом никакой полезной информации. Все остальное — домыслы, попытки опереться и угадать исходя из дополнительного контекста, что же разработчик имел ввиду.
                                                        0
                                                        Флоу разные бывают, да и в разных ситуациях разные нюансы могут быть. Но фраза «у меня работает» всё же несёт информацию о том, что разработчик пытался воспроизвести баг (ложь во внимание не принимаем), но не смог.
                                                          0
                                                          В нашем же случае речь идет скорее о работе стейкхолдера. Тест расположен на стороннем сервисе, на который работу которого мы не влияем. Можем жаловаться, но масс-маркет подход стейкхолдера избавляет нас от шансов на успех. Знаю, что и в компаниях происходят такие случаи (когда на аутсорсе целые компании и они косячат). Как (кроме категорической замены стейкхолдера) регулируются такие случаи?
                                +1

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

                                  +1
                                  Ответственность за что? За трату рабочего времени на гадание на кофейной гуще в попытках воспроизвести проблему без прямого указания начальства на то?

                                  И не «разработчик типа уже не причем», а «не в моей компетенции устраивать клиенту допрос с пристрастием, для выяснения того чем его конфигурация отличается от рекомендованной, а, тем более, чем конфигурация продакшена, к которой у меня нет доступа, отличается от рекомендованной».
                                    0
                                    Ответственность за что?

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


                                    не в моей компетенции

                                    Ну, если не в вашей компетенции, то оставьте общение с клиентами тем, в чьи компетенции это входит. Всё просто же.


                                    его конфигурация отличается от рекомендованной

                                    Для начала надо ещё доказать, что проблема в этом. И спойлер: чаще всего проблема не в этом.

                                      0
                                      Результат вот он, на моей локальной машине, развёрнутый с нуля в виртуалке или контейнере по согласованной и утверждённой инструкции скриптами разворачивания, лежащими в продакшен ветке репозитория.

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

                                        Результат он только на проде и нигде больше, что у вас там на локальной машине — вообще никого не волнует, ни клиентов, ни начальство.

                                          0
                                          Зависит от принятого флоу, от definition of done.
                                0
                                Допустимо всем при наличии процессов синхронизации дев-окружений со всеми остальными и выполнением всех действий по ним со своей стороны. Как абстрактный пример — если я внёс изменения в какой-то список пакетов для установки на сервере, а кто-то накатал остальные артефакты на сервер, но шаг установки пакетов пропустил «для скорости, всё равно раз в год меняется список», то вполне нормальный ответ.
                            +1
                            После прочтения списка софт-скилов (особенно про «взять под крыло всю команду») возник вопрос: а что в этой парадигме остается тим-лиду? Или позиция тим-лида окончательно откатилась в менеджерскую сферу и с командой-аджайлами-проектированием уже никак не связана?
                              +3
                              Видимо сеньёр это звание, а тимлид это должность.
                                0
                                Вряд ли. Потому как ему в довесок же еще будет всевозможное представление команды внешнему миру и пр. И в то же время выше в «жестких» скилах сказано, что нужно и фреймворки когда-то изучать =)

                                Т.е. вряд ли без ущерба для здоровья можно совмещать тимлида и супер-синьора. Либо я таки чего-то не понимаю.
                                  +1
                                  Так и есть. Жуткие штрафы за мульти-классовость. Видел лично, много раз, что совмещение менеджера со специалистом не бывает без ущерба роли «менеджера» или «специалиста».
                                    0
                                    Давайте так: если софт-скилл-часть у специалиста хорошо прокачана, то, скорее всего, он и сам не будет против совмещения — захочет двигаться дальше. Если прямо плохо, то скорее всего, у него будут те или иные сложности в работе. Зависит от степени сложностей, конечно. Мы для себя принимаем, что хорошему профессионалу достаточно среднего значения. А по тесту мы видим, что ему проще и лучше бы развить, а что несовместимо с его собственными желаниями роста
                                      +1
                                      Чудес не бывает. Будет средний специалист и хороший менеджер. Либо средний менеджер и хороший специалист.

                                      И как бы средний специалист это вредитель на большом проекте, средний менеджер это вредитель на любом проекте.
                                        0
                                        тут дело не столько в мультиклассовости, а в том что тимлид решает вопросы на другом уровне. Он оперирует архитектурой, и крупными блоками, не закапываясь в мелкие детали. Делает он это по прежнему руками (к примеру архитектор обычно уже нет). Тем не менее в детали обычно закапываются другие, за исключением случаев требующих особой квалификации или знаний. Это просто более высокий уровень абстракции, а не другой класс работы.
                                        Хотя конечно, от компании зависит. Бывает по всякому.
                                    +3
                                    Пункт про фреймворки вообще странный, если человек концепции понимает, то нет никакого смысла изучать все фреймворки про запас.
                                      +1
                                      Я придерживаюсь мнения, что «изучать фреймворки» полезно для поиска новых концепций (e.g. ECS, Sagas — из последнего для меня). Но в то же время есть фреймворки достаточно устоявшиеся и их специфику лучше знать.
                                0
                                Отличный вопрос, спасибо. Действительно, в последние годы мы явно видим именно такую тенденцию — руководители и CEO уходят функциями на уровень развития компании и направлений, больше занимаются кросс-функциональными вопросами и стратегиями, а тимлидам отходит все больше функций операционного менеджмента, ну а продвинутые senior-ы — все больше рулят технической стороной дела и помогают тимлидам. Так что возможностей для роста каждого — все больше) Было бы желание и способности
                                  0
                                  Такие ощущения и были, да. Вот только «возможностей для роста» я тут не вижу — просто «растянули» существующие позиции.

                                  Ну, и в качестве отвлеченного замечания: это что же, теперь синьор еще и людей любить должен?!!!
                                    0
                                    Скорее, это некое расслоение внутри большого уровня «Senior»: тот, кто может любить людей и ориентируется на вертикальную административную карьеру прокачивает софт-скиллы и все больше перенимает функций тимлида, чтобы со временем им стать. Те, кто ориентируются на развитие по технической части, тоже особо не могут себе позволить нелюбить людей, потому что Тех, к примеру,-лид и Архитектор тоже должны уметь с людьми конструктивно работать. Ну, а если уровня крепкого Senior достаточно, то, как минимум, все равно нужно хорошо взаимодействовать в команде, конструктивно договариваться и брать на себя ответственность за довольно большой кусок своей работы. Ответ — все равно «да», вопрос только дозы любви)
                                      0
                                      О, не, конечно, «не любить людей» — это я утрирую =) Просто мне кажется для поддержания здорового климата в команде нужно что-то большее, чем просто «способность к конструктивному диалогу по необходимости».

                                      Про расслоение — понял, интересно. Спасибо.
                                  0
                                  Кстати, во многих крупных/продвинутых компаниях выкристаллизовалось и направление скрам-мастера отдельное. Если Senior-у ориентироваться на эту ветку развития, то придется изучать методологии плотнее. И все равно: тот же набор софт-скиллз как база останется и там.
                                    0
                                    Ему хард-скиллы сеньора зачем?
                                      0
                                      А это их база, они изначально разработчики и развиваются как разработчики. Доходят до какого-то заметного уровня и, если хотят развиваться дальше таким путем, перестают качать хард. Но при этом до Senior-то уровня они уже добрались
                                        0
                                        Я к тому, что, по-моему, на скрам-мастера можно хоть с джуна начинать учиться, а может даже лучше вообще не иметь технического бэкграунда, чтобы, например, не занимать подсознательно ту или иную сторону в разгоревшемся споре.
                                          0
                                          Можно, только никто не будет джуна серьезно воспринимать. Чтобы стать скрам-мастером и команда приняла в таком качестве надо сначала себя спецом здорово показать. Иначе никакое руководство не будет поддерживать и вкладываться в развитие. Будут говорить: скрам — прекрасно, а когда кодить нормально начнешь? У нас пока что все-таки движение очень линейное
                                            0
                                            Скрам-мастер не является членом команды разработки, его функции чисто менеджерские.
                                              0
                                              А вот даже и не менеджерские =D Его задача фа-си-ли-ти-ро-вать аджайл практики в команде, простиоспади.
                                                0
                                                Главное суть — управлять людьми, говорить им что делать и что не делать :)
                                                  +1
                                                  В том-то и беда. Мастер не может указывать, что делать. Он подсказывает, как ту или иную практику аджайла лучше сделать здесь и сейчас (e.g. борду организовать поможет, ретроспективу\постмортем в конструктивном русле поможет сдержать).

                                                  На психоаналитиков похожи, на мой взгляд =D
                                                    0
                                                    «Что делать» не в плане какие задачи пилить, а что делать во время митингов, например.
                                    0
                                    Тимлиду — заниматься мотивацией команды
                                      0
                                      Да-да, об этом и речь. Все дальше тим-лиды уходят от работы В команде в сторону работы С командой (i.e. внешне по отношению к команде). Лишь бы не перестали говорить на одном языке с инженерами =)
                                        0
                                        Вот честно, не очень понимаю зачем :) Была у нас, как говорится кроссфункциональная команда и тимлидом был дизайнер (а я техлидом или даже архитектором) — вполне дружно жили
                                      0
                                      Есть такое понятие как наставничество. Вот оно как раз относится к софт. Умение быть хорошим наставником полезный навык.
                                        0
                                        Это мне? Про тим-лида? Можно как-то перефразировать — я не уверен, что правильно понял ответ.
                                          0
                                          Да, ответ вам.
                                          Просто авторы различных книжонок и рекомендаций вкладывают в софт скилс под управлением, в первую очередь навык наставничества. Не знаю откуда пошла эта мода но в здоровых коллективах оно выстраивается естественно. В каждой команде есть старожил который расскажет подробно о всех явных и не явных процессах в компании.
                                          0
                                          Более того — одна функция, но обилие навыков: организация своей работы и ближнего, коммуникация и аргументация, дробление задач больше-мельче/сложнее-проще, зачатки планирования и контроль, где-то и мотивация с поддержкой… Плацдарм для менеджмента, по сути
                                        +6
                                        посмотрел требования к super senior, и даже не понял, это о senior или junior? «понимание принципов ООП», «шаблоны проектирования», «система контроля версий», это все от джунов требуют. Остальные форумлировки оставляют желать лучшего. Вот если взять все эти формулировки и перенести их в резюме, я бы не смог классифицировать его между middle и senior. Тут же фокус не в том чем владеть, а на каком уровне. Для мидла вполне себе нужно уметь развернуть, настроить и поработать с NoSQL, тем более что одно дело поработать с редисом, а другое — с эластиком. Для сениора уже недостаточно просто «иметь навыки управления», он уже должен всю внутреннюю механику понимать, и желательно в деталях.

                                        По проблемам с софт скилами, тут мне кажется основное дело вот в чем. Как правило требования к ним растут не линейно. По факту обычно сидит человек кодит себе, никого не трогает, качает свои хард скилы. А в один прекрасный день к нему приходит менеджер и говорит, теперь ты будешь тимидом. Что это такое, как это делать, никто не объяснит. На курсы тоже не отправят. Вот тебе проблемы, разгребай. И дальше начинают прилетать проблемы. Ты чего своих не менторишь? А что надо было? И в том же духе. Сверху начинают сыпаться одни только проблемы, получается негативное закрепление. В итоге большая часть говорит, что нафиг мне такое счастье? Кодил себе и все хорошо было. Нафиг качать эти софт скилы, от них проблемы одни.
                                        А качать их это хорошо, правильно, и классно. Просто далеко не везде.
                                          +2
                                          «… это все от джунов требуют» — не все, но в Яндексе требуют, это да. И тесты всех заставляют писать. Ну, может от стажёров не так сильно требуют.

                                          Формулировки ужасные. «Грамотная оценка комплекса задач» — это что имеется в виду? «Я посмотрел на задачи, они сложные?»
                                          «Принятие ответственности в сферах: целей и планов, профессиональных взаимоотношений, руководства, карьерного развития» — ответственность это хорошо, но о чём здесь речь? Вот допустим человек считает, что достоен повышение, а руководство отказывает. Что тогда? Ответственно сменить работу? Или не сменить и ответственно гребсти на галере? И это ещё простой вопрос. А если коллега, скажем, упёртый, сложный в общении? Или с планами? Планировать за руководство?

                                          Ощущение от всего этого описания и теста, что Сеньор — этакая палочка-выручалочка: придёт и молча исправит всё. Даже то, что вне его сферы ответсвенности.
                                            0
                                            «Принятие ответственности в сферах: целей и планов, профессиональных взаимоотношений, руководства, карьерного развития» — ответственность это хорошо, но о чём здесь речь?

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

                                            Ну вроде так и есть. Разве нет? По опыту чего-то такого от сениоров и ждут.
                                              0
                                              Размытые формулировки еще не беда. Проблема в том, что в большинстве случаев ни в требованиях, ни внутри компании ими открыто не оперируют, но по ним оценивают и «отказывают». Мы вытаскиваем их на свет божий) В статье мы привели лишь названия критериев в двух софт-скиллз блоках. В интерпретации к тесту мы даем более развернутое представление о каждом критерии и степени его развития. Чтобы сделать это здесь потребовалась бы отдельная статья
                                              0
                                              Действительно, проблема разной оценки специалиста самим специалистом и руководителем нередко случается. Поэтому мы и считаем, что важно не только выяснять по каким конкретно критериям руководитель отказывает, но и воспользоваться как можно бОльшими альтернативными источниками оценки по этим критериям. Потому что, с одной стороны, сам специалист может не видеть дефицитов (особенно если скиллы по этим критериям крайне слабо развиты — это классика), а с другой — и у руководителя могут быть свои причины не продвигать сотрудника.

                                              Если senior — это супер-профессионал высокого уровня, то он, безусловно, выручалочка) Не зря у него и статус, и ЗП соответственные. Хотя, конечно, не волшебник. Тут перегибать не стоит.
                                                0
                                                Выручалочка, но только в области своей компетенции. Да, он может сделать технически хороший продукт, но он не спасёт компанию, если её учредитель, скажем, сделает что-то, что её утопит (в виду сокращения финансирования, например), или продажники накосячат, или юристы всё профукают, или ещё что-то случится. Он может говорить, убеждать, но это вне его сферы ответственности. А тот же опрос явно составлен с перекосом на «командную ответственность» безо всякого контекста. Когда ответственны все — не ответственен никто.
                                                  0
                                                  Ну вообще это отдельный актуальный и не раскрытый в статье вопрос. На самом деле сейчас от сениоров многие ждут не просто технических решений. От них ждут технических решений на уровне бизнеса, т.е. в том числе иногда и бизнес решений.
                                                  Другими словами нужен инженер который не просто пишет код, а делает продукт, а код это уже второстепенно. И сфера компетенции в таком случае естественным образом значительно размывается.
                                                  Правда разные компании находятся на разных стадиях осознания процесса. Кто-то явно понимает и открыто об этом говорит, а кто-то выстраивает непонятные абстрактные формулировки, за которыми можно только догадываться.
                                                    0
                                                    Полностью согласны! Чем выше уровень, тем больше бизнес-ожиданий накладывается. И там границы ответственности провести сложнее. Однако во все времена, чем большими факторами человек оперирует, чем шире поляну видит: целый продукт, продуктовая линейка/направление, компания и бизнес-сфера, их возможности/ограничения + все вариации технологических решений под это — тем выше он будет цениться.
                                                      0
                                                      Ну тут дело не только в высоте позиции. Есть еще такая штука как уровень развития компании (я сейчас про спиральную динамику и бирюзовые организации). По мере продвижения самой компании уровни ответственности начинают размыватся на всех уровнях иерархии. Как, впрочем, и сама иерархия.
                                                        0
                                                        Уровни начинают развиваться — точно. Но не степень личностной ответственности каждого. Один из краеугольных камней бирюзовых организаций именно в том, что члены команды разделяют высокую степень ответственности. Именно поэтому структура способна быть плоской, а руководителя в официальном эквиваленте вообще уже может не быть. Бирюза — она для высокооответственных и прокачано софт-скилловых, иначе все развалится)
                                                          0
                                                          Там дело не только в высокой ответственности и количестве софт скилов, там вообще огромный спектр требований. Нужно до идеала надраить все предыдущие уровни — и иерархическое управление, и роль индивидуума, и культурный слой, шаринг знаний, список длинный. Но сейчас речь не об этом.
                                                          В бирюзовых организациях любой сотрудник имеет возможность проводить изменения любого уровня. По сути, даже джун, может проводить изменения на уровне компании, то что в классической схеме управления часто может сделать только владелец компании. Это таки очень сильно увеличивает степень ответственности на всех уровнях, особенно на низких (на высоких она наоборот снижается, происходит выравнивание).
                                                            0
                                                            Да, это более комплексная картина)
                                                      0
                                                      Люблю говорить на собеседованиях: «хочу решать бизнес-задачи техническими методами» :)
                                                        0
                                                        Музыка для ушей моих)
                                                          0
                                                          У нас таки есть вакансии
                                                          Почему кандидаты на собеседованиях так редко это говорят…
                                                    0
                                                    > Вот допустим человек считает, что достоен повышение, а руководство отказывает. Что тогда? Ответственно сменить работу? Или не сменить и ответственно гребсти на галере?

                                                    Узнать причину отказа, выяснить что нужно сделать (грубо, какие скиллы прокачать), чтобы не отказали в следующий раз, оценить стоит ли овчинка выделки в данной компании и принять решение либо качать тут, либо качать в другом месте (грубо, курсы тимлидов), пока оставаясь тут работать, или качать в другом месте и работать в другом месте. А может в другом месте уже сочтут, что достаточно прокачен.
                                                      0
                                                      Тут главный вопрос статьи в том, чтобы можно было понять подходит человек или нет. И как по таким критериям оценить эту «ответственность»? Спрашивать кандидата что он будет делать в такой ситуации? Так это из извечных вопросов, на которые все знают правильный ответ, и никто в здравом уме не будет отвечать искренне (если уже не забили на собеседование по каким-то причинам).

                                                      P.S. А на вопросы про причины отказа ответят просто: «не тянешь» (вар.: «долго делал») или «софт-скиллов не хватает», без конкретики конечно же.
                                                        +1
                                                        Далеко не все знают правильные ответы на вопросы типа «Полчаса до конца рабочего дня, приходит критикал баг с высшим приоритетом. Начинаете разбираться, прошло 25 минут, но даже локализовать не получилось. Ваши действия?». Хотя бы потому что в разных компаниях или даже у разных руководителей разные понятия об ответственных действиях в данной ситуации.

                                                        Если без конкретики, то надо валить, если реально хочешь повышения. Возможно не сразу, а найдя что-то взамен предварительно, причём прямо на собеседованиях спрашивая «сейчас я пришёл сеньором, но через год вижу себя в вашей компании тимлидом. Вот вы меня поизучали, допустим делаете оффер и я его принимаю — скажите, что мне конкретно нужно ещё изучить-освоить чтобы при открытии такой вакансии вы её мне предложили? У вас внутренние курсы или типа того есть для этого? » На удивление, часто рассказывают. Ну или отвечают так, что даже если оффер будет, то принимать его не станешь.
                                                          0
                                                          вот кстати да, пример реально жизненный. У нас на собеседованиях редко, но спрашивают так, и мы честно все рассказываем.
                                                          И кстати факт такого вопроса обычно идет добавляет свой плюсик к итогам собеседования.
                                                          0
                                                          Ответственность, пожалуй, самая сложная тема. Мало кто умеет ее оценивать. Мы по этому блоку (внешний-внутренний локус контроля по-психологически) приводим в тесте и интерпретациях вполне конкретные критерии и их расшифровку. Некие ориентиры это показывает — в каких направлениях человек более склонен брать на себя ответственность, а в каких -сливать или ожидать от других. У нас, конечно, очень краткая версия — но и собеседования никто не отменял.
                                                            0
                                                            «Внешний-внутренний локус контроля по-психологически» — это здорово, но как вы обрабатываете случай гиперответственности? (То есть ответственности за пределами реального влияния.) А она ведь прямой путь к конфликтам.
                                                              0
                                                              ХМ, гиперответственность — это когда человек захватывает слишком много ответственности на себя и уже несколько в ущерб окружению. Этакий герой, который тянет на себе все до чего может дотянуться, и стонет от натуги. При этом остальные либо расслабляются (зачем напрягаться, герой сам все сделает), либо раздражаются, потому что им достается меньше и они не растут. Кажется, Вы имеет ввиду что-то другое. Например, когда вменяют в ответственность то, что делать не хочется или кажется, что лежит на чужой территории? Так?
                                                                0
                                                                Кажется, Вы имеет ввиду что-то другое. Например, когда вменяют в ответственность то, что делать не хочется или кажется, что лежит на чужой территории? Так?
                                                                Нет. С чего вы взяли?
                                                                0
                                                                Пока по личной практике гиперответственность это скорее плюс. Она конечно создает некоторые неудобства, но они с лихвой окупаются плюсами.
                                                                  0
                                                                  Гиперответственность — работа на износ. Ну и плюсы у неё появляются, по-моему, только если рядом чья-то безответственность.
                                                                    0
                                                                    Ну как тут было уже в комментариях, при росте в должности зоны ответственности обычно размываются. Тоже происходит при развитии компании в сторону самоорганизации. А при росте в должности, в компании растущей в сторону самоорганизации — размытие идет в квадрате. И обычно людей надо учить тому, как правильно в такой среде жить. И это не просто. Гиперответственных учить не нужно, даже наоборот, на них в этом вопросе нужно положится. Они сразу себя чувствуют в такой среде как рыба в воде.
                                                                    А вот работа на износ, это да. С любопытством наблюдаю за такими. Пока вроде никто из тех за кем наблюдаю не сгорел за несколько лет. Но кто знает.
                                                                  0
                                                                  Ха, пришли результаты. Правильно, никак.
                                                                  Вы старательно разграничиваете ответственность за рабочий процесс и результат с Вашим руководством. Не берете на себя больше, чем достаточно для Вашей позиции. А зря. Чем больше ответственности Вы разделяете с руководством, чем более высокоуровневый взгляд (помимо техничного решения задач) показываете — тем более ценным сотрудником Вы становитесь.
                                                                  То есть идеальный сеньор по мнению авторов: тот, который не соблюдает субординацию, лезет не в своё дело и навязывает своё мнение. Тест дурацкий, что было понятно с самого начала.

                                                                  P.S. Ещё ответили, что у меня слабые знания языка. Ага, сразу. Я точно знал ответы на все вопросы по языку. Скорее всего, где-то в тесте ошибка.
                                                                    0
                                                                    Причём тут «не соблюдает субординацию»? Дать предложение непосредственному начальнику или стейкхолдеру, который ставит задачу, субординацию не нарушает.
                                                                      0
                                                                      Дать предложение — это не брать на себя ответственность за то, что не в твоей власти, как пишется в тексте выше.
                                                                        +2
                                                                        Мы против крайностей. И согласны с предыдущим оратором. Я знаю много компаний, в который «в твоей власти» много зон, где ты способен предлагать хорошие идеи, реально что-то сделать помочь и нести ценность. Насколько широк или узок этот круг и насколько жесткие у него границы — каждый зачастую решает сам.
                                                                          0
                                                                          Фига себе: решает сам! Представляю себе: решает так сотрудник, что он самый главный, приходит в кабинет генерального директора, и говорит: «теперь я всё решаю! Где там бюджет фирмы?» Вы правда думаете, что это так работает? Сразу видно, что вы плаваете в теме. Как вы тест составляли-то с такими тараканами? (Вопрос риторический.)
                                                                            0
                                                                            Вы удивитесь, но у нас в компании у сотрудников таки есть доступы к бюджетом. И любой разработчик может прийти (в том числе и к владельцу), и выдвинуть свои предложения о том, как этим бюджетам следует распорядится.
                                                                            И вполне возможна ситуация, что владелец скажет — окей, займись этим, т.е. выдаст ему все полномочия для проведения этих изменений. Для этого есть специальный механизм, и касается это даже джунов.
                                                                            Так что вы несколько ошиблись в том, кто плавает в теме.
                                                                              0
                                                                              И причём тут это? Это те доступы, которые выдали, а не те, которые были самовольно захвачены. Если владелец выдаёт полномочия, то с ответственностью проблем нет. Я же о другом. Что-то плохо у людей с определением границ…
                                                                                +1
                                                                                А границы далеко не всех радуют. Многие в них видят потолки) Не припомню, чтобы у меня лично или у кого-то из коллег возникали вопросы с полномочиями, когда они приходили с видением проблемы, аргументами, приносили решение и демонстрировали готовность действовать
                                                                                  0
                                                                                  Ну те доступы которые не выданы, ты вполне можешь запросить и получить. У нас нет вообще очень мало такого, что «тебе знать не положено». Любой человек может заниматься любыми вопросами. Это просто реальный пример по приведенному вами случаю, который приводился в пример, что «так не работает». Работает. И еще как. Не совсем так как приведено у вас конечно, но работает. Владелец выдает полномочия, когда ты сильно выходишь за рамки ответственности, и попадаешь на его «поле». Но если речь идет о бюджете департамента, то тоже будет происходить с руковдителем департамента.
                                                                                  Но границ нет. Есть зоны ответственности, но они никак не ограничивают в деятельности. Да, конечно, твои действия должны быть согласованы с тем, в чьих зонах ответственности ты действуешь, но это не граница, там нет запрета на пересечение.
                                                                                    0
                                                                                    «Да, конечно, твои действия должны быть согласованы с тем, в чьих зонах ответственности ты действуешь…»
                                                                                    Это и есть именно та граница, за пределами которой начинается гиперответственность. Просто по определению. И если её пересечь, несмотря на ясное «нет», то начнутся серьёзные конфликты. Как минимум, невротизм обеспечен.

                                                                                    В тесте этой границы вообще нет, она никак не обозначена. И это одна из его больших проблем. Тест по умолчанию подразумевает, что сеньор должен лезть всюду. И такая профанация там во всех вопросах, судя по результатам.
                                                                                      +1
                                                                                      Как я уже сказал, нет никакого «нет» на пересечение зон ответственности. Его и быть не должно. И да, человек должен лезть повсюду. Если человек видит проблему, знает как и хочет ее исправить, ничего не должно ему мешать. Наоборот — все должны ему помогать. Это не так часто происходит как хотелось бы, что бы еще какие-то ограничения вводить.
                                                                            +1
                                                                            Ограничение областей власти нынче не в моде )
                                                                    0
                                                                    Да даже не скажут, что софт-скиллов не хватает, в большинстве случаев так и не узнаете, по каким причинам, кроме недочетов в хард-скиллз ы не прошли. В этом и проблема, потому что в картине мира разработчика того о чем ему НЕ сказали так и не появилось. А значит нечего развивать и корректировать. Замкнутый на хард-скиллз круг.
                                                                0
                                                                Чтобы оценить уровень важно понять не только senior специалист или нет. Поэтому, как правило, компаниями даются задания для разных уровней — попроще и посложнее. А в последнее время, читая требования к вакансиям junior, мы и сами удивляемся — насколько много от них сейчас требуют. Здесь мы привели обзор всех требований. А тест укомплектовали заданиями разной степени сложности, чтобы видеть «оттенки» уровней.

                                                                Ну а ситуация «ты будешь лидом!», к сожалению, встречается. Из-за дефицита человеческих ресурсов, особенно, на верхнем уровне. Хотя у компании всегда есть выбор: например, нанять тимлида с рынка по соотвестующим критериям. Мы делали или так, или помогали развиваться: у нас была целая программа тренингов развития всех нужных навыков.
                                                                  +2
                                                                  ну просто формулировать надо точнее. А то «что такое синиор» и дальше набор требований не поймешь к какой позиции, что вроде и миддл тоже подходит. Весьма очевидно что этот набор должен по сути отвечать на вопрос «в чем разница между мидлом и сениором», и он на него не отвечает.

                                                                  Ситуация «ты будешь лидом» не просто встречается. Это повсеместная практика. Что бы не быть голословным — я довольно долго искал в Питере компанию, в которой этот вопрос был бы решен. И мне оказалось проще найти ее за пределами Питера, и привести ее на рынок, чем найти. А это уже по факту означает что можно считать что это не решено в городе вообще нигде.
                                                                  И дело не в наличии ресурсов. И мало всегда и везде, это в принципе лимитированная вещь. Дело в подходе. Нужно что бы к моменту, когда человеку придет время стать лидом, у него в голове уже должны быть необходимые опыт и знания. Видение. Он уже должен понимать что такое команда, что с ней делать, шарить в методологиях управления, и много чего еще. И при этом у него еще желательно должен быть какой-то маломальский опыт в этом. Для этого в компании должна быть очень продвинутся система роста людей и управления, работающая на опережение. А у нас обычно реактивное управление, никто ничем не занимается, пока петух не клюнет. Заранее даже на шаг не думают.
                                                                  «опыт, это такая штука, которая приходит сразу после того, как была нужна».
                                                                    0
                                                                    Маломальский опыт компании могут давать свои сеньорам относительно просто: разорвав основные прямые коммуникации между лидами(или ПМами) с джунами/мидлами, переведя последних в подчинению сеньорам, образовав мини-команды на 2-3 человека,
                                                                      0
                                                                      ну прям разрывать прямые коммуникации это так себе решение, саботажем отдает. Но да, так или иначе должна работать цепочка — лид работает с сеньорами, сеньоры с мидлами, мидлы с джунами, мидлы и джуны со стажерами.
                                                                      Но вот что бы это прямо реально работало нужно много условий. Нужна налаженная система менторинга, планов развития, аттестаций, бюджетов на обучение (как финансовых так и временных) и так далее. Нужна постоянная подпитка системы снизу, при том желательно со стажировки. В очень небольшом количестве компаний все это есть, и в еще меньшем количестве это не просто формальность, а реально работающий инструмент.
                                                                        0
                                                                        Речь исключительно о получении небольшого опыта управления и делегирования сеньорами. Например, команда из двух сеньоров, миддлов и джунов, а лид собрался на повышение через несколько месяцев. Лид работает с сеньорами, ставит им все задачи, а те либо сразу переназначают на своего миддла или джуна, возможно дополнительно что-то объяснив, либо декомпозируют задачу, что-то делая самостоятельно, что-то делегируя. У кого лучше получится, тот и будет новым лидом :)

                                                                        Вообще слышал совет такой: придя на руководящую должность, которая не является пределом твоих мечтаний, нужно с первого дня готовить себе заместителя из числа подчинённых. Это в том числе поможет убрать такое препятствие в карьере как: «да, ты потянешь эту должность, но я тебе её не дам, потому что на твоё место мне поставить некого, некому руководить твоей командой»
                                                                          0
                                                                          Когда компания переходит на стратегический уровень управления, на уровень прогнозирования бизнеса она начинает делать это и с персоналом: всегда на каждой ключевой должности должен быть #2. Руководитель на недельной страт.сессии? Рулит тимлид. Руководитель в отпуске, тимлид заболел — рулит самый крутой Senior или архитектор или тех.лид. Мы всегда исповедовали такой принцип. При нем компания вообще без руководителей отделов (хоть всех сразу) может спокойно проработать 2 недели. Иногда в операционном ключе — даже лучше))
                                                                            0
                                                                            Чтобы сеньор смог рулить у него должно быть хоть какое-то понимание как и зачем рулить :) Нередко это лучше поручить сеньору с самым крутым пониманием этого, а не самому крутому по техскиллам, который их имеет, потому что людей сторонится и всё свободное от работы время совершенствуется в них.

                                                                            Похвально, жаль что не все это исповедуют де-факто, даже если де-юре у всех замы есть.
                                                                              0
                                                                              мы это дополняем размазывая ведение проектов по всей шкале. Даем небольшие простенькие проекты вести регулярам. Тогда к сеньору он уже вполне готов заменить лида на время.
                                                                            +1
                                                                            Как по мне, это надо делать в любом случае, независимо от должности и собственных амбиций. Это позволяет спокойно уйти в отпуск недели на три или заболеть сосредоточившись на себе, а не на том, что там с проектом.
                                                                            Ну и опять же, если вдруг придется уходить (всякое бывает, например сделали предложение от которого сложно отказаться) можно уйти со спокойной совестью не отрабатывая месяца полтора.
                                                                    0
                                                                    Чтобы оценить уровень важно понять не только senior специалист или нет. Поэтому, как правило, компаниями даются задания для разных уровней — попроще и посложнее. А в последнее время, читая требования к вакансиям junior, мы и сами удивляемся — насколько много от них сейчас требуют. Здесь мы привели обзор всех требований. А тест укомплектовали заданиями разной степени сложности, чтобы видеть «оттенки» уровней.

                                                                    Ну а ситуация «ты будешь лидом!», к сожалению, встречается. Из-за дефицита человеческих ресурсов, особенно, на верхнем уровне. Хотя у компании всегда есть выбор: например, нанять тимлида с рынка по соотвестующим критериям. Мы делали или так, или помогали развиваться: у нас была целая программа тренингов развития всех нужных навыков.
                                                                    +5
                                                                    Поймался на любопытство, прошёл тест. Ответ пришлём на почту.
                                                                    Отличная компания сделала этот тест. Я думаю, в их коллективе хорошо относятся к сексуальным меньшинствам. Ну и разными другими достоинствами они тоже не обделены.
                                                                      –2
                                                                      Наша компания, безусловно, толерантна.
                                                                      Поэтому мы понимаем недовольство «ответом на почту») Для целей нашего проекта нам достаточно неавтоматизированной обработки результатов. Здесь мы привели наш тест в качестве примера и практической иллюстрации приведеных требований. Но все же поделимся интерпретациями со всеми, кому будет интересно.
                                                                      +1

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

                                                                        –1
                                                                        Почему автор статьи нарушает правила и использует нецензурную лексику?
                                                                          0
                                                                          Это Вы про цитату из песни?
                                                                            0
                                                                            я про слово «f@ck»
                                                                              0
                                                                              Уж больно песня была популярная, мы не удержались) Однако, спасибо за наблюдение, внесли правку
                                                                                0
                                                                                Не благодарите, никаких благих целей у моего замечания нет.
                                                                            0
                                                                            > потребление fuck считается непристойным и расценивается как оскорбление в официальных, политических и культурных кругах. С другой стороны, данное слово может быть воспринято спокойно и даже ожидаемо в неформальном общении, или же в либерально настроенных культурных группах.

                                                                            Что-то ничего про цензуру, и даже вряд ли можно сказать, что тут собрались официальные, политические и культурные круги.
                                                                              –8
                                                                              В случае, если автор не удалит это слово из статьи, я пожалуюсь на нарушение правил.
                                                                                +9
                                                                                Вам заняться нечем?
                                                                            +2
                                                                            Я например не могу по памяти написать оптимальный алгоритм быстрой сортировки. Не могу даже быстро написать оптимальный алгоритм опрееления простоты числа. Банально потому, что не сталкиваюсь с этим и использую более высокие абстракции. Алгоритмы знаю, могу на словах рассказать как что должно работать, но написать быстро не могу.

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

                                                                            Вопрос: кто я?

                                                                            Спрашиваю это к тому, что некоторые тесты, которые присылают компании в качестве предварительного этапа для отбора кандидатов, я не могу пройти, так как не хватате времени.
                                                                              0
                                                                              Такой эффект у Senior (потери скорости решения более простых задач), действительно, случается. В этом одна из проблем оценочных методик, особенно когда компания пытается оценить разработчика по 1-2 однотипным задачам. Поэтому, на наш взгляд, при оценке все-таки важно дать более широкий охват (разные блоки в тесте). Если кандидат прошел самые сложные задания и «так себе» — более простые, то это повод задуматься для работодателя, уточнить что-то на собеседовании. Ну а если нужен, к примеру, Junior+ и средний Middle, чтоб все горело в руках и быстро решались типовые задачи, то такие задания имеют право на жизнь
                                                                                0
                                                                                Ха, да, было такое на собесе. Приходишь собеседоваться на тимлимлида, говорят очень нам нужен тимлид. И первый вопрос — реализуйте три алгоритма сортировки за ограниченное время. Чето там пытаешься вспомнить, накорябаешь. А они смотрят, качают головой, нет, на лида не тянете. И не понимаешь, это лыжи не едут, или как.
                                                                                Было это кстати в одной очень известной компании. Выходишь такой и думаешь, ну и хорошо что не взяли.
                                                                                  0
                                                                                  Это как раз то, почему мы все же не рекомендуем на высоком уровне «забывать» про базовые хард-скиллы. Потому что, по-факту, в компаниях все равно на них смотрят, какого бы уровня вакансия не была. Меряют так серьезность отношения разработчика к своей подготовке. И часто никакой балансировки по степени сложности заданий, что усугубляет картину.
                                                                                    +1
                                                                                    А это вообще базовый хард скилл? Может для джуна да. Для школьника-олимпиадника, тоже да. Для тимлида? Я не могу это быстро сделать не потому что у меня мозги не варят. Я не могу это быстро сделать, потому что это знание не пригодилось мне ни разу за десять лет практики и целую кучу проектов самых разных видов. Мне даже сложно себе представить, где в современной разработке это может быть полезно.
                                                                                    Может быть, был бы я Си разработчиком (без плюсов, чистый Си), мне бы это и пригодилось. Но я питон разработчик. Любая ручная реализация сортировки заведомо медленнее чем [].sort() тупо из-за расходов на интерпретацию, другими словами никакой практической пользы не имеет.
                                                                                    Ну или для джуна или миддла еще приемлемо смотреть на «серьезность подготовки» по всякой ерунде. А если мы говорим о том, что даже старший разработчик должен иметь понимания бизнеса, то это уже не найм раба на галеру, где преданность в глазах должна быть. Это практически равноправная сделка, что уже говорить о ведущих разработчиках, которые частенько весь бизнес вывозят. Там подготовку по другим параметрам смотрят — погуглил ли он о компании, насколько меткие вопросы задает, внимательно ее изучает. И чем выше, тем больше вообще стоит вопрос — кто кого вообще собеседует. Начиная с определенной квалификации (особенно если есть чем ее подтвердить), то собеседование вообще наизнанку выворачивается.
                                                                                      0
                                                                                      Сначала нужно дать определение, что такое Тимлид в рамках конкретной компании. Это может быть, как Программист-звезда, так и Менеджер с техническим бэкграундом.

                                                                                      Было бы странно, если бы Программист-звезда не знал базовый computer science.

                                                                                      «Мне cs не нужен, всё уже есть в языке» — а потом можно посмотреть на одну из больших корпораций, например Одноклассники, где пишут, например, свои надстройки над базами, языками, виртуальными машинами и другим. А тут уже оказывается, что все алгоритмы придётся писать руками, а не брать из языка.
                                                                                        +1
                                                                                        А чего странного, в том что у человека не отскакивает от зубов то, что ему никогда не пригодится? В наше время разработчик-звезда и так должен знать столько всего, что ему реально нужно. Нужно и на низком уровне понимать, и на высоком, и сто пятьсот архитектур, баз данных самых разных. Нужно и в менеджмент уметь, и методики управления понимать, и в бизнес контексте понимать. Быть и немного психологом до кучи. Список длинный.

                                                                                        Не странно ли при всем при этом спрашивать у людей то, что реально никогда не пригодится, и делать это ключевым критерием отбора? По мне так это откровенно не адекватно.
                                                                                          +2
                                                                                          Аналогично, нанимая гендиректора, допустим, фармакологической фирмы, надо спрашивать его примерно такое: «А напишите-ка нам, милейший, формулу Диметилтриптамина» — и по этому судить о его компетенции в качестве генерального директора — ведь ему не хухры-мухры, ему с химией иметь дело!
                                                                                            0
                                                                                            Извините, а когда Тимлид стал не просто играющим тренером, а одним из топ менеджмента?
                                                                                              0
                                                                                              … и даже не о тимлиде: речь об оценке программистов всех уровней, чуть прицельнее — Senior. У тимлидов уже много совсем других критериев — более сложных hard и soft.
                                                                                                +2
                                                                                                Всё зависит от того, что вы хотите от тимлида, в какой пропорции и какова специфика. У человека так же ограничен ресурс знания, и держать абстрактное ВСЁ в актуальном состоянии — идеалистическая претензия. Недаром существует и разделение труда — иначе чем отличается ваш тимлид от любого другого программиста в команде. А работодатель это зачастую не понимает — отсюда монструозные списки требующихся навыков, написанных по принципу «всё-всё-всё, и еще вот это», когда из всего этого используется лишь часть и фрагментарно.

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

                                                                                                Это ли не безумие?
                                                                                                  0
                                                                                                  Ну на самом деле чем выше должность, чем больше тебе платят именно за знания, а не за деятельность. По сути по мере роста компании в сторону бирюзы (тут вроде оказалось достаточно много народу способных поддержать беседу в этом ключе), руководитель превращается из исполнителя в советника. И то чем он по сути занимается — это шарит знания, а не производит какую-то реальную работу. Они имеют гораздо большую ценность. Тимлид в таких структурах это самая верхняя из должностей кто реально еще может что-то делать руками, но должен уже стремится к тому, что бы перейти на следующую ступеньку, где ему этого не светит.

                                                                                                  Ну а монструозные списки требований как правило вылезают из размазанных зон ответственности. По факту обычно не известно точно, что нужно. Есть некоторая дыра которую надо закрыть, и тут уж кого найдут — тем и закроют. Т.е. список требований — это список пожеланий и не нужно к нему подходить как то, что нужно реально все это знать. Как правило ожидают до 75% покрытия.
                                                                                                  Ну, и опять же, планка критериев поиска всегда должна быть выше ожидаемого результата. Вы удивитесь по насколько безумным требованиям иногда удается находить реальных кандидатов, которые им удовлетворяют. А если не завышать ожидания, таких не найдешь.
                                                                                                    0
                                                                                                    Как и сказано в статье — под должностью Х всякий понимает что-то своё, и название «Тимлид» по большому счету ничего не дает для понимания как именно он будет тимлидить в конкретной компании — то ли будет ведущим программистом в основном, то ли будет архитектором, то ли будет ревьюировать, то ли тренировать, то ли что еще.

                                                                                                    Поиски универсальных волшебников — это, конечно, увлекательно и возвышенно, но как минимум непрактично — я это и хотел сказать своим комментарием.
                                                                                                  +2
                                                                                                  Даже для играющего тренера, ожидать знания всех формул на зубок странно. И чем больше вы ожидаете от него как от тренера, тем меньше очевидно следует ожидать технических знаний.
                                                                                                  Например если это тимлид плюс, который может уже не только тимлидить, а подхватывать и более высокоуровневые вопросы, то такой человек очевидно гораздо более ценен практически для любой компании. Таким подходом такие люди автоматом отсеиваются. А должно быть наоборот.
                                                                                                  0
                                                                                                  Здесь мы говорим не о Гендиректоре (он уже давно «в менеджмент»), а все-таки, скорее о Ведущих спецах-химиках фирмы. Ну и опять же — спрашивать-то можно. Вопрос только спрашивать ли только это или еще много чего и как интерпретировать. Мы отражаем как это интерпретируют компании. А сами мы смотрим — если по языковому блоку так-сяк, а по самым крутым и сложным здорово… Нам эта картина интересна (писали уже об этом выше). На собеседовании поговорим и уточним.
                                                                                                    +1
                                                                                                    Ну и даже в этом случае — это чаще всего следствие неразумных амбиций, вместо трезвого понимания — чем именно будет заниматься человек. Конечно, если вы ищете писателя сортировок — то да, нужен такой скилл. Но действительно ли этим и будет заниматься ваш нанимаемый спец? Вот о чём речь.
                                                                                                      0
                                                                                                      Кажется, мы говорим о разных вещах. Вы — о конкретных требованиях к конкретной позиции с конкретной спецификой и должностями обязанностями, а мы — в целом об оценке уровня программиста. Оценка для конкретной позиции с требованиями для конкретной компании — одно, а в целом чем оперирует специалист и в какой степени, а чем нет — это другое. Скорее мы видим общую картину и дальше уже имеем дело с требованиями. Определяемся — для какой позиции и 0% ничего страшного, а для чего и 70% — мало. Если нам нужен Middle — набор процентов по одним блокам, Senior — другой по другим.