Собеседуем кандидата на должность Senior Software Developer

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

    Что за птица — Senior?


    Итак, Senior Software Developer(aka Старший Разработчик) — это разработчик со значительным опытом(от 5 лет) и глубокими знаниями в коммерческой разработке софта. Опыт работы разработки за деньги — это необходимое, но недостаточное условие. Обязательно нужно поучаствовавать в каком-нибудь проекте уровня Enterprise, а если еще и с самого начала — вообще прекрасно, это дает незабываемый опыт и широкий кругозор. Senior от Middle отличается прежде всего тем, что может довести любую задачу до состояния production-ready. Он четко знает, что можно сделать, а что нельзя. Способен уловить момент, когда в ПО пора делать рефакторинг или просто переписывать с нуля. Пишет достаточно качественный код без критических и архитектурных ошибок.

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

    Основная цель собеседования


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

    Кто должен собеседовать?


    Здесь единственно правильный ответ — непосредственный будущий начальник aka Team Lead. Частая ошибка — собеседовать по 2-3 человека со стороны собеседующего, задавая перекрестные и непоследовательные вопросы. Это все создает ненужный стресс для собеседуемого и мешает установлению психологического контакта.

    Атмосфера


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

    Узнаем компетенции


    Как я уже написал в «Целях», важно узнать сильные стороны собеседуемого, с чем он работал ранее, на чем съел собаку, какие подходы использовал, какие челенжи встретил по дороге.

    Ключевые компетенции для Senior-разработчика:

    • Алгоритмы.
    • Архитектура, шаблоны проектирования.
    • Базы данных.
    • Параллельное выполнение и синхронизация работы процессов.
    • Основы производительности ПО.
    • Дебаг и логирование.

    Для разработчика важную роль играет понимание как это работает, знание концепций и особенностей, нежели знание конкретного инструмента. Например, если он досконально разобрался с MySQL, то ему не составит большого труда разобраться и с Postgres. В большинстве случаев для разработчика уровня Senior не составит труда быстро изучить любой инструмент.

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

    • Каким образом используя SQL удалить одну строку, если под критерии выборки попадает больше одной?
    • Какой командой git откатить последний коммит?
    • Какие методы объекта Object в Java Вы знаете? Тут могут быть другие варианты в других языках — то, что хорошо знает собеседующий.

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

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

    • Почему люк круглый?
    • Как налить ровно 4 литра воды в одно ведро, если есть два ведра — 3 и 5 литров?
    • Решите какую-нибудь головомку, например соберите кубик Рубика.

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

    Ищем мотивацию


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

    Какие бывают мотивации:

    • Деньги. Самая популярная мотивация, но зачастую не принято в этом признаваться. Хорошо работает для семейных и тех, кто привык много тратить или очень хочется накопить.
    • Интересные задачи. Когда людям реально нравится их работа и они готовы работать сверхурочно и в выходные не требуя дополнительной оплаты.
    • Прокачать новые скилы. Индустрия не стоит на месте и постоянно приходится их прокачивать, чтобы оставаться востребованным на рынке труда.
    • Карьерный рост. Одна из главных мотиваций работы в стартапе.
    • Известная или хайповая компания. Возможность быть частью ее и пожинать плоды ее известности.

    Чего не стоит спрашивать у Senior Developer


    • Как работает редко нужный алгоритм XXX(например, quicksort). Зачем спрашивать то, что не нужно в повседневной работе разработчика, но гуглится за 5 секунд?
    • Владеете ли Вы несложным иструментом YYY(например git). Я еще не встречал разработчика, который бы не освоил базовые возможности git, нужные для повседневной работы, за день-два.
    • Умеете ли писать тесты. Вопрос со звездочкой. Сам процесс написания тестов — несложен, а вот научиться понимать, что именно нужно тестировать и в каком объеме — тут нужна длительная практика. На деле же достаточно одного опытного тестописателя в команде, который сможет контролировать этот процесс в эффективной манере.
    • Что такое Agile/Kanban/Scrum. Методологию, как будет вестись разработка, выбирает Team Lead, соответственно рядовым исполнителям знать ее досконально не обязательно, а базовые принципы постигаются за считанные дни.

    Типы Senior-разработчиков


    Чтобы понять мотивацию и способности конкретного разработчика, необходимо выделить типы, ему присущие. Я выделил следующие, часто встречающиеся типы:

    • Креативщик или Увлеченный. Его прет от самой работы, нетривиальных задач, там, где нужно что-то изобрести. Иногда получаются велосипеды, но с ростом компетенций производит весьма качественные продукты. Основная мотивация — интересные проекты и задачи.
    • Рутинщик. Способен выполнять весьма рутинную работу не снижая производительности со временем и не требуя какой-либо мотивации.
    • Супергерой. Выполнит задачу любой ценой, даже если не хватает компетенций и времени. Часто лепит из говна и палок но с ростом компетенций получается что-то более-менее приличное. Очень ценный для стартапов и требовательных начальников.
    • Грамотный. Его на мякине не проведешь, хайпом не обманешь, всегда старается постичь суть технологий и задач, мыслит глубоко и структурно. Ценный сотрудник в любом проекте.
    • Поверхностный. Нахватается умных слов, подходов, изучит(поверхностно) хайповые технологии и тулзы и пытается все это применить в проекте, насыпая большими горстями, даже если можно обойтись малым. Свойственно на заре карьеры и просто ведомым и впечатлительным товарищам.
    • Заложник настроения. Есть настроение — работа так кипит, что только подноси снаряды, нет настроения — больше будет делать задумчивый вид и философствовать, чем работать.
    • Карьерист. Четко нацелен на карьерный рост. Нет роста больше года — потенциальный кандидат на вылет.
    • Консерватор. Любитель стабильности и традиций, негативно относится ко всем этим новомодным штучкам, инструментам и подходам.
    • Манимен. Работает там, где больше платят, поэтому лояльность к компании довольно низка. Любит премии, бонусы, бесплатные ништяки и прочие финансовые мотивации.

    Зачастую, у конкретного индивидуума сочетается несколько типов в различных пропорциях. Со временем типы и их пропорции у человека изменяются, а также есть индивидуумы, которые могут адаптироваться под задачи(свойственно Супергероям). Замечено, что с возрастом доля Консерватора растет у многих, Креативщик может выгореть, а Поверхностный может вырасти в Грамотного.

    Психологическое состояние


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

    Нередко встречаются такие состояния:

    • Жизнь — тлен. Иногда бывает так, что написанный код не идет в production по каким-то причинам (например по бизнес-решениям) или живет недолго(стартап или неумелое управление). Это серьезно деморализует со всеми вытекающими. Тут надо не путать со здоровым обычным цинизмом ввиду опыта работы.
    • Постигший дзен. За годы в статичном Enterprise-проекте разработчик изучает его вдоль и поперек и у него складывается ощущение, что он теперь редкий специалист. На самом деле его навыки и умения за пределами этого проекта почти не стоят ничего, налицо переоценка своих возможностей разработчиком.
    • Недооцененный и неуверенный. Череда неудачных проектов, плохого управления и прочих рисков заставляют разработчика сомневаться в своих способностях и умениях, хотя на деле он может оказаться весьма способным и ценным сотрудником. Часто недооценивает себя по зарплате и/или должности.
    • Переоцененный. В контраст недооцененному и неуверенному этот индивидуум словил удачный проект или серию, который прошел крайне удачно и на этой волне сильно переоценивает свои способности и возможности.

    А как же тестовое задание?


    Проблема в коротком тестовом задании(2-3 часа) в том, что по его результатам нельзя сделать никаких определенных выводов, обладает ли автор опытом разработки уровня Senior или нет. С таким же успехом Вы можете просто подкинуть монетку в воздух.

    Выводы


    По итогам собеседования должно сложиться объективное впечатление о разработчике:

    • Какие у него сильные стороны.
    • Как он может усилить команду.
    • Сколько ему времени нужно для выхода на «крейсерскую скорость».
    • Насколько желаемая зп соответствует вышеуказанным пунктам.
    • Есть ли психологический контакт и совместимость с командой.

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

    P.S. Все моменты в одной статье не изложишь, поэтому если у Вас есть вопросы или хотите что-то обсудить — пишите в комментариях или на email.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 151

      +9

      Статья хороша тем, что правильно убирает фокус от не нужных вещей, типа "НЕ спрашивать про частности, про конкретные инструменты, про люки".


      И содержит много полезных мелочей во вспомогательных темах (типа раздела "мотивация").


      Тем не менее, хотя на собеседовании важно ответить на 4 важных вопроса (типа "может ли кандидат работать на этой должности", "хочет ли работать на этой должности" и т.п.) ключевой раздел — компетенции — освещён недостаточно.


      То есть неплохо бы раскрыть более подробно как именно проверить знание алгоритмов, архитектуры… И не "от противного", а без этих "не", которыми полна эта статья.


      Так что было бы неплохо увидеть продолжение!

        +6
        боюсь проверить компетенции в мире ИТ практически невозможно. можно только построить гипотезу тк правильные ответы не дают гарантий, что человек умеет это применить, ровно как и не знание теории не говорит о непригодности. тут все очень сложно и строится на чистой субъективности
          +3
          Спасибо за предложение, возможно, следующая статья будет именно про оценку компетенций Senior-разработчика.
          +1
          Я бы чуть-чуть поправил пункт про «кто должен собеседовать». Все таки перекрестный опрос хоть и стресс, но моя практика показывает, что это наиболее эффективный способ задать правильные вопросы и правильно интерпретировать ответы на них. По мимо лида на собеседовании должен присутствовать hr (или грамотный манагер с пониманием психологии) и ещё кто нибудь из команды разработки. Что это даёт в сумме: у компании и команды есть возможность презентовать себя не одним лицом, что позволит собеседоемому чуть лучше понимать во что он хочет ввязаться. У команды же появляется возможность спросить самые многогранные вопросы в контексте и правильно понять ответы, принять коллективное решение. Если идти по пути я начальник — я все знаю (один в поле воин) можно что-то упустить, не так понять и пр человеческие факторы.
          Есть только одно требование к подобным собеседованиям: все представители команды должны работать как единый организм, а не тянуть одеяло на себя.
          Меня лично собеседовали и 5 технарей (вся дев команда) и солянка из представителей каждого организационного уровня. Что мне, как собеседуемому, позволяло понимать куда я попал и что будет дальше если принять оффер. В роли собеседующего (лида) за последние 2 года мы выработали практику, что в собеседовании участвуют минимум 2 технаря и всегда заранее обсуждаем некую стратегию чтобы не устраивать хаос. Не всегда, но частенько так же участвует hr дабы спрашивать другие правильные вопросы. После чего принимаем коллективное решение.
            +3
            Если Вы Тим Лид, то жизнь Вам дарит одну из интересных возможностей себя проявить — набрать свою команду, под свои нужды, видение, вкусы и личную совместимость. Помимо возможностей, тут есть конечно же и ответственность. Размывая или перекладывая ответственность за решения на других ставит Вашу компетенцию как начальника под сомнение. Возможно, Тимлидство просто не для Вас.

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

                Зачем накладывать на себя бремя разруливать конфликты нового члена команды из-за несовместимости со старыми, если это можно проверить на берегу?

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

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

                  0
                  Тестовые даете?
                    +8
                    Нет, тестовые не даем.
                    Я стараюсь больше уделять внимание тому, КАК кандидат мыслит, а не ЧТО он знает.
                    Конкретные знания конечно же важны, но в каком-то пределе, а вот умение мыслить — бесценно.
                    А тестовые не даем по нескольким причинам одна из которых — хорошие спецы в них не нуждаются и более того с высокой вероятностью сразу Вас пошлют при первом же намеке на тестовое (я и сам не люблю тестовые)
                      +2

                      А Мне вот дали тестовое и я не послал. Может я не senior? И тестовое было интересным и я понимал почему оно именно такое.

                        +2

                        у вас просто много времени или желания

                          +2
                          Есть еще такой момент — если ты, Google, то можешь давать тестовое.
                          Если обычная средняя компания, то давая тестовое, ты отсекаешь часть годных кандидатов.
                            0

                            Не факт. Есть и вторая сторона. На работу искал себе в команду мидла-сеньора — все как на подбор джуны оказываются. Ни знаний, ни умений, ни опыта.
                            Тестовое даём реально на 1-2 часа делать дома без ограничения по времени — оно отсекает около 90% джунов, желающих получать сеньорскую зп.

                              +1
                              100% джунов можно отсечь по CV и 5-минутному разговору по телефону.
                                +1
                                Всякое бывает. Может условия такие были, что мидлы, сеньоры мимо проходили.

                                При одинаковых условиях, для экономии своего времени, я сначала выбирал вакансии без тестовых задач. А то 10 конторам сделать тестовые на 1-2 часа уйдет часов 50, пока будешь стараться сделать как можно лучше и перепроверять.
                                  0
                                  Вы знаете, это очень отличается от того что я знаю из своего опыта или опыта близких знакомых. Я согласен с JordanoBruno в том, что резюме и 5-10 минут погооврить достаточно, чтобы отсечь явно не подходящих кадров.
                                  Как я понял, вы судите исключительно по тестовому заданию — и тут либо вы его даете просто всем (естественно, что 90% людей оказываются неподходящими) либо ваше мерило уровня не совпадает с общепринятым.
                                  Когда мы практиковали тестовое задание — до половины кандидатов его проходило… чтобы потом неприятно удивить на собеседовании. Поэтому сейчас я предпочитаю сессию парного программирования тестовому. Очень сложно правильно судить о специалисте только по его «искуственному» коду.
                                0

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

                                0
                                Т. е. можно дать тестовое, и если кандидат пошлёт откажется, значит хороший спец
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    0

                                    Мне както предложили поработать недельку а потом они мне скажут подхожу я или нет. Причем это стандартная практика у них.
                                    Компания довольно интересная, гео расчеты, свой супер компьютер (в 5ке самых мощных в южном полушарии), но как то нереалистично для не студентов.
                                    Вот они отсекают очень немало хороших кандидатов.

                                      0
                                      Ну, если по срочному договору – почему бы и нет?
                                      Или там строго бесплатно?
                                      0

                                      Имхо, одно дело тестовое для реально крутой компании а-ля Гугла, Яндекса, Амазона, Мейл.ру и совсем другое для Васи Пушкина.

                                  +3

                                  У меня есть три вопроса, и не только к автору, буду рад если увижу много ответов: сколько разработчиков в вашей практике покидали команду из-за некомпетентности (недостаточных знаний, медленной работы, большого количества ошибок)? Сколько из-за денег? Сколько по другим причинам?

                                    +1
                                    В хорошей комфортной команде, при адекватном отборе на собеседовании, при оплате как минимум по рынку и не на говнопроектах или стартапах текучка будет небольшая(5-10% в год). Многое зависит от возраста — молодые(до 30 лет) намного проще уходят. Причины ухода бывают разные, но весьма стандартные — деньги, хочется других и интересных задач, хочется карьеры, с кем-то не сработался и это критично, предложили более интересное/выгодное место. Нужных специалистов держат, тех кого несложно заменить — нет.
                                      +2
                                      Я так понимаю, что DrFdooch хотел услышать вашу статистику.
                                        +1
                                        Для полноценной статистики у меня нет достаточных данных. Также не всегда известна реальная причина ухода. Нередко бывает что это совокупность причин.
                                        0

                                        Спасибо, я так понял что из-за недостаточной квалификации практически ни с кем не приходится расставаться.
                                        А как вы определяете, держать спеца или нет?

                                          0
                                          Квалификация проверяется на собеседовании, если кандидат ее прошел — значит с ней проблем нет.

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

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

                                              А как вы отбираете людей на собеседование?
                                                0
                                                Первичный отбор — по резюме. Потом короткий звонок. Если все ОК — приглашение на техническое собеседование.
                                                  0
                                                  Еще 2.5 вопроса :)
                                                  Какой процент пришедших на интервью его проходит?
                                                  Есть не техническое интервью после технического? Какой процент проходит его?
                                                    0
                                                    Прошедших — немного обычно, не более 10 процентов. Хотя цифры условные и зависят от локации, бюджета, проекта, должности, дедлайнов…

                                                    После технического — только Background Check и далее Offer.
                                                    0

                                                    Смотрите ли всякие гитхабы? Если да, то насколько они влияют?

                                                      +1
                                                      Конечно, хотя что-то интересное нечасто бывает. В любом случае, код кандидата посмотреть надо во избежание неприятного удивления при работе.

                                                      Влияет самым непосредственным образом.
                                                        0

                                                        Помогает понять насколько чел соблюдает кодстайл и общий принцип его мышления по почерку.

                                                    0

                                                    Устроился 3 года назад в контору на ЗП мидла в нижней планке по городу, т.к. только переехал в крупный город и деньги физически заканчивались, а других офферов не было.
                                                    Сейчас я тут тимлид, фулстек, девопс, 3 человека в подчинении (сам набирал)… Сам с нуля поднимал и настраивал прод, жиру, гитлаб. Скрипты, вебхуки и прочее. Задачи раскидываю по команде, скрипты автоматизации писал…
                                                    … спросил за повышение хотя бы до уровня сеньора — сказали "у нас нет таких зарплат" и подняли на 10%. Обидно.
                                                    Так как уволить они меня не могут (понимают что контора раком станет моментально), постепенно ищу другое подходящее место с комфортными условиями и, желательно, сложными задачами, т.к. от админок для лендинга уже блевать хочется.

                                              0
                                              Я бы спросил «Когда и как вы поняли, что стали Senior разработчиком?»
                                                +3
                                                Лично я себя почувствовал сиром, когда я перестал искать задачи, задачи стали искать меня.
                                                  +9

                                                  Когда тебя взяли на эту роль другие люди.

                                                    +1
                                                    Между тем, как меня первый раз взяли на роль Senior, и моим полноценным осознанием своей «сеньорности»(и того, что её не было до этого), прошло порядка двух лет. До того я был достаточно сильным миддлом, который весьма неплохо справлялся с любыми задачами.
                                                      +2
                                                      тогда я стал сеньором в 22 года (10 лет назад). Как угодно хотели продать заказчику, лишь бы подороже. Мне смешно было слушать также какой я хороший сеньор когда я увольнялся в 24. А начал чувствовать после двух кейсов:
                                                      — решения нескольких нестандартных сложнейших задач (архитектурно-производительных)
                                                      — когда остался одним опытным разработчиком на проекте и все лежало на мне продолжительное время, соответственно научился ответственности
                                                      +7
                                                      Я бы перефразировал «Когда и как Вы поняли, что считая себя Senior Вы на самом деле не Senior?»
                                                        +2
                                                        Это конечно более тонкий вопрос, но мне кажется это может надавить на кандидата. Все любят говорить о своих успехах, а такая формулировка к синдрому самозванца ведёт, да и можно подумать, что тебя не хотят брать на Senior.
                                                        +7
                                                        Я ассессмент на галере прошёл, у меня и докУмент есть.
                                                          +2
                                                          Я вот до сих пор не знаю, кто я.
                                                          Вроде 5+ лет опыта есть — значит, сеньор.
                                                          С другой стороны, чем я занимался-то? Круды писал первое время, во фронт лазил, разве ж это опыт… Наверное миддл…
                                                          Хотя — последние несколько лет тяну проект, поднимал его вообще в одиночку, и вроде неплохо спроектировал — значит, всё же сеньор?
                                                          С другой стороны, проект-то так себе, внутри костыли, особо интересных задач нет, вокруг много таких же — кто угодно бы справился. Миддл?
                                                          Но опять же — уже на 7к рпс вышли, миллионы крутятся, куча технологий использована, наверное сеньор.
                                                          Но… Я же алгоритмов не знаю почти, паттерны программирования так и не изучил, какой я сеньор, так, миддл.
                                                          Но, мне же платят зарплату вполне себе сеньорскую по рынку, и повышают регулярно, со мной советуются другие разработчики, значит — сеньор?
                                                          Да блин, я за технологиями не слежу, более менее знаю только php, всё остальное по верхам нахватал, регулярно гуглю варианты — миддл?

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

                                                            Наверное, всё зависит от компании и того, какую роль Вы выполняете в команде. У одних ты можешь быть сеньором, а у других — средним мидлом.

                                                              0

                                                              Опять же, есть люди кто и 5, и 10, и 15 лет работает в какой-нибудь веб-студии или что-то сам пытается не совершенствуясь и оставаясь максимум на переходном состоянии из джуна в мидлы.
                                                              Так что время я бы лично вообще не учитывал в определении сеньорства да и любого другого статуса.

                                                                +1

                                                                Эта градация относительная, кто вы, зависит от вашего окружения.

                                                                0

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

                                                                +8
                                                                порой собеседующие не следуют основной цели собеседования — определить, будет ли разработчик полезен команде и насколько эта польза соотносится с затратами на данного разработчика. Вместо этого, собеседующий часто выявляет чего разработчик не знает, вместо того, чтобы выяснить, что он знает и умеет.

                                                                Это надо золотыми буквами сделать на всех видных местах, где проходят собеседования. Чтобы собеседующий всегда помнил. Наверное самое главное предложение из всей статьи. Спасибо автор :)
                                                                  0
                                                                  Может в начале каждого резюме писать) Как еще собеседующие это увидят?
                                                                    +2
                                                                    Эх, еслиб они его еще читали… А то как обычно «Мы внимательно изучили ваше резюме, бла бла бла» и следом вопрос «А вы работали с javascript?»
                                                                      +1
                                                                      Это да.
                                                                      У меня случай был, спрашивали вопросы только по шейдерам.
                                                                      Только после собеседования я понял, что им шейдерщик был нужен. Я бы и сам на эту позицию не пошел, т.к. игровую логику хотел писать, а не шейдеры.
                                                                      То что HR глянул резюме и увидел слово «шейдер», я не сомневаюсь. То, что его не читал собеседующий, я тоже не сомневаюсь.

                                                                    0

                                                                    Только это цель одной стороны, а не общая

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

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

                                                                        Ни разу еще мне не удавалось с помощью собеседований и тестовых заданий определить станет ли кандидат хорошим коллегой впоследствии…


                                                                        Понял лишь что если сразу что-то явно не нравится, то надо извиняться и вежливо расставаться.

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

                                                                          У меня есть один хороший пример: канидат на собеседовании показал себя понимающим и опытным разработчиком, но по факту оказался неспособен работать в условиях малейшей неопределенности (а это в нашей сфере, к сожалению, норма). В итоге любая задача без исчерпывающей спецификации, с которой Senior должен как раз справляться без проблем, растягивается в три-четыре раза — и 10% лишнего времени уходит на собственно уточнения требований, а 90% — на фрустрацию и прокрастинацию от безысходности. В итоге разработчик чувствует себя, извините, говном (а это плохо не только для него); менеджмент периодически полыхает; перестроить процесс, работающий для остальных — невозможно. Спасает только парное программирование, но применять его постоянно тоже не выход.
                                                                            0

                                                                            О! Практикуете парное программирование!? Через TDD? Это замечательная техника! Я как раз считаю что применять это надо постоянно.


                                                                            Если говорить про кандидатов, то 95% процентов из них показывают себя на собеседованиях вполне перспективно, а затем проваливаются в повседневной производственной коммуникации. Люди не устройства с совместимыми интерфейсами.


                                                                            Более-менее адекватная оценка для кандидата появляется после пары месяцев совместной работы в обычной обстановке. И ежедневное парное программирование наиболее этому способствует.

                                                                              0
                                                                              95% процентов из них показывают себя на собеседованиях вполне перспективно, а затем проваливаются

                                                                              Сергей, Вы точно что-то делаете не так на собеседованиях. Возможно, Вам стоит кардинально пересмотреть вопросы, которые Вы задаете. Предположу также, что Вы упускаете ключевые моменты из ответов кандидата.
                                                                                0
                                                                                О! Практикуете парное программирование!? Через TDD? Это замечательная техника! Я как раз считаю что применять это надо постоянно.

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

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

                                                                                          Как же тогда выбрать кандидата из всех, которые могут эффективно работать, а это практически все? — Попробуйте решить с вместе с ним какую-нибудь задачу, характерную для позиции. Найдите решение и усложните задачу. Потом усложните задачу до невозможности. Если вам нравится, что говорит и делает кандидат — берите его, не нужно собеседовать все. Вы не Гугл и никогда им не будете.
                                                                                            +3
                                                                                            А что делать если вы гугл/нетфликс/etc?
                                                                                              +11
                                                                                              Не пытаться искать ответы в комментариях на Хабре
                                                                                                0
                                                                                                Напишите свой хабр/Stack Overflow/etc и задавайте вопросы там :)
                                                                                                0
                                                                                                Очень интересный и дельный, на мой взгляд, подход! Некая имитация совместной работы как раз даст возможность собеседуемому «выдохнуть» и поработать.
                                                                                                  0
                                                                                                  Вы не Гугл и никогда им не будете.

                                                                                                  Я не был бы так категоричен. Гугл может позволить себе купить многие компании и покупает их.

                                                                                                    0
                                                                                                    Как понять, сможет ли кандидат эффективно у вас работать? — Очень просто, если он предыдущем месте проработал больше года, сможет и у вас.

                                                                                                    Ключевое слово — эффективно.
                                                                                                    Объективной информации о его работе на предыдущем месте у вас нет и не будет.
                                                                                                    Кандидата могли терпеть по каким-то своим причинам больше года.
                                                                                                    Теперь терпеть придется вам.

                                                                                                      0
                                                                                                      Можно взять телефон и позвонить. Не усложняйте.
                                                                                                        +1

                                                                                                        Можно. Но я не уверен что информация будет достоверна.
                                                                                                        В случае, если у человека был конфликт (и неважно по какой причине. Может, сотрудник был настолько ценный, что отпускать не хотели, и поэтому поругались) — вы услышите только негатив.
                                                                                                        Если конфликтов не было — услышите что-то нейтральное или хорошее. Вменяемый руководитель не станет сор из избы выносить.

                                                                                                          +1
                                                                                                          Значит, мы вернулись туда, где и были — нет ни одного способа узнать, насколько вам подойдет кандидат. Поэтому выгодная стратегия — оптимистично относится к людям.
                                                                                                            0
                                                                                                            Если конфликтов не было — услышите что-то нейтральное или хорошее.

                                                                                                            Смотря какой задавать вопрос.
                                                                                                            Самый главный вопрос, который надо всегда задать в процессе общения с предыдущим работодателем кандидата:
                                                                                                            «Вы бы взяли его себе обратно на работу, при условии, что у вас бы нашлась для него работа?»
                                                                                                            Если да — значит эффект в его работе был. Если нет — надо узнавать причину — возможно для вас это не проблема.

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

                                                                                                        Золотые слова, Юрий Бенедиктович!

                                                                                                        –1
                                                                                                        Похоже, что автор рассматривает собеседование именно с точки зрения подбора «своих людей» в «свою команду». Но бизнес — это не ваше, и это даже не моё, это чужое. Просто совсем левое.

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

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

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

                                                                                                        Какой из этого вывод? Да просто расслабьтесь. Не нервничайте по поводу глупых вопросов и всего того, из-за чего вы привыкли нервничать. Ну да, мальчик-джун очень хочет проявить себя и задаёт вам олимпиадные задачки, про которые он где-то читал. Ну так что в этом плохого? Он и обязан это делать, просто в полном соответствии со своим неокрепшим разумом и недостаточным опытом. На что тут жаловаться? На то, что вы не можете вспомнить, какой метод нужно дёрнуть для решения поставленной джуном задачи? Ну так и скажите — я хочу поглядеть документацию по такому-то классу, и через 5 минут отвечу. Если вы боитесь, что джун потом напишет негативный отзыв — не стоит нервничать! Вышестоящий начальник хорошо понимает, кого и куда он послал, поэтому решать всё равно будет субъективно, лишь частично опираясь на отзыв джуна. То есть просто действуйте спокойно, как вы привыкли, и пусть джун под вас подстраивается и потом покрывается, когда вы ему возражаете. Ну ведь просто же!

                                                                                                        Так что — расслабьтесь и не нервничайте. Но к собеседованиям, безусловно, готовьтесь. То есть если бы ко мне пришёл якобы сеньор, но поленившийся освежить в голове хотя бы основное по списку указанных в вакансии технологий — ну очевидно же, что он привык к лёгкой жизни на старом месте, не учил новые технологии, не готов банально почитать о том, чем придётся заниматься на новой работе. Именно поэтому возникает вопрос о его проф.пригодности. Не из-за каких-то субъективных факторов, а именно из-за неготовности чуть-чуть напрячься. Потому что новое место работы — это всегда некоторое напряжение, связанное с необходимостью учиться тому, чего на прошлой работе не было.

                                                                                                        Но даже моё возражение в куче контор никак бы не повлияло на субъективный выбор кем-то другим, так что опять же — расслабьтесь, не нервничайте, не попали в одну контору — попадёте в другую. А все эти собеседования — субъективная суета. Напрягают лишь если буквально жрать нечего, потому что денег нет. А во всех остальных случаях — не парьтесь. Но только при условии, что вы реально способны учиться и реально обладаете ценными опытом и знаниями.
                                                                                                          +3
                                                                                                          Кстати по поводу джунов, встречались такие собеседования да. Когда тебя собеседует человек, который несёт откровенную хню, и когда настает твой черед задавать вопросы, начинает дергаться и нервничать сам :) Как будто собеседующий пытается самоутвердиться в диалоге с тобой, выглядит это нелепо и смешно.
                                                                                                            0

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

                                                                                                            0
                                                                                                            А что посоветуете «мальчику-джуну», который не отличил манагера и спеца и теперь единственный прогер с кучей отвенственности? :)
                                                                                                              0
                                                                                                              Run, Forest, RUN!
                                                                                                            +1
                                                                                                            В кои то веки отличная статья про хайринг. Согласен почти со всем изложеным. Единственное замечание — кто-то из технарей в собеседовании все-таки должен учавствовать.
                                                                                                              0
                                                                                                              На сегодняшний день, понятие «рыночная стоимость» очень размыто, точнее не катируется среди многих разработчиков, т.к. в одном месте дают 2 яблока, а в другом 5… и это колличество часто никак не сходится с рыночными показателями.
                                                                                                              В связи с отсутствием необходимого количества кандидатур, пункт «Насколько желаемая зп соответствует вышеуказанным пунктам» становится очень критичным.
                                                                                                              Конечно же понятно, что бюджет на позицию ограничен, но порой будет больше толка от мидла с зарплатой сениора, чем будешь ждать подходящего сениора на белом коне — это как пример.
                                                                                                              Как Вы/вы считаете?
                                                                                                              Что говорит практика?
                                                                                                                0
                                                                                                                Это отдельная история — как нанять толкового сеньора, если бюджет ограничен.

                                                                                                                «Рыночная стоимость» определяется весьма просто — можете поинтересоваться у хедхантинговых агентств, за сколько набирали до Вас. Можете посмотреть в HH, сколько примерно предлагают. Также, первые же кандидаты Вам сами подскажут примерный рынок.

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

                                                                                                                Сейчас весьма распространен подход набора на удаленку, так как это сильно расширяет аудиторию и упрощает найм. Также нередко сотрудничают с бодишопами просто арендуя у них спецов.
                                                                                                                0
                                                                                                                а вот меня прям недавно спросили про методы у Object

                                                                                                                правда там и ещё было умных вопросов, но вот этот запомнился…

                                                                                                                а года 4 назад поинтересовались как перевозить какое-то зверьё в темноте через мост в лодке с фонариком и батарейки кончаются и река горит и вообще апокалипсис.
                                                                                                                  +1
                                                                                                                  зверьё в темноте через мост в лодке с фонариком и батарейки кончаются и река горит и вообще апокалипсис

                                                                                                                  Я даже боюсь представить, под какими препаратами это придумывалось и зачем им тут разработчик. Тут психиатр нужен.
                                                                                                                    0
                                                                                                                    думаю это была такая задача:
                                                                                                                    petruchek.info/problems/night-bridge-flashlight.html

                                                                                                                    там потом выяснилось что отпуск надо планировать за год, и всё такое, приходить к 9 утра, в общем не сложилось с ними, хотя 150тыр 5 лет назад было неплохо конечно…
                                                                                                                      0
                                                                                                                      Я ничуть не удивлюсь, что с такими задачами у них полно скелетов в шкафах. Я считаю, что разработчика нужно спрашивать про разработку.
                                                                                                                        +1
                                                                                                                        ага. Яндексу это расскажите.
                                                                                                                        0
                                                                                                                        Задача норм, только непонятен вопрос про минимальное время. Если за ними кто-то гонится, то мост надо переходить друг за другом гуськом и как можно быстрее :)
                                                                                                                      0
                                                                                                                      Меня как-то раз один умник спросил про теорему Чёрча-Росса про ламбда исчисление. После этого забил на всякие интервью и начал делать свой проект, чтобы никому ничего не доказывать.
                                                                                                                      +1
                                                                                                                      про кубик-рубик зачет! никогда не понимал такого. я будут тестером головоломок или сениор девелопером? как это умение поможет мне как-то в работе?
                                                                                                                      возвращаясь к кубику Рубика. у нас с сестрой в детстве был такой способ его сборки: после 1-2 ударов им об стену, у него выпадывал угол, после чего его можно было разобрать и вставить правильно все цвета. данная операция занимала несколько минут. то же самое с пирамидкой, но там выбить компонент было сложнее.
                                                                                                                        0
                                                                                                                        Сразу видно нестандартный подход к решению задач — надо брать!
                                                                                                                        0

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


                                                                                                                        На мой взгляд решение — только под ответственность тимлида (они должны быть на одной волне) и чётко оговоренный испытательный срок.

                                                                                                                          0
                                                                                                                          Полдня кодинга в офисе вполне могут включать в себя вариант парного программирования, чтобы понять, как человек ведет разработку. Здесь смысл — не закодить что-то, а продемонстрировать владение навыками разработки на уровне Senior, чтобы потом тимлиду не было мучительно больно за принятое решение. Можно даже без непосредственного кодирования, а просто взять какой-нибудь код и послушать кандидата, что в нем плохо, что хорошо, что стоит переделать и как.
                                                                                                                            +1
                                                                                                                            Ну не знаю, я вот сам никогда не применял нигде парного программирования. Если я приду на собеседование и ко мне подсядет чувак, который будет меня палить, то мне будет как-то не по себе… почему так — часто, когда решаешь задачу, то сначала пишешь код который минут через 30 возможно придётся переписать. Но со смотрящим рядом ведь хочется не ударить в грязь лицом и из-за этого будет сильный дискомфорт. Разве нет?
                                                                                                                              0
                                                                                                                              Да не вопрос, нравится кодить одному — Ваше право. Задача — посмотреть на Вашу работу в комфортной среде, а не создать стресс, как делают некоторые.
                                                                                                                          0
                                                                                                                          >> Тут могут быть другие варианты в других языках — то, что хорошо знает собеседующий.

                                                                                                                          А вот это как раз вкорне неверно и очень даже вредно спрашивать то, в чем Вы сами хорошо разбираетесь и на данный момент в контексте.
                                                                                                                          Ну вот разобрался я на последней неделе в библиотеке какой-то, держу в голове часть документации и не лезу раз за разом в гугл. С какой стати собеседуемый должен держать в голове то же самое?
                                                                                                                            0
                                                                                                                            Первый раз вижу настолько хорошую статью о себеседовании.
                                                                                                                              +2
                                                                                                                              Senior, которого прет от работы и которому нужны интересные задачи, а не деньги — это, конечно, очень ценный кадр, но, боюсь, в природе он встречается не часто.
                                                                                                                              Проблема в том, что интересных задач обычно мало, а рутины много. И сложную рутину тоже надо кому-то делать, спихнуть всё на низовой состав нереально. Поэтому senior со временем привыкает к тому, что интересные задачи приходят и уходят, а деньги — штука хорошая и их платят за разную работу, в том числе и не очень то интересную. Другое дело, что если процент неинтересной работы на конкретном месте начинает зашкаливать, senior это терпеть не будет даже ради денег. )
                                                                                                                                +1
                                                                                                                                Поддержу. В моем видении сеньора это одно из основных качеств — практически одинаковая производительность и на интересных задачах, и на рутине.
                                                                                                                                  0
                                                                                                                                  Я таких людей не встречал — с одинаковой производительностью. Возможно Вам повезло больше, не исключаю.
                                                                                                                                    0
                                                                                                                                    Не, про одинаковую производительность я не говорил. Просто сеньор уже пожил и понимает, что рутиной тоже надо заниматься, даже если очень не хочется. И он занимается. Не так, чтобы прям с песнями, но куда деваться.
                                                                                                                                    0
                                                                                                                                    Часто за неинтересные задачи платят сильно больше именно поэтому. Например — кто-то видел хоть одну систему без отчетности? Не самая интересная работа, казалось бы, а на рынке-то не протолкнуться от конкурирующих продуктов.
                                                                                                                                    0
                                                                                                                                    А насчёт быстрого освоения — всё верно. Меня на нынешнюю работу взяли не смотря на то, что я не знал async/await, а он тут был нужен. Освоил это дело за несколько дней и активно стал применять. Никаких проблем. Внутренне был готов к концепции, просто не было надобности ранее. Как столкнулся — легко изучил.
                                                                                                                                      +2

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

                                                                                                                                        0
                                                                                                                                        Если Вы имеете ввиду какую-нибудь классику из кнутовской серии, то это крайне редко нужно на практике. Под алгоритмами на собеседовании подразумевается насколько эффективно разработчик воплощает задачу в коде. Это нужно для того, чтобы понять, являются ли алгоритмы его сильной стороной или нет.
                                                                                                                                          +1
                                                                                                                                          И зачастую на собеседования «сами знаете куда» дают олимпиадные или около задачки. На основании которых определяют человек умеет или не умеет в алгоритмы.
                                                                                                                                          А я рад был бы увидеть примеры алгоритмических, но не олимпиадных задач, которые могут показать, что разработчик справится с алгоритмами для средних задач в жизни. Есть примеры?
                                                                                                                                            0
                                                                                                                                            Проверка строки на палиндром: leetcode.com/problems/valid-palindrome
                                                                                                                                            Слияние связных списков: leetcode.com/problems/merge-two-sorted-lists (под вопросом степень олимпиадности)
                                                                                                                                            Можно упростить предыдущую задачу сделав слияние двух сортированных массивов с использованием дополнительной памяти. Обычно таки у нас нет возможности сливать массивы in-place.
                                                                                                                                            Идентичность бинарного дерева: leetcode.com/problems/same-tree
                                                                                                                                            Написать свой Cross/Left/Right Join для двух списков неких объектов по заранее заданному полю.

                                                                                                                                            P.S.: Let's holy war begin!
                                                                                                                                              0

                                                                                                                                              А примеры то какие? Для чего это постоянно в бизнес задачах?

                                                                                                                                                0
                                                                                                                                                Проверка строки на палиндром — базовый пример аккуратной работы с массивами и фильтрации данных. По сути задачка на один цикл и три ветвления, работу с ними и проверяет.
                                                                                                                                                Слияние связных списков или массивов — вот для него сложнее всего подобрать пример. Надо подумать еще.
                                                                                                                                                Идентичность бинарного дерева — по сути кастомный equals для объектов со сложной структурой.
                                                                                                                                                Join по ID — стандартная задача по построению некой модельки, по которой будет рендерится отображение, на основании данных из двух или более источников. В наш век микросервисной архитектуры вполне себе частая история должна быть.

                                                                                                                                                Тут еще стоит уточнить, что подразумевать под бизнес задачами.
                                                                                                                                                Если это только вызвал API и ответ без преобразования отправил дальше — то никак не соотносится, разумеется.
                                                                                                                                                  0
                                                                                                                                                  Давайте по-другому. Пускай не бизнес задача. Задача, которую необходимо решать относительно часто и для решения которых нет уже готовых инструментов из «коробки»
                                                                                                                                                    0
                                                                                                                                                    Тогда можно использовать 1, 3 и 4 задачи. На мой взгляд проверяемые ими навыки вполне себе подходят под «относительно часто без готовых инструментов».
                                                                                                                                        0

                                                                                                                                        Так как налить ровно 4 литра при вёдрах 3 и 5 ?

                                                                                                                                          +1
                                                                                                                                          Пусть, в3 — ведро 3л, в5 — ведро 5л
                                                                                                                                          1) Наливаем в в3 и выливаем в в5
                                                                                                                                          2) Наливаем еще в в3 и выливаем в в5 пока не заполнится. В в3 остается 1л.
                                                                                                                                          3) Опустошаем в5 и переливаем туда 1л из в3
                                                                                                                                          4) Наливаем в в3 3л и выливаем это в в5 с 1 л, получаем 4л.

                                                                                                                                          p.s. сори если это был сарказм и я не в тему, просто пролистал комменты до конца и ваш был последний
                                                                                                                                            0
                                                                                                                                            А не проще ли налить по полведра? 2.5+1.5=4, это если конечно возможно «половину» определить.
                                                                                                                                              0
                                                                                                                                              Понятно. Не подумал что можно просто вылить из ведра на землю. Думал, что уже налитое можно переливать только между ведрами
                                                                                                                                                0

                                                                                                                                                Я тоже так подумал, кстати.

                                                                                                                                                +1
                                                                                                                                                вариант
                                                                                                                                                Пусть, в3 — ведро 3л, в5 — ведро 5л
                                                                                                                                                1) Наливаем в в3 и выливаем в в5
                                                                                                                                                2) Наливаем еще в в3 и выливаем в в5 пока не заполнится. В в3 остается 1л.

                                                                                                                                                Задача получения 1л решена.
                                                                                                                                                Оформляем результат решения задачи в виде функции.
                                                                                                                                                Выливаем отладочный результат 1л из в3.
                                                                                                                                                Для в5, вызываем функцию получения 1л, 4 раза в цикле последовательно или в 4 параллельных потоках.
                                                                                                                                                  0
                                                                                                                                                  У вас получилось восемь этапов, если разделить на отдельные действия.
                                                                                                                                                  Задача решается за шесть)
                                                                                                                                                  решение
                                                                                                                                                  1) наливаем в в5
                                                                                                                                                  2) переливаем из в5 в в3 сколько влезет(в в5 остаётся 2л)
                                                                                                                                                  3) выливаем в3
                                                                                                                                                  4) переливаем из в5 в в3 2л
                                                                                                                                                  5) наливаем в в5
                                                                                                                                                  6) переливаем из в5 в в3 сколько влезет (1л), в в5 осталось 4л.

                                                                                                                                                    +1
                                                                                                                                                    Вот к слову, хороший пример. Есть два человека, один решил эту задачу за 8 шагов, другой за 6.
                                                                                                                                                    Можно ли сказать, что последний будет работать эффективней на 25%? Нет.
                                                                                                                                                    Можно ли сказать, что последний умней на 25%? Тоже нет.

                                                                                                                                                    Таким образом, польза от подобных единичных задач неочевидна. Для каких-то корректных выводов таких задач нужно дать минимум сотню.
                                                                                                                                                0
                                                                                                                                                Я провел не одну сотню собеседований как с одной стороны, так и с другой.
                                                                                                                                                А когда вы работать-то успеваете? «Собеседование» (job interview) со стороны нанимающегося на работу длится от 4 до 8 часов, «не одна сотня» (допустим, две сотни) займет у вас 6 * 200 = 1200 часов, т.е. практически два месяца рабочего времени.

                                                                                                                                                например — полдня кодинга непосредственно в компании, оплаченные по средней ставке
                                                                                                                                                Это ваша юношеская мечта, что-ли? По какой статье расходов будете проводить оплату в бухгалтерии? ;)
                                                                                                                                                  0
                                                                                                                                                  1) Классическое собеседование длится не больше часа. Иногда меньше, иногда больше.
                                                                                                                                                  2) Вопрос оплаты в нормальных конторах проблемой не является.
                                                                                                                                                    0
                                                                                                                                                    1) Не знаю, что такое «классическое собеседование» (это, что-ли, как Сократ Платона в ученики собеседовал?), но обычно час длится для интервьюера, но отнюдь не для интервьюируемого. Самое короткое собеседование в моей, не выдуманной ради красного словца, а реальной, 30-летней карьере (из них 23 года в Штатах), длилось примерно полтора часа (из них час ушел на совместную отладку с software architect-ом предложенного мною неожиданного решения задачи), а самое длинное, что могу припомнить, 8 часов (с часовым перерывом на ланч) в Amazon-е.
                                                                                                                                                    2) Вы как-нибудь все-таки у бухгалтера сначала поинтересуйтесь, прежде, чем чушь писать. И дело вовсе не в наличии или отсутствии у «конторы» денег.
                                                                                                                                                      0
                                                                                                                                                      Вы как-нибудь все-таки у бухгалтера сначала поинтересуйтесь, прежде, чем чушь писать.

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

                                                                                                                                                    где-то сейчас заплакал один молодой скрам-мастер и засмеялся (зловеще) аджайл-коуч в галстуке.
                                                                                                                                                    0
                                                                                                                                                    Статья очень понравилась. Согласен практически со всеми пунктами.
                                                                                                                                                    Если автору будет интересно описать метаморфозы сеньора девелопера, происходящие с ним по мере старения, то с удовольствием прочитаю.
                                                                                                                                                      0
                                                                                                                                                      Про метаморфозы интересно. У меня по молодости, когда только начинал, была тяга ко всему новому: быстрая смена стеков, проектов, хотелось попробовать что-нибудь новое и тд. Сейчас по прошествии лет пришло некое умиротворение и спокойствие. Не хочется скакать по проектам, менять стеки, хочется чего-нибудь стабильного, чтобы на долгие годы и в спокойном темпе, благо нет скрама и удалёнка позволяет :))
                                                                                                                                                        0
                                                                                                                                                        Хороший вопрос.
                                                                                                                                                        Чем старее разработчик — тем более консервативен он становится. Вплоть до полного отрицания новых технологий, особенно, если старый стек до сих пор востребован(например, Java 7-8). Плюсом такой консервативности можно считать то, что в старом стеке он плавает как рыба в воде.
                                                                                                                                                        Еще минус возраста то — что тимлиды моложе их встречаются чаще, иногда существенно моложе. Для тимлида 30 лет морально тяжело работать с разработчиком 45 лет, а разработчик с высоты своего опыта и возраста старается давить на него, что вызывает дискомфорт в отношениях. Поэтому старички-разработчики обычно мигрируют в Enterprise и там вполне комфортно себя чувствуют до пенсии.
                                                                                                                                                        0
                                                                                                                                                        Напомнило об очень интересной статье от одного из менеджеров в microsoft о том, как они поменяли процесс собеседования:

                                                                                                                                                        blog.usejournal.com/rethinking-how-we-interview-in-microsofts-developer-division-8f404cfd075a

                                                                                                                                                        tl;dr: вместо шаблонных вопросов решают вместе с кандидатом реальную задачу во всей её полноте, начиная с работы с требованиями и т.п.
                                                                                                                                                        Лично мне такой подход крайне импонирует и, думаю, даже провал такого собеседования будет ощущаться лучше т.к. человек сам увидит, что не справился, не разобрался, etc и как минимум получит полезный опыт. Куда полезнее заучивания всех «принципов ООП».
                                                                                                                                                          0

                                                                                                                                                          А какие у вас появляются дополнительные требования, если вы ищите Lead developer, а не Senior developer?

                                                                                                                                                            +1
                                                                                                                                                            Lead — это фактически маленький тимлид, то бишь есть некоторые разработчики(часто — middle или junior), для которых он мининачальник. Если вкратце — то лиду нужны навыки менеджерства, наставничества, педагогики. Соответствующие вопросы и надо задавать для их выявления. Если же в подчинении у него нет разработчиков, то по факту — это продвинутый Senior и требования к нему те же, что и к обычному.
                                                                                                                                                            0

                                                                                                                                                            Относительно недавно проходил собес как раз на сеньора.
                                                                                                                                                            Из краткого: закидали терминологией (solid, dry, kiss, di, инкапсуляция и т.п.) из "умных" слов. Сразу сказал что у меня теория хромает, зато на практике реально много чего могу. Как ещё не спросили "что такое ООП"…
                                                                                                                                                            В сумме около трёх часов разговаривали (так получилось).
                                                                                                                                                            Дали тестовое. Сделал чтоб не стыдно было. Сказали "офигеть как шикарно", но на работу не позвали.
                                                                                                                                                            При этом, с девчонкой HR неплохо поболтали.
                                                                                                                                                            Ну, нет так нет.


                                                                                                                                                            На другом собесе задачу дали на листочке написать:
                                                                                                                                                            Не используя условные операторы при передаче в функцию числа "1" вернуть "2", а при передаче "2" — вернуть "1".
                                                                                                                                                            Я с такими задачами не сталкивался и честно пытался решить около пяти минут — не смог. Зато придя домой всего за 15 секунд написал рабочее решение не открывая Гугла:
                                                                                                                                                            function get($num)
                                                                                                                                                            {
                                                                                                                                                            return ($num | 2) — 1;
                                                                                                                                                            }

                                                                                                                                                              0
                                                                                                                                                              return 3 — x?
                                                                                                                                                                +1
                                                                                                                                                                мне такое первым в голову пришло:
                                                                                                                                                                return 1+!(num-1); // js код
                                                                                                                                                                Но задача дурацкая. Максимум какую инфу получат — сообразил ли кандидат в данный момент или нет.
                                                                                                                                                                А решение выше (return 3 — x), классное!)
                                                                                                                                                                  0

                                                                                                                                                                  Как насчёт get(x) = 3-x ?

                                                                                                                                                                  0
                                                                                                                                                                  Спасибо большое за пост. Очень грамотная и систематизация и полезные акценты.
                                                                                                                                                                  Хотел бы добавить вам в копилку пару идей из своей практики…

                                                                                                                                                                  Как известно, правильно поставленный вопрос — это половина решения проблемы. Поэтому люди, умеющие задавать правильные вопросы, как правило, и хорошо умеют эти проблемы решать. Если есть желание и возможность — попробуйте «собеседование наоборот»: пусть кандидат экспромтом попробует вас самих взять на работу:) Ну, во всяком случае, это может быть весело. Как минимум, нестандартность приёма иногда позволяет снимать стресс…

                                                                                                                                                                  И ещё не стоит сбрасывать со счетов «любителей дурацких вопросов»...99% из них и вправду дурацкие, т.к. ответы на них не говорят ровным счётом ничего полезного. Тем не менее, если привлечь на помощь научно обоснованные достижения современной психологии, то кой-какие полезности из их арсенала вполне можно использовать… Например, такие вот простенькие тесты «на когнитивное отражение». Обоснование зачем это и почему может быть полезно популярно рассказано вот тут.

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

                                                                                                                                                                  Самое читаемое