Идеальное (наверное) собеседование мобильного разработчика-мидла

    За последнее время на хабре вышло столько рассказов о плохих собеседованиях, что порой закрадывается сомнение, а бывают ли в природе собеседования хорошие? Так что разнообразия ради в этом мы рассмотрим пример хорошего* подхода. Рассказ будет идти с точки зрения разработчика работодателя, который напрямую участвует в процессе найма.



    * наверное

    Диспозиция


    Маленькая продуктовая команда (30-40 человек) внутри крупной компании (несколько тысяч человек). В команду входят все, кто занимается проектом: фуллстек разработчики и фронтедеры, дизайнеры и интерфейсологи, тестировщики, спецы по пиару, аналитики, авторы текстов и т.п. В общем, мы стараемся поменьше аутсорсить профильную работу в другие проекты, и мобильная разработка — не исключение.

    Мобильное приложение у нас кроссплатформенное, написано на Xamarin Native под iOS и Android. При этом мы полностью готовы брать в меру опытного разработчика, писавшего только под одну платформу, при условии, что он готов изучать разработку под вторую ОС.

    Этап 0 — встретились два одиночества


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

    Эти вопросы — минимальный фильтр на адекватность, никаких технических вопросов не будет. Дальше резюме и ответы передаются уже разработчику со стороны нанимателя, и тот принимает решение, идём дальше или нет. За последний месяц я посмотрел пару десятков резюме, и понятия не имею, что должен написать и ответить кандидат, чтобы мне пришлось сказать «нет» уже на этом этапе. Написать на вакансию Android-разработчика «пишу только под iOS, потому что Android – полный отстой»?

    Этап 1 — тестовое задание или пример кода


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

    • три экрана: два связанных списка + форма ввода данных, которую при желании можно заменить на модальное окно
    • работа с сетью
    • работа с хранилищем данных (задание подразумевает БД, если разработчик сможет обосновать другой вывод — милости просим)

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

    • приложение слишком маленькое, код не показателен или вызывает слишком много вопросов просим таки сделать наше тестовое
    • приложение подходящее, но есть нюансы — просим сделать небольшие доработки (меньше чем на вечер)

    По результатам тестового мы или зовём разработчика на собеседование, или даём отказ, но во втором случае будет дан подробнейший отзыв — что сделано хорошо, что спорно, какие возникают вопросы, что стоит почитать и так далее. В результате выигрывают все:

    • кандидат получает код, который потом можно переиспользовать на другом собеседовании с подобными принципами, а также обратную связь для работы над собой. Работает ли оно? Ну, как минимум к нам присылали тестовые задания, изначально написанные для других компаний, так что похоже, что работает;
    • работодатель экономит время на опросниках и прочей фигне. А уж как радуется собеседующий-интроверт, которому не нужно проводить по 1-2 собеседованию в неделю, если б вы только знали!

    Этап 2 — собеседование


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

    Далее будет 1-2 небольшие практические задачки, они зависят от тестового задания. Опять таки даём в руки клавиатуру (подключенную к компьютеру, компьютер с монитором!) и просим что-нибудь написать или отредактировать. Одна из моих любимых вещей — дать рабочую, но плохо написанную функцию строчек на 10-20 и предложить её отрефакторить. Сразу становится понятно, есть ли у кандидата чуйка на «плохой код», что он знает о конструкциях языка, умеет ли читать чужой код и далее по списку.

    И это в общем-то всё. Максимум через пару-тройку дней мы дадим кандидату ответ. Впрочем, чаще всего ответ даётся в тот же день). И в случае отказа опять таки будет адекватное обоснование. Ну, а если его будет недостаточно, то кандидат всегда может попросить контакты разработчиков с собеседования для уточнения каких-то моментов, и ему их с высокой долей вероятности дадут.

    Но ведь кандидат мог и обмануть


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

    Так, стоп! Я узнал команду, о которой идёт речь, собеседовался в неё пару лет назад, и там схема сильно отличалась


    Да, каюсь, тогда я грешил небольшими опросами и собеседованиями без тестового. Много времени потратил, и своего, и чужого. Так что когда речь зашла о новых поисках разработчика, то я решил попробовать иной подход. Разработчики пишут код? Отлично! Покажи мне свой код, и я скажу, стоит ли нам собеседоваться.

    Но я и в компанию узнал! Устраивался в другой проект, и там тоже всё не так!


    А вот тут ситуация с хитринкой. К нам в компанию идёт приличный поток бэкендеров/фулл-стек разработчиков, и таких разработчиков в компании несколько сотен. Поэтому процесс их набора уже достаточно устаканился и стандартизировался. Мобильных же разработчиков в компании пока что мало, так что нам легче экспериментировать с подходами к собеседованиею.

    У описанного подхода есть и другие недостатки!


    Жду вас в комментариях. Подискутируем ;-)
    Поделиться публикацией

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

    • НЛО прилетело и опубликовало эту надпись здесь
        0
        Вообще мне нравится идея базового тестового, но у нас сейчас соль в том, что нам интересно узнать, как именно разработчик решит задание с нуля. Какие библиотеки использует для упрощения своей работы и т.п. Мы же ищем миддла, у него должен быть наработан какой-то опыт ;-)

        А вот подготовить не просто пример плохого кода, а прямо работоспособные экраны — мысль интересная, спасибо!
        • НЛО прилетело и опубликовало эту надпись здесь
            +1
            > Какие библиотеки использует для упрощения своей работы и т.п. Мы же ищем миддла, у него должен быть наработан какой-то опыт ;-)

            скорее всего вы библиотеки ищите, а не мидла
              0
              Эм… не понял. Если не трудно, разверните мысль более подробно)
            +1

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

              +2
              А я за написание с нуля. Верстка займет не так уж много времени. Требования к дизайну-же никто не предлагает. Накидал элементы и пошел дальше. Но сама по себе она то же может много сказать о кандидате. Скажем есть разница если в XML Linear, Relative или Constraint. Поля для всех элементов идут в одном порядке или в разнобой. Кто-то скажет, что и так ведь работает, а кто-то заметит, что сопровождать легче если есть система. Можно просто накидать абы работало, а можно более-менее разложить. Все-таки для разработчика системность, аккуратность и последовательность достаточно важные качества.

              А дальше, если говорить о мидле, у каждого свой подход и предрасположенность к инструментам. Кто-то любит Butter Knife, а кто-то AnroidAnnotation, кто-то использует Room, а кто-то только GreenDAO. Зачем ограничивать? Тем более, что со знакомыми инструментами соискатель задачу выполнит быстрее.

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

              И по поводу плохих практик. Бывает проекты приходят к нам уже готовыми и нужно что-то в них добавить или переделать. И делаем мы это за деньги. Если в каждом таком проекте исправлять все, что плохо, а не просто сделать свою работу, то это затягивается до бесконечности. А хорошие практики соискатель и так покажет в своем коде. А вот дать почитать чужой код- полезно. Причем не с закидонами, а самый обычный. Мы же все нормальные люди и пишем так, что бы потом это можно было сопровождать? ;)
              • НЛО прилетело и опубликовало эту надпись здесь
              +1

              А как происходит собеседование джунов?
              Видео про Xbox кстати было шикарным))

                0
                Спасибо)
                Про джунов надо узнать, ни разу не набирал. Для нашей команды именно мобильный джун разработчик пойдёт по тому же пути, но требования к нему будут пониже.
              • НЛО прилетело и опубликовало эту надпись здесь
                  +3
                  Если тестовое занимает больше 1 вечера — пожалуй, со скрипом могу согласиться, но тут надо уже обсуждать детали.

                  Если компания потом явно может использовать результат тестового как коммерческий продукт — опять же соглашусь.

                  В противном случае — не согласен. Тестовое, как и собеседование — это обоюдное вложение сил как со стороны кандидата (сделать задание), так и со стороны работодателя (качественно и осмысленно проверить тестовое и дать качественную же обратную связь требует времени).
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Вложение сил обоюдное, но при этом оно оплачивается всем, кроме кандидата.
                    0
                    Смотрел с двух сторон )
                    Со стороны соискателя. (Технологии для примера)
                    1. В резюме «Разработчик Android», присылают вакансию «разработчик iOS». Пишу вакансия интересная, но с iOS не работал. Отвечают — это не важно, приходите. Нам главное, чтобы вы знали javascript. )
                    2. Дается тестовое задание. Это не страшно, если у тебя только одно предложение. Интересно, как бы отнесся работодатель, если бы я предложил ему заплатить за него? Почему-то каждый уверен, что его вакансия настолько интересна, что кандидат готов на все ради нее. Увы, это не всегда так.
                    Ради «работы мечты» многие готовы и попотеть, возможно впустую, а вот ради рядового предложения…
                    Допустим, у Вас 3-4 собеседования в неделю, плюс работа, плюс домашние дела.
                    И нужно найти 4 свободных вечера.
                    3. Идея «покажи свой код» интересная, если у разработчика есть личные проекты. А если нет, и он все время разрабатывал коммерческий код? «Украсть» его? Я уж не говорю о том, что серьезные проекты не пишутся одним человеком.
                    Со стороны работодателя.
                    1. Составьте список вопросов в соответствии с необходимыми знаниями кандидата. А не один на все виды вакансий.
                    2. Подготовьте тестовое задание( в идеале каркас приложения на компьютере), чтобы после интервью можно было проверить навыки кандидата.
                    3. Задание не должно проверять все на свете, только ключевые для вас вещи и иметь разумное время выполнения.
                    4. Собеседовать должен не «разработчик-интроверт», а team-lead. Который сможет оценить и знания кандидата, и способность работы в команде.
                    5. На собеседовании прекрасно видно, кто знает, а кто нет, если сами хорошо разбираетесь в теме. Намного лучше, чем тестовое задание, как это не странно. Впрочем его все равно лучше дать, это дополнит интервью.
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        Со стороны соискателя.

                        1) Чертовски забавная иллюстрация) Но я бы предположил, что в компании используется какая-нибудь кроссплатформа на базе JS, например React Native. Мы вот например сразу предупреждаем, что у нас Xamarin и сразу под две платформы, но если нет опыта именно в нём, но есть в нативной разработке — для нас это не критично.

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

                        Ну мне кажется 3-4 собеседования за неделю это перебор. Лучше же максимум по одному в неделю, чтобы иметь время проанализировать результаты, отрефлексировать, обдумать вопросы, что-то покопать… Но опять таки, согласен — всякое в жизни бывает, не всегда есть возможность искать работу в комфортном темпе.

                        Со стороны работодателя.

                        Со всем согласен! И тимлид на нашем собеседовании обязательно участвует) Но обычно с тимлидом идёт и кто-нибудь из разработки, потому что это:

                        1) дополнительное мнение о кандидате
                        2) прокачка других разработчиков, в том числе в софтскиллах
                          0
                          Со стороны соискателя.
                          2-3) Интересно, а Вы тоже проводите собеседования по одному в неделю? Или «ищите в неспешном темпе»?
                          3-4 в неделю, потому как еще неделю-другую Вы будете ждать ответ, и выбора у Вас не будет. Т.е. для работодателя нормально иметь выбор, а для кандидата нет? )
                          Идея: Вы сделаете все, что мы захотим, «это же в Ваших интересах!» (реальная фраза) не всегда актуальна, работодатель заинтересован не меньше.
                          И кстати, у меня нет кода, который я бы мог представить. Поскольку мои личные проекты — «это исследовательские вещи», тестирование концепций, технологий, прототипов. Там есть и баги, и минимум тестов, и «не причесанные» куски кода, чего нет в рабочих проектах. Если какие-то наработки впоследствии использую в работе, то они выглядят уже совсем по-другому. Но это уже коммерческий код.
                          Есть несколько интересных вещей, которые можно довести до продукта, но нужна переработка кода и доработка функционала — особо не покажешь.
                          Со стороны работодателя.
                          речь о фразе «А уж как радуется собеседующий-интроверт, которому не нужно проводить по 1-2 собеседованию в неделю, если б вы только знали!».
                          Если он не хочет проводить эти собеседования так часто, он просто может не ходить)
                          Тимлид будет собеседовать один. )
                          Оценку знаний на отметку не люблю.
                          Вот оцените знание Вашей любимой технологии по 10-бальной шкале.
                          Оценили?
                          Вряд ли это будет 10. Это прямо уровень «бог» )
                          Да и 9 вряд ли. (Хотя уже возможно, но побывав на конференциях и почитав статьи ...)
                          Скорее 7-8. В зависимости от скромности ;)
                          А теперь представьте, что кандидат говорит вам 8.
                          Т.е. получается, что он как минимум, должен знать ее не хуже Вас. )
                          А по факту он имеет ввиду, что он хорошо ее знает.
                          Лучше не баллы, а примерное разделение по уровню.
                          Очень хорошо знаю.
                          Хорошо знаю.
                          Знаю, доводилось работать.
                          Изучал по книгам, опыта нет.
                          Не знаю.
                        +1
                        Либо разработчик натыкается на вакансию и высылает резюме, после чего HR отправляет ему несколько уточняющих вопросов, либо HR натыкается на резюме разработчика, после чего высылает ему примерно тот же самый ряд вопросов.

                        Эти вопросы — минимальный фильтр на адекватность, никаких технических вопросов не будет. Дальше резюме и ответы передаются уже разработчику со стороны нанимателя, и тот принимает решение, идём дальше или нет.
                        А можно взглянуть на конкретный пример таких вопросов?

                        На собеседовании обязательно будут не только разговоры за жисть
                        А можно конкретнее? Какие «разговоры за жисть»? Зачем это нужно?
                          0
                          1) Сюда могут попасть и уточнение каких-нибудь деталей, например «занимался таким то приложением» может вызывать вопросы «писал один или в команде», «если в команде, то кто отвечал за архитектуру», «пришёл на готовый проект или писал с нуля» и т.п. Если из резюме видно несколько разработанных продуктов — это наведёт на вопрос о том, какой из проектов показался интереснее всего и почему и т.п.

                          2) Это я так назвал вводную «не техническую» часть беседы, которая с одной стороны призваны помочь расслабиться кандидату, а с другой — узнать его бэкграунд. Например почему человек пошёл именно в мобильную разработку и именно под такую то платформу, как был построен процесс разработки на предыдущем месте, чем ему этот процесс нравился или не нравился и подобное.
                            +1
                            разговоры «за жизнь» — очень важная часть собеса. Если человек «э слыш, иди сюда!» то, скорее всего, с ним сложно будет работать. Работа в команде подразумевает не только техническое общение, но и «привет как дела» за чаем.
                            +2
                            Приятно читать, что бывают и адекватные работодатели.

                            Я бы к вашей методике добавил вот что. Тестовый проект должен быть предоставлен в виде ссылки на Git (или на то, что обычно использует соискатель). По логу очень хорошо видно как работает человек. Или все последовательно закомичено и видны все этапы или комит только один. К тому-же точно убедитесь, что человек умеет пользоваться Git-ом ;) А то случаи разные бывают.

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

                            И я бы не стал делать упор на технической части собеседования. Я же не думаю, что в вашей команде все работают исключительно под давлением, интернета у вас нет, а использование документации карается штрафами. Обычно на собеседовании человек расскажет вам примерно половину, а то и треть от того, что он знает в обычной ситуации. А я сильно сомневаюсь, что вам нужен человек, который очень хорошо проходит собеседования ;) А то я знаю такой случай. Взяли человека. Блестяще прошел собеседование. На него возлагали большие надежды. Но по факту оказалось, что он ни рыба ни мясо и вообще ноль без палочки. Но собеседования он проходит великолепно.
                              0
                              Всегда специально удаляю git. Могу оставить, если специально попросят, но такого еще не случалось :). В таком логе нельзя увидеть, как человек решает возникающие конфликты и как он ребейзит.
                              +1
                              Статья тронула, спасибо.
                              Расскажу про свой случай, из последних.
                              Собеседовался на позицию senior .net fullstack в компанию-аггрегатора рекламных/медиа платформ с мировым именем. На собеседовании мне не задали ни одного конкретного тех. вопроса. Все вопросы в духе «а делали вот это? а работали с этим? как относитесь к тестовому заданию ?».

                              Ближе к вечеру прислали тестовое задание: нужно было написать клиента для гитхаба, производящего поиск по репозиториям согласно поисковому запросу. Результаты сохранять в бд, должна быть сортировка по куче полей с гитхаба. Плюс каждый репозиторий, из результата поиска, должно быть возможным обновить (для получения дифа по звездам, коммитам и т.д). Итого: бд + бек с орм + ui. В итоге тянет на готовый продукт. Срок реализации, по условиям, 2-3 дня.

                              Лично мне, для выполнения задачи, пришлось бы потратить порядка двух дней на изучение апи гитхаба и, собственно, реализацию. И таки да — это с полным погружением (~6-8 часов в день).
                              Передав свою оценку трудозатрат и рентабельности траты времени на реализацию мне ответили — наш джун сделает это меньшем, чем за день. Немного подгорело, но ладно.
                              Мое видение тестовых заданий — максимум пара часов дома, без потенциала готового продукта.
                                +1

                                Но ведь все правильно получилось. Вы поняли, что эта фирма не для вас, фирма поняла, что вы им не подходите. Никто не потерял времени. Как по мне, так вин-вин ситуация.

                                  0
                                  Абсолютно не правильно: три специалиста компании потеряли по часу. Я потерял три часа. Результата нет.
                                  Я мог отказаться от вакансии на этапе 0, когда мне прислали ТЗ на тестовое задание.
                                  0
                                  Присоединяюсь к @Gespear, плюс добавлю такой момент «что-то показать с GitHub» тоже встречается как типовое мобильное задание, но там обычно нет фильтров или есть какой-то один очень простой. Т.е., написав один раз такое тестовое можно пересылать его потом ещё минимум дюжине других компаний.
                                    0
                                    Может оказаться, что джун это за час сделает, если он год только этим и занимался. Вопрос в том, нужен ли именно человек со знанием api гитхаба? Если да, то можно написать это в требованиях.
                                    +1
                                    Учитывая что вы предполагаете один вечер на такого рода задание, что вы предполагаете в нем увидеть? Большинство людей работают на готовых проектах и даже при идеальном понимании архитектуры, вдумчиво воссоздать ее с нуля — дело требующее некоторого времени на обдумывание.
                                    Накидать «абы как» лишь бы работало — да, можно и за вечер. Вдумчиво подойти к архитектуре, учесть корнер кейсы, написать хоть пару тестов — нуууу, я бы сказал дня 3 точно займет.
                                      +1
                                      например решение некоторого кол-ва задач, вырванных из контекста, на время. Без вариантов ответа — нужно писать код. Возможно с мат. уклоном, алгоритмических, архитектурных и или просто на знание платформы.
                                      Желающих тратить даже один полный день для выполнения подобного рода задач будет полтора человека: соискатель либо активно ищет и работает или просто по три собеседования в день. И тут выбор — не ходить на работу или на собеседования пару дней ради работы над тестовым заданием, с крайне туманным профитом.
                                        0
                                        Тесты в нашем случае совсем не обязательны, а смотреть будем на многое: как автор работает с базой (и какой базой), как перемещается между экранами (и что выбрал в качестве экранов — например на android можно выбрать activity или fragment), как валидирует ввод, использует ли IoC контейнер и т.п. Интересно, какие из типовых решений выберет кандидат, а потом на собеседование — послушать аргументацию, пообсуждать, почему не выбрать другое решение и так далее. И аргументация не менее важна, чем само решение.
                                          0
                                          Вы не совсем поняли мой поинт. Да, все это можно проверить, но кроме того вы наверняка будете ожидать увидеть зачатки тестируемой, расширяемой архитектуры, грамотно разбитой по слоям. И эта задача сильно отличается от повседневной работы 99% разработчиков, а потому потребует достаточно много времени. Если же вы этого не ожидаете, то как прелагали выше — почему бы не проделать всю эту работу за кандидата, предоставив ему готовое приложение в котором нужно доработать какую-то часть?
                                            0
                                            А это ещё один момент, который можно проверить: насколько кандидат умеет не оверинженерить без лишней необходимости ;-)
                                              0
                                              Тестовое задание имитирует начало работы над настоящим проектом и ИМХО кандидаты относятся к нему соответствующим образом. Разве что если вы в требованиях первым делом пишите, что решение должно быть максимально простым и не нужно заотиться о его тестируемости и масштабируемости.
                                                0
                                                Как показывает моя практика — кандидаты в большинстве своём всё-таки подходят к задаче именно с точки зрения «выполнить разумный минимум». Т.е., нет попытки сделать максимально гибко с точки зрения развития на 58 лет вперёд, но и нет прибивания всё и вся гвоздями. И как по мне, это как раз попадет под определение «начала проекта»: закладывается возможность развития, но без фанатизма, ведь новый продукт может после пары релизов быть выкинут. MVP, вот это вот всё.

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

                                                P.S. Я понимаю, что мой опыт нужно экстраполировать очень аккуратно)
                                            0
                                            Допустим, я могу использовать 3 разных вида баз, но проще взять текстовый файл и писать туда. Это проще и решает задачу. IoC тоже не факт, в небольших участках кода преимуществ не будет. И т.д.
                                            Что-то понять можно, вопрос в том, не что он выбрал, а почему выбрал не это, а вот это.
                                          0
                                          Как по мне, просьба сделать тестовое задание уже провальная идея. Почему никто не учитывает тот факт, что разработчик который находится в поиске работы, принимает не одно или два предложения в неделю, а около десяти, и каждый из них просят сделать тестовое задание, а некоторые просят это делать сразу при собеседовании где вокруг тебя сидит 5 человек и смотрят как на дебила.
                                            0
                                            Мне кажется, что разработчик может находиться минимум в двух состояниях:
                                            1. активном поиске работы (уволился с предыдущего места)
                                            2. пассивном поиске работы (пока работает на старом, но уже ищет новое)


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

                                            Ну и соглашусь, давать задачу объёма тестового непосредственно на собеседовании — это перебор. По-моему, задачи по написанию или (ещё лучше) редактированию кода на собеседовании могут быть, но они должны быть максимально небольшими.
                                              0
                                              Комментарий был ответом Kernell, но или хабр посчитал иначе, или я промазал.
                                                +1
                                                2. Не ищет новое, а в принципе не против что-то посмотреть, но не настроен уходить в первое попавшееся хорошее место. Значит вы ему должны предложить «работу мечты». ) Т.е. что-то, что сподвигнет его «броситься в ваши объятья» ;) А не к конкурентам, которые тоже предлагают прийти к ним «поговорить».
                                                  0
                                                  Бывают ситуации, когда в активном поиске, но не уволился с предыдущего места. Количество пар глаз, которые смотрели меня на идиота в такие дни — безумно огромное. Потому что единственный вариант — назначать собеседование сразу после работы,-- на текущую езжу рано. И тут уже как карта ляжет, либо мозг отключится от перегруза и превратится в лапшу, либо все пройдет как по маслу. Самый угарный вариант — третий, когда мозг отключается через 30-40 минут общения.
                                                  Так вот, рабочий день + исследовательская + по собеседованию ежедневно. Я отказываюсь писать код на бумажке потому, что могу что угодно объяснить на пальцах, но поплыву, если начну писать инструкции.
                                                  Расписание забивается на неделю-полторы вперед.
                                                  И вот у меня есть свободные 2 часа в сутках, которые мне нужны для торможения активности и последующего засыпания. В моем случае куда предпочтительней тех.собес, где я отвечаю на вопросы «как». Более того, в этом случае можно отсеивать религиозно настроенные компании. Например, один отказ я получил после краткой и взвешенной критики продуктов JetBrains (и да, это было не с бухты барахты, а ответ на вопрос «почему не используете пычарм»). Потому что разрабы на них, буквально, молятся.

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

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