Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Как подходить к тестовым заданиям: советы от тех, кто их проверяет

Зачем нужны тестовые задания, как их оценивают и как с их помощью хорошо себя зарекомендовать, особенно если вы пытаетесь обойти конкурентов на вакансию Junior? Об этом мы расспросили IT-специалистов, которые в своих компаниях ответственны за проверку таких заданий.

Максим Ковтун, Chief Software Architect в Sigma Software

Процесс найма сотрудников — это воронка, каждый этап которой призван отсеять часть кандидатов. Цель воронки — оптимизировать процесс и затраты на найм.

Представьте, что на входе у вас 100 кандидатов, и вы просто приглашаете каждого на техническое собеседование и потом на повторное с руководителем. Если собеседования длятся по часу и в них участвует по два собеседующих, то вы потратите 400 часов на обработку кандидатов. После собеседований вы понимаете, что у части кандидатов вообще нет нужного вам опыта, часть не владеет нужной технологией, часть не разделяет ваши ценности, часть не может написать код, но на каждого вы потратили по 4 часа.

Возникает вопрос: а могу ли я узнать неподходящих мне кандидатов, потратив меньше четырех часов? Наверное, я могу посмотреть резюме кандидата и понять, есть ли у него нужный мне опыт. Это займет 5-10 минут и позволит отсеять вообще нерелевантных. Я могу 20 минут пообщаться с кандидатом по телефону и получить ответы на критические для меня вопросы. Я могу дать тестовое задание, проверка которого займет 10-20 минут. Этапы в процессе выстраиваются в порядке затратности: сначала идут те, которые занимают меньше времени, и дальше по увеличению затратности.

Если из резюме и общения с кандидатом мы не увидели, что кандидат может писать код, решать задачи, проектировать модули системы, мы даем тестовое задание.

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

Более опытным даем задачи на дизайн классов или структурный дизайн приложения (будет состоять из таких-то проектов, зависимости будут такие, модули будут подключаться динамически/статически, зависимости будут инджектиться вот так-то).

Как оцениваем тестовые работы. Мы стараемся детально указывать в тексте задания критерии оценки. Обращаем внимание кандидатов на то, что важно для нас, указываем, что нужно сделать обязательно, а какие вещи будут плюсом.

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

Также важна эффективность решения с точки зрения алгоритмической сложности, количества кода и затраченного времени.

Дальше мы оцениваем, насколько написанный код близок к коммерческому исполнению, а не просто является лабораторной работой. Здесь мы смотрим на стилистику кода, обработку исключительных ситуаций и ошибок, валидацию аргументов, обработку edge-кейсов.

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

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

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

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

В тестовой задаче какие-то моменты могут быть условными или не требовать реализации. Обозначьте их явно, напишите комментарий в коде или в письме: «Эту функцию не реализовал специально, так как условием задачи не требуется».

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

Если вы делаете что-то экстра (например, DI контейнер для одного интерфейса), чтобы продемонстрировать, что вы это умеете, то напишите явный комментарий — дабы не казалось, что вы перемудрили. Или напишите: «В задаче такого размера DI использовать контейнер нет необходимости, но если тут будет ..., то я бы его использовал».

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

Алексей Стягайло, QA Automation Tech Lead в KeepSolid

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

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

Для QA Automation в тестовом задании я описываю определенный user case на одном из наших ресурсов и ставлю задачу написать автотест для этого сценария. Это позволяет сразу проверить умение создавать тест-кейсы, находить элементы и писать автотесты на основании тест-кейсов.

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

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

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

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

Как кандидату хорошо себя зарекомендовать:

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

Сергей Филоненко, Tech Lead of Design Department в CHI Software

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

Можно бесконечно восторгаться удачными градиентами его портфолио и читать в CV, что он владеет Sketch на 86%. Но понять, как он думает и думает ли в принципе, можно лишь по тестовому.

Из недавних тестовых на позиции UX-дизайнера: джуниору предлагали придумать новый главный экран десктопного приложения, которое распознает лица. Миддлу давали не самый лучший wireframe мобильного приложения для записи экрана с просьбой улучшить UX и отрисовать UI.

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

Можно кинуть линк на архив, в котором папка с тремя джипегами, а можно собрать прототип в Invision с итерациями между экранами. Однако стоит заметить, что если джипеги в папке окажутся более осмысленными — возьмем первого.

Какие бывают ошибки. Зачастую кандидаты делают тестовые задания в нерабочее время на домашнем лэптопе перед сном или же на работе в обеденные перерывы подходами по 20 минут. Отсюда все беды. Многие недооценивают его важность, особенно если это шестое тестовое за неделю. Нужно больше любви. И внимания.

Как кандидату хорошо себя зарекомендовать. Задача кандидата — показать, что он попытался разобраться в доменной области, составил портрет пользователя, то есть подошел к решению задачи комплексно. Ну и об UI-составляющей не стоит забывать. Все мы визуалы — и надо, чтобы красивенько, выровнено и без lorem ipsum.

Іван Попович, Scrum Master/Senior Software Engineer у Conscensia

Ми проводили різні варіанти інтерв’ю — і на власному досвіді переконалися, що теоретичні навички кандидатів не завжди збігаються з практичними. Тому вирішили розробити невеличке тестове завдання, виконання якого потребуватиме необхідних на нашому проекті навичок і вмінь.

Специфікою нашого завдання є те, що ми не даємо його наперед. По-перше, таке не усім підходить, бо для цього потрібно витратити свій вільний час. По-друге, якщо чесно, то невідомо, хто і яким чином його насправді виконував. Тому ми пропонуємо маленьке тестове завдання, яке потрібно виконати безпосередньо на співбесіді. Для цього залишаємо кандидата самого на 15 хвилин.

Оскільки час обмежений, то завдання має бути простим для розуміння, але показувати глибину знань. Тому ми написали невеликий кусок коду: інтерфейс і клас, який його реалізовує. Цей клас й інтерфейс представляють одну зі структур даних. Вона реалізована синтаксично правильно — щоб кандидат не відволікався на синтаксис та перевірку одруків, але має багато недоліків. Загалом завдання поміщається на одному листку А4.

Кандидату потрібно зробити code review і сказати, чи така програма взагалі працюватиме, що можна зробити інакше, що оптимізувати.

У нас нема окремих завдань на різні позиції, проте помилки й недоліки мають різні рівні складності. Деякі очевидні, деякі потребують застосування глибших знань і досвіду. Ми не даємо різні завдання кандидатом різного рівня, а орієнтуємося на глибину відповідей.

Як оцінюємо тестові роботи. Перед початком роботи над завданням ми даємо кандидату питання для аналізу — свого роду план, на що треба звернути увагу. Наприклад, яка це структура даних, чи буде вона правильно працювати, чи буде коректно працювати в багатопотоковому середовищі, чи правильно вона реалізована з точки зору принципів SOLID, чи відсутні memory leaks.

По цим же критеріям і спілкуємося з кандидатом. Часом трапляються люди, які вражають своїми розгорнутими відповідями. Бували навіть такі, що вказували нам на покращення, на які ми самі не звернули увагу.

Які бувають помилки. Найчастіша помилка — кандидати використовують не весь запропонований час і не заглиблюються в питання. Знайшли 2-3 найочевидніші помилки та вважають, що вже все виконали. Коли ми їх розпитуємо, розкручуємо, то починають бачити більше.

Наше завдання орієнтоване на те, щоб оцінити як конкретні речі, так і побачити ситуацію на більш високому, архітектурному рівні. Не всім вдається зрозуміти, чи буде працювати конкретний метод, і водночас оцінити структуру в цілому і зрозуміти, як варто її покращити — наприклад, розділити на підкласи, виокремити інтерфейси.

Як кандидату добре себе зарекомендувати. Важко придумати золотий алгоритм. Моя порада — уважно читайте завдання. Адже правильне його розуміння — це вже половина відповіді. Після цього розробіть у себе в голові план, як виконувати code review — для прикладу, можна почати від конкретного і рухатись до глобального.

Варто бути уважним до деталей, але не забувати також дивитися на код на вищому рівні — щоб зрозуміти, чи буде зручно іншим користуватися такою структурою даних.

Але ці поради стосуються конкретно нашого завдання. Назагал, треба просто добре розуміти код, критично мислити і вміти реалізувати всі свої ідеї.

Дмитрий Андрусенко, Senior .NET Developer в DataArt Kyiv

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

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

Обычно тестовые задания на Junior, Middle или Senior-позиции отличаются незначительно. Разница в том, как оценивается результат и на что эксперты обращают внимание.

