Про тестовые задания

[Toy]

Многие работодатели оплачивают тестовые задания.

[rekub]

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

[andbas]

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

[rekub]

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

[Propheta13]

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

[rekub]

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

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

[rekub]

Ух ты, это-то за что заминусовали!? Программы тоже по количеству строк оцениваете?

[Dolios]

Минусуют, скорее всего, по той причине, что пост ни о чем. Вас никто не заставляет делать тестовое задание.
Пару раз сталкивался с ситуацией, когда после собеседования соискатель говорил, что он нервничает на собеседованиях из-за чего часто производит плохое впечатление и сам просил дать ему тестовое задание, чтобы продемонстрировать свои навыки. Так что, не все так однозначно. Я не hr, если что.

[GKONNOV]

Когда сам принимаю на работу, то даю небольшой тикет (Пара часов, если есть опыт) на каком-нибудь небольшом, но реальном проекте. Лучшей метрики, чем эта не нашел. Т.к. сразу вскрывается неумение работать с библиотеками, анализировать чужой код, неумение его оформлять или желание быдлокодить. Это никак иначе не проверишь. Если человек выполняет успешно, то он принимается. Все, кто тянули задание больше пары дней, как правило, и с работой не справлялись. Код был нечитаем и уходил в /dev/null. Работает гораздо лучше, чем задание «на листочке» или пространные беседы. Но до выдачи тестового задания надо определиться по ожидаемой зарплатной вилке и условиям работы.

[GKONNOV]

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

[aprel_co]

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

[GKONNOV]

Я был бы только рад, если бы чаще попадалось то, о чем вы говорите, а не такое в тестовых заданиях по Node JS, к примеру:

self.db.run(sql6, [userName], function (error, result) {
	if (error) {self.sendDBError(command, error);return;};

	prevRat = result.rows[0].rest_comment_overall_ratio;
	self.db.run(sql7, [overallRatio-prevRat, params.id_restaurant], function (error, result) {
		if (error) {self.sendDBError(command, error);return;};
	});
	self.db.run(sql5, [userName], function (error, result) {
		if (error) {self.sendDBError(command, error);return;};

		self.db.run(sql3, [params.comment, params.service_ratio, params.dish_ratio, params.price_ratio, overallRatio,
			params.id_user, params.id_restaurant], function (error, result) {
			if (error) {self.sendDBError(command, error);return;};

			result = result || {};
			command.sendResult(result);
		});
	});
});

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

[aprel_co]

Тогда не буду показывать какой код я «производил» на 4 курсе университета:)
Тоже приведу пример из жизни. Не касающийся собеседований, просто чтобы разбавить.
Однажды коллега, не студент 4 курса, для обработки стандартного дерева запихнул в рекурсию вызов из БД узла по идентификатору родителя.
Типичная детская ошибка была совершена человеком с пятилетним стажем.

[GKONNOV]

Буду рад все-таки прочитать какое-то обоснование минусам, чтобы скорректировать модель по которой веду прием сотрудников в свою небольшую компанию.

Если обоснование найдет подтверждение в реальных интервью, то с удовольствием напишу статью на хабр, как я описывал сейчас становление фирмы и ответы на вопросы: habrahabr.ru/company/innotrio/

[k102]

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

[GKONNOV]

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

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

[Dolios]

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

[GKONNOV]

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

О становлении компании можно прочитать здесь: habrahabr.ru/company/innotrio/blog/204864/

[AlexandrDP]

Это не пост

[rekub]

Это не комментарий ;)

[Valery35]

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

[trickii]

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

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

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

[rekub]

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

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

[UncleAndy]

Я, честно говоря, не люблю объемные и не интересные тестовые задания. Когда для его выполнения нужна рутинная работа, его и выполнять-то не хочется. На текущее место работы я пришел как раз из-за того, что первые тестовые задачи были довольно интересными. Они были не объемными, но способы их решения были не очевидными. Поэтому и заинтересовался. Работаю уже больше года на этом месте и ничуть не жалею. :)

[rekub]

Я думал туда написать сначала, но мне, неожиданно, захотелось получить какой-то фидбек.

[Smekalisty]

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

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

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

[GKONNOV]

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

P.S. Был случайным свидетелем собеседования, где человека попросили написать обход дерева для поиска элемента по id. Спустя 15 минут он все послал подальше, т.к. задача слишком сложная и не жизненная, а у него многолетний опыт и диплом.

[PavelPV]

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

[GKONNOV]

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