Как-то в нашу компанию потребовались ASP.NET-разработчики. Ну и чтобы сэкономить свое время на продолжительных собеседованиях мы предварительно просили соискателей выполнить несложное тестовое задание.
Задание из разряда: вывести содержимое таблички, добавить возможность фильтрации данных, но при этом заложить в архитектуру возможность последующего развития и масштабируемости. Примечание: Настоящее ТЗ конечно более подробное.
Каково же было мое изумление, когда один за другим, кандидаты с солидным резюме присылали такие перлы, что просто страшно становилось за их системы. Соответственно таких кандидатов мы не приглашали, а ведь наверняка это были хорошие разработчики.
В этом посте я хотел бы описать основные характеристики и ошибки тестового задания, на которые я обращаю внимание. Надеюсь, этот список поможет кому-то быстрее найти работу.
Первым делом, хочу сказать, что для меня тестовые задания делать всегда лениво. Это же нужно в перерывах между собеседованиями или вечерами после работы выделить время на написание программы, которая скорее всего не имеет никакого практического применения. Тратить свое время на ТЗ, когда я, соискатель, еще окончательно не решил, нужна мне эта компания или нет?
Тут хочу посоветовать побороть лень и выполнить задание максимально качественно, думаю, ради новой работы, новой зарплаты, новых перспектив стоит найти на это силы.
Итак, архив с программой у меня есть, и вот основные пунктики, на которые я обращаю внимание:
Иногда соискатели впадают в крайность и предлагают сверхсложные варианты, со своими велосипедами и нетрадиционными подходами не оговаривая это в сопроводительном письме к ТЗ. Изучать такое ТЗ интересно, но чаще всего соискатель получает доп. минус или как минимум настороженное отношение.
В общем, как-то так вот все происходит.
Спасибо всем, кто дочитал до конца, надеюсь представленная информация будет вам полезной.
Задание из разряда: вывести содержимое таблички, добавить возможность фильтрации данных, но при этом заложить в архитектуру возможность последующего развития и масштабируемости. Примечание: Настоящее ТЗ конечно более подробное.
Каково же было мое изумление, когда один за другим, кандидаты с солидным резюме присылали такие перлы, что просто страшно становилось за их системы. Соответственно таких кандидатов мы не приглашали, а ведь наверняка это были хорошие разработчики.
В этом посте я хотел бы описать основные характеристики и ошибки тестового задания, на которые я обращаю внимание. Надеюсь, этот список поможет кому-то быстрее найти работу.
Первым делом, хочу сказать, что для меня тестовые задания делать всегда лениво. Это же нужно в перерывах между собеседованиями или вечерами после работы выделить время на написание программы, которая скорее всего не имеет никакого практического применения. Тратить свое время на ТЗ, когда я, соискатель, еще окончательно не решил, нужна мне эта компания или нет?
Тут хочу посоветовать побороть лень и выполнить задание максимально качественно, думаю, ради новой работы, новой зарплаты, новых перспектив стоит найти на это силы.
Итак, архив с программой у меня есть, и вот основные пунктики, на которые я обращаю внимание:
- Описание программы и если надо наличие инструкции по развертыванию приложения. Здесь можно написать кратко о принятых архитектурных решениях, упомянуть о необходимости изменения файла конфигурации или о необходимости запуска SQL скриптов.
- Приложение должно просто и легко открываться в среде разработки (Visual Studio) и не требовать установки доп. модулей. Если используются сборки сторонних приложений, то не забудьте их приложить к архиву.
- Пользовательский интерфейс — хоть задание и тестовое, но UI должен быть приятным глазу. Я, конечно не требую дизайна от А. Лебедева, картинок и прочего, но неряшливо разброшенные по белому холсту контролы плюсов не добавляют. Тут же я прикидываю юзабельность предлагаемого решения. Некоторые используют стандартный дизайн (например, дизайн стандартного приложения ASP.NET MVC), он, конечно приятный, но в этом случае не дает возможности понять, насколько у вас развит навык front-end разработки.
- Далее выполняю анализ верстки, тут в основном смотрю на наличие файла стилей, на оформление html разметки, на название элементов. Ничего сложного, но и этого многие не делают. Табличную и дивную верстку не разделяю, но очень хорошо, когда можно посмотреть и на то и на другое. Здесь еще обращаю внимание на наличие MasterPage.
- Прохождение ручных тестов. Пытаюсь различными способами уронить приложение, и мне это удается в большинстве случаев. К моему сожалению, наиболее частая ошибка — SQL Injection, это сразу огромный минус, можно сказать, fail. Пожалуйста, проверяйте свои программы, давайте их потестировать друзьям и знакомым, а то создается впечатление, что программу и не запускали никогда.
- Далее смотрю на стандарт кодирования. Конечно, стандарты бывают разные, в этом случае я смотрю на единообразие в оформлении кода. Код с TextBox1, Label1 и прочими именами тоже единообразен, но я его отношу с «плохому» стандарту. Не ленитесь дать корректные имена контролам, соблюдать регистр и правила в наименовании методов, параметров, переменных, комментировать код и пр.
- Далее смотрю каким образом организована работа с БД. Очень хорошо, если используются технологии указанные в требованиях к вакансии. Также я отдаю предпочтение заданиям, в которых используется ORM. Большинство разработчиков с БД работают через GridView + Object/LinqDataSource, вроде так проще и быстрее. Мне кажется такой подход не всегда дает понять уровень разработчика, и расхолаживает его в дальнейшем. Тут тонкий момент, если начать делать грид самому, то можно попасть в касту «велосипедистов». Поэтому стоит предупредить о выбранном решении в readme к программе.
- Далее смотрю, разделено ли приложение на слои. К моему сожалению классика — уровень источника данных, уровень бизнес-логики (сервисов) и представление очень редко используется. Многие ограничиваются помещением всего кода в codebehind одной страницы. Не делайте этого! Да, так проще и быстрее, но тем самым вы ставите себя на уровень junior-разработчика! Когда видишь такой код, то отпадает всякое желание смотреть его дальше и знакомиться с кандидатом.
- Далее смотрим на способ обработки ошибок. Какие способы логгирования используются? Куда перебрасывает пользователя при ошибке? Видит ли пользователь весь стек ошибки или ее лаконичное описание? Вообще, задумывался разработчик об ошибках?
- Далее можно еще посмотреть на использование JavaScript и Ajax, конкретно для нас требования необязательные, но полезные.
- Под конец изучаю предложенную схему кеширования (запросов к БД и страниц).
- Приятной редкостью является наличие Unit-тестов. Это сразу плюс в карму соискателя.
- По ходу дела выискиваю орфографические ошибки. Для меня это показатель аккуратности разработчика.
Иногда соискатели впадают в крайность и предлагают сверхсложные варианты, со своими велосипедами и нетрадиционными подходами не оговаривая это в сопроводительном письме к ТЗ. Изучать такое ТЗ интересно, но чаще всего соискатель получает доп. минус или как минимум настороженное отношение.
В общем, как-то так вот все происходит.
Спасибо всем, кто дочитал до конца, надеюсь представленная информация будет вам полезной.