Большинство заданий универсальны и позволяют изменять перечень технологий, не меняя сути самого задания. Например, одно и то же задание может даваться с требованиями реализовать DAL на ADO.NET, Entity Framework, NHibernate и т. д., в зависимости от того, знание какой технологии вызвало сомнения при устном собеседовании.

Сами задания меняются вместе с требованиями рынка. Сегодня задания охватывают Web, DAL, SQL. Для Back-end разработчика могут быть ограничены требования к UI, либо вообще ограничен скоуп задачи до создания сервиса, методы которого будут проверяться вызовами из простого консольного приложения. Для Front-end разработчика, наоборот, требования по DAL и SQL могут быть сведены до создания стабов, возвращающих предопределенные значения.

Как оцениваем тестовые работы. Оценка во многом зависит от уровня, на который претендует кандидат.

Для Junior-позиции может быть достаточно, чтобы работал базовый функционал (Happy Path). В остальном код, скорее, служит для оценки, как много времени и усилий потребуется, чтобы закрыть критические пробелы в знаниях кандидата и доучить его до уровня Middle.

Для Middle-позиции, помимо работы кода, будут учитываться и его структура, и стабильность работы при отклонении от Happy Path. Наличие серьезных дыр, вроде передачи пароля пользователя открытым текстом в GET-запросе, уже повлияет на конечную оценку кандидата.

Для Senior-позиций дополнительно оценивается работа с требованиями, архитектура, работа с нефункциональными требованиями. При этом вовсе не обязательно, чтобы решение Senior-кандидата содержало больше функционала, чем решение специалиста уровня Middle. Достаточно, если места, требующие дополнительного внимания, будут снабжены комментариями, описывающими при каких условиях и что нужно будет добавить или изменить.

Например, если в задании есть sensitive data, вроде пароля, пин-кода или номера паспорта, то от Senior-разработчика мы ожидаем как минимум уточняющего вопроса о необходимости шифровать эти данные. То есть он должен отнестись к задаче, как к требованиям реального клиента: обнаружить потенциальные проблемные места и предложить решение.

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

Какие бывают ошибки. Во-первых, отсутствие анализа требований перед началом работы. Нужно ли шифровать sensitive data? Нужно ли делать юнит-тесты? Необходимо ли предусмотреть защиту от различных атак: injection, cross-site и других? Если одну и ту же задачу можно реализовать разными способами с разными временными затратами — какой из них выбрать? Как трактовать те или иные требования в постановке задачи?

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

Во-вторых, неправильная оценка объема работ. Иногда кандидаты придумывают дополнительные требования, которых нет в задании. Например, включают в проект IoC, когда он не помогает упростить решение задачи. Или добавляют 100% покрытия юнит-тестами или динамическую локализацию. В таких случаях они в ущерб основному функционалу тратят время на то, что никак не будет оцениваться.

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

Наконец, обфускация кода или просто использование неинформативных имен переменных и методов. Это сильно затрудняет понимание кода.

Как кандидату хорошо себя зарекомендовать. Главное — не бойтесь и не стесняйтесь задавать любые вопросы по заданию еще до начала написания кода. Это сэкономит ваше время и поможет точнее выполнить задание.

Старайтесь не добавлять в задание ненужных допущений и ограничений.

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

Виталий Валявский, Programmer в Luxoft

Компания работает с клиентами из разных отраслей, потому сразу уточню, что на разных проектах и для специалистов разного уровня тестовые задания отличаются. Например, недавно на одном из проектов в сфере энергетики мы проводили собеседования с потенциальными интернами. Чтобы выбрать одного из трех приблизительно одинаковых по уровню кандидатов, мы предложили выполнить тестовое задание. В соответствии с ТЗ написать приложение на UI-движке на выбор — Swing, Java Fx или SWT. Так мы можем оценить способность кандидата выполнить задание в ограниченный срок (3 рабочих дня) и увидеть качество написанного им кода.

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

В случае с интернами мы оценивали, запустилось ли приложение, работает ли оно без сбоев, насколько правильно оно реализовано в соответствии с техническим заданием. Также смотрели, насколько качественно написан код: как сформированы доменные объекты, названы пакеты, классы и переменные, читабелен ли код, отсутствуют ли явные антипаттерны.

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

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

Во-вторых, анализируйте свой код на читабельность и не забывайте соблюдать Java code conventions или другие рекомендации к стилю кода.

Алексей Чикалов, Lead Software Engineer в EPAM

Цель тестового задания, как и любого вопроса на интервью — определить, насколько кандидат подходит на текущую открытую позицию, отвечает ли требованиям. Тестовое задание помогает выявить сильные и слабые стороны кандидата, увидеть, как он справляется с анализом требований и решением задач, задает ли вопросы. Помимо качества кода, видны и навыки self-менеджмента — например, стрессоустойчивость. Иногда пара строчек кода скажет о кандидате намного больше, чем полуторачасовая беседа.

Некоторые кандидаты отказываются от прохождения тестового задания — в основном, это специалисты уровня Senior. В таких случаях мы показываем кандидату распечатку с кодом плохого качества. Там нарушены какие-либо базовые принципы: SOLID, YAGNI, DRY, KISS, а также неправильная стилистика кода. Мы просим проанализировать код, рассказать, что он думает о качестве, и предложить способы его улучшения.

Задания зависят от позиции, на которую претендует кандидат. Если это Junior-разработчик и у него нет практического опыта, он должен хорошо разбираться в теории. Такому человеку даем задачу, связанную с базовыми принципами ООП и SOLID. Например, задизайнить какой-нибудь класс или взаимодействие между ними. Классы и требования могут быть разными, но смысл всегда один и тот же.

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

Во время интервью на Senior-позицию часто даем задание разработать API согласно архитектурному стилю REST. Просим сохранить сущность с набором полей, вычитать ее, изменить и удалить. Решение этой задачи, как правило, разбивается на три этапа:

  • построение URL-запроса и описание методов HTTP-запросов, которые будут использованы, а также проработка возможных ответов сервера на каждый запрос;
  • написание класса Controller;
  • поиск сущности по множеству ID или по каким-либо критериям — если кандидат справился с предыдущими этапами.

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

Как оцениваем тестовые работы. Прежде всего, мы оцениваем то, как ведет себя кандидат, получая и выполняя задание. Конечно же, проверяем качество кода. Смотрим, как он написан, как организован, соответствует ли изначально поставленной задаче.

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

Не обязательно предоставлять готовое решение на 100%. Иногда достаточно иметь хорошую идею и четко ее проговорить.

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

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

Также мы обращаем, насколько кандидат следит за временем. Особенно это касается уровня Senior и выше. Контроль времени демонстрирует, как человек будет вести себя на реальном проекте в условиях ограниченного временного ресурса. Попросит ли он уменьшить scope, дать больше времени или просто завалит сроки. Очень часто кандидаты даже не фиксируют свои отведенные 10 минут. Они ждут от нас сигнала о завершении времени.

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

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

Не стесняйтесь задавать уточняющие вопросы до и во время выполнения задания. Например, полезно будет спросить: «В правильном ли направлении я двигаюсь?».

Всегда следите за временем. И, конечно, за качеством кода. Пишите такой код, который вы готовы заделиверить заказчику. Даже, если этот код на листке бумаги.

Андрей Бондарь, Team Lead Java/Full Stack в Intersog

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

Ребятам уровня Middle и Senior я не предлагаю тестовое. Думаю, с моей стороны это не этично :)

Лучше поговорить тет-а-тет и дать задание вживую — например, попросить спроектировать архитектуру, определить узкие места.

На позиции Junior Java аппликантов слишком много, и мы предлагаем им тестовые задания. Вот несколько типовых примеров:

  • реализовать простой веб-сервер с REST API, который использует какие-то сторонние открытые данные (например, RSS с погодой, курсами валют и прочее) и делает базовые операции с этими данными;
  • написать свое файловое хранилище по типу RapidShare, S3, MegaUpload с функциями загрузки файлов, скачиванием, удалением старых файлов;
  • написать поиск по очень большому текстовому файлу.

Как оцениваем тестовые работы. Суть и цель тестового — определить, как кандидат владеет фреймворками и понимает, насколько оптимально и быстро будет работать код. Также смотрим, как организован код, аккуратен ли он, есть ли тесты и документация.

Какие бывают ошибки. Плохо, если код написан в стиле «спагетти аль денте»: очень длинные и нечитабельные куски, много сырых элементов, мусора, не обработанных ситуаций. Сюда же — плохое логирование и отсутствие комментариев.

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

Владимир Кондратьев, Senior JavaScript Developer в Acceptic

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

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

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

Если говорить о примерах, то это может быть такая задача:

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

