Comments 36
Так собеседование прошёл или нет? ;)
До этого я неоднократно начинал его делать, но сталкивался с тем, что без нормального фронтэнда приложение вообще не вдохновляло.
Такое ощущение, что я его делал, но в менее подробном варианте и на react. Да ещё и на позицию senior/tech lead.
На практике, я так и не понял, что ждали от меня, поскольку завернули с формулировкой о недостаточном уровне построенной архитектуры.
Отсутствующем требовании, которое невозможно реализовать без понимания развития проекта: микрофронты, сильно или слабо связанный монолит, особенности бизнес-логики, компетенций команды.
Но, все к лучшему, я пришел в проект на порядок сложнее. Но ТЗ тоже было.
Первое правило тестовых заданий — никогда не делайте тестовые задания!
Ну не знаю, на свою первую работу по фронтенду я устроился, написав тестовое задание. (3 дня писал, дважды переписывал), зато сразу на позицию миддла. Без тестового задания со мной даже разговаривать бы не стали.
Вы не смотрите их репозиторий? Не просите примеры написанного ими кода?
1) Опыт из резюме, который теоретически можно написать вообще любой
2) Репозиторий, куда можно положить теоретически не свои задачи
3) Ссылки на тостер и stackoverflow с хорошим рейтингом и множеством отвеченных вопросов (тут уже не придраться, показатель относительно объективный)
4) Live собеседование (но оно может не дать ясной картины, так как кандидат может волноваться и задачи можно дать лишь простые)
И получается что тестовое на пару часов наиболее объективный показатель
2) Если я смотрю репозитории, то задаю вопросы, почему были приняты те или иные решения. Если кандидат скопирует чужие задачи, то быстро спалиться, хотя такого я не встречал, мне интересно как человек принимает решения.
4) На live собеседованиях, мне главное проверить не блефует ли человек, задаю вопросы от простейших и постепенно перехожу к коротким, не сложным задачам. Мне здесь важно оценить способность инженерно мыслить. По моему опыту хождения на собеседованиях, встречал разное, от абсурдного и смешного до профессионального, продуктивного общения. Встреча работодателя и кандидата — это наверное самое важное, здесь сразу можно понять с кем и как предстоит работать, решить нужно ли оно обоим.
Как люди относятся к колегам, которые за 7 лет работы не завели публичных репозиториев, потому что плохой код поделок "только для себя" выкладывать стыдно (да и кому он нужен?), а писать хороший код в хобби-проекте на недельку только чтобы покрасоваться, лениво? А дольше недели ничего не увлекает, и ещё и поэтому нет репозиториев, основанных на энтузиазме.
Может кому то, будет интересно. Делал такое же тестовое. Кстати дальше прошел. https://github.com/dDenysS/vue-todo
Никогда не понимал тестовые задания, решением которых является калька кода из todo.mvc или просто туториала по языку. Особенно когда его нужно начать с нуля, где в итоге большая часть времени уйдет на разворачивание окружения.
Мне больше нужно было проверять такие, чем выполнять, и каждый раз возникает вопрос "и на что смотреть? Все как везде, что оно проверяет?"
Сам я обычно делаю тестовое задание, которое должно занять не более часа и представляет собой готовое решение, в которое нужно встроить свой, например, редакс стор (все страницы и компоненты уже готовы), и просто оживить страницу. Но чтобы не было так скучно, обычно есть хитрый компонент или хитрое АПИ у сервера, в итоге можно сделать разными способами и потом на собеседовании рассказать почему решили задачу именно так.
TypeScript на Vue 2 спорно применять, слабая поддержка.Для поддержки TypeScript есть сторонние библиотеки и они вполне хорошо работают.
А самое печальное — половина ТЗ требует как минимум 1 дня на выполнение (Т.к. требуется писать с нуля, иногда без использования фреймворков).
Отдельный маразм: Потребовали написать одностраничник с формой обратной связи. Без фреймворков. Вообще всё ТЗ было так составлено, что проще всего его выполнять «в старом стиле», через функциональный подход, двумя файлами (вывод страницы и обработчик формы).
А в итоге выяснилось, что они ожидали чутьли не полноценный аналог Laravel…
Тестовое задание дается с целью отличить программиста знакомого с технологиями от специалиста работающего с ею. Можно не знать vue и выполнить задание по примерам из доков. Это не отражает Ваш уровень.
В задании запретили использовать сторонние библиотеки — ну покажите, что можете без них.
Если в тексте формулировки ИЛИ, то нужно выбирать более ценное решение из предложенных. Согласитесь, если бы приложение было обернуто в docker, написаны какие-нибудь jest тесты, в коде использовались разные приемы организации css: scope / modules / бэм, подключен vuex, реализована асинхронная подгрузка, js'ки заменить на ts'ки с внятным описанием типов (или вообще собрать на vue3), добавить I18n, нормально оформить конфиг, т.д.; то результат работы выглядел бы куда интереснее, чем простое выполнение.
PS: На месте фаундера не ответить было некрасиво.
сайта.ехническое заданиеехническое заданиеехническое задание
поправьте
github.com/vadimLuzyanin/vue-todo-list
Дошел до собеседования, но фидбека по нему так и не получил)
* Поможет ли выполнение собственному развитию,
* хорошо ли оно будет смотреться в собственном портфолио,
* приложил ли работодатель усилия, чтобы познакомиться с вами.
Если работодатель (или специально обученный работник от него) молча высылает задание в ответ на отклик, или даже учтиво сначала задаст пару незначащих вопросов — это звоночек, что задание будет выполнено бесполезно, если только не пригодится себе — для развития и портфолио.
Если даже потом этот собеседник настаивает на уточнении сроков и ведёт общий диалог — оценивайте исключительно с позиций собственной выгоды, на что тратить время — на другие собеседования и встречи, или в ущерб им тратить время на углубление в задание.
То же самое — если задание платное. Нет смысла разрывать период поисков на неорганично вписывающуюся в них мелкую работу. Если чувствуете, что работа над заданием мешает — отложите её до лучших времён.
Детали: habr.com/en/post/213913 (от 2014 года).
Разбираем тестовое задание на должность фронтенд-разработчика на Vue.js