Комментарии 42
НЛО прилетело и опубликовало эту надпись здесь
Вообще мне нравится идея базового тестового, но у нас сейчас соль в том, что нам интересно узнать, как именно разработчик решит задание с нуля. Какие библиотеки использует для упрощения своей работы и т.п. Мы же ищем миддла, у него должен быть наработан какой-то опыт ;-)
А вот подготовить не просто пример плохого кода, а прямо работоспособные экраны — мысль интересная, спасибо!
А вот подготовить не просто пример плохого кода, а прямо работоспособные экраны — мысль интересная, спасибо!
Подход с тестовым заданием оправдан, если одно и то же задание (а зачастую они похожи) принимают несколько потенциальных работодателей. Домашний проект может стать хорошей отрывной точкой, при необходимости его можно дорабатывать под требования разных команд. История в Git покажет как у разработчика менялись подходы к решению проблем.
А я за написание с нуля. Верстка займет не так уж много времени. Требования к дизайну-же никто не предлагает. Накидал элементы и пошел дальше. Но сама по себе она то же может много сказать о кандидате. Скажем есть разница если в XML Linear, Relative или Constraint. Поля для всех элементов идут в одном порядке или в разнобой. Кто-то скажет, что и так ведь работает, а кто-то заметит, что сопровождать легче если есть система. Можно просто накидать абы работало, а можно более-менее разложить. Все-таки для разработчика системность, аккуратность и последовательность достаточно важные качества.
А дальше, если говорить о мидле, у каждого свой подход и предрасположенность к инструментам. Кто-то любит Butter Knife, а кто-то AnroidAnnotation, кто-то использует Room, а кто-то только GreenDAO. Зачем ограничивать? Тем более, что со знакомыми инструментами соискатель задачу выполнит быстрее.
К тому-же базовый проект нужно будет все время держать в актуальном стоянии. Я думаю ни для кого не секрет, что обновление библиотек может привести к многочасовой потере времени. А это мало похоже на заботу о соискателе.
И по поводу плохих практик. Бывает проекты приходят к нам уже готовыми и нужно что-то в них добавить или переделать. И делаем мы это за деньги. Если в каждом таком проекте исправлять все, что плохо, а не просто сделать свою работу, то это затягивается до бесконечности. А хорошие практики соискатель и так покажет в своем коде. А вот дать почитать чужой код- полезно. Причем не с закидонами, а самый обычный. Мы же все нормальные люди и пишем так, что бы потом это можно было сопровождать? ;)
А дальше, если говорить о мидле, у каждого свой подход и предрасположенность к инструментам. Кто-то любит Butter Knife, а кто-то AnroidAnnotation, кто-то использует Room, а кто-то только GreenDAO. Зачем ограничивать? Тем более, что со знакомыми инструментами соискатель задачу выполнит быстрее.
К тому-же базовый проект нужно будет все время держать в актуальном стоянии. Я думаю ни для кого не секрет, что обновление библиотек может привести к многочасовой потере времени. А это мало похоже на заботу о соискателе.
И по поводу плохих практик. Бывает проекты приходят к нам уже готовыми и нужно что-то в них добавить или переделать. И делаем мы это за деньги. Если в каждом таком проекте исправлять все, что плохо, а не просто сделать свою работу, то это затягивается до бесконечности. А хорошие практики соискатель и так покажет в своем коде. А вот дать почитать чужой код- полезно. Причем не с закидонами, а самый обычный. Мы же все нормальные люди и пишем так, что бы потом это можно было сопровождать? ;)
А как происходит собеседование джунов?
Видео про Xbox кстати было шикарным))
НЛО прилетело и опубликовало эту надпись здесь
Если тестовое занимает больше 1 вечера — пожалуй, со скрипом могу согласиться, но тут надо уже обсуждать детали.
Если компания потом явно может использовать результат тестового как коммерческий продукт — опять же соглашусь.
В противном случае — не согласен. Тестовое, как и собеседование — это обоюдное вложение сил как со стороны кандидата (сделать задание), так и со стороны работодателя (качественно и осмысленно проверить тестовое и дать качественную же обратную связь требует времени).
Если компания потом явно может использовать результат тестового как коммерческий продукт — опять же соглашусь.
В противном случае — не согласен. Тестовое, как и собеседование — это обоюдное вложение сил как со стороны кандидата (сделать задание), так и со стороны работодателя (качественно и осмысленно проверить тестовое и дать качественную же обратную связь требует времени).
Смотрел с двух сторон )
Со стороны соискателя. (Технологии для примера)
1. В резюме «Разработчик Android», присылают вакансию «разработчик iOS». Пишу вакансия интересная, но с iOS не работал. Отвечают — это не важно, приходите. Нам главное, чтобы вы знали javascript. )
2. Дается тестовое задание. Это не страшно, если у тебя только одно предложение. Интересно, как бы отнесся работодатель, если бы я предложил ему заплатить за него? Почему-то каждый уверен, что его вакансия настолько интересна, что кандидат готов на все ради нее. Увы, это не всегда так.
Ради «работы мечты» многие готовы и попотеть, возможно впустую, а вот ради рядового предложения…
Допустим, у Вас 3-4 собеседования в неделю, плюс работа, плюс домашние дела.
И нужно найти 4 свободных вечера.
3. Идея «покажи свой код» интересная, если у разработчика есть личные проекты. А если нет, и он все время разрабатывал коммерческий код? «Украсть» его? Я уж не говорю о том, что серьезные проекты не пишутся одним человеком.
Со стороны работодателя.
1. Составьте список вопросов в соответствии с необходимыми знаниями кандидата. А не один на все виды вакансий.
2. Подготовьте тестовое задание( в идеале каркас приложения на компьютере), чтобы после интервью можно было проверить навыки кандидата.
3. Задание не должно проверять все на свете, только ключевые для вас вещи и иметь разумное время выполнения.
4. Собеседовать должен не «разработчик-интроверт», а team-lead. Который сможет оценить и знания кандидата, и способность работы в команде.
5. На собеседовании прекрасно видно, кто знает, а кто нет, если сами хорошо разбираетесь в теме. Намного лучше, чем тестовое задание, как это не странно. Впрочем его все равно лучше дать, это дополнит интервью.
Со стороны соискателя. (Технологии для примера)
1. В резюме «Разработчик Android», присылают вакансию «разработчик iOS». Пишу вакансия интересная, но с iOS не работал. Отвечают — это не важно, приходите. Нам главное, чтобы вы знали javascript. )
2. Дается тестовое задание. Это не страшно, если у тебя только одно предложение. Интересно, как бы отнесся работодатель, если бы я предложил ему заплатить за него? Почему-то каждый уверен, что его вакансия настолько интересна, что кандидат готов на все ради нее. Увы, это не всегда так.
Ради «работы мечты» многие готовы и попотеть, возможно впустую, а вот ради рядового предложения…
Допустим, у Вас 3-4 собеседования в неделю, плюс работа, плюс домашние дела.
И нужно найти 4 свободных вечера.
3. Идея «покажи свой код» интересная, если у разработчика есть личные проекты. А если нет, и он все время разрабатывал коммерческий код? «Украсть» его? Я уж не говорю о том, что серьезные проекты не пишутся одним человеком.
Со стороны работодателя.
1. Составьте список вопросов в соответствии с необходимыми знаниями кандидата. А не один на все виды вакансий.
2. Подготовьте тестовое задание( в идеале каркас приложения на компьютере), чтобы после интервью можно было проверить навыки кандидата.
3. Задание не должно проверять все на свете, только ключевые для вас вещи и иметь разумное время выполнения.
4. Собеседовать должен не «разработчик-интроверт», а team-lead. Который сможет оценить и знания кандидата, и способность работы в команде.
5. На собеседовании прекрасно видно, кто знает, а кто нет, если сами хорошо разбираетесь в теме. Намного лучше, чем тестовое задание, как это не странно. Впрочем его все равно лучше дать, это дополнит интервью.
НЛО прилетело и опубликовало эту надпись здесь
Со стороны соискателя.
1) Чертовски забавная иллюстрация) Но я бы предположил, что в компании используется какая-нибудь кроссплатформа на базе JS, например React Native. Мы вот например сразу предупреждаем, что у нас Xamarin и сразу под две платформы, но если нет опыта именно в нём, но есть в нативной разработке — для нас это не критично.
2-3) Вот именно для такого и даётся выбор — пример своего кода или тестовое. Если у человека нет первого и не хочет делать второго, то да, в этом случае наше решение работает как фильтр на входе. И это осознанное решение — оно кажется меньшим злом, чем всевозможные квизы. Мы рассчитываем на такую (вроде бы немалую) вероятность, что разработчик докачавшийся до миддла разрабатывал не только в рабочее время, но и сам, для своего удовольствия копался в этой области, а значит у него есть какие-то наработки. А если и нет — вот тестовое в качестве альтернативы.
Ну мне кажется 3-4 собеседования за неделю это перебор. Лучше же максимум по одному в неделю, чтобы иметь время проанализировать результаты, отрефлексировать, обдумать вопросы, что-то покопать… Но опять таки, согласен — всякое в жизни бывает, не всегда есть возможность искать работу в комфортном темпе.
Со стороны работодателя.
Со всем согласен! И тимлид на нашем собеседовании обязательно участвует) Но обычно с тимлидом идёт и кто-нибудь из разработки, потому что это:
1) дополнительное мнение о кандидате
2) прокачка других разработчиков, в том числе в софтскиллах
1) Чертовски забавная иллюстрация) Но я бы предположил, что в компании используется какая-нибудь кроссплатформа на базе JS, например React Native. Мы вот например сразу предупреждаем, что у нас Xamarin и сразу под две платформы, но если нет опыта именно в нём, но есть в нативной разработке — для нас это не критично.
2-3) Вот именно для такого и даётся выбор — пример своего кода или тестовое. Если у человека нет первого и не хочет делать второго, то да, в этом случае наше решение работает как фильтр на входе. И это осознанное решение — оно кажется меньшим злом, чем всевозможные квизы. Мы рассчитываем на такую (вроде бы немалую) вероятность, что разработчик докачавшийся до миддла разрабатывал не только в рабочее время, но и сам, для своего удовольствия копался в этой области, а значит у него есть какие-то наработки. А если и нет — вот тестовое в качестве альтернативы.
Ну мне кажется 3-4 собеседования за неделю это перебор. Лучше же максимум по одному в неделю, чтобы иметь время проанализировать результаты, отрефлексировать, обдумать вопросы, что-то покопать… Но опять таки, согласен — всякое в жизни бывает, не всегда есть возможность искать работу в комфортном темпе.
Со стороны работодателя.
Со всем согласен! И тимлид на нашем собеседовании обязательно участвует) Но обычно с тимлидом идёт и кто-нибудь из разработки, потому что это:
1) дополнительное мнение о кандидате
2) прокачка других разработчиков, в том числе в софтскиллах
Со стороны соискателя.
2-3) Интересно, а Вы тоже проводите собеседования по одному в неделю? Или «ищите в неспешном темпе»?
3-4 в неделю, потому как еще неделю-другую Вы будете ждать ответ, и выбора у Вас не будет. Т.е. для работодателя нормально иметь выбор, а для кандидата нет? )
Идея: Вы сделаете все, что мы захотим, «это же в Ваших интересах!» (реальная фраза) не всегда актуальна, работодатель заинтересован не меньше.
И кстати, у меня нет кода, который я бы мог представить. Поскольку мои личные проекты — «это исследовательские вещи», тестирование концепций, технологий, прототипов. Там есть и баги, и минимум тестов, и «не причесанные» куски кода, чего нет в рабочих проектах. Если какие-то наработки впоследствии использую в работе, то они выглядят уже совсем по-другому. Но это уже коммерческий код.
Есть несколько интересных вещей, которые можно довести до продукта, но нужна переработка кода и доработка функционала — особо не покажешь.
Со стороны работодателя.
речь о фразе «А уж как радуется собеседующий-интроверт, которому не нужно проводить по 1-2 собеседованию в неделю, если б вы только знали!».
Если он не хочет проводить эти собеседования так часто, он просто может не ходить)
Тимлид будет собеседовать один. )
Оценку знаний на отметку не люблю.
Вот оцените знание Вашей любимой технологии по 10-бальной шкале.
Оценили?
Вряд ли это будет 10. Это прямо уровень «бог» )
Да и 9 вряд ли. (Хотя уже возможно, но побывав на конференциях и почитав статьи ...)
Скорее 7-8. В зависимости от скромности ;)
А теперь представьте, что кандидат говорит вам 8.
Т.е. получается, что он как минимум, должен знать ее не хуже Вас. )
А по факту он имеет ввиду, что он хорошо ее знает.
Лучше не баллы, а примерное разделение по уровню.
Очень хорошо знаю.
Хорошо знаю.
Знаю, доводилось работать.
Изучал по книгам, опыта нет.
Не знаю.
2-3) Интересно, а Вы тоже проводите собеседования по одному в неделю? Или «ищите в неспешном темпе»?
3-4 в неделю, потому как еще неделю-другую Вы будете ждать ответ, и выбора у Вас не будет. Т.е. для работодателя нормально иметь выбор, а для кандидата нет? )
Идея: Вы сделаете все, что мы захотим, «это же в Ваших интересах!» (реальная фраза) не всегда актуальна, работодатель заинтересован не меньше.
И кстати, у меня нет кода, который я бы мог представить. Поскольку мои личные проекты — «это исследовательские вещи», тестирование концепций, технологий, прототипов. Там есть и баги, и минимум тестов, и «не причесанные» куски кода, чего нет в рабочих проектах. Если какие-то наработки впоследствии использую в работе, то они выглядят уже совсем по-другому. Но это уже коммерческий код.
Есть несколько интересных вещей, которые можно довести до продукта, но нужна переработка кода и доработка функционала — особо не покажешь.
Со стороны работодателя.
речь о фразе «А уж как радуется собеседующий-интроверт, которому не нужно проводить по 1-2 собеседованию в неделю, если б вы только знали!».
Если он не хочет проводить эти собеседования так часто, он просто может не ходить)
Тимлид будет собеседовать один. )
Оценку знаний на отметку не люблю.
Вот оцените знание Вашей любимой технологии по 10-бальной шкале.
Оценили?
Вряд ли это будет 10. Это прямо уровень «бог» )
Да и 9 вряд ли. (Хотя уже возможно, но побывав на конференциях и почитав статьи ...)
Скорее 7-8. В зависимости от скромности ;)
А теперь представьте, что кандидат говорит вам 8.
Т.е. получается, что он как минимум, должен знать ее не хуже Вас. )
А по факту он имеет ввиду, что он хорошо ее знает.
Лучше не баллы, а примерное разделение по уровню.
Очень хорошо знаю.
Хорошо знаю.
Знаю, доводилось работать.
Изучал по книгам, опыта нет.
Не знаю.
Либо разработчик натыкается на вакансию и высылает резюме, после чего HR отправляет ему несколько уточняющих вопросов, либо HR натыкается на резюме разработчика, после чего высылает ему примерно тот же самый ряд вопросов.А можно взглянуть на конкретный пример таких вопросов?
Эти вопросы — минимальный фильтр на адекватность, никаких технических вопросов не будет. Дальше резюме и ответы передаются уже разработчику со стороны нанимателя, и тот принимает решение, идём дальше или нет.
На собеседовании обязательно будут не только разговоры за жистьА можно конкретнее? Какие «разговоры за жисть»? Зачем это нужно?
1) Сюда могут попасть и уточнение каких-нибудь деталей, например «занимался таким то приложением» может вызывать вопросы «писал один или в команде», «если в команде, то кто отвечал за архитектуру», «пришёл на готовый проект или писал с нуля» и т.п. Если из резюме видно несколько разработанных продуктов — это наведёт на вопрос о том, какой из проектов показался интереснее всего и почему и т.п.
2) Это я так назвал вводную «не техническую» часть беседы, которая с одной стороны призваны помочь расслабиться кандидату, а с другой — узнать его бэкграунд. Например почему человек пошёл именно в мобильную разработку и именно под такую то платформу, как был построен процесс разработки на предыдущем месте, чем ему этот процесс нравился или не нравился и подобное.
2) Это я так назвал вводную «не техническую» часть беседы, которая с одной стороны призваны помочь расслабиться кандидату, а с другой — узнать его бэкграунд. Например почему человек пошёл именно в мобильную разработку и именно под такую то платформу, как был построен процесс разработки на предыдущем месте, чем ему этот процесс нравился или не нравился и подобное.
разговоры «за жизнь» — очень важная часть собеса. Если человек «э слыш, иди сюда!» то, скорее всего, с ним сложно будет работать. Работа в команде подразумевает не только техническое общение, но и «привет как дела» за чаем.
Приятно читать, что бывают и адекватные работодатели.
Я бы к вашей методике добавил вот что. Тестовый проект должен быть предоставлен в виде ссылки на Git (или на то, что обычно использует соискатель). По логу очень хорошо видно как работает человек. Или все последовательно закомичено и видны все этапы или комит только один. К тому-же точно убедитесь, что человек умеет пользоваться Git-ом ;) А то случаи разные бывают.
В тестовом задании или на втором этапе соискателю можно предложить применить ту технологию, которую он не знает. Это покажет как быстро он учится и умеет-ли вообще это делать. На самом деле это куда более важно чем то, что человек знает.
И я бы не стал делать упор на технической части собеседования. Я же не думаю, что в вашей команде все работают исключительно под давлением, интернета у вас нет, а использование документации карается штрафами. Обычно на собеседовании человек расскажет вам примерно половину, а то и треть от того, что он знает в обычной ситуации. А я сильно сомневаюсь, что вам нужен человек, который очень хорошо проходит собеседования ;) А то я знаю такой случай. Взяли человека. Блестяще прошел собеседование. На него возлагали большие надежды. Но по факту оказалось, что он ни рыба ни мясо и вообще ноль без палочки. Но собеседования он проходит великолепно.
Я бы к вашей методике добавил вот что. Тестовый проект должен быть предоставлен в виде ссылки на Git (или на то, что обычно использует соискатель). По логу очень хорошо видно как работает человек. Или все последовательно закомичено и видны все этапы или комит только один. К тому-же точно убедитесь, что человек умеет пользоваться Git-ом ;) А то случаи разные бывают.
В тестовом задании или на втором этапе соискателю можно предложить применить ту технологию, которую он не знает. Это покажет как быстро он учится и умеет-ли вообще это делать. На самом деле это куда более важно чем то, что человек знает.
И я бы не стал делать упор на технической части собеседования. Я же не думаю, что в вашей команде все работают исключительно под давлением, интернета у вас нет, а использование документации карается штрафами. Обычно на собеседовании человек расскажет вам примерно половину, а то и треть от того, что он знает в обычной ситуации. А я сильно сомневаюсь, что вам нужен человек, который очень хорошо проходит собеседования ;) А то я знаю такой случай. Взяли человека. Блестяще прошел собеседование. На него возлагали большие надежды. Но по факту оказалось, что он ни рыба ни мясо и вообще ноль без палочки. Но собеседования он проходит великолепно.
Статья тронула, спасибо.
Расскажу про свой случай, из последних.
Собеседовался на позицию senior .net fullstack в компанию-аггрегатора рекламных/медиа платформ с мировым именем. На собеседовании мне не задали ни одного конкретного тех. вопроса. Все вопросы в духе «а делали вот это? а работали с этим? как относитесь к тестовому заданию ?».
Ближе к вечеру прислали тестовое задание: нужно было написать клиента для гитхаба, производящего поиск по репозиториям согласно поисковому запросу. Результаты сохранять в бд, должна быть сортировка по куче полей с гитхаба. Плюс каждый репозиторий, из результата поиска, должно быть возможным обновить (для получения дифа по звездам, коммитам и т.д). Итого: бд + бек с орм + ui. В итоге тянет на готовый продукт. Срок реализации, по условиям, 2-3 дня.
Лично мне, для выполнения задачи, пришлось бы потратить порядка двух дней на изучение апи гитхаба и, собственно, реализацию. И таки да — это с полным погружением (~6-8 часов в день).
Передав свою оценку трудозатрат и рентабельности траты времени на реализацию мне ответили — наш джун сделает это меньшем, чем за день. Немного подгорело, но ладно.
Мое видение тестовых заданий — максимум пара часов дома, без потенциала готового продукта.
Расскажу про свой случай, из последних.
Собеседовался на позицию senior .net fullstack в компанию-аггрегатора рекламных/медиа платформ с мировым именем. На собеседовании мне не задали ни одного конкретного тех. вопроса. Все вопросы в духе «а делали вот это? а работали с этим? как относитесь к тестовому заданию ?».
Ближе к вечеру прислали тестовое задание: нужно было написать клиента для гитхаба, производящего поиск по репозиториям согласно поисковому запросу. Результаты сохранять в бд, должна быть сортировка по куче полей с гитхаба. Плюс каждый репозиторий, из результата поиска, должно быть возможным обновить (для получения дифа по звездам, коммитам и т.д). Итого: бд + бек с орм + ui. В итоге тянет на готовый продукт. Срок реализации, по условиям, 2-3 дня.
Лично мне, для выполнения задачи, пришлось бы потратить порядка двух дней на изучение апи гитхаба и, собственно, реализацию. И таки да — это с полным погружением (~6-8 часов в день).
Передав свою оценку трудозатрат и рентабельности траты времени на реализацию мне ответили — наш джун сделает это меньшем, чем за день. Немного подгорело, но ладно.
Мое видение тестовых заданий — максимум пара часов дома, без потенциала готового продукта.
Но ведь все правильно получилось. Вы поняли, что эта фирма не для вас, фирма поняла, что вы им не подходите. Никто не потерял времени. Как по мне, так вин-вин ситуация.
Присоединяюсь к @Gespear, плюс добавлю такой момент «что-то показать с GitHub» тоже встречается как типовое мобильное задание, но там обычно нет фильтров или есть какой-то один очень простой. Т.е., написав один раз такое тестовое можно пересылать его потом ещё минимум дюжине других компаний.
Может оказаться, что джун это за час сделает, если он год только этим и занимался. Вопрос в том, нужен ли именно человек со знанием api гитхаба? Если да, то можно написать это в требованиях.
Учитывая что вы предполагаете один вечер на такого рода задание, что вы предполагаете в нем увидеть? Большинство людей работают на готовых проектах и даже при идеальном понимании архитектуры, вдумчиво воссоздать ее с нуля — дело требующее некоторого времени на обдумывание.
Накидать «абы как» лишь бы работало — да, можно и за вечер. Вдумчиво подойти к архитектуре, учесть корнер кейсы, написать хоть пару тестов — нуууу, я бы сказал дня 3 точно займет.
Накидать «абы как» лишь бы работало — да, можно и за вечер. Вдумчиво подойти к архитектуре, учесть корнер кейсы, написать хоть пару тестов — нуууу, я бы сказал дня 3 точно займет.
например решение некоторого кол-ва задач, вырванных из контекста, на время. Без вариантов ответа — нужно писать код. Возможно с мат. уклоном, алгоритмических, архитектурных и или просто на знание платформы.
Желающих тратить даже один полный день для выполнения подобного рода задач будет полтора человека: соискатель либо активно ищет и работает или просто по три собеседования в день. И тут выбор — не ходить на работу или на собеседования пару дней ради работы над тестовым заданием, с крайне туманным профитом.
Желающих тратить даже один полный день для выполнения подобного рода задач будет полтора человека: соискатель либо активно ищет и работает или просто по три собеседования в день. И тут выбор — не ходить на работу или на собеседования пару дней ради работы над тестовым заданием, с крайне туманным профитом.
Тесты в нашем случае совсем не обязательны, а смотреть будем на многое: как автор работает с базой (и какой базой), как перемещается между экранами (и что выбрал в качестве экранов — например на android можно выбрать activity или fragment), как валидирует ввод, использует ли IoC контейнер и т.п. Интересно, какие из типовых решений выберет кандидат, а потом на собеседование — послушать аргументацию, пообсуждать, почему не выбрать другое решение и так далее. И аргументация не менее важна, чем само решение.
Вы не совсем поняли мой поинт. Да, все это можно проверить, но кроме того вы наверняка будете ожидать увидеть зачатки тестируемой, расширяемой архитектуры, грамотно разбитой по слоям. И эта задача сильно отличается от повседневной работы 99% разработчиков, а потому потребует достаточно много времени. Если же вы этого не ожидаете, то как прелагали выше — почему бы не проделать всю эту работу за кандидата, предоставив ему готовое приложение в котором нужно доработать какую-то часть?
А это ещё один момент, который можно проверить: насколько кандидат умеет не оверинженерить без лишней необходимости ;-)
Тестовое задание имитирует начало работы над настоящим проектом и ИМХО кандидаты относятся к нему соответствующим образом. Разве что если вы в требованиях первым делом пишите, что решение должно быть максимально простым и не нужно заотиться о его тестируемости и масштабируемости.
Как показывает моя практика — кандидаты в большинстве своём всё-таки подходят к задаче именно с точки зрения «выполнить разумный минимум». Т.е., нет попытки сделать максимально гибко с точки зрения развития на 58 лет вперёд, но и нет прибивания всё и вся гвоздями. И как по мне, это как раз попадет под определение «начала проекта»: закладывается возможность развития, но без фанатизма, ведь новый продукт может после пары релизов быть выкинут. MVP, вот это вот всё.
Ну и в конце концов, если у кандидата есть сомнения — он может уточнить, с учётом чего и упором на что стоит писать приложение. Это тоже показатель — будет ли он задавать вопросы и какие? Или попытается непонятные ему моменты додумать сам?
P.S. Я понимаю, что мой опыт нужно экстраполировать очень аккуратно)
Ну и в конце концов, если у кандидата есть сомнения — он может уточнить, с учётом чего и упором на что стоит писать приложение. Это тоже показатель — будет ли он задавать вопросы и какие? Или попытается непонятные ему моменты додумать сам?
P.S. Я понимаю, что мой опыт нужно экстраполировать очень аккуратно)
Допустим, я могу использовать 3 разных вида баз, но проще взять текстовый файл и писать туда. Это проще и решает задачу. IoC тоже не факт, в небольших участках кода преимуществ не будет. И т.д.
Что-то понять можно, вопрос в том, не что он выбрал, а почему выбрал не это, а вот это.
Что-то понять можно, вопрос в том, не что он выбрал, а почему выбрал не это, а вот это.
Как по мне, просьба сделать тестовое задание уже провальная идея. Почему никто не учитывает тот факт, что разработчик который находится в поиске работы, принимает не одно или два предложения в неделю, а около десяти, и каждый из них просят сделать тестовое задание, а некоторые просят это делать сразу при собеседовании где вокруг тебя сидит 5 человек и смотрят как на дебила.
Мне кажется, что разработчик может находиться минимум в двух состояниях:
В первом случае я могу понять, не до тестовых. А во втором? Никуда не торопишься, за раз больше одного тестового не берёшь, больше одного собеседования не назначаешь, можешь проверить свой скилл, возможность добавить новый проект в гитхаб… плюсы есть, минусы не очевидны.
Ну и соглашусь, давать задачу объёма тестового непосредственно на собеседовании — это перебор. По-моему, задачи по написанию или (ещё лучше) редактированию кода на собеседовании могут быть, но они должны быть максимально небольшими.
- активном поиске работы (уволился с предыдущего места)
- пассивном поиске работы (пока работает на старом, но уже ищет новое)
В первом случае я могу понять, не до тестовых. А во втором? Никуда не торопишься, за раз больше одного тестового не берёшь, больше одного собеседования не назначаешь, можешь проверить свой скилл, возможность добавить новый проект в гитхаб… плюсы есть, минусы не очевидны.
Ну и соглашусь, давать задачу объёма тестового непосредственно на собеседовании — это перебор. По-моему, задачи по написанию или (ещё лучше) редактированию кода на собеседовании могут быть, но они должны быть максимально небольшими.
Комментарий был ответом Kernell, но или хабр посчитал иначе, или я промазал.
2. Не ищет новое, а в принципе не против что-то посмотреть, но не настроен уходить в первое попавшееся хорошее место. Значит вы ему должны предложить «работу мечты». ) Т.е. что-то, что сподвигнет его «броситься в ваши объятья» ;) А не к конкурентам, которые тоже предлагают прийти к ним «поговорить».
Бывают ситуации, когда в активном поиске, но не уволился с предыдущего места. Количество пар глаз, которые смотрели меня на идиота в такие дни — безумно огромное. Потому что единственный вариант — назначать собеседование сразу после работы,-- на текущую езжу рано. И тут уже как карта ляжет, либо мозг отключится от перегруза и превратится в лапшу, либо все пройдет как по маслу. Самый угарный вариант — третий, когда мозг отключается через 30-40 минут общения.
Так вот, рабочий день + исследовательская + по собеседованию ежедневно. Я отказываюсь писать код на бумажке потому, что могу что угодно объяснить на пальцах, но поплыву, если начну писать инструкции.
Расписание забивается на неделю-полторы вперед.
И вот у меня есть свободные 2 часа в сутках, которые мне нужны для торможения активности и последующего засыпания. В моем случае куда предпочтительней тех.собес, где я отвечаю на вопросы «как». Более того, в этом случае можно отсеивать религиозно настроенные компании. Например, один отказ я получил после краткой и взвешенной критики продуктов JetBrains (и да, это было не с бухты барахты, а ответ на вопрос «почему не используете пычарм»). Потому что разрабы на них, буквально, молятся.
Так вот, рабочий день + исследовательская + по собеседованию ежедневно. Я отказываюсь писать код на бумажке потому, что могу что угодно объяснить на пальцах, но поплыву, если начну писать инструкции.
Расписание забивается на неделю-полторы вперед.
И вот у меня есть свободные 2 часа в сутках, которые мне нужны для торможения активности и последующего засыпания. В моем случае куда предпочтительней тех.собес, где я отвечаю на вопросы «как». Более того, в этом случае можно отсеивать религиозно настроенные компании. Например, один отказ я получил после краткой и взвешенной критики продуктов JetBrains (и да, это было не с бухты барахты, а ответ на вопрос «почему не используете пычарм»). Потому что разрабы на них, буквально, молятся.
Не стоит забывать про очень важные моменты:
1) что Вы продаете позицию, а не просто покупаете специалиста, т е у вас есть конкуренты в лице других работодателей
2) цените и свое и чужое время, т е макс на все собеседования и задания с проверками должно занять не более 2-х часов (идеал-45 минут) на одного кандидата. Иначе-проще выбрать другого работодателя в силу п.1, у которого процесс найма более оптимизирован.
И есть две крайности в найме:
1) если что-то не так, то не брать
2) почти всегда брать, а на исп сроке определиться, если по общению (не только по профилю) сомнений нет
На самом деле важно понять что можно получить от человека на время исп срока. И если польза есть, то брать, а во время исп срока уже окончательно определиться. Если пользу не получили, то нужно работать над собой. Однако, доводить до п.1-это не выход, а показатель банального подхода к проверке компетенций человека. Опытный рекрутер за 15 минут из простого общения поймет уровень личных качеств, а опытный технарь (компетенции в технической части и в управлении человеческим капиталом, т е проще говоря-технический руководитель) еще за столько же-можно ли подпускать на исп срок (т е какую пользу кандидат может принести в компанию). И выбрать самого оптимального (не лучшего, а оптимального по всем параметрам) для данной (а может и другой) вакансии за определенное выделенное время (поиски вечными же не могут быть).
Когда меня собеседовали, то было всего 3 почти идеальных собеседования (первый-45 мин и я поработал в компании почти 4 года, второй-30 минут и работаю аутсорс более 2-х лет, и посл-1 час). Эти все собеседования были в форме просто общения-никаких запросов, примеров, кодов и прямых вопросов типа почему Вы решили сменить работу-все узнавали неявным образом из беседы, что более правильно, т к на прямые вопросы можно дать подготовленные и часто несовсем правдивые ответы.
И не стоит забывать когнитивные особенности человека, а именно, что в большинстве случаев сосредоточенно воспринимать информацию сознание способно первые 40-50 минут, а далее уже все меньше восприниматься будет.
1) что Вы продаете позицию, а не просто покупаете специалиста, т е у вас есть конкуренты в лице других работодателей
2) цените и свое и чужое время, т е макс на все собеседования и задания с проверками должно занять не более 2-х часов (идеал-45 минут) на одного кандидата. Иначе-проще выбрать другого работодателя в силу п.1, у которого процесс найма более оптимизирован.
И есть две крайности в найме:
1) если что-то не так, то не брать
2) почти всегда брать, а на исп сроке определиться, если по общению (не только по профилю) сомнений нет
На самом деле важно понять что можно получить от человека на время исп срока. И если польза есть, то брать, а во время исп срока уже окончательно определиться. Если пользу не получили, то нужно работать над собой. Однако, доводить до п.1-это не выход, а показатель банального подхода к проверке компетенций человека. Опытный рекрутер за 15 минут из простого общения поймет уровень личных качеств, а опытный технарь (компетенции в технической части и в управлении человеческим капиталом, т е проще говоря-технический руководитель) еще за столько же-можно ли подпускать на исп срок (т е какую пользу кандидат может принести в компанию). И выбрать самого оптимального (не лучшего, а оптимального по всем параметрам) для данной (а может и другой) вакансии за определенное выделенное время (поиски вечными же не могут быть).
Когда меня собеседовали, то было всего 3 почти идеальных собеседования (первый-45 мин и я поработал в компании почти 4 года, второй-30 минут и работаю аутсорс более 2-х лет, и посл-1 час). Эти все собеседования были в форме просто общения-никаких запросов, примеров, кодов и прямых вопросов типа почему Вы решили сменить работу-все узнавали неявным образом из беседы, что более правильно, т к на прямые вопросы можно дать подготовленные и часто несовсем правдивые ответы.
И не стоит забывать когнитивные особенности человека, а именно, что в большинстве случаев сосредоточенно воспринимать информацию сознание способно первые 40-50 минут, а далее уже все меньше восприниматься будет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Идеальное (наверное) собеседование мобильного разработчика-мидла