Далее идет список дополнительных условий. Например:

  • страница дашборда должна находиться на одном и том же роуте для обоих типов пользователей;
  • для фронтенда использовать фреймворк Х (дополнительно можно наложить ограничения на список зависимостей);
  • для аутентификации использовать secure cookie и т. п.

Как оцениваем тестовые работы. Если это тестовое задание для кандидата уровня Junior, то приложение должно работать. При этом громадный плюс, если в коде будет прослеживаться какая-то логика построения приложения.

У Middle разработчика всё должно работать без ошибок и быть более или менее читабельным.

Для квалификации выше Middle приложение должно заработать одной командой, содержать только стабильные и безопасные зависимости и выглядеть абсолютно обслуживаемым.

При проверке лично я обращаю внимание на читабельность и однородность кодстайла, на присутствие хотя бы примитивных паттернов и количество подключенных зависимостей. Также немаловажным при оценивании является полнота выполнения задания. Будет плюсом, если кандидат дополнил решение мелочами, типа confirm-диалогов для подтверждения необратимого действия, удаления или logout’a или favorite.ico.

Ну и конечно же, в современных реалиях, хорошим тоном считается, если готовое тестовое задание предоставлено через ссылку на репозиторий GitHub, GitLab, Bitbucket c простейшим Readme.

Какие бывают ошибки. Самая частая ошибка — когда в задании есть ограничения на использование фреймворка, а в решении видно, что кандидат абсолютно не знает официальные рекомендации по best practices применения этого фреймворка и пытается переизобрести колесо. Также общая оценка кардинально снижается, если кандидат ради простейшей задачи подключает объемную библиотеку и использует один единственный метод, функцию или класс из нее. Кандидат обязан знать, что есть в «коробке».

Чтобы проверить себя перед отправкой выполненного задания, удалите с вашего компьютера всё, что относится к законченному проекту: очистите БД, удалите экспорт переменных окружения, очистите систему от intermediate контейнеров. Склоньте свой проект с репозитория и проделайте всё, что вы описали в Readme, чтобы запустить свой же проект — гарантирую, вы будете удивлены.

Как кандидату хорошо себя зарекомендовать. Делайте задание не для «дяди», а для себя лично, как будто вы — заказчик фичи и вам с этим работать в будущем: развивать, поддерживать и обслуживать. Но тут также есть скользкий момент — не нужно продумывать абсолютно все нюансы, просто сделайте своё задание на 105-110%.

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

Алена Мельник, консультант по рекрутингу, GlobalLogic

Мы используем технические тестовые задания преимущественно при отборе кандидатов на подготовительные курсы GL BaseCamp и на позиции trainee в проекты компании. Цель тестовых заданий — «первичный отсев», который включает в себя проверку базовых технических навыков, мотивации, способности выполнять задание в указанный срок.

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

Для отбора на подготовительные курсы GL BaseCamp предлагаем кандидатам тесты с вариантами ответов. Для проведения тестов мы используем собственную платформу GL TestBench. У кандидата есть определенное время на выполнение всех заданий, проверка результатов происходит автоматически.

Но куда больше мне нравится тесты в формате маленьких задачек. На их выполнение, как правило, нужно не более 2 часов — то есть один продуктивный вечер. Наши технические эксперты составляют задачи таким образом, чтобы на их проверку уходило не более 5 минут времени.

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному3
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Самая главная ошибка в выполнении тестовых заданий это их делать.

Шоб я так жил... оказывается 2-6 часовые тесты проверяют! :-)
Почему же 99,9% рекрутеров не находят 2 раза по 1 минуте для того чтобы проявить елементарнейшую вежливость и ответить что-то типа: «спасибо, мы приймем решение в течении 2-х недель» и «спасибо за Ваше время мы уже нашли кандидата своей мечты... это не Вы, но мы желаем Вам успехов в поиске работы своей мечты».
А уж о том чтобы кто-то конструктивно ответил, что понравилось/не_понравилось, в чем ошибки/недочеты и мечтать не стоит... ниразу не встречал.

А мораль сей басни такова, что Земля — она круглая и лично я тесты давно перестал делать — это такая же потеря времени как игра в наперстки!
А вот интересно, как отреагирует работодатель если в ответ на тест (для подтверждения знаний) кандидат попросит оплатить 2-6 часов времени по двойному тарифу для подтверждения платоспособности работодателя!? :-)

З.Ы. Почему по двойному? Да потому что у большинства кандидатов уже есть работа и подобные тесты для них — одноразовая и сверхурочная работа!
И да, при ее выполнении работодатель экономит на аренде помещения, организации рабочего места, оргтехнике, электричестве, кофеварке... квалифицированной уборщице и тому подобных мелочах. :-)

А потом все удивляются, потому HRы не могут закрыть вакансии по пол года...
Прочитав статью, заметил, что большинство ссылается на то, что надо задавать вопросы и подходить к решению комплексно. Исходя из своей практики могу сказать следующее:
На счёт вопросов: Да, это хорошо когда задаются вопросы и по делу. Это поможет решить тестовое правильно и избавит от лишних вопросов. Однако, как показывает практика, уточняя интересующие меня аспекты, я сталкивался с фразами «Делайте как считаете нужным», «Это задание на логику», «Простите, но я не могу ответить», «Политика компании не предусматривает ответы на вопросы. Простите, вы нам не подходите». Если кто-то не верит — jobs.dou.ua/...​mpanies/govitall/reviews (обратите внимание на то что «хорошие» отзывы были написаны за 2-е недели). Как результат — тестовое делается на совесть, но не так, а на вопрос «а как?» — «как хотите».
Комплексное решение: Тут тоже очень спорный вопрос. Лично я всегда отправляю ссылки на следующие материалы: фотография скетча на бумаге, дашборд в пинтересте, кликабельный прототип в фигме + комментарии, отдельно скрины на гугл диске. Но опять же, в данном случаи мы сталкиваемся с человеческим фактором. У меня очень часто было так, что hr-у нужна только одна ссылка — ссылка на решение, а я присылаю 4-5. Была такая ситуация (если точнее то 3) что мне писали отказ из-за того что прототип принимался за решение (хотя ссылка на UI/UX была следующая в списке). При чём самое интересное, что от уровня компании это совсем не зависело.
Лично от себя хочу сказать следующее наблюдение. Исходя из «делайте сами», «мы хотим видеть как вы думаете», «мне нужна только одна ссылка» я сделал вывод, что в дизайне как такового решения тестового просто не существует. Каждый исполнитель имеет свой уникальный опыт, который, собственно, и применяет. Поэтому хотелось бы пожелать тем, кто составляет тз, понимать и учитывать человеческий фактор (с обеих сторон) и делать задание простым для понимания, но сложным для выполнения

«Процесс найма сотрудников — это воронка, каждый этап которой призван отсеять часть кандидатов. Цель воронки — оптимизировать процесс и затраты на найм.

Представьте, что на входе у вас 100 кандидатов, и вы просто приглашаете каждого на техническое собеседование и потом на повторное с руководителем».

Именно поэтому смысла ходить на такие собеседования нет никакого. Вероятность, что вас выберут из 100 человек, стремится к нулю. Это САМЫЙ бестолковый способ потратить ВАШЕ время. Лучше в спортзал сходить, или на прогулку.

При поиске работы нужно заниматься совершенно другим, а не выполнять никому не нужные тестовые задания и сидеть в очереди из 100 человек. Для компаний, в которых работает этот чувак, вы — всего лишь песчинка, попавшая в их ВОРОНКУ(!). И они этого не скрывают!!!111

Очень полезная статья по этому поводу — www.kalzumeus.com/...​ll-yourself-a-programmer , если вы, конечно, владеете английским. Если нет, то видел на хабре ее перевод — статья по-русски называется «Не называй себя программистом», или как-то так. Поищите. Она перевернет ваш мир, поверьте, товарищи прогеры.

Недавно на Доу прокатилась серия статей: пизд..ц при приеме на работу, полный трэш при прохождении собеседования, и как правильно нужно нанимать и собеседовать специалистов.

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

Когда моя старшая малая пошла в первый класс, то при подаче документов требовали сдать вступительный экзамен!!! Требовалось уже знание: читать и писать, знать арифметику (складывать и вычитать). У меня к преподам тогда возник вопрос, а на хрена тогда школа нужна? Так и тут, при приеме джуна требуют знать, что такое сервис локаторы, фабрики, инверсия зависимостей и т.д. Наверное, скоро будут требовать защищенной кандидатской на позицию младшего помощника старшего джуна.

Вота фак??? Вы серьезно???

148 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

главное с варгеймингом не связывайтесь.

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

«Процесс найма сотрудников — это воронка, каждый этап которой призван отсеять часть кандидатов. Цель воронки — оптимизировать процесс и затраты на найм.

