Недавно мы публиковали перевод статьи о технических собеседованиях с использованием белой доски. Автор той статьи разбирал альтернативные варианты проверок навыков разработчиков. Среди этих вариантов были и тестовые задания, выдаваемые на дом.
В полном соответствии с законом парных случаев нам попалась еще одна статья о тестовых заданиях. Сайт DOU.UA взял интервью у нескольких разработчиков и попросил их высказать свое мнение о подобных проверках. Мы предлагаем вам почитать перевод статьи DOU. Также было бы очень хорошо, если бы наши читатели выразили собственное мнение по теме тестовых заданий (велкам в комментарии!).
Аргументы против
К ним чаще всего прибегают те, кому неоднократно или хотя бы раз не повезло. Программисты жалуются на непродуманность задач, а еще на интервьюеров, которые потом не дают обратной связи, а если и дают, то их отказы звучат неубедительно.
Тестовые задания, оторванные от жизни
Александр Левинсон, ASP .NET Developer
В 2014 году, когда началась война, я бежал из Донецка и потерял работу. Опыта у меня много: я начал программировать в 15, а сейчас мне 50. Я поселился в небольшом городе и стал искать работу удаленно, а в то время это было вызовом.
Поиски заняли много времени, и когда мне предлагали тестовые, я в основном их выполнял. По крайней мере сначала. Потом понял, что 80% из них были ни о чем. Проверяли одни навыки, а в работе были нужны другие, поэтому никакого отношения к реальной жизни те задачи часто не имели.
Иногда тестовое дают «примерно на 4 часа», но если делать его на совесть, то не факт, что хватит 2-3 дней. Даже в том, что знаешь, бывают вещи, на которые сначала не обратил внимания. Никто не может сказать, что умеет все. Появляются новые языки, технологии, подходы. Был случай, когда ответил, что могу взяться за задание, но буду выполнять его дольше, потому что нужно разобраться в нескольких незнакомых технологиях. На мои условия согласились, но уже на следующий день HR спросила, когда будет работа. Я ответил, что, видимо, уже никогда, раз такой подход.
По моему мнению, ИТ в Украине сегодня — это преимущественно «галерная промышленность», владельцы компаний не всегда заинтересованы в хороших специалистах. Часто они ищут просто определенный набор навыков, чтобы «грести дальше».
В компании, где сейчас работаю, я сначала около часа общался с менеджером. Когда более-менее понял, чем они занимаются, ответил, что могу взяться за работу, однако тестовое выполнять не буду. Потому что рискуют обе стороны. Но если хотите меня проверить, дайте доступ к своему коду, предложите реальные задачи, которые есть в проекте. При их выполнении я буду задавать вам вопросы, и так несколько часов поработаем. Если по моим нынешним расценкам вы эту работу оплатите, это уже будет реальный опыт: я увижу, как мне работается с вами, а вы — как вам со мной.
На мои условия согласились, и я сделал несколько реальных задач за деньги. И уже через неделю мы увидели, что нам комфортно и интересно сотрудничать. Сегодня я уже больше года работаю в том проекте главным разработчиком.
Вообще, когда компания нанимает специалиста высокого уровня, может оказаться, что не только разработчик не подходит компании, но и компания не является хорошим продолжением карьеры для разработчика. Например, я могу не соглашаться с подходами — любую работу можно выполнить миллионом разных способов. Может получиться и так, что мне не интересно то, что от меня требует работодатель, я уже много похожего делал и/или знаю лучший путь. А ведь это вопрос карьеры: в будущем я буду рассказывать, чем и как занимался, следующем работодателю.
Тестовые задания — это неплохо, когда нанимаешь начинающего. Простое тестовое помогает понять, способен ли человек решать хоть какие-то проблемы при помощи кода. Когда речь идет об опытных сотрудниках, нужны другие средства проверки знаний и навыков. И любая работа должна быть оплачиваемой. Компания рискует временем и деньгами, но и разработчик рискует временем и карьерой. Если руководство этого не понимает, с ним вряд ли есть смысл сотрудничать.
Странные аргументы в интервьюеров
Анна, Middle .NET Developer
К тестовым я отношусь скорее отрицательно, потому что считаю, что достаточно собеседования и испытательного срока. Когда ищешь работу, иногда реально не хватает времени на все тестовые. Порой я берусь за них. Но часто бывает, что перестаю рассматривать компанию как подходящий вариант именно из-за наличия тестового, особенно если оно еще и не очень интересное.
Случилась у меня одна интересная история с тестовым заданием, связанным с маленьким трекером задач. Я работала над ним дома пару дней. Задача касалась проектирования базы данных. В базе надо было хранить сущности проекта и задачи. Я создала отдельные таблицы для сущностей, поскольку они были разные. Но мне сказали, что их надо было записать в одну таблицу. Когда я спросила, что это за подход такой, может, я чего-то не знаю, мне ответили, «что вряд ли это где-то описано, такое приходит с опытом».
Это странный аргумент, потому что это не какая-то слишком новая задача и большинство подходов, которые можно здесь использовать, уже давно описаны. На всякий случай я еще переспросила у более опытных коллег, что они об этом думают, вдруг я все-таки чего-то не знаю. Но мне ответили: «Беги оттуда».
Когда позже та компания захотела дать мне оффер, но «на других условиях» (типа я не дотягиваю до желаемой зарплаты), хотелось громко смеяться. Вежливо отказалась.
Работодатели и кандидаты могут обманывать
Тимофей Воробьев, Senior freelance PHP Developer
Как-то ко мне обратилась одна компания, которой необходимо было доработать свою систему. Система подверглась хакерской атаке: базу нарушили, пароль администратора сменили. Исправить это было несложно. Мне ответили, что если справитесь, то будем работать дальше вместе. То есть это стало моим тестовым заданиям для получения постоянной работы в компании.
Я сказал, что мое время стоит денег, и назвал конкретную сумму за час работы. Они согласились. Но когда я все починил и спросил, что там с оплатой, ответили: «Все будет потом». Я обращался еще несколько раз, но ни ответов, ни денег не получил. Спросил знакомого, который тоже имел дело с той компанией. Он сказал, что там всегда «кидают», из-за чего имеют много проблем. Обещать обещают, а платят только тогда, когда их начинают прессовать. Думаю, кто-то из моих предшественников поэтому и сломал им базу.
Чтобы минимизировать риски, я бы посоветовал не брать слишком большой объем работы, а только такой, который сможете быстро выполнить. Чтобы не жалеть, что потеряете время. Если же это похоже на реальную работу, то следует четко обсуждать, что это время должно быть оплачено. Когда я ищу людей в команду, то предлагаю кандидатам code review. То есть показываю им кусок программы, где много ошибок, сделанных умышленно. Чем больше ошибок человек найдет, тем больше вероятность, что с ним можно продолжать общение.
Небольшое задание лучше предлагать выполнить в реальном времени, а не давать его домой. Особенно с учетом того, что некоторые начинающие выполняют их, как в университете: находят специалиста, у которого нет денег, и предлагают ему выполнить задание вместо себя. У меня был похожий случай. На собеседование пришла девушка, которая претендовала на позицию администратора сайта. Ей необходимо было обладать базовыми навыками HTML. Резюме было хорошее, но когда я предложил написать на месте простенький HTML-код, она отказалась. Сказала, что всегда работала с каким-то онлайн-редактором, который это делал сам, а потому не понимает, зачем ей этим заниматься. Очевидно, это был блеф.
Это унижение для программистов
Артем Комисаренко, Software Developer в Zultys
В 2009 году, когда начался финансовый кризис, я оказался без работы. Опыта у меня было года два, пришлось отсылать резюме куда только можно. Помню, в одной из компаний тестовое было элементарное, на уровне «продемонстрировать владение языком и стандартной библиотекой». Я вылизывал его несколько часов, прислал и получил в ответ: «Плохо». Когда попытался переспросить почему, мне ответили, что там есть memory leaks. Их там не было, однако я догадываюсь, почему так подумали. Но какой смысл спорить? Я вообще довольно тщеславный: доказывать, что не верблюд, тем, кого не уважаю, мне не интересно. И это же мои потенциальные будущие коллеги, я хотел бы у них чему-то поучиться, а не вот это все.
Второй эпизод с тестовым произошел в офисе. Я тогда жил в Харькове и поехал в Киев на интервью ночным поездом. Он приезжал рано, поэтому я побродил немного по городу перед интервью. Собеседование было очень «горячим» и продолжалось два часа, если не дольше. Я видел, что понравился, мы много спорили и разговаривали, и тут вдруг оказалось, что у них еще есть тестовое, которое надо выполнять в офисе. Не очень сложное, но объемное — на несколько часов. Причем я такого еще не делал: надо было читать документацию, разбираться, а потом писать. В городе на ночь я оставаться не планировал, поэтому пошел пообедать, а когда вернулся и сел за компьютер, понял, что после собеседования, шатания по городу, ночного переезда и вообще вот этого всего уже слишком устал. Отказался и поехал домой.
Когда я искал работу последующие разы, в 2012 и 2013 годах, мое резюме было уже интереснее, и позиции я фильтровал. Всех с тестовыми я отправлял в конец списка, в который так и не доходил. Сейчас я считаю тестовые задания элементом унижения начинающих программистов. Когда тебе говорят «мы вам перезвоним», а на самом деле обратной связи не дают. Кроме того, тестовые еще и неэффективны, если смотреть со стороны тех, кто нанимает. Я сам проводил собеседования и понимаю, что когда вы не Google и человек согласился выполнять тестовое, значит, его больше никто не хочет брать, а это плохой признак.
Иногда тестовое дают в офисе компании, как было у меня, но тогда на результат может повлиять волнение или усталость. В то же время часто причиной увольнения является выгорание за плохих условий труда или конфликт, а здесь вы человека сажаете на несколько часов «педалить», как на экзамене. Конечно, стоит посмотреть, как человек пишет код. Для этого можно давать небольшую задачку, на полчаса, прямо на интервью. Но надо помнить, что если кто-то приехал из другого города или пришел на собеседование с работы, то может «тормозить», и это нормально. Больше всего люди, по-моему, раскрываются во время разговора о предыдущих проектах: что там было интересного, какие трудности возникали и тому подобное. Есть, конечно, патологические лжецы, но их немного и они выдают себя на подробностях. В конце концов, есть испытательный срок, а уволить ФЛП — вообще не проблема.
Аргументы за
К тестовым заданиям часто благосклонно относятся те, кому таким образом удалось найти первую работу, особенно без предварительного опыта в ІТ.
Кто-то занимает нейтральную позицию: мол, мне не повезло, но в целом это действенный способ понять уровень кандидата. И есть те, кто считает, что тестовое — это шанс проявить себя так, как не всегда удается на собеседовании.
Хорошо для тех, кто боится собеседований
Игорь Янишевский Software Developer в Eyeo GmbH
В свое время тестовые помогли мне получить работу. Я думаю не очень быстро, и на собеседованиях, как и многие другие люди, стрессую. А с тестовым у меня было время спокойно сесть, поработать, все хорошо оформить.
Компании представляют себе программистов как людей, превращающих кофе код, но мы не машины, а люди. Когда просят что-то сделать онлайн и в реальном времени — это стресс, ты можешь просто не вспомнить в тот момент конкретный кусок функционала. То есть если компания хочет проверить, насколько быстро кандидат думает и справляется с напряжением, такие тестовые — именно то, что нужно. Но в основном никто не ищет разработчиков, которые пишут код за секунды.
В Европе этот процесс сложнее: просят сделать и тестовое, и немного код написать на том же собеседовании. Я недавно общался с коллегой, которого проверяли в режиме реального времени. Но перед тем ему десять раз объяснили, что не будут учитывать качество кода, который он будет писать — хотят только увидеть, как он думает. Такая благоприятная атмосфера сыграла свою роль: он чувствовал себя уверенно, не боялся ошибиться. Тогда это имеет смысл.
Я был и с другой стороны — проводил собеседования с кандидатами. Осознавал, что написание кода на доске не даст мне понять, кого я отбираю. Проще сесть и перечитать уже то, что человек писал дома. Так ты знаешь, что у него было время все сделать как следует, пересмотреть собственные решения.
Тестовым можно и выделиться среди других. Пусть на должность претендуют 100 человек — половина из них вообще не сделает тестового. У половины из той половины что-то не будет работать, у других будут очевидные ошибки, по факту останется десять, среди которых можно выделиться. Надо подумать, какими еще могут быть решения, пересмотреть, насколько элегантно вы решили задачу, хорош ли нейминг и тому подобное. Если задание более практическое — прописать, какие еще могут быть юзкейсы, что-нибудь предусмотреть. Такое ценят.
По моему мнению, тестовые необходимые разработчикам всех уровней. На собеседованиях ставят часто задаваемые вопросы, их можно просто выучить. А когда человек приходит на работу, и у него с самого начала все складывается плохо из-за того, что никто не проверял, как хорошо он пишет код или взаимодействует с другими — такого никому не хочется. И что с того, что в резюме написано Senior? Сегодня сеньорами становятся в 23. Предыдущая компания могла повысить специалиста до этого уровня просто чтобы продать клиенту, а не из-за соответствующего опыта. Я и сам так делал: подписывался сеньором в своем резюме, если имел этот статус в прошлой компании, хотя может и на слишком дотягивал. Конечно, так не везде, но явление довольно распространенное. И сеньоры бывают разными, все равно нужны тестовые.
Тестовые — это опыт, который можно указать в резюме
Денис Гришко, Junior Front-end Developer
У меня было много тестовых, за полтора месяца я откликнулся на больше чем 250 вакансий. Все сделать я не мог, потому выбрал самые интересные. Я знал, что основой является JavaScript, и разбирался в одном из фреймворков — React. Но на рынке популярны еще два — Vue.js и Angular, поэтому подавался и туда. Как по мне, если знаешь основу, со всем можно разобраться. В таких случаях я просто просил немного больше времени. Для меня это был вызов, выход из зоны комфорта.
Попробовав, я уже записывал в резюме, что умею работать с теми технологиями. Почему нет? Если применял их на практике, значит, ориентируюсь и можно отметить это. Сегодня многие люди боятся подаваться на вакансии, потому что слишком много критериев и требований. В современных реалиях идеального кандидата не найти. Поэтому если понимаешь, что на 50-70% это твоя вакансия, то стоит откликнуться. А по тестовым уже поймешь, сможешь работать или нет.
Порой, когда вакансия меня интересовала, мне отвечали, что моего опыта недостаточно. Если там действительно был необходим высокий уровень, я оценивал свои шансы, желал всего наилучшего и прощался. А если понимал, что все-таки могу вытянуть, то старался выбить или тестовое, или техническое собеседование. Своей настойчивостью пытался получить шанс, порой это срабатывало, и мне давали тестовое. Да, в основном я эти тестовые проваливал, однако опыт все же получал.
Переломным моментом был первый раз, когда мне прислали тестовое. Я сделал задание, уложился в дедлайн, добавил там сам несколько пунктов, чтобы выделиться среди других кандидатов. Однако ответа не получил никакого. Я писал HR течение месяца, и не получил никакого фидбэка. Меня это сильно задело, ведь я потратил на тестовое четыре дня. Но ситуация на рынке такова, что кандидатов много и компании могут позволить себе так к ним относиться. Хорошо, что в тот момент меня поддержали, однако кого-то такая неудача в начале может и сломать. Но, как показывает опыт, если не останавливаться, какие-то из дверей точно откроются.
В компании, куда меня в конце концов взяли на работу, тестовое выбивать не пришлось, но пришлось выбивать ответ. Я выполнил задание и потом еще три недели постоянно напоминал о себе HR. Она не отвечала, я писал снова. В какой-то момент мне сказали, что человек, который проверяет тестовые, то ли в отпуске, то ли занят. Мол, как проверит, мы вам скажем. Я подождал еще неделю и опять написал. И только через три недели мне ответили и назначили собеседование.
Не факт, что если бы я о себе не напоминал, меня бы не забыли. И теперь всем советую: когда прислали резюме, всегда старайтесь взять контакт, желательно прямо звонить.
Шанс попасть в профессию
Василий Жук, Senior Back-end Developer в Digital Pulp
Если бы не тестовое, я бы не попал в профессию. Да, я с детства интересовался компьютерами, на третьем курсе создал первый сайт. Делал сайт и для Могилянки (Киево-Могилянская академия, — прим. перев.), где учился, но просто потому, что мог. Когда учился на финансиста и начал искать первую работу, то и не знал, что могу зайти в серьезный IT-мир. Впервые мне это подсказали на собеседовании в конторе, занимавшейся внедрением ERP, системы управления предприятиями. Финансовый тест я завалил, но на интервью обратили внимание на мой опыт программирования и предложили попробовать себя программистом.
Я пропустил это мимо ушей и решил пойти в тестировщики — у многих моих друзей получилось. И когда пришел наниматься, председатель IT-отдела сказал: «Слушай, мы можем взять тебя тестировщиком за 800 долларов в месяц, но душа у тебя лежит к другому, поэтому в результате получим несчастного программиста». И круто, но как быть с тем, что я не имею профессионального образования? Он мне ответил, что если справлюсь с тестовым заданием, то образование никого волновать не будет.
Так я впервые узнал о тестовых заданиях и о том, что они важнее диплома. Это освежило мне голову и я нашел работу за день, успешно пройдя четыре собеседования. На первом мне не понравилось: там были типы младше меня, задававшие вопросы, на которые я не знал ответа. Когда ехал на второе собеседование, загуглил. Оказалось, это были технические вопросы, теория. Сегодня я уже знаю, что это не слишком хороший подход к подбору людей. Второе собеседование было в компании, где в корпоративной культуре заложены встречи, на которых разработчики учат друг друга. Кто-то освоил новую технологию — рассказал другим. Парень, который меня интервьюировал, был фанатом своего дела. Он понимал, что я не имею базы, а потому мое тестовое было таким: он меня спрашивал, что бы я делал, если бы был инженером. Когда я чего-то не знал, то догадывался. Это было похоже на коллоквиум, и мне понравилось.
Следующее собеседование начиналась с тестового задания и теоретических вопросов. Тестовое я сделал просто — уже был опыт, а в теоретической части ко мне были благосклонны. Меня интервьюировал человек старше меня, из когорты инженеров-разработчиков, который учился еще на древних компьютерах. Он подошел мне по духу, и работу предложили тот же день.
Но я все же решил пойти на четвертое собеседование: это была единственная контора, которую я нашел сам. Их техническое задание было на несколько страниц — тесты закрытого типа на знание программных конструктов, использование языка PHP. Я справился, однако офис мне не понравился: тесные помещения, опенспейс, людей много — не люблю такого. В результате выбрал третью компанию, впоследствии оказалось не слишком удачным выбором, но так или иначе это история о том, что тестовые задания работают.
Тестовые бывают разные. Могут попросить с помощью рекурсии написать возведение числа в степень — это легко загуглить, но такой возможности нет. А бывают и задачи на день-два, когда надо сделать целую программу. Когда-то читал историю парня, которому как тестовое задание предложили создать 3D-змейку, полноценную игру, где можно переключать камеру и наблюдать за змейкой с разных ракурсов. Все это прикольно, но звучит подозрительно. Затем кто-то может разместить эту игру на App Store, поэтому парень сказал «до свидания».
Ситуации бывают разные, всегда надо оценивать адекватность задачи и больше узнавать о компании, куда идешь, и действительно ли там хотят найти долгосрочного игрока, а не просто использовать человека.
Тестовое задание должно показывать умение алгоритмизировать. Сегодня между инженерами и разработчиками разница: первые умеют алгоритмизировать, придумывать новое. Даже если этого нет в API, они знают, как написать эффективный кастомный код. Зато девелоперов, которые сегодня выпускают много с разных курсов, учат использовать API — составлять что-то из готовых кирпичиков. И если какого-то кирпича нет, для них это часто тупик.
Еще один подход — предложить описать архитектуру (или подход) под конкретный кейс. Мне этот вариант нравится, когда я сам интервьюирую. Комбинируя код, с помощью «гугла и какой-то матери», программировать можно легко, а разработать архитектуру для нестандартной задачи — это уже другое дело. Вывод: джуниоров можно проверять по знаниям API, мидлов — по умению алгоритмизировать, а сеньоров — по построению архитектуры.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
