Что за птица — 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.
Комментарии (142)
Magikan
10.12.2019 23:56Я бы чуть-чуть поправил пункт про «кто должен собеседовать». Все таки перекрестный опрос хоть и стресс, но моя практика показывает, что это наиболее эффективный способ задать правильные вопросы и правильно интерпретировать ответы на них. По мимо лида на собеседовании должен присутствовать hr (или грамотный манагер с пониманием психологии) и ещё кто нибудь из команды разработки. Что это даёт в сумме: у компании и команды есть возможность презентовать себя не одним лицом, что позволит собеседоемому чуть лучше понимать во что он хочет ввязаться. У команды же появляется возможность спросить самые многогранные вопросы в контексте и правильно понять ответы, принять коллективное решение. Если идти по пути я начальник — я все знаю (один в поле воин) можно что-то упустить, не так понять и пр человеческие факторы.
Есть только одно требование к подобным собеседованиям: все представители команды должны работать как единый организм, а не тянуть одеяло на себя.
Меня лично собеседовали и 5 технарей (вся дев команда) и солянка из представителей каждого организационного уровня. Что мне, как собеседуемому, позволяло понимать куда я попал и что будет дальше если принять оффер. В роли собеседующего (лида) за последние 2 года мы выработали практику, что в собеседовании участвуют минимум 2 технаря и всегда заранее обсуждаем некую стратегию чтобы не устраивать хаос. Не всегда, но частенько так же участвует hr дабы спрашивать другие правильные вопросы. После чего принимаем коллективное решение.
JordanoBruno Автор
11.12.2019 02:17Если Вы Тим Лид, то жизнь Вам дарит одну из интересных возможностей себя проявить — набрать свою команду, под свои нужды, видение, вкусы и личную совместимость. Помимо возможностей, тут есть конечно же и ответственность. Размывая или перекладывая ответственность за решения на других ставит Вашу компетенцию как начальника под сомнение. Возможно, Тимлидство просто не для Вас.
А уж привлекать на техническое собеседование HR — это с какой целью? Разработчики, а тем более высококвалифицированные, мягко говоря, бывают весьма нестандартными людьми. У них могут быть свои нюансы в общении и мышлении, что может показаться HR-специалисту подозрительным, он будет против них и отсеет вполне годных кандидатов.
anticyclope
11.12.2019 06:54Тимлид с презумпцией того, что HR не способен разбираться в рамках своей компетенции, похож на «познавшего дзен».
VolCh
11.12.2019 14:06Зачем накладывать на себя бремя разруливать конфликты нового члена команды из-за несовместимости со старыми, если это можно проверить на берегу?
dimm_ddr
11.12.2019 17:38А уж привлекать на техническое собеседование HR — это с какой целью? Разработчики, а тем более высококвалифицированные, мягко говоря, бывают весьма нестандартными людьми. У них могут быть свои нюансы в общении и мышлении, что может показаться HR-специалисту подозрительным, он будет против них и отсеет вполне годных кандидатов.
Собственно это же и есть прямая обязанность HR: управлять людьми и одна из сторон этого управления — оценивать кто впишется, а кто — нет. Если вы считаете что ваш HR не способен правильно оценить разработчика, то либо вы неправы, либо у вас некомпетентный в своей области HR.
alekciy
11.12.2019 06:35Тестовые даете?
Magikan
11.12.2019 07:27Нет, тестовые не даем.
Я стараюсь больше уделять внимание тому, КАК кандидат мыслит, а не ЧТО он знает.
Конкретные знания конечно же важны, но в каком-то пределе, а вот умение мыслить — бесценно.
А тестовые не даем по нескольким причинам одна из которых — хорошие спецы в них не нуждаются и более того с высокой вероятностью сразу Вас пошлют при первом же намеке на тестовое (я и сам не люблю тестовые)webmascon
11.12.2019 08:04А Мне вот дали тестовое и я не послал. Может я не senior? И тестовое было интересным и я понимал почему оно именно такое.
softaria
11.12.2019 18:01Есть еще такой момент — если ты, Google, то можешь давать тестовое.
Если обычная средняя компания, то давая тестовое, ты отсекаешь часть годных кандидатов.
Helldar
13.12.2019 00:03Не факт. Есть и вторая сторона. На работу искал себе в команду мидла-сеньора — все как на подбор джуны оказываются. Ни знаний, ни умений, ни опыта.
Тестовое даём реально на 1-2 часа делать дома без ограничения по времени — оно отсекает около 90% джунов, желающих получать сеньорскую зп.JordanoBruno Автор
13.12.2019 01:03100% джунов можно отсечь по CV и 5-минутному разговору по телефону.
strannik_k
13.12.2019 10:26Всякое бывает. Может условия такие были, что мидлы, сеньоры мимо проходили.
При одинаковых условиях, для экономии своего времени, я сначала выбирал вакансии без тестовых задач. А то 10 конторам сделать тестовые на 1-2 часа уйдет часов 50, пока будешь стараться сделать как можно лучше и перепроверять.
DrFdooch
13.12.2019 10:52Вы знаете, это очень отличается от того что я знаю из своего опыта или опыта близких знакомых. Я согласен с JordanoBruno в том, что резюме и 5-10 минут погооврить достаточно, чтобы отсечь явно не подходящих кадров.
Как я понял, вы судите исключительно по тестовому заданию — и тут либо вы его даете просто всем (естественно, что 90% людей оказываются неподходящими) либо ваше мерило уровня не совпадает с общепринятым.
Когда мы практиковали тестовое задание — до половины кандидатов его проходило… чтобы потом неприятно удивить на собеседовании. Поэтому сейчас я предпочитаю сессию парного программирования тестовому. Очень сложно правильно судить о специалисте только по его «искуственному» коду.
nikolayv81
13.12.2019 17:44(очень давно) Как-то сделал тестовое(большое, и гарантированно ему нет применения на практике) оно вроде как о очень понравилось (и отняло у меня прилично времени, т.к. я от этой темы уже отошёл к тому моменту), в итоге мы не сошлись чем-то(на мой взгляд оценкой важности тех или иных вещей хотя кто знает) с непосредственным "будущим начальником", вот и зачем я его заранее делал...
sashocq
11.12.2019 23:14Т. е. можно дать тестовое, и если кандидат
пошлётоткажется, значит хороший спец
Pest85
12.12.2019 07:43Мне както предложили поработать недельку а потом они мне скажут подхожу я или нет. Причем это стандартная практика у них.
Компания довольно интересная, гео расчеты, свой супер компьютер (в 5ке самых мощных в южном полушарии), но как то нереалистично для не студентов.
Вот они отсекают очень немало хороших кандидатов.
Helldar
12.12.2019 23:59Имхо, одно дело тестовое для реально крутой компании а-ля Гугла, Яндекса, Амазона, Мейл.ру и совсем другое для Васи Пушкина.
DrFdooch
11.12.2019 00:46+2У меня есть три вопроса, и не только к автору, буду рад если увижу много ответов: сколько разработчиков в вашей практике покидали команду из-за некомпетентности (недостаточных знаний, медленной работы, большого количества ошибок)? Сколько из-за денег? Сколько по другим причинам?
JordanoBruno Автор
11.12.2019 01:57В хорошей комфортной команде, при адекватном отборе на собеседовании, при оплате как минимум по рынку и не на говнопроектах или стартапах текучка будет небольшая(5-10% в год). Многое зависит от возраста — молодые(до 30 лет) намного проще уходят. Причины ухода бывают разные, но весьма стандартные — деньги, хочется других и интересных задач, хочется карьеры, с кем-то не сработался и это критично, предложили более интересное/выгодное место. Нужных специалистов держат, тех кого несложно заменить — нет.
alekciy
11.12.2019 06:34Я так понимаю, что DrFdooch хотел услышать вашу статистику.
JordanoBruno Автор
11.12.2019 14:49Для полноценной статистики у меня нет достаточных данных. Также не всегда известна реальная причина ухода. Нередко бывает что это совокупность причин.
DrFdooch
11.12.2019 09:51Спасибо, я так понял что из-за недостаточной квалификации практически ни с кем не приходится расставаться.
А как вы определяете, держать спеца или нет?JordanoBruno Автор
11.12.2019 14:26Квалификация проверяется на собеседовании, если кандидат ее прошел — значит с ней проблем нет.
Держат тех, кого заменить тяжело. Например Вася знает хорошо проект, успешно развивает значительную его часть и у него нет серьезных конфликтов.
akdes
11.12.2019 15:11а как держат, и на сколько велик шанс, что удержат?
Т.к. думаю, что очень сложно, уловить «уплывающего» тёпленьким, прежде чем он объявит об уходе…
Или у Вас это проходит стабильно, раз, два, н раз в году собеседование и премия или повышение?JordanoBruno Автор
11.12.2019 16:08-1Если отношения хорошие в команде, то сотрудник сначала поговорит со своим начальником — «предложили больше денег, что будем делать?».
Пересмотр зп у нас был согласно личным достижениям/заслугам и рыночным изменениям. В некоторых компаниях практикуется пересмотр зп стабильно раз в полгода.
DrFdooch
11.12.2019 15:37Квалификация проверяется на собеседовании
А как вы отбираете людей на собеседование?JordanoBruno Автор
11.12.2019 16:10Первичный отбор — по резюме. Потом короткий звонок. Если все ОК — приглашение на техническое собеседование.
DrFdooch
11.12.2019 16:18Еще 2.5 вопроса :)
Какой процент пришедших на интервью его проходит?
Есть не техническое интервью после технического? Какой процент проходит его?JordanoBruno Автор
11.12.2019 16:36Прошедших — немного обычно, не более 10 процентов. Хотя цифры условные и зависят от локации, бюджета, проекта, должности, дедлайнов…
После технического — только Background Check и далее Offer.
0xd34df00d
11.12.2019 18:25Смотрите ли всякие гитхабы? Если да, то насколько они влияют?
JordanoBruno Автор
11.12.2019 20:22Конечно, хотя что-то интересное нечасто бывает. В любом случае, код кандидата посмотреть надо во избежание неприятного удивления при работе.
Влияет самым непосредственным образом.
Helldar
13.12.2019 00:11Помогает понять насколько чел соблюдает кодстайл и общий принцип его мышления по почерку.
Helldar
13.12.2019 00:09Устроился 3 года назад в контору на ЗП мидла в нижней планке по городу, т.к. только переехал в крупный город и деньги физически заканчивались, а других офферов не было.
Сейчас я тут тимлид, фулстек, девопс, 3 человека в подчинении (сам набирал)… Сам с нуля поднимал и настраивал прод, жиру, гитлаб. Скрипты, вебхуки и прочее. Задачи раскидываю по команде, скрипты автоматизации писал…
… спросил за повышение хотя бы до уровня сеньора — сказали "у нас нет таких зарплат" и подняли на 10%. Обидно.
Так как уволить они меня не могут (понимают что контора раком станет моментально), постепенно ищу другое подходящее место с комфортными условиями и, желательно, сложными задачами, т.к. от админок для лендинга уже блевать хочется.
411
11.12.2019 01:21+1Я бы спросил «Когда и как вы поняли, что стали Senior разработчиком?»
ksigne
11.12.2019 05:24Лично я себя почувствовал сиром, когда я перестал искать задачи, задачи стали искать меня.
MisterParser
11.12.2019 05:39Когда тебя взяли на эту роль другие люди.
411
11.12.2019 10:22Между тем, как меня первый раз взяли на роль Senior, и моим полноценным осознанием своей «сеньорности»(и того, что её не было до этого), прошло порядка двух лет. До того я был достаточно сильным миддлом, который весьма неплохо справлялся с любыми задачами.
iago
11.12.2019 18:07тогда я стал сеньором в 22 года (10 лет назад). Как угодно хотели продать заказчику, лишь бы подороже. Мне смешно было слушать также какой я хороший сеньор когда я увольнялся в 24. А начал чувствовать после двух кейсов:
— решения нескольких нестандартных сложнейших задач (архитектурно-производительных)
— когда остался одним опытным разработчиком на проекте и все лежало на мне продолжительное время, соответственно научился ответственности
Hydro
11.12.2019 08:18Я бы перефразировал «Когда и как Вы поняли, что считая себя Senior Вы на самом деле не Senior?»
411
11.12.2019 10:18Это конечно более тонкий вопрос, но мне кажется это может надавить на кандидата. Все любят говорить о своих успехах, а такая формулировка к синдрому самозванца ведёт, да и можно подумать, что тебя не хотят брать на Senior.
wladyspb
12.12.2019 14:26Я вот до сих пор не знаю, кто я.
Вроде 5+ лет опыта есть — значит, сеньор.
С другой стороны, чем я занимался-то? Круды писал первое время, во фронт лазил, разве ж это опыт… Наверное миддл…
Хотя — последние несколько лет тяну проект, поднимал его вообще в одиночку, и вроде неплохо спроектировал — значит, всё же сеньор?
С другой стороны, проект-то так себе, внутри костыли, особо интересных задач нет, вокруг много таких же — кто угодно бы справился. Миддл?
Но опять же — уже на 7к рпс вышли, миллионы крутятся, куча технологий использована, наверное сеньор.
Но… Я же алгоритмов не знаю почти, паттерны программирования так и не изучил, какой я сеньор, так, миддл.
Но, мне же платят зарплату вполне себе сеньорскую по рынку, и повышают регулярно, со мной советуются другие разработчики, значит — сеньор?
Да блин, я за технологиями не слежу, более менее знаю только php, всё остальное по верхам нахватал, регулярно гуглю варианты — миддл?
И вот на таких качелях постоянно качаюсь. Кто я — хз, то ли я сеньор с синдромом самозванца, то ли миддл которому повезло получить хорошее место с высокой зарплатой.
DimoNj
12.12.2019 21:09Наверное, всё зависит от компании и того, какую роль Вы выполняете в команде. У одних ты можешь быть сеньором, а у других — средним мидлом.
Helldar
13.12.2019 00:19Опять же, есть люди кто и 5, и 10, и 15 лет работает в какой-нибудь веб-студии или что-то сам пытается не совершенствуясь и оставаясь максимум на переходном состоянии из джуна в мидлы.
Так что время я бы лично вообще не учитывал в определении сеньорства да и любого другого статуса.
Helldar
13.12.2019 00:15Когда осознал что мой практический опыт значительно выше многих мидлов, с которыми работал. Также коллеги постоянно спрашивают как лучше организовать ту или иную архитектуру приложения и какие подводные камни я вижу.
Pavenci
11.12.2019 09:06+1порой собеседующие не следуют основной цели собеседования — определить, будет ли разработчик полезен команде и насколько эта польза соотносится с затратами на данного разработчика. Вместо этого, собеседующий часто выявляет чего разработчик не знает, вместо того, чтобы выяснить, что он знает и умеет.
Это надо золотыми буквами сделать на всех видных местах, где проходят собеседования. Чтобы собеседующий всегда помнил. Наверное самое главное предложение из всей статьи. Спасибо автор :)strannik_k
11.12.2019 13:31Может в начале каждого резюме писать) Как еще собеседующие это увидят?
Pavenci
11.12.2019 15:02Эх, еслиб они его еще читали… А то как обычно «Мы внимательно изучили ваше резюме, бла бла бла» и следом вопрос «А вы работали с javascript?»
strannik_k
11.12.2019 16:16Это да.
У меня случай был, спрашивали вопросы только по шейдерам.
Только после собеседования я понял, что им шейдерщик был нужен. Я бы и сам на эту позицию не пошел, т.к. игровую логику хотел писать, а не шейдеры.
То что HR глянул резюме и увидел слово «шейдер», я не сомневаюсь. То, что его не читал собеседующий, я тоже не сомневаюсь.
VolCh
11.12.2019 14:03Только это цель одной стороны, а не общая
avtor13
11.12.2019 14:17Простите, но не понятно какую именно сторону вы имеете в виду.
«будет ли разработчик полезен команде и насколько эта польза соотносится с затратами на данного разработчика» — тут про пользу команде, деленную на аппетиты разработчика
iago
11.12.2019 18:09может тимлид и хочет так вести собес, а ПМ ему говорит — подготовь список вопросов, на которые никто не ответит, и задавай побольше конкретики чтобы соискатель не сильно зарплату хотел и я мог бы этим надавить при разговоре, ссылаясь на то что «я не технический специалист, но вижу ваши пробелы»
Mugik
11.12.2019 09:09-2Вы уж простите, что я спрашиваю. Но напомните, пожалуйста, а в каких компаниях вы работали и какие сильные продуктовые команды вы собрали и успешно ими руководите (руководили). Просто не нашел такой информации, может я плохо искал, тыкните, пожалуйста.
Хотелось бы ознакомиться и так сказать выслушать ваши учения и тезисы, которые вы бы подкрепили реальными результатами, а не голословными утверждениями.
SergeyEgorov
11.12.2019 10:10Ни разу еще мне не удавалось с помощью собеседований и тестовых заданий определить станет ли кандидат хорошим коллегой впоследствии…
Понял лишь что если сразу что-то явно не нравится, то надо извиняться и вежливо расставаться.
DrFdooch
11.12.2019 10:32Можете рассказать об успешном собеседовании, в результате которого кандидат не стал хорошим коллегой? Мне кажется, такие ситуации происходят очень часто, но многие не обращают на них достаточно внимания.
У меня есть один хороший пример: канидат на собеседовании показал себя понимающим и опытным разработчиком, но по факту оказался неспособен работать в условиях малейшей неопределенности (а это в нашей сфере, к сожалению, норма). В итоге любая задача без исчерпывающей спецификации, с которой Senior должен как раз справляться без проблем, растягивается в три-четыре раза — и 10% лишнего времени уходит на собственно уточнения требований, а 90% — на фрустрацию и прокрастинацию от безысходности. В итоге разработчик чувствует себя, извините, говном (а это плохо не только для него); менеджмент периодически полыхает; перестроить процесс, работающий для остальных — невозможно. Спасает только парное программирование, но применять его постоянно тоже не выход.SergeyEgorov
11.12.2019 12:20О! Практикуете парное программирование!? Через TDD? Это замечательная техника! Я как раз считаю что применять это надо постоянно.
Если говорить про кандидатов, то 95% процентов из них показывают себя на собеседованиях вполне перспективно, а затем проваливаются в повседневной производственной коммуникации. Люди не устройства с совместимыми интерфейсами.
Более-менее адекватная оценка для кандидата появляется после пары месяцев совместной работы в обычной обстановке. И ежедневное парное программирование наиболее этому способствует.
JordanoBruno Автор
11.12.2019 14:3495% процентов из них показывают себя на собеседованиях вполне перспективно, а затем проваливаются
Сергей, Вы точно что-то делаете не так на собеседованиях. Возможно, Вам стоит кардинально пересмотреть вопросы, которые Вы задаете. Предположу также, что Вы упускаете ключевые моменты из ответов кандидата.
DrFdooch
11.12.2019 15:30О! Практикуете парное программирование!? Через TDD? Это замечательная техника! Я как раз считаю что применять это надо постоянно.
Замечательная, согласен :) Но постоянно парное применять не получается, есть категория задач, где надо сосредоточиться и войти в поток, сделать это вдвоем — это очень высокий уровень близости :)
silent_jeronimo
11.12.2019 14:06А я работал с подобным человеком и могу сказать, что в том случае была реакция на умолчания, принятые в команде для того, чтобы было спихнуть на кого ответственность за ошибку. Полагаю, что ваш разработчик тоже неоднократно оставался крайним, когда реализовывал что-то в условиях отсутствия исчерпывающей спецификации — и знал о том, что это он виноват в ошибках, потому что выбрал неверный способ решения проблем, предвиденные грабли на котором реализовались по предсказанному им сценарию.
Тут поможет только постепенное снятие с него ответственности под протокол особого мнения, если этот разработчик нужен. Зато если он дорастёт до архитектора, то будет приятно с ним работать.
tretyakovmax
11.12.2019 10:10Для меня любой вопрос, не касающийся профессии, навыков, опыта работы или каких-то нужных кадровикам формальностей — это однозначно повод серьезно задуматься, нужно ли мне идти в эту компанию? Ну равзве что иногда интересуются твоим хобби или что-то такое — бывает, для поддержания как бы неформального общения. Остальное в топку. Это признак непрофессионализма а иногда откровенного дебилизма эйчара. И если руководство до сих пор не выгнало такого «специалиста» — значит само недалеко от него ушло.
Rumex339
11.12.2019 16:23Мой начальник так развлекался на собеседованиях, когда уже знал, что кандидат не подходит ему: просил спланировать воображаемую свадьбу или поиграть в «Крокодила». Эйчарам объяснял, мол, это для проверки действий в нестандартной ситуации.
Alexsey
11.12.2019 20:19Сразу видно уровень профессионализма вашего начальника. Интересно какой процент людей пришли бы на собеседование если бы знали про такие развлечения.
JordanoBruno Автор
11.12.2019 20:34Есть собеседования, где цель — не нанять человека, даже если это Джеймс Гослинг, Гвидо ван Россум и Сергей Брин в одном лице за скромную зарплату.
Stas911
12.12.2019 05:49Вашему начальнику, видимо, совершенно все равно, какой имидж будет у вашей компании на рынке (а рынок ИТ, обычно, очень тесный даже в больших городах и информация расходится быстро). Это не делает ему чести, а лишь показывает его непрофессионализм.
Rumex339
12.12.2019 10:50Соглашусь с тем, что на таком собеседовании (где кандидат ему уже сразу не нравился) он вел себя, мягко говоря, очень странно, но как профессионал в своей области он — что надо.
Stas911
12.12.2019 14:19Если человек не умеет работать с людьми и не владеет элементарными правилами вежливости — специалист он так себе, как бы он ни разбирался в своем предмете при этом.
dim2r
11.12.2019 10:23К сожалению замечаю, что за частую упор на то что кандидат не знает. Объем знаний не оценивается.
kwardakov
11.12.2019 11:46+2Как понять, сможет ли кандидат эффективно у вас работать? — Очень просто, если он предыдущем месте проработал больше года, сможет и у вас. Не надо считать себя уникальным работодателем. Вы не Гугл и не Нетфликс, вы обычная компания, таких сотни тысяч.
Как же тогда выбрать кандидата из всех, которые могут эффективно работать, а это практически все? — Попробуйте решить с вместе с ним какую-нибудь задачу, характерную для позиции. Найдите решение и усложните задачу. Потом усложните задачу до невозможности. Если вам нравится, что говорит и делает кандидат — берите его, не нужно собеседовать все. Вы не Гугл и никогда им не будете.Rumex339
11.12.2019 15:48Очень интересный и дельный, на мой взгляд, подход! Некая имитация совместной работы как раз даст возможность собеседуемому «выдохнуть» и поработать.
KvanTTT
12.12.2019 14:48Вы не Гугл и никогда им не будете.
Я не был бы так категоричен. Гугл может позволить себе купить многие компании и покупает их.
Gradiens
12.12.2019 17:39Как понять, сможет ли кандидат эффективно у вас работать? — Очень просто, если он предыдущем месте проработал больше года, сможет и у вас.
Ключевое слово — эффективно.
Объективной информации о его работе на предыдущем месте у вас нет и не будет.
Кандидата могли терпеть по каким-то своим причинам больше года.
Теперь терпеть придется вам.kwardakov
12.12.2019 18:01Можно взять телефон и позвонить. Не усложняйте.
Gradiens
12.12.2019 18:08Можно. Но я не уверен что информация будет достоверна.
В случае, если у человека был конфликт (и неважно по какой причине. Может, сотрудник был настолько ценный, что отпускать не хотели, и поэтому поругались) — вы услышите только негатив.
Если конфликтов не было — услышите что-то нейтральное или хорошее. Вменяемый руководитель не станет сор из избы выносить.kwardakov
12.12.2019 18:51+1Значит, мы вернулись туда, где и были — нет ни одного способа узнать, насколько вам подойдет кандидат. Поэтому выгодная стратегия — оптимистично относится к людям.
jaddd
12.12.2019 19:15Если конфликтов не было — услышите что-то нейтральное или хорошее.
Смотря какой задавать вопрос.
Самый главный вопрос, который надо всегда задать в процессе общения с предыдущим работодателем кандидата:
«Вы бы взяли его себе обратно на работу, при условии, что у вас бы нашлась для него работа?»
Если да — значит эффект в его работе был. Если нет — надо узнавать причину — возможно для вас это не проблема.
Вопрос этот нужно задавать после стандартных вопросов типа, как он работал, все ли было хорошо и т.п. Но ответы на них будут скорее всего социально приемлемыми. Поэтому их и надо сначала задавать, чтобы у предыдущего руководителя создалось ощущение, что он нормальный человек и зря никого не обижает.
А вот на вопрос о приеме обратно, как правило, отвечают более-менее честно. Тем более он явно не характеризует человека, он характеризует только отношение к нему работодателя.
user_man
11.12.2019 13:50-1Похоже, что автор рассматривает собеседование именно с точки зрения подбора «своих людей» в «свою команду». Но бизнес — это не ваше, и это даже не моё, это чужое. Просто совсем левое.
Поэтому не стоит давать советы бизнесу. Хотя пытаться влиять на принятие решений, выгодных грамотным специалистам, безусловно стоит. И да, вот такими статьями тоже. То есть неявно идёт банальная война за деньги и минимум напряжения между бизнесом и специалистами. Специалисты, вот как в данной статье, описывают своё видение, свои предпочтения, ну а бизнес почитывает и делает выводы. Или не делает, что случается чаще. Хотя дефицит кадров бизнес очень волнует, но ведь всегда есть очень простой способ — купить проджект манагера (начальника отдела или ещё как-то похоже) и свесить все остальные заботы на него. Особенно в больших конторах. И этот манагер уже будет дрючить испытуемых исходя из личного опыта, который, возможно, включает прочтение подобных статей. Но часто не включает. Просто потому, что реальность требует много дешёвых кодеров, ну а манагер вынужден это чутко улавливать. Вот и методы отбора у него вырабатываются соответствующие. И это уже не выбить из такой головы.
Поэтому я бы рекомендовал специалистам «познать цзен». То есть, имея опыт, вы легко отличите манагера от хорошего специалиста, либо мальчика-джуна, посланного вас собеседовать по техническим вопросам менее грамотными товарищами (включая сеньоров). Просто вспомните, как вы сами участвовали в подобных действах. Там всё тривиально — конторе нужен продукт, продукту нужны кодеры, манагер пинает HR, те присылают толпу, далее нужно отсеивать, но понятно, заниматься этим лень, поэтому и посылают начинающего, но умело отвечавшего на собеседовании на технические вопросы. Ну и начинающий затем выдаёт своё ценное мнение наверх, этому мнению наверху не верят, ибо знают, что начинающий, пишут соседям, мол побеседуйте тоже и т.д. В общем — типичная конторская деятельность по перепихиванию работы с себя на окружающих. И где в такой суете место грамотным вопросам? Правильно — нет его.
Бывают конторы, где специалистам верят, поскольку от них всё зависит, но и там «идеальный отбор» отсутствует. Если всем рулит тим-лид, то вышестоящий начальник свешивает всю процедуру на него, ну а он уже подбирает народ под себя. Не по знаниям, не по «полезности для команды», а именно под себя (можно считать, что по сути он думает «команда — это я»). Да, не все люди идеальны. Хороших спецов я на собеседованиях встречал немного. Бывали интересные люди, но всегда были некие манагеры, либо те же мальчики-джуны, либо ещё какие-то специфические условия.
Какой из этого вывод? Да просто расслабьтесь. Не нервничайте по поводу глупых вопросов и всего того, из-за чего вы привыкли нервничать. Ну да, мальчик-джун очень хочет проявить себя и задаёт вам олимпиадные задачки, про которые он где-то читал. Ну так что в этом плохого? Он и обязан это делать, просто в полном соответствии со своим неокрепшим разумом и недостаточным опытом. На что тут жаловаться? На то, что вы не можете вспомнить, какой метод нужно дёрнуть для решения поставленной джуном задачи? Ну так и скажите — я хочу поглядеть документацию по такому-то классу, и через 5 минут отвечу. Если вы боитесь, что джун потом напишет негативный отзыв — не стоит нервничать! Вышестоящий начальник хорошо понимает, кого и куда он послал, поэтому решать всё равно будет субъективно, лишь частично опираясь на отзыв джуна. То есть просто действуйте спокойно, как вы привыкли, и пусть джун под вас подстраивается и потом покрывается, когда вы ему возражаете. Ну ведь просто же!
Так что — расслабьтесь и не нервничайте. Но к собеседованиям, безусловно, готовьтесь. То есть если бы ко мне пришёл якобы сеньор, но поленившийся освежить в голове хотя бы основное по списку указанных в вакансии технологий — ну очевидно же, что он привык к лёгкой жизни на старом месте, не учил новые технологии, не готов банально почитать о том, чем придётся заниматься на новой работе. Именно поэтому возникает вопрос о его проф.пригодности. Не из-за каких-то субъективных факторов, а именно из-за неготовности чуть-чуть напрячься. Потому что новое место работы — это всегда некоторое напряжение, связанное с необходимостью учиться тому, чего на прошлой работе не было.
Но даже моё возражение в куче контор никак бы не повлияло на субъективный выбор кем-то другим, так что опять же — расслабьтесь, не нервничайте, не попали в одну контору — попадёте в другую. А все эти собеседования — субъективная суета. Напрягают лишь если буквально жрать нечего, потому что денег нет. А во всех остальных случаях — не парьтесь. Но только при условии, что вы реально способны учиться и реально обладаете ценными опытом и знаниями.Pavenci
11.12.2019 15:23+1Кстати по поводу джунов, встречались такие собеседования да. Когда тебя собеседует человек, который несёт откровенную хню, и когда настает твой черед задавать вопросы, начинает дергаться и нервничать сам :) Как будто собеседующий пытается самоутвердиться в диалоге с тобой, выглядит это нелепо и смешно.
Helldar
13.12.2019 00:26Особенно любители блеснуть недавно прочитанными "умными" словами доставляют)
И кандидата грузят областью в которой он, чаще всего, плавает, и сами себя выставляют будто ищут не разраба, а преподавателя.
dshtempluck
11.12.2019 14:37В кои то веки отличная статья про хайринг. Согласен почти со всем изложеным. Единственное замечание — кто-то из технарей в собеседовании все-таки должен учавствовать.
akdes
11.12.2019 15:16На сегодняшний день, понятие «рыночная стоимость» очень размыто, точнее не катируется среди многих разработчиков, т.к. в одном месте дают 2 яблока, а в другом 5… и это колличество часто никак не сходится с рыночными показателями.
В связи с отсутствием необходимого количества кандидатур, пункт «Насколько желаемая зп соответствует вышеуказанным пунктам» становится очень критичным.
Конечно же понятно, что бюджет на позицию ограничен, но порой будет больше толка от мидла с зарплатой сениора, чем будешь ждать подходящего сениора на белом коне — это как пример.
Как Вы/вы считаете?
Что говорит практика?JordanoBruno Автор
11.12.2019 17:02Это отдельная история — как нанять толкового сеньора, если бюджет ограничен.
«Рыночная стоимость» определяется весьма просто — можете поинтересоваться у хедхантинговых агентств, за сколько набирали до Вас. Можете посмотреть в HH, сколько примерно предлагают. Также, первые же кандидаты Вам сами подскажут примерный рынок.
Если Вы предлагаете зп по рынку — вероятность взять толкового сеньора весьма невелика, можно ждать месяцами. Если дать +10% к рынку — шансы увеличиваются, но скорей всего Ваш оффер будет использован сеньором на текущем месте работы для повышения зп.
Поэтому надо предлагать что-то большее, возможно, не только материальные блага.
Сейчас весьма распространен подход набора на удаленку, так как это сильно расширяет аудиторию и упрощает найм. Также нередко сотрудничают с бодишопами просто арендуя у них спецов.
kolemik
11.12.2019 18:17а вот меня прям недавно спросили про методы у Object
правда там и ещё было умных вопросов, но вот этот запомнился…
а года 4 назад поинтересовались как перевозить какое-то зверьё в темноте через мост в лодке с фонариком и батарейки кончаются и река горит и вообще апокалипсис.JordanoBruno Автор
11.12.2019 22:38зверьё в темноте через мост в лодке с фонариком и батарейки кончаются и река горит и вообще апокалипсис
Я даже боюсь представить, под какими препаратами это придумывалось и зачем им тут разработчик. Тут психиатр нужен.kolemik
11.12.2019 22:50думаю это была такая задача:
petruchek.info/problems/night-bridge-flashlight.html
там потом выяснилось что отпуск надо планировать за год, и всё такое, приходить к 9 утра, в общем не сложилось с ними, хотя 150тыр 5 лет назад было неплохо конечно…JordanoBruno Автор
11.12.2019 22:56Я ничуть не удивлюсь, что с такими задачами у них полно скелетов в шкафах. Я считаю, что разработчика нужно спрашивать про разработку.
demsp
11.12.2019 23:16Задача норм, только непонятен вопрос про минимальное время. Если за ними кто-то гонится, то мост надо переходить друг за другом гуськом и как можно быстрее :)
alekam
11.12.2019 19:11про кубик-рубик зачет! никогда не понимал такого. я будут тестером головоломок или сениор девелопером? как это умение поможет мне как-то в работе?
возвращаясь к кубику Рубика. у нас с сестрой в детстве был такой способ его сборки: после 1-2 ударов им об стену, у него выпадывал угол, после чего его можно было разобрать и вставить правильно все цвета. данная операция занимала несколько минут. то же самое с пирамидкой, но там выбить компонент было сложнее.
Alesh
11.12.2019 19:25Наиболее вменяемое что попадалось здесь по теме. Но про полдня кодинга в офисе, на мой взгляд тоже мимо. В специфику ваших задать въехать не успеет, а что то другое, тоже тестовое, только в стрессовом состоянии.
На мой взгляд решение — только под ответственность тимлида (они должны быть на одной волне) и чётко оговоренный испытательный срок.
JordanoBruno Автор
11.12.2019 22:36Полдня кодинга в офисе вполне могут включать в себя вариант парного программирования, чтобы понять, как человек ведет разработку. Здесь смысл — не закодить что-то, а продемонстрировать владение навыками разработки на уровне Senior, чтобы потом тимлиду не было мучительно больно за принятое решение. Можно даже без непосредственного кодирования, а просто взять какой-нибудь код и послушать кандидата, что в нем плохо, что хорошо, что стоит переделать и как.
agent10
12.12.2019 00:45+1Ну не знаю, я вот сам никогда не применял нигде парного программирования. Если я приду на собеседование и ко мне подсядет чувак, который будет меня палить, то мне будет как-то не по себе… почему так — часто, когда решаешь задачу, то сначала пишешь код который минут через 30 возможно придётся переписать. Но со смотрящим рядом ведь хочется не ударить в грязь лицом и из-за этого будет сильный дискомфорт. Разве нет?
JordanoBruno Автор
12.12.2019 00:52Да не вопрос, нравится кодить одному — Ваше право. Задача — посмотреть на Вашу работу в комфортной среде, а не создать стресс, как делают некоторые.
slovak
11.12.2019 19:51>> Тут могут быть другие варианты в других языках — то, что хорошо знает собеседующий.
А вот это как раз вкорне неверно и очень даже вредно спрашивать то, в чем Вы сами хорошо разбираетесь и на данный момент в контексте.
Ну вот разобрался я на последней неделе в библиотеке какой-то, держу в голове часть документации и не лезу раз за разом в гугл. С какой стати собеседуемый должен держать в голове то же самое?
CrazyElf
11.12.2019 20:20+1Senior, которого прет от работы и которому нужны интересные задачи, а не деньги — это, конечно, очень ценный кадр, но, боюсь, в природе он встречается не часто.
Проблема в том, что интересных задач обычно мало, а рутины много. И сложную рутину тоже надо кому-то делать, спихнуть всё на низовой состав нереально. Поэтому senior со временем привыкает к тому, что интересные задачи приходят и уходят, а деньги — штука хорошая и их платят за разную работу, в том числе и не очень то интересную. Другое дело, что если процент неинтересной работы на конкретном месте начинает зашкаливать, senior это терпеть не будет даже ради денег. )VIkrom
11.12.2019 22:28Поддержу. В моем видении сеньора это одно из основных качеств — практически одинаковая производительность и на интересных задачах, и на рутине.
JordanoBruno Автор
11.12.2019 22:31Я таких людей не встречал — с одинаковой производительностью. Возможно Вам повезло больше, не исключаю.
CrazyElf
11.12.2019 23:32Не, про одинаковую производительность я не говорил. Просто сеньор уже пожил и понимает, что рутиной тоже надо заниматься, даже если очень не хочется. И он занимается. Не так, чтобы прям с песнями, но куда деваться.
Stas911
12.12.2019 05:57Часто за неинтересные задачи платят сильно больше именно поэтому. Например — кто-то видел хоть одну систему без отчетности? Не самая интересная работа, казалось бы, а на рынке-то не протолкнуться от конкурирующих продуктов.
CrazyElf
11.12.2019 20:28А насчёт быстрого освоения — всё верно. Меня на нынешнюю работу взяли не смотря на то, что я не знал async/await, а он тут был нужен. Освоил это дело за несколько дней и активно стал применять. Никаких проблем. Внутренне был готов к концепции, просто не было надобности ранее. Как столкнулся — легко изучил.
RaShe
11.12.2019 21:13Зачем спрашивать про алгоритмы? Каждое мое собеседование меня спрашивали алгоритмы. Но за 10 лет работы разработчиком я ни разу не применил эти знания.
JordanoBruno Автор
11.12.2019 22:30Если Вы имеете ввиду какую-нибудь классику из кнутовской серии, то это крайне редко нужно на практике. Под алгоритмами на собеседовании подразумевается насколько эффективно разработчик воплощает задачу в коде. Это нужно для того, чтобы понять, являются ли алгоритмы его сильной стороной или нет.
agent10
12.12.2019 00:54И зачастую на собеседования «сами знаете куда» дают олимпиадные или около задачки. На основании которых определяют человек умеет или не умеет в алгоритмы.
А я рад был бы увидеть примеры алгоритмических, но не олимпиадных задач, которые могут показать, что разработчик справится с алгоритмами для средних задач в жизни. Есть примеры?
vadlit
11.12.2019 23:42Так как налить ровно 4 литра при вёдрах 3 и 5 ?
darkAlert
11.12.2019 23:56Пусть, в3 — ведро 3л, в5 — ведро 5л
1) Наливаем в в3 и выливаем в в5
2) Наливаем еще в в3 и выливаем в в5 пока не заполнится. В в3 остается 1л.
3) Опустошаем в5 и переливаем туда 1л из в3
4) Наливаем в в3 3л и выливаем это в в5 с 1 л, получаем 4л.
p.s. сори если это был сарказм и я не в тему, просто пролистал комменты до конца и ваш был последнийvoidMan
12.12.2019 09:06А не проще ли налить по полведра? 2.5+1.5=4, это если конечно возможно «половину» определить.
Agne
12.12.2019 14:32вариант
Пусть, в3 — ведро 3л, в5 — ведро 5л
1) Наливаем в в3 и выливаем в в5
2) Наливаем еще в в3 и выливаем в в5 пока не заполнится. В в3 остается 1л.
Задача получения 1л решена.
Оформляем результат решения задачи в виде функции.
Выливаем отладочный результат 1л из в3.
Для в5, вызываем функцию получения 1л, 4 раза в цикле последовательно или в 4 параллельных потоках.
wladyspb
12.12.2019 14:53У вас получилось восемь этапов, если разделить на отдельные действия.
Задача решается за шесть)
решение1) наливаем в в5
2) переливаем из в5 в в3 сколько влезет(в в5 остаётся 2л)
3) выливаем в3
4) переливаем из в5 в в3 2л
5) наливаем в в5
6) переливаем из в5 в в3 сколько влезет (1л), в в5 осталось 4л.JordanoBruno Автор
12.12.2019 14:58Вот к слову, хороший пример. Есть два человека, один решил эту задачу за 8 шагов, другой за 6.
Можно ли сказать, что последний будет работать эффективней на 25%? Нет.
Можно ли сказать, что последний умней на 25%? Тоже нет.
Таким образом, польза от подобных единичных задач неочевидна. Для каких-то корректных выводов таких задач нужно дать минимум сотню.
crazytrucker
12.12.2019 00:33Я провел не одну сотню собеседований как с одной стороны, так и с другой.
А когда вы работать-то успеваете? «Собеседование» (job interview) со стороны нанимающегося на работу длится от 4 до 8 часов, «не одна сотня» (допустим, две сотни) займет у вас 6 * 200 = 1200 часов, т.е. практически два месяца рабочего времени.
например — полдня кодинга непосредственно в компании, оплаченные по средней ставке
Это ваша юношеская мечта, что-ли? По какой статье расходов будете проводить оплату в бухгалтерии? ;)JordanoBruno Автор
12.12.2019 00:36+11) Классическое собеседование длится не больше часа. Иногда меньше, иногда больше.
2) Вопрос оплаты в нормальных конторах проблемой не является.
vvbob
12.12.2019 01:45Ххе, по этой статье я типичный креативщик-заложник настроения, видимо из-за этого мне хреново работается по аджайлу, когда до дедлайна много времени и никто у меня над душой не стоит, я хорошо работаю в своем рваном ритме (то много то ничего) и все успеваю, а постоянная рутина со всеми этими спринтами и каждодневными отчетами меня в тоску вгоняет, чувствую себя как заключенный под присмотром.
DrFdooch
12.12.2019 10:38постоянная рутина
каждодневными отчетами
чувствую себя как заключенный
где-то сейчас заплакал один молодой скрам-мастер и засмеялся (зловеще) аджайл-коуч в галстуке.
Orange11Sky
12.12.2019 06:13Статья очень понравилась. Согласен практически со всеми пунктами.
Если автору будет интересно описать метаморфозы сеньора девелопера, происходящие с ним по мере старения, то с удовольствием прочитаю.Pavenci
12.12.2019 11:38Про метаморфозы интересно. У меня по молодости, когда только начинал, была тяга ко всему новому: быстрая смена стеков, проектов, хотелось попробовать что-нибудь новое и тд. Сейчас по прошествии лет пришло некое умиротворение и спокойствие. Не хочется скакать по проектам, менять стеки, хочется чего-нибудь стабильного, чтобы на долгие годы и в спокойном темпе, благо нет скрама и удалёнка позволяет :))
JordanoBruno Автор
12.12.2019 13:55Хороший вопрос.
Чем старее разработчик — тем более консервативен он становится. Вплоть до полного отрицания новых технологий, особенно, если старый стек до сих пор востребован(например, Java 7-8). Плюсом такой консервативности можно считать то, что в старом стеке он плавает как рыба в воде.
Еще минус возраста то — что тимлиды моложе их встречаются чаще, иногда существенно моложе. Для тимлида 30 лет морально тяжело работать с разработчиком 45 лет, а разработчик с высоты своего опыта и возраста старается давить на него, что вызывает дискомфорт в отношениях. Поэтому старички-разработчики обычно мигрируют в Enterprise и там вполне комфортно себя чувствуют до пенсии.
Guzergus
12.12.2019 12:56Напомнило об очень интересной статье от одного из менеджеров в microsoft о том, как они поменяли процесс собеседования:
blog.usejournal.com/rethinking-how-we-interview-in-microsofts-developer-division-8f404cfd075a
tl;dr: вместо шаблонных вопросов решают вместе с кандидатом реальную задачу во всей её полноте, начиная с работы с требованиями и т.п.
Лично мне такой подход крайне импонирует и, думаю, даже провал такого собеседования будет ощущаться лучше т.к. человек сам увидит, что не справился, не разобрался, etc и как минимум получит полезный опыт. Куда полезнее заучивания всех «принципов ООП».
Gradiens
12.12.2019 18:47А какие у вас появляются дополнительные требования, если вы ищите Lead developer, а не Senior developer?
JordanoBruno Автор
12.12.2019 18:57Lead — это фактически маленький тимлид, то бишь есть некоторые разработчики(часто — middle или junior), для которых он мининачальник. Если вкратце — то лиду нужны навыки менеджерства, наставничества, педагогики. Соответствующие вопросы и надо задавать для их выявления. Если же в подчинении у него нет разработчиков, то по факту — это продвинутый Senior и требования к нему те же, что и к обычному.
Helldar
12.12.2019 23:54Относительно недавно проходил собес как раз на сеньора.
Из краткого: закидали терминологией (solid, dry, kiss, di, инкапсуляция и т.п.) из "умных" слов. Сразу сказал что у меня теория хромает, зато на практике реально много чего могу. Как ещё не спросили "что такое ООП"…
В сумме около трёх часов разговаривали (так получилось).
Дали тестовое. Сделал чтоб не стыдно было. Сказали "офигеть как шикарно", но на работу не позвали.
При этом, с девчонкой HR неплохо поболтали.
Ну, нет так нет.
На другом собесе задачу дали на листочке написать:
Не используя условные операторы при передаче в функцию числа "1" вернуть "2", а при передаче "2" — вернуть "1".
Я с такими задачами не сталкивался и честно пытался решить около пяти минут — не смог. Зато придя домой всего за 15 секунд написал рабочее решение не открывая Гугла:
function get($num)
{
return ($num | 2) — 1;
}strannik_k
13.12.2019 10:09мне такое первым в голову пришло:
return 1+!(num-1); // js код
Но задача дурацкая. Максимум какую инфу получат — сообразил ли кандидат в данный момент или нет.
А решение выше (return 3 — x), классное!)
saaivs
13.12.2019 00:18Спасибо большое за пост. Очень грамотная и систематизация и полезные акценты.
Хотел бы добавить вам в копилку пару идей из своей практики…
Как известно, правильно поставленный вопрос — это половина решения проблемы. Поэтому люди, умеющие задавать правильные вопросы, как правило, и хорошо умеют эти проблемы решать. Если есть желание и возможность — попробуйте «собеседование наоборот»: пусть кандидат экспромтом попробует вас самих взять на работу:) Ну, во всяком случае, это может быть весело. Как минимум, нестандартность приёма иногда позволяет снимать стресс…
И ещё не стоит сбрасывать со счетов «любителей дурацких вопросов»...99% из них и вправду дурацкие, т.к. ответы на них не говорят ровным счётом ничего полезного. Тем не менее, если привлечь на помощь научно обоснованные достижения современной психологии, то кой-какие полезности из их арсенала вполне можно использовать… Например, такие вот простенькие тесты «на когнитивное отражение». Обоснование зачем это и почему может быть полезно популярно рассказано вот тут.
questor
Статья хороша тем, что правильно убирает фокус от не нужных вещей, типа "НЕ спрашивать про частности, про конкретные инструменты, про люки".
И содержит много полезных мелочей во вспомогательных темах (типа раздела "мотивация").
Тем не менее, хотя на собеседовании важно ответить на 4 важных вопроса (типа "может ли кандидат работать на этой должности", "хочет ли работать на этой должности" и т.п.) ключевой раздел — компетенции — освещён недостаточно.
То есть неплохо бы раскрыть более подробно как именно проверить знание алгоритмов, архитектуры… И не "от противного", а без этих "не", которыми полна эта статья.
Так что было бы неплохо увидеть продолжение!
Magikan
боюсь проверить компетенции в мире ИТ практически невозможно. можно только построить гипотезу тк правильные ответы не дают гарантий, что человек умеет это применить, ровно как и не знание теории не говорит о непригодности. тут все очень сложно и строится на чистой субъективности
JordanoBruno Автор
Спасибо за предложение, возможно, следующая статья будет именно про оценку компетенций Senior-разработчика.