Представьте, что на входе у вас 100 кандидатов, и вы просто приглашаете каждого на техническое собеседование и потом на повторное с руководителем».

Именно поэтому смысла ходить на такие собеседования нет никакого. Вероятность, что вас выберут из 100 человек, стремится к нулю. Это САМЫЙ бестолковый способ потратить ВАШЕ время. Лучше в спортзал сходить, или на прогулку.

При поиске работы нужно заниматься совершенно другим, а не выполнять никому не нужные тестовые задания и сидеть в очереди из 100 человек. Для компаний, в которых работает этот чувак, вы — всего лишь песчинка, попавшая в их ВОРОНКУ(!). И они этого не скрывают!!!111

Очень полезная статья по этому поводу — www.kalzumeus.com/...​ll-yourself-a-programmer , если вы, конечно, владеете английским. Если нет, то видел на хабре ее перевод — статья по-русски называется «Не называй себя программистом», или как-то так. Поищите. Она перевернет ваш мир, поверьте, товарищи прогеры.

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

А если представить что 80-99 из 100 откажутся делать ДЗ :)

При поиске работы нужно заниматься совершенно другим

И чем же? (Если нет своих идей, можете высказать основные тезисы из статьи по ссылке)

Вадим, мне кажется Вы исходите из позиции, что все приходящие кандидаты — это адекватные люди.На деле же ситуация совершенно обратная — 95% резюме и заявок, которые мы получаем и должны рассмотреть, имеют слабую корреляцию с тем, чем мы занимаемся и кого ищем. Сотни писем в день прилетает от людей, которые не всегда вообще понимают что такое ИТ, от людей не из нашей отрасли, от начинающих специалистов, которым впарили коммерческий курс «стань программистом за месяц», и вот они его закончили и теперь готовы к работе :). Многим так же не повезло работать в компаниях, в которых знают как грамотно работать, в компаниях с процессами, с «разделением труда» да и просто с грамотными специалистами. И вот вроде резюме не пустое, и опыт практический есть, но умеет только «на коленке» что-то сделать.
Если бы приходили только люди которые здесь оставляют коменты, мы бы с радостью брали всех за половину собеседования, но увы, реалии заставляют нас тратить сотни часов работы на то, чтоб отсеять всех нерелевантных как можно раньше, не тратя на это время технических специалистов. Думаю Вам бы тоже не понравилось тратить время на собеседование десятков людей, из которых 2-3 имеют какое-то попадание, Вы были бы первым, кто сказал бы «кого вы мне присылаете? Делайте отбор, не присылайте всех подряд, зачем я трачу на них свое время?»

Абсолютно согласен с вами. Но кто ж так толковых специалистов ищет? Вы сами делаете все для того, чтобы вас заваливали, по сути, спамом.

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

Например, Петя, который у вас работает джавистом, знает толкового пхп-шника-синьора Васю. А не попросить ли нам Петю попросить Васю прийти на собес? Предварительно задав Пете пару вопросов, насколько хороший Вася пхп-шник? Это НЕ кумовство, как кто-то может подумать. Это экономия времени (=денег) вас/владельца бизнеса, в котором вы работаете. Понятно, что вы прособеседуете подсказанного вам человека.

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

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

Еще раз: САМЫЙ неэффективный способ искать работу/исполнителя — это выбрасывать в открытое пространство вакансию. Как для соискателя, так и для нанимателя. Вполне нормально, что на вакансию приходят тонны совершенно левых писем. Мне кажется, так можно только уборщицу искать, но никак не специалиста средней руки.

А ведь сначала нужно tap your network, т.е. пошерстить свои контакты. Люди, с которыми вы общаетесь, плохого спеца вам не посоветуют.

Но для того, чтобы шерстить свою network, ее нужно иметь, конечно, что в условиях наших (в подавляющем большинстве) галер нереально. Какие там долгосрочные отношения с сотрудниками.... Если галера год проработала — уже хорошо! Рекорд! И для этого сотрудникам нужно еще хорошо платить, чтобы они хотели помочь решить проблемы начальства. Но это уже совсем другая история...

P.S. Это не к вам конкретно, а в целом, для аутсорса нашего разлива.

Во-первых, сначала ищут спеца по рекомендациям знакомых/знакомых знакомых/знакомых знакомых знакомых. Это называется — нетворкинг, и это гораздо эффективнее

Когда вам надо найти 1 человека в год :) Проблема с тольковыми спецами в том что у них, как правио, уже есть ребота.
Эти сказки про нетворкинг пошли со стартапов из Долины, которым надо 1-2 человека на 3-6 месяцев для того чтобы начать проект.

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

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

сказки про нетворкинг

эти «сказки» — для тех, кто в 40 лет хочет не кодить, а получать доход, например, с собственного бизнеса, или хотя бы быть начальником начальников тех, кто кодит.

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

эти «сказки» — для тех, кто в 40 лет хочет не кодить, а получать доход, например, с собственного бизнеса, или хотя бы быть начальником начальников тех, кто кодит.

Да-да. Вот надо у Вована спросить предложил ли ему кто-то из его спаринг партнеров подарить отель в Крыму и яхту.

Давайте таки вернемся в констекст статьи:

сказки про нетворкинг

сказки про __найм технических специалистов__ через нетворкинг

Ситуация на рынке такова, что компаниям нужно намного больше специалистов, чем возможно найти и нанять. В таких условиях мы не можем себе позволить отказаться от какого-то способа поиска и привлечения, даже от самого неэффективного :).
Но если вернуться к теме тестовых заданий, мы на самом деле даем их совсем не часто, думаю и 5% не насобирается. А кандидатам, на которых мы вышли через нетворкинг, возможно и вообще никогда не давали, ведь нетворкинг означает, что у нас уже есть какая-то информация от тех людей, которые с кандидатом работали, а это обычно более информативно, чем ТЗ.
А касательно «песчинки в нашей воронке» :), Вы зря так говорите, мы очень ценим и уважаем всех наших кандидатов, приходите к нам, сами оцените. Более точной будет аналогия драгоценного камня в воронке/сите с песком, и наша задача не упустить вас не набрав при этом поуши песка.

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

Это мы сейчас не затрагиваем тему зарплаты в принципе... Это еще один фактор, который ой как влияет на процесс найма сотрудников.

Витя, верно ли я поняла,что ты работал сугубо со входящими резюме ,то бишь,с откликами на конкретную вакансию?И не проводил сорсинг ?

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

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

«Мышки, станьте ёжиками».

мышки, станьте львами. эта метафора уместнее здесь.

Боюся тоді запитати що таке велике завдання. На тиждень?

Вот вам мысля:
3-5 рабочих дней — это минимальный размер ДЗ при котором оно может быть эффективно для задачи оценить насколько человек и с технической и с личностной стороны подойдет компании. Другое дело куда будет послан наниматель с такими ДЗ :)

Вот вам один метод из REST API:
def set_data_calculate
mat = MaterialCalculator.new
@materials = mat.materials_data @project
end

А в MaterialCalculator лежит генератор, который перебирает огромный словарь, в котором есть ссылки на свои классы, которые через фабрику превращаются в объекты, а у каждого объекта есть куча своих методов, которые вызываются от генератора уже другого словаря и так далее. Да там кода, реально на тысячи строк, и куча сложной логики. А так рест метод конечно маленький, на две строчки, хули там его проектировать, как раз на 15 минут )))

Можеш сміятися, але по 90% API (як RESTы так і самі класи), що я бачив, 15 хв. цілком достатньо для того щоб зрозуміти хто їх проектував.

Это называется уровень, с большой буквы У!

Я проходил тестовое на полчаса. Да, результатом должна была быть одноэкранка, и это устраивало обе стороны.
Даже на таком объёме можно многое понять.

Я проходил тестовое на полчаса. Да, результатом должна была быть одноэкранка, и это устраивало обе стороны.

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

Даже на таком объёме можно многое понять.

А что именно можно было понять по вашему решению?

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

Так и было.

А что именно можно было понять по вашему решению?

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

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

Написание кода во время собеседования — это не тестовое задание :)

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

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

Короче, я делаю ответ на это письмо со словами, выбросите этот ужас и больше никогда и никому не показывайте. Всего хорошего, всех благ и адьес. Через три дня звонит хрюша и говорит: «Вы нам подходите». Я подавился кофе и чуть со стула не рухнул. Вежливо сказал, мол спасибо, уже устроился.

Так что бывают и такие казусы.

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

Шоб я так жил... оказывается 2-6 часовые тесты проверяют! :-)
Почему же 99,9% рекрутеров не находят 2 раза по 1 минуте для того чтобы проявить елементарнейшую вежливость и ответить что-то типа: «спасибо, мы приймем решение в течении 2-х недель» и «спасибо за Ваше время мы уже нашли кандидата своей мечты... это не Вы, но мы желаем Вам успехов в поиске работы своей мечты».
А уж о том чтобы кто-то конструктивно ответил, что понравилось/не_понравилось, в чем ошибки/недочеты и мечтать не стоит... ниразу не встречал.

А мораль сей басни такова, что Земля — она круглая и лично я тесты давно перестал делать — это такая же потеря времени как игра в наперстки!
А вот интересно, как отреагирует работодатель если в ответ на тест (для подтверждения знаний) кандидат попросит оплатить 2-6 часов времени по двойному тарифу для подтверждения платоспособности работодателя!? :-)

З.Ы. Почему по двойному? Да потому что у большинства кандидатов уже есть работа и подобные тесты для них — одноразовая и сверхурочная работа!
И да, при ее выполнении работодатель экономит на аренде помещения, организации рабочего места, оргтехнике, электричестве, кофеварке... квалифицированной уборщице и тому подобных мелочах. :-)

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

На самом деле не всегда. Допустим, человек не работал с технологией но очень-очень хочет научиться. Брать его на работу и учить за свой счёт чтобы через две недели он сказал:"извините, но я у вас работать не буду"? Нет, батенька. Вот тебе список задач примерно того уровня, которую ты будешь делать каждый день. Выбери любую, сделай и покажи мне. В процессе задавай вопросы. Не нравится? Но ты же хотел научиться! Учить тебя за свой счёт? Зачем это мне?

если человек уровня сениор специалиста — его не нужно учить 2 недели. он почитает доки, посмотрит примеры существующего кода и сделает

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

Вот поэтому-то я и говорю: хочешь у меня работать — сделай тестовое

У меня отдельный случай для тех, у кого нет опыта с разработкой 👅

Помню случай, когда пришел устраиваться в галеру с именитым именем ( время от времени имеют большой баннер на ДОУ ), так меня там первым делом спросили, какой код согласно ascii соответствует букве Ö, а потом минут десять, смакуя, спорили с друг другом какой же ответ. Стратегия с точки зрения психологии понятная, почему это спрашивали :). На мое предположение что такую фигню лучше все же погуглить а не забивать голову, обозвали ламерским решением ))

Всё правильно сделали.

ЗЫ: кстати весьма интересная штука причём со всех сторон как технической так и «организационной».

Кто правильно сделал, они ? Рили ? Вы тоже так делаете? Если так, то скажите вашу компанию, чтоб я к вам не дай Бог, не попал на интервью

«п» «палево» ((

Мой дешифратор так не смог подобрать отсутствующие буквы

Ось цікаво... від кандидата просять потратити 2-6 годин на тестове.
Скільки ж часу витрачають на перевірку цих тестових?

Чесно ... ми пробували колись давати тестові завдання. Щоб адекватно оцінити прислані рішення, якщо то не зовсім шлак, треба потратити хоча б пів години на кожне (якщо просто пройтись по коду). А якщо ще і запускати — то і всю годину займе.

Після цього ми вирішили не тратити ні наш час, ні час кандидатів на такі тести.
Резюме => 2-3 уточнюючих питання по пошті => співбесіда — цього pipeline-у нам вистачало. Інколи ще 5хв по телефону вели розмову перед тим як звати на співбесіду.

Зазвичай, більшість кандидатів відсіюються ще на етапі відповідей на питання по email.

Самая главная ошибка в выполнении тестовых заданий это их делать.

dou.ua/...​rums/topic/25122/#1423275

Тестовое задание бывает разным. Вот я откровенно говоря даю тестовое при условии, что опыта работы с технологией нет и уверенности, что этим(создание языков программирования)хочется заниматься тоже нет. Иначе получится так:я работал у тебя две недели, читал книгу.

Вы когда будет давать ДЗ, то добавляйте сразу ссылку на ваш же коммент:

Самая главная ошибка в выполнении тестовых заданий это их делать.

Конечно речь идёт о опытных с данной технологией

А про джуна тестовое тебе тоже ничего не расскажет в общем-то.

Вы, как и сам Вован, не улавливаете суть:
ДЗ — это плохо когда тебе дают и хорошо когда даешь ты :)

Давать тестовое и делать тестовое — это две разные активности. В чем вы нашли противоречие? Может, Владимир как раз, и отфильтровывает тех, кто решается их сделать, как неадекватов.

Джуну без коммерческого опыта дать тестовое норм. Если, конечно, у него нет своего гитхаба с какими-то поделками.
Это ничего не скажет о том, как этот джун проявит себя в данной конкретной компании. Но по крайней мере позволит убедиться, что человек способен писать код и решать чётко поставленные задачи с применением нужных технологий. Собственно, что и требуется от джуна.

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

Что не позволяет сделать это на собеседовании?

Собственно, что и требуется от джуна.

А потом через 3 года повышения ЗП вдруг окажется что «могу копать, могу не комать» был максимум этого человека :)
От джуна требуется умение обучатся. Ибо джун — это инвестиция в то что он быстро выростет до синьора, который будет двигать компанию вперед.

Что не позволяет сделать это на собеседовании?

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

А потом через 3 года повышения ЗП вдруг окажется что «могу копать, могу не комать» был максимум этого человека :)

Это уже от человека зависит. Кто-то хочет расти, кто-то нет.

От джуна требуется умение обучатся.

От любого девелопера требуется это умение. Синьор тоже может остаться за бортом, если перестанет учиться.
Проблема в том, что умение обучаться на одном собеседовании не проверишь.

Их надо как-то отсеивать, не тратя время сотрудников компании.

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

Проблема в том, что умение обучаться на одном собеседовании не проверишь.

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

Итого мы от «убедиться, что человек способен писать код» приходим к банальному просеву входящего потока.

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

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

Противоречит, особенно если говорить про джунов :)

Просев должен быть на чём-то основан. Например, на умении писать код

2 простых вопроса:
1) Если ДЗ сделано говорит ли это о том что человек умеет писать код? — Или может ему одногруппник за пивас сделал? Или оно решалось целым консилиумом? Или ваши ДЗ можно нагуглить?
2) Если человек не сделал ДЗ говорит ли это что человек не умеет писать код? — Или может он нашел работу без подобных заморочек? Или просто ваше задание ввело его в ступор и если немного подтолкнуть его в правильном направлении, то оно было бы решино?

Противоречит, особенно если говорить про джунов :)

А я говорю что не противоречит. Как выяснить, кто прав?

1) Если ДЗ сделано говорит ли это о том что человек умеет писать код? — Или может ему одногруппник за пивас сделал? Или оно решалось целым консилиумом? Или ваши ДЗ можно нагуглить?

Для этого и нужно собеседование. В ходе которого должны задаваться вопросы в том числе о реализации этого ДЗ.

Если человек не сделал ДЗ говорит ли это что человек не умеет писать код?

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

Или просто ваше задание ввело его в ступор и если немного подтолкнуть его в правильном направлении, то оно было бы решино?

Значит низкий уровень софтскиллов, неготовность общаться с (будущими) коллегами. Что для джуна должно быть особенно важно.
Можно ведь написать письмо и задать интересующие вопросы. Ответят — подтолкнут — задание решится — человек пойдёт на собеседование. Не ответят — значит, опять же, на одного неразобравшегося у них у дверей стоят толпы разобравшихся и решивших самостоятельно, которые для этой компании имеют преимущество.

Значит низкий уровень софтскиллов, неготовность общаться с (будущими) коллегами. Что для джуна должно быть особенно важно.
Можно ведь написать письмо и задать интересующие вопросы.

И тут вторая проблема: культура удаленной работы намного сложнее чем непосредственного общения. Касательно джунов все еще веселее ибо вам прийдется его ремоутно дообучать.

Если человек не сделал ДЗ говорит ли это что человек не умеет писать код?
Не говорит, ибо решение может быть чужим (что, впрочем, сразу же вылезет на собеседовании).

1) очень похоже, что вы пропустили «не» в моем вопросе.
2) практика показывает что на собеседование не вылезет. А вылезет через 2 месяца ИС, с большим удивлением как чувак так классно налапашал на собеседовании и прислал такой хороший код, а на ИС делает совсем глупые ошибки :)

Если не сделал — это говорит о том, что не так уж и сильно он хотел получить работу именно в этой компании.

Угу, и мы снова приходим к простому отсеву (не по техническим скилам)

Итак в оставшейся выборке у тебя останутся середнячки и лгуны.

Я надеялся что Taras Morozovsky сам дойдет до этого вывода :)

Ну лгунов он как-то отсеет

Иногда бывает так:

2) практика показывает что на собеседование не вылезет. А вылезет через 2 месяца ИС, с большим удивлением как чувак так классно налапашал на собеседовании и прислал такой хороший код, а на ИС делает совсем глупые ошибки :)

Или там ИС был 3 месяца, точно не помню

Не дойду, потому что он не является единственной и абсолютной истиной. Раз на раз не приходится. Что с ТЗ, что с любыми другими методиками, по которым компании выбирают кандидатов.

Они все далеки от совершенства, и единственный способ понять, подойдёт кандидат или нет, — это, собственно, начать с ним работать.
Ни ТЗ, ни вопросы на собеседованиях, ни что-либо ещё не смогут этого гарантировать.
Это всегда рандом. А уж какие именно «рандомизаторы» использовать — здесь каждая компания решает сама.

Лично я бы спрашивал, как звали собаку Скотта Майерса. Кто внимательно читал его книги, тот вспомнит. А значит он знает хорошие практики кодинга на C++ и умеет избегать типичных ошибок использования этого языка.
Наверное.
А может и нет.

Не дойду, потому что он не является единственной и абсолютной истиной.

Речь не про абсолютные истины, а про количество false negative.

Касательно джунов все еще веселее ибо вам прийдется его ремоутно дообучать.

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

1) очень похоже, что вы пропустили «не» в моем вопросе.

Эмм... У меня, конечно, сейчас голова немного забита другими вещами (рабочий день, как-никак), но вроде бы я ничего не пропустил.
Я считаю, что если соискатель не выполнил ДЗ, это ещё не говорит о его неумении кодить. Поскольку причины невыполнения могут быть разными — как техническими, так и не очень.

2) практика показывает что на собеседование не вылезет.

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

Угу, и мы снова приходим к простому отсеву (не по техническим скилам)

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

Понятно их код можно и не смотреть дальше.

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

И задавать вопросы в том числе по нему на собеседовании. Так сразу и лгуны отсеются, и будет больше конкретных тем для разговора с человеком
2) практика показывает что на собеседование не вылезет. А вылезет через 2 месяца ИС, с большим удивлением как чувак так классно налапашал на собеседовании и прислал такой хороший код, а на ИС делает совсем глупые ошибки :)

Кстати, зная темы к которым готовится лабу ... то есть тестовое задание пихать проще.

Читать классику менеджмента это конечно не наш метод :(

Нет никакой возможности выбрать одного из трехсот умелых людей, снабженных прекрасными характеристиками. Приходится признать, что система неверна изначально. Незачем привлекать такую массу народу. Но никто об этом не знает, и объявления составлены так, что они неизбежно приманят тысячи. Например, сообщают, что освободился высокий пост, так как занимавшее его лицо теперь в палате лордов. Платят много, пенсия большая, делать не придется ничего, привилегий масса, побочные доходы огромны, на службу ходить не надо, предоставляется служебная машина, командировки можно брать в любое время. Соискатель должен представить, когда сможет, копии (не оригиналы) трех справок. Что же выйдет? Дождем посыпятся заявления, в основном от умалишенных и от майоров в отставке, наделенных, по их словам, административными способностями. Остается сжечь их все и начинать сначала. Легче и выгодней было бы подумать сразу.

Если же подумать, увидишь, что идеальное объявление привлечет одного человека, и того именно, кто нужен. Начнем с предельного случая:

«Требуется акробат, который может пройти по проволоке на высоте 200 м над бушующим пламенем. Ходить придется дважды в день, по субботам трижды. Плата — 25 фунтов в неделю. Ни пенсии, ни компенсации за увечье не будет. Явиться лично в цирк „Дикий Кот“ от 9 до 10.»

Быть может, слог и не очень хорош, но цель ясна: нужно так уравновесить риском денежную выгоду, чтобы не явилось больше одного соискателя. О мелочах тут спрашивать не придется. Тех кто не очень ловко ходит по проволоке, объявление не привлечет. Незачем указывать, что претендент должен быть здоровым, непьющим и не подверженным головокружению. Это поймут без слов. Незачем и говорить, что не годятся люди, страдающие высотобоязнью. Они и так не придут. Искусство тут в том, чтобы плата соответствовала опасности. 1000 фунтов в неделю может приманить человек десять, 15 фунтов не приманят никого. Где-то посередине — нужная сумма, которая и привлечет того, кто годится. Если придут двое, это значит, что мы завысили цифру.

Похоже на мечты барыни о том единственном, накаченом красавце на белом скакуне. Можно и подождать, 50 ведь не возраст.

p.s. со многими идеями согласен, но вот про оплату в конце — мелочное жлобство, которое всё и погубит.

Чтоб пришла 1000, зарплата должна быть x3 и выше от рыночной.
На стандартную компенсацию и так синьёров толпы не налетают.
Беда вообще в том, что её вообще не указывают )

А потом один акробат свалится (причём некрасиво!) прямо в пламя, второй не придёт и сорвёт представление. Премьер-министр вместо «мучительной смерти во имя родной страны» оставит вместо себя обгорелый труп бомжа и будет жить на Кайманах на наворованные деньги. Ну и так далее.

СНП пишет красиво, да. Но если ты не понимаешь, что это двусторонняя сатира, а не руководство к действию — то это уже твоя недоработка.

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

Недавно на Доу прокатилась серия статей: пизд..ц при приеме на работу, полный трэш при прохождении собеседования, и как правильно нужно нанимать и собеседовать специалистов.

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

Когда моя старшая малая пошла в первый класс, то при подаче документов требовали сдать вступительный экзамен!!! Требовалось уже знание: читать и писать, знать арифметику (складывать и вычитать). У меня к преподам тогда возник вопрос, а на хрена тогда школа нужна? Так и тут, при приеме джуна требуют знать, что такое сервис локаторы, фабрики, инверсия зависимостей и т.д. Наверное, скоро будут требовать защищенной кандидатской на позицию младшего помощника старшего джуна.

Вота фак??? Вы серьезно???

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

Интересно что смогли ответить преподы на ваш фопрос кроме: Вота фак??? Вы серьезно???

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

Шас говорят попроще, это лет 10-15 назад было модно всех ганять по паттернам. Отвечая на ваш вопрос: требуют знать теоретически, а во вребя работы человек научится это все правильно применять на практике.
Джун — это __работник__ с небольшим/отсутствующим __практическим__ опытом. У нас же некторые считают что джун — это человек которого контора будет обучать и за это платить деньги.

Интересно что смогли ответить преподы на ваш фопрос кроме: Вота фак??? Вы серьезно???

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

Отвечая на ваш вопрос: требуют знать теоретически, а во вребя работы человек научится это все правильно применять на практике.

Вы серьезно? Вы можете теоретически осмыслить теорию ДНК, строения клеток ни разу не заглянув в микроскоп, не понимая вообще о чем речь идет на практике, как это все выглядит и на фиг это надо? Да процентов 80, если не больше, опытных сениоров не в состоянии самостоятельно построить архитектуру приложений! Поэтому расплодилось до фига фреймворков, таких теплых и уютных. И еще столько же не смогут сложный запрос самостоятельно на sql написать (я уже молчу про оттестировать его), поэтому столько чудесных ORM появилось. А вы что-то от джуна хотите требовать.

У нас же некторые считают что джун — это человек которого контора будет обучать и за это платить деньги.

Есть два пути. Взять человека с опытом, даже небольшим и платить ему нормальные деньги. Или взять без опыта и обучать его. Желание же галеры нанять за еду начинающего, но уже с опытом, специалиста приводит к тому, что подобные вакансии висят годами, никогда не закрываясь. По вашему зачем галеры ищут джунов?

Дашь слабину, то будут чмырить и тебя и ребенка.

Будь мужиком! Пусть твой ребенок не будет уметь читать и считать до первого класса!
Читать, писать слова (без пунктуации и тд) и простая арифметика — это то чему должны были научить в садике и/или родители. По крайней мере когда я шел в первый класс у нас вроде бы все это умели.

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

Вас похоже в школе читать таки не научили:

Джун — это __работник__ с небольшим/отсутствующим __практическим__ опытом.

Даю подсказку: отсутствие практического опыта не равно отсутствию теоретических знаний.

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

Лол. Вакансии джунов не закрываются? Вота фак??? Вы серьезно???

По вашему зачем галеры ищут джунов?

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

Будь мужиком! Пусть твой ребенок не будет уметь читать и считать до первого класса!
Читать, писать слова (без пунктуации и тд) и простая арифметика — это то чему должны были научить в садике и/или родители. По крайней мере когда я шел в первый класс у нас вроде бы все это умели.

Я шел в школу в середине 80х, не зная ничего. Мне это совсем не помешало. А сейчас сделали 12 лет обучение, зачем?

Вас похоже в школе читать таки не научили

А вас может и научили код писать, но вот с аналитикой у вас беда! И не только в ответах мне!

Даю подсказку: отсутствие практического опыта не равно отсутствию теоретических знаний.

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

Лол. Вакансии джунов не закрываются? Вота фак??? Вы серьезно???

Да, я серьезно! При этом вы выдернули фразу из контекста, как в лучших традициях пропагандистских СМИ.

Потому что при правильной огранизации руками джуном можно делать очень много работы.

Есть немало аутсорсовых контор, которые выдают своих джунов: «Молодая и высокопрофессиональная команда, быстро развивающаяся, выполнит проекты любого уровня сложности. Бла-бла-бла». Я бы на месте заказчика на таких попасть не хотел.

Сманивать синьора — это куда дороже чем взять адекватного джуна и направлять его чтобы он смог развиваться и вырости в синьора.

Это просто вишенка на торт! Мы хотим сделать Амазон, но не знаем, как это сделать. Мы хотим взять сениора, но у нас на это нет денег. Мы возьмем джуна и вырастим его... Я даже не знаю в кого и кто его будет растить. Опять проблемы с анализом.

По крайней мере когда я шел в первый класс у нас вроде бы все это умели.

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

И давайте прекратим этот глупый разговор (это даже не спор, а какой-то дешевый троллинг с вашей стороны)!

А вас может и научили код писать

Интересно что про код в моем сообщении тоже ничего не было написано. Через 12 лет попросите чтобы ваш ребенок прочитал вам в голос этот тред :)

В каждом классе по 32-36 детей. Препод один, при этом абсолютно не мотивированный, в начальной школе. Как вы думаете, какой уровень знаний получают дети в первые четыре года?

К тому же умение читать и писать не имеют вообще никакого отношения к интеллектуальным способностям.

Чем мерять будем? Количеством комментариев на Доу? Ваши предложения?

В случае с интернами мы оценивали, запустилось ли приложение, работает ли оно без сбоев, насколько правильно оно реализовано в соответствии с техническим заданием. Также смотрели, насколько качественно написан код: как сформированы доменные объекты, названы пакеты, классы и переменные, читабелен ли код, отсутствуют ли явные антипаттерны.

после слова «также» стало интересно

Не понимаю я, зачем нужны уточняющие вопросы. Есть задание. Я его воспринимаю как список правил, а всё, что не включено в этот список — значит разрешено и могу делать.
Читая эту статью, прихожу к выводу, что так и останусь работать в той же компании без попыток смены работы. Не хочу угадывать, что от меня действительно хотят, чтоб задавал вопросы или чтоб не задалбывал вопросами, а творил. Чтоб мог создать свой велосипед или же мог использовать фреймворк с готовым решением.

Я его воспринимаю как список правил, а всё, что не включено в этот список — значит разрешено и могу делать.

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

другой вопрос, что я бы от джуна особо клиенто-ориентированности и не ожидал. во-1, приходит с опытом. во-2, джун и не должен такие вопросы рулить, иначе в компании хаос вместо процессов.

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

фишка в том, что на миддл+ позиции и в текущей компании от вас будут ожидать и софт-скиллов тоже.

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

простите, пожалуйста, а за что тогда получает деньги довольно большой набор людей, которые называются по разному, вот к примеру — BA ?
или разработчик должен и за него думать ? и за ПМа ? и за заказчика ?

от вас будут ожидать и софт-скиллов тоже.

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

www.linkedin.com/...​development-jesse-watson
But If Someone Else Knows the Business, Why Can’t They Can’t They Just Give Me a Spec?

The greatest misconception about software development is that it is a separable discipline from deep analysis of the business problem. We think all we need is an analyst who understands the business problem, a developer who knows how to code, then they can email a few notes or a specification. “Good to go”, right?

Not so much. At the outset, a business problem might appear simple, or only somewhat complex. You might think you have a handle on all the caveats and corner cases. But the average person who hasn’t programmed extensively doesn’t appreciate the level of detail and explicitness that computers require to do absolutely anything. Every behavior must be dictated with excruciating specificity. And your plan for how users will interact with the system will likely get thrown out and redrawn from scratch dozens of times before you have a minimum viable product.

No matter how good you believe you are at envisioning the details, or how sound you believe your logic is, when things get complex, you’ll find yourself quickly humbled by the users keeping you honest about what they want, and the computer keeping you honest about the cost of developing it. You’ll find out you don’t understand the business logic “at depth” until you’ve tried building an application to solve it.

But even that doesn’t touch on the biggest challenge of software development.

In my experience, if you added them all up, most of the miles logged on any software project (the majority of the design effort, coding hours, testing, bug fixes) are not spent dealing with technology-related issues or the business logic, as such.

Most of the time is spent thinking and communicating about a virtually endless number of micro-problems that seemingly emerge out of nowhere, and constitute the real territory between the technology and the business problem. Part of traversing this landscape of micro-problems is inventing, communicating, and internalizing a plethora of named and unnamed abstractions. It is the only way to break down the complexity so you can grapple with it.

А будьте так добры, пожалуйста, подробнее расскажите мне пожалуйста, где Вы увидели в моих словах:
«Без четкого ТЗ ничего не делаю»

P.S.
copy-paste — крутой навык, но для чего Вы начали играть роль КО, ума не приложу. Вроде умный человек, а делаете вид, что совсем не поняли что я пишу.

Дмитрий, я и не говорил, что вы утверждаете, что

«Без четкого ТЗ ничего не делаю»

:). По моему мнению, в этой части статьи автор хорошо дает ответ на вопросы вида «А как же BA? Почему не разделить обязанности? Так ли уж необходимо и разработчику в это вникать?».
P.S.
Скопировал релевантный кусок, чтоб было удобнее читать дискуссию.

простите, пожалуйста

ничего страшного

а за что тогда получает деньги довольно большой набор людей, которые называются по разному, вот к примеру — BA ?

анализ бизнес-процессов, формализация и предложения по улучшению.

или разработчик должен и за него думать ? и за ПМа ? и за заказчика ?

если коротко — да.

Предупреждать их с технологической стороны и так далее

что это значит «тенхологическая сторона» в этом контексте? «возможно/не возможно»? «будет летать/будет тормозить»? «сможем протестировать/остается только надеяться»?

если Вы заехали в реку на исправной машине

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

вам заказали «транспорт». а вы по своему разумению выдали именно самокат.

Какое тут может быть «мое разумение», если это вопрос чистой технологии ? Ведь даже в этой задаче идет целый список вопросов — сколько перевозить человек и груз ? какой уровень комфорта ? Дальность ? Топливо ? Характер передвижения (едем/летим) и так далее.
Но если клиент заказал именно авто, именно обычное, при этом не уточнил, что нужна амфибия и даже не уточнил, что означенный транспорт будет ездить вне дорог общего пользования, а потом утопил и ходит надутый, в Tesla сидят козлы, она не плавает ... Не стоит ли не подменять инженером весь бизнес ?

если коротка — да.

Прекрасно, спасибо. Но я бы хотел уточнить — а кто отвечает за результат ? не банальная ли это попытка «найти крайнего» в лице самого безответного ?
Ведь бизнес — дело рискованное. А если я не могу сформировать бизнес модель даже для рядом стоящих, то .... ?
Ведь не Вернер фор Браун решал, лететь на Луну или нет, он решал задачу: «человек должен быть на Луне».
Потому чтобы если бы он решал бы, его роль была бы иная — президент США скажем (хотя это невозможно).

И вот тут мне кажется ключевая грань — инженер не есть бизнес. Он может ее воплотить, активно участвовать в ее корректировке и так далее. Но он не есть бизнес. И если мне надо будет формулировать бизнес-модель целиком, то простите это уже задача не инженера.

Ведь даже в этой задаче идет целый список вопросов — сколько перевозить человек и груз ? какой уровень комфорта ? Дальность ? Топливо ? Характер передвижения (едем/летим) и так далее.

то есть, все же потребности надо анализировать? и вопросы надо задавать?

Но я бы хотел уточнить — а кто отвечает за результат ?

PM или кто играет его роль — перед клиентом. клиент — перед инвесторами. оба-два — перед законодательством(если нарушили).

И если мне надо будет формулировать бизнес-модель целиком
бизнес-модель целиком
целиком

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

Я думаю нам пора заканчивать, мне очень жаль, что я занял Ваше время, большое спасибо за Ваши ответы.
Постараюсь закрыть Ваш вопрос:

а вот это из чего, вдруг, родилось такое предположение?

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

как вы себе вообще представляете моделирование бизнес-процесса целиком силами кого бы то ни было?

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

то есть, все же потребности надо анализировать? и вопросы надо задавать?

Вы мне приписали то, чего у меня не было. Вы путаете меня и Романа, хотя некоторые его мысли созвучны моим.

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

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

т.е. в идеальном мире за разработчика планированием, оценкой и приоритезацией занимается кто-то другой? ооок.

В мире нормального менеджмента. Да я видел такое и не в единичных количествах.

Вопрос качества неинженерного персонала, на подбор которого также надо тратить силы, причем мне лично кажется, не меньшие, чем для инженеров.
Многие просто не понимаю ЗАЧЕМ готовятся для инженера материалы и так далее.
Это как в медицине: Хирург и сам может себе все приготовить, но будет правильно, если медицинские сестры приготовят, анестезиолог сделает свою работу ...

Да, это называется «разделение труда». Придумано на заре цивилизации и позволяет делать конечный результат лучше / быстрее.
А в галерном спорте хотят чтобы ты и full stack швец и заказчику на soft skill-ах по ушам ездец.

Разделение труда стало популярным в эпоху индустриализации. Суть в повышении эффективности и взаимозаменяемости, т.е. чем больше разделение труда, тем менее важно какой именно конкретный человек выполняет работу, тем легче нового обучить работе, и следовательно тем более такой чекловек легко заменим. Яркий пример — это работник на конвеере завода, работа которого может заключаться в том, чтоб прикручивать правую дверь к автомобилю, изо дня в день. Недостатоком разделения труда являются монотонность, ощущение бессмысленности своей работы в виду того, что ты не видишь общей картины и не понимаешь свой вклад в общее дело или считаешь его ничтожным. Исследования говорят, что наличие purpose для работников умственного труда является одним из трех основных мотиваторов: www.youtube.com/watch?v=u6XAPnuFjJc, следовательно сделай ты в ИТ конвеер, в нем люди не будут работать.
Как по мне, то выходит, что для «галер» напротив выгодно делать разделение труда, не полагаться на конкретных людей, а делать их винтиками в машине, которых было бы проще обучить и заменить. Но увы, схема завода просто не работает для нас, так что дело совсем не в том, что компании хотят всех отэксплуатировать, а в том, что в нашей деятельности по другому работает плохо.

Конечно, Вы правы, нельзя быть спецом во всем. Мне кажется T-Shaped модель хорошо описывает ожидаемое компаниями: medium.com/...​haped-people-e8706198e437
Суть в том, чтоб каждый был специалистом в какой-то своей области, но при этом имел обзорные знания в других/смежних областях. Такие обзорные знания делают взаимодействие различных специалистов эффективными.

проблема в том, что в реальном проекте ...

Не прочитав би пару таких статей, ніколи б не подумав, що «тестове завдання» має моделювати реальний проект.
Тестове завдання сприймається як замкнена в собі задача з збірника задач.
Якщо ж «тест» полягає в чомусь іншому, то варто так і ставити задачу: «ось запит від замовника:... які будуть ваші наступні кроки?»

Не потрібно вимагати від кандидатів телепатичних навичок. Не кожен гарний спеціаліст буде майстром емпатії та телепатії. І навпаки, не кожен майстр комунікацій буде гарно вирішувати технічні задачі.

ніколи б не подумав, що «тестове завдання» має моделювати реальний проект

хоча б у чомусь, та має. інакше який сенс? «в нас проект на джаві і аджайл, але ось вам тестове, яке ви маєте виконаті на котліні чи перлі, а ще продумати наперед усі можливі edge cases, наче у нас waterfall»

Не кожен гарний спеціаліст буде майстром емпатії

ви ж в курсі, що це слово означає, чи не так?

Не потрібно вимагати від кандидатів телепатичних навичок.

згоден повністю. телепатичні навички я б ніколи не очікував.

хоча б у чомусь, та має. інакше який сенс?

Якщо чесно, не зовсім зрозумів, що ви мали на увазі наведеним прикладом :)
Коли я писав тезу, на яку ви відповіли, я мав на увазі, що якщо в завданні немає посилання на те, що воно не повне, то зазвичай розуміється, що всі достатні та необхідні умови завдання написано в завданні і додаткових уточнень та обговореннь не потребує.

ви ж в курсі, що це слово означає, чи не так?

Щойно перечитав статтю у вікіпедії про «емпатію» ... так, це саме те, що я мав на увазі :)

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

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

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

Еще можно тесты написать для всех важных сценариев. И алгоритм расписать так чтобы джун все понял ... можно даже описание алгоритмов давать на том языке на котором надо запрограммировать (ну чтобы джун точно ничего не перпутал).

Человек дающий задание джуниору должен примерно понимать возможности своего исполнителя

Если джун не способен не способен оценить что он может сделать сам, а что лучше спросить у более опытных коллег, то дальше джуна он не пойдет в профессиональном плане (а вот ЗП за выслугу лет будет хотеть больше).
Вопрос: зачем инвестировать в такого человека?

Если джун не способен не способен оценить что он может сделать сам, а что лучше спросить у более опытных коллег

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

А где ты видел других джунов?

10+ лет назад в зеркале :) Потом видел уже как ментор/старший коллега на работе и в конторках где помогал/консультировал.
Если джун не задает вопросов по задаче, ему надо сказать/показать что он может так делать. Если и потом не задает, то лучше уволить ибо такой человек будет балластом для команды.

>Не понимаю я, зачем нужны уточняющие вопросы. Есть задание. Я его воспринимаю как список >правил, а всё, что не включено в этот список — значит разрешено и могу делать.

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

Интересно, как бы выглядело тестовое для юриста, психолога, врача, сантехника и др.

Интересно, как бы выглядело тестовое для юриста, психолога, врача, сантехника и др.

dou.ua/...​rums/topic/25122/#1423275 — это реальные примеры. Там еще в треде другие примеры есть.

Могу показать примеры тестовых для бренд-менеджеров.

скинь хоть одну. а то "нутром чую что бред, но доказать не могу"©

это наверное? jobingood.com/...​nka-rekrutinga-po-novomu
как по мне, в рекрутинге не может быть шаблонных подходов. рекрутинг джуниоров, сениор специалистов, и менеджмента, или к примеру CEO, не может производиться по одним и тем же шаблонам и критериям.

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

Вы считаете, что есть какая-то другая цель в просьбе выполнить тестовое задание, кроме понять подходит/не подходит?

Цель зависит от того кто ее ставит, поэтому цель может быть любая.
Но вот ДЗ эффективный инструмент только для одной задачи:
Уменьшить поток кандидатов. (Иногда, например с джунами, это надо)

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

А потом все удивляются, потому HRы не могут закрыть вакансии по пол года...
Прочитав статью, заметил, что большинство ссылается на то, что надо задавать вопросы и подходить к решению комплексно. Исходя из своей практики могу сказать следующее:
На счёт вопросов: Да, это хорошо когда задаются вопросы и по делу. Это поможет решить тестовое правильно и избавит от лишних вопросов. Однако, как показывает практика, уточняя интересующие меня аспекты, я сталкивался с фразами «Делайте как считаете нужным», «Это задание на логику», «Простите, но я не могу ответить», «Политика компании не предусматривает ответы на вопросы. Простите, вы нам не подходите». Если кто-то не верит — jobs.dou.ua/...​mpanies/govitall/reviews (обратите внимание на то что «хорошие» отзывы были написаны за 2-е недели). Как результат — тестовое делается на совесть, но не так, а на вопрос «а как?» — «как хотите».
Комплексное решение: Тут тоже очень спорный вопрос. Лично я всегда отправляю ссылки на следующие материалы: фотография скетча на бумаге, дашборд в пинтересте, кликабельный прототип в фигме + комментарии, отдельно скрины на гугл диске. Но опять же, в данном случаи мы сталкиваемся с человеческим фактором. У меня очень часто было так, что hr-у нужна только одна ссылка — ссылка на решение, а я присылаю 4-5. Была такая ситуация (если точнее то 3) что мне писали отказ из-за того что прототип принимался за решение (хотя ссылка на UI/UX была следующая в списке). При чём самое интересное, что от уровня компании это совсем не зависело.
Лично от себя хочу сказать следующее наблюдение. Исходя из «делайте сами», «мы хотим видеть как вы думаете», «мне нужна только одна ссылка» я сделал вывод, что в дизайне как такового решения тестового просто не существует. Каждый исполнитель имеет свой уникальный опыт, который, собственно, и применяет. Поэтому хотелось бы пожелать тем, кто составляет тз, понимать и учитывать человеческий фактор (с обеих сторон) и делать задание простым для понимания, но сложным для выполнения

Підписатись на коментарі