Русский
Русский
English
Статистика
Реклама

Джун

Тестовое задание для фронтендера

21.01.2021 10:23:56 | Автор: admin

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

Верстальщик такой человек, который хорошо разбирается в HTML и CSS и немного знает JavaScript. Ну то есть понимает, как в целом всё работает, но сильно не погружается. При этом бывает непросто выбрать хорошего верстальщика, потому что всех учат по-разному.

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

На что смотреть в целом

Соответствует ли результат ТЗ? Всё работает? Всё заверстано? Джуну прощаются мелкие недочёты, но он хотя бы показывает что хотел сделать как можно лучше, просто пока не хватает практики. Если сделано спустя рукава, то это тоже видно.


Пример: сверстать аккордеон

Соответствие ТЗ: аккордеон завёрстан по макету, нет ошибок в HTML. JavaScript написан без onclick, код для аккордеона можно переиспользовать на других страницах и блоках.

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


Предусмотрено ли переполнение? Сильно ли едет макет при добавлении/удалении элементов? Можно ли ввести 4 строки, если в дизайне нарисовано 2? Предусмотрены ли максимальные и минимальные размеры?

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

Столько плюсов каждому по нраву

Как оформлена сборка? Есть readme? Запускаются таски из gulp? Такие мелочи показывают, есть ли у человека опыт в разработке. Обычно, когда сверстаешь пару проектов, учишься наводить порядок в файлах и умеешь работать с таск-менеджерами. В идеале нужна чистая сборка: всё разложено по папкам, комментарии убраны, лишних файлов нет.

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

Как подключаются скрипты и стили? Есть ли инлайн? Есть ли onclick="" или style=""? Джуну какие-то вещи простить можно, мидлу нет.

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

Как реализованы ховеры и адаптив? Это не обязательно, но будет плюсом, показывает опыт и аккуратность. Сразу видно, как человек импровизирует, так как в макете не рисуются разные состояния кнопок. Хорошая импровизация показывает, что человек может заморочиться и сделать вау потому что ему хочется так сделать, а не потому что так сказал босс.

Ховеры на сайте Лиги А.

HTML

Что с семантикой? Есть ли header/main/footer? Правильно ли построена разметка по макету?

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

Как вставлены картинки? Предусмотрены ли webp и ретина?

Как оформлены векторные элементы? Вектор это точно SVG, а не PNG? В тестовом задании мы обращаем внимание на сжатие SVG (вручную или через таск-менеджеры) и как элементы вставлены в разметку (лучше всего использовать спрайты для иконок, а не псевдоэлементы или img).

Вот что может случиться, если не подумать о графике заранее:

Внеклассное чтение:

Как свёрстана форма? Есть ли ховеры/фокусы? Какая кликабельность у элементов?

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

CSS

Прибит ли футер к низу экрана? Очень практическая штука, которая показывает опыт кандидата.

Вот здесь не прибит, например. Но мы всё равно вас любимВот здесь не прибит, например. Но мы всё равно вас любим

Как написана сетка? Используются гриды или флексы? Если сетка кривая, то или человеку всё равно, или он ещё джун.

Как подключаются шрифты? Если как-то странно, например, в каждом font-face в качестве шрифтового семейства прописаны montserrat-thin, montserrat-bold вместо montserrat и указания жирности отдельным свойством, то это джун. Используются ли новые свойства вроде font-display или unicode-range? Они не обязательны, но если есть и они действительно там нужны, это плюс.

Используются ли препроцессоры? Это необязательно в тестовом задании, но упрощает разработку.

В JavaScript-коде

Эти требования, в основном, для мидлов. Джуну достаточно знаний HTML/CSS и аккуратной сборки проекта.

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

let a = 1let b = 2setTimeout(() => {[a, b] = [b, a]console.log(a) // 2console.log(b) // 1}, 0)

Странный код для обмена значений двух переменных

Какая версия языка используется? Есть ли единообразие? Есть ли такое, что весь проект на ES5, а потом блок на ES6? Обычно это показатель того, что какой-то блока кода писал кто-то другой.

Пример смешивания:

Как разбит код? Это один огромный модуль (плохо) или есть деление на папки/скрипты, где 1 скрипт = 1 задача (хорошо)? Также не должно быть слишком много файлов, а вызов и обработка функции происходит в одном файле, а не в нескольких.

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

Spoiler
const mailRegEx = /[a-zA-Z0-9]{1}([a-zA-Z0-9-.]{1,})?@[a-zA-Z]{1}([a-zA-Z0-9.]{1,})?[a-zA-Z0-9]{1}.[a-zA-Z]{2,}/;const PHONEMINLENGTH = 18;const showErrorIcon = (sth) => {const input = sth.target || sth;const errorIcon = input.closest('.custom-input').querySelector('.custom-inputerror');if (!errorIcon.classList.contains('custom-inputerror--shown')) {errorIcon.classList.add('custom-input_error--shown');}};function IsNumeric(sText) {var ValidChars = "0123456789.";var IsNumber = true;var Char;for (i = 0; i < sText.length && IsNumber == true; i++) {Char = sText.charAt(i);if (ValidChars.indexOf(Char) == -1) {IsNumber = false;}}return IsNumber;}

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

  • https://kenwheeler.github.io/slick/

  • https://glidejs.com/

  • https://swiperjs.com/

Slick требует jQuery, у нас в проекте он не используется. Вычеркиваем.

Смотрим документацию. У glide она подробная, у swiper тоже. Если бы её не было, мы бы вычеркнули один из пунктов.

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

  • https://github.com/nolimits4web/swiper - 11 минут назад

  • https://github.com/glidejs/glide - 23 дня назад

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

Далее смотрим на вес. glide ~23kb, swiper ~140kb значит, одно очко за glide.

Зачем нам плагин? У нас большой сайт с кучей анимаций, где нужно сделать слайдер в слайдере с 3D-эффектом перехода? Берем swiper, он как швейцарский нож, в котором есть почти всё. У нас одна страница с простыми переходами? Берём glide, в нём ничего лишнего.


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

Сверстать макет (тут у каждой компании будет своя ссылка на фигму).

Учебный проект Барбершоп из курса HTML и CSS. Профессиональная вёрстка сайтовУчебный проект Барбершоп из курса HTML и CSS. Профессиональная вёрстка сайтов

Требования:

  • Шапка всегда закреплена, у неё белый фон;

  • Фильтр должен сортировать карточки;

  • Кнопка сбросить фильтр показывается после того, как выбрали что-нибудь;

  • Адаптив на своё усмотрение.

  • Нельзя использовать jQuery;

  • Возможно использование плагинов JavaScript;

  • Использование Gulp или Webpack для сборки будет преимуществом.

С таким заданием будет гораздо проще искать фронтендера хоть джуна, хоть мидла.

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

Подробнее..

Джуном? в 40-к лет? Ещё и на удаленку? Да ну, не выдумывайте

24.03.2021 00:15:52 | Автор: admin

И все-таки это возможно...

..., в 40 лет выучиться топтать кнопки и этим зарабатывать, но путь к этому тернист, сложен, неоднозначен, сами придумайте какое-нить сложное определение, непростой и нелегкий. Если Вы уверены, что готовы к нему - то вы однозначно его пройдете!

Вообще таких success stories в интернетах полным-полно, помните как таксист учил Java на перекурах, курьер слушал подкасты на велике, хирург... уж не помню, когда хирург умудрялся учить ООП, но похоже делал он это вместе с таксистом и курьером.

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

Да-да, я именно тот 40-летний джун, которому удалось попась на удаленку и среднюю зарплату в не очень крупную, но гордую контору... Хотите узнать как это получилось?


Глава 1: что мы имеем?

Прекрасно, когда вам 15-ть... считай жизнь только начинается... и 25-ть... девушки, тусовки... и 35-ть... кажется, как много уже сделано...

Мой случай, сложнее... 40 лет, жена и дети, родители-пенсионеры, дом и хозяйство, собака и кошка, мыши и тараканы, работа в кровавом энтерпрайзе по 10 часов/день и полное отсуствие времени...

Да, энтерпрайз давал зарабатывать приемлимые деньги, но постоянное погружение в болото (хоть и теплое) бюрократии, под управлением гибкой методологии "Я начальник, ты - раб", оттачивание мастерства по придумыванию на ходу отмазок и отговорок; умение в пол-глаза и пол-руки наваять до 12-ти (кстати, реальное число) версий объяснительных по одной проблеме... все это..., угнетало...

Я же в конце концов специалист, инженер, ИТ-шник, Телеком-щик, кто угодно, но не тот, кем меня заставляют быть!

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

Глава 2: начало...

Решение принято, надо двигаться - вспоминать/повышать квалификацию, но с чего начать? Кто спрятал рецепт счастья? Где пархает эта синяя птица удачи?

А ещё надо решать вопрос, где брать на все это время... ведь работу то бросать нельзя - все хотят кушать и куклы LOL... На работе - работаешь..., наняты специальные люди, которые за зарплату следят как ты работаешь, тут в образование не вложишься...

Выход один - придется снова жертвовать сном...

Не буду подробно утомлять читателя муками выбора специализации, но взор упал на "попробовать Python" и на "почитать про QA" (на самом деле, просто потому что Python просто "попер", а QA очень отдаленно пересекался с работой в энтерпрайзе)...

Глава 3: и как все это учить?

Все это учить можно в Интернете и бесплатно... Звучит классно, но - не работает...

Информации в этих ваших Интернетах настолько много, что, лучше бы ее не было вообще... ну или просто поменьше...

При любом более-менее релевантном поисковом запросе, тебя раздивает на части реклама, которая уверяет, что в твоей жизни уже все прекрасно, осталось перевести все-лишь какие нить n*10 тысяч рублей вот по этим реквизитам (и это уже с 30% скидкой, надо же как повезло), и буквально после наших месячных курсов, HR-ы из FAANG будут мыть тебе ноги в надежде привлечь твое внимание...

А как же традиционный для нашей страны особый путь? Надо найти возможность и учиться бесплатно... Что в результате получилось:

  • Видосики в Youtube - отбросил, потому как засыпаю... Плюс тяжко разбираться, какая инфа актуальная, какую технологию уже давно все забыли... Дальше видосиков не шло, кнопки не понажимать...

  • Подкасты - почти сразу после начала, голоса авторов перекрывал мой храп.

  • Книги - тоже рубит, сухое повествование убаюкивало ещё в студенческие времена...

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

Зашли курсы от www.codecademy.com и немного www.datacamp.com, пока там можно писать код бесплатно...

Так, синтаксис примерно понятен, прохэллоувордились, дальше что? И из FAANG что-то все никак не звонят...

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

Глава 4: хорошее ревью - стоит денег, ревью от ментора - бесценно.

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

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

Выбор программ основывался на следующих условиях:

  • много практики, чем больше тем лучше, и только выжимка теории (читайте по про метод сломанной пирамиды);

  • ревью... ревью живого человека, у которого можно спросить, с которым можно поспорить;

  • кейсы приближенные к коммерческим, поменьше виртуальности;

  • комьюнити таких же дураков джунов как я...;

  • бюджет побюджетнее..., действительность корректирует хотелки.

И да, я нашел таких ребят! И да, я НЕ назову их здесь!

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

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

А ещё комьюнити... Можно перетереть с такими же как ты, учениками/студентами, с преподами, и даже с основателями/евангелистами всей этой кухни!

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

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

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

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

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

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

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

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

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

Тестовое сделал вечером, отправил ещё позже и... через 20 минут я получаю приглашение на второй этап... Ну вот те на...

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

Ещё удивительнее было через пару дней... прилетела обратка от давно отправленного тестового... ещё один офер :).

Послесловие.

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

Про QA: Я рассказал, про то как познавал Python и ни слова о QA. Исправляюсь... разрешите посоветовать труды Святослава Куликова, уж очень доступно все изъясняет... Спасибо ему за бескорыстный труд!

Про английский язык: Он просто необходим... У меня дружба с ним не клеялась и сейчас если и склеена то на сопли и слезы...

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

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

Про контору, которая забрала меня к себе писать код: Меня пригласили писать тесты на PyTest, Selenium и допиливать какие внутренние библиотеки. Сам ещё не знаю с какой стороны подойти к той пиле, которой должен буду допиливать...

Всем удачи! А мне пора писать код... :).

Подробнее..

Три ошибки, которые я совершала как junior QA engineer

04.03.2021 08:09:05 | Автор: admin

Есть мнение, что войти в айти легче через тестирование. Будучи на третьем курсе, я part-time подрабатывала асессором. Тогда я впервые попробовала себя в тестировании, увидела первые чек-листы (я еще не знала, что они так называются). Войти в айти не было моей целью, потому что я уже и так училась на программиста, но сама идея тестирования меня очень увлекла. Так на последнем курсе я устроилась на стажировку в Kolesa Group.

Месяц подготовки: чтение пресловутого Романа Савина Тестирование дот ком, просмотр роликов на YouTube и практика в создании тест-кейсов. Этого мне хватило, чтобы начать свой джедайский путь в тестировании.

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

0. Не просить помощи

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

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

Вывод: проси помощь. Все мы люди и иногда нуждаемся в ней. Не успеваешь делегируй, но не злоупотребляй. Грамотно оценивай свои возможности и время.

1. Бояться задавать вопросы или задавать слишком много вопросов

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

В большинстве случаев так и есть, ответы на какие-то вопросы легко можно найти после пары минут гугления или поиска в stack overflow. Вопросы, связанные с бизнес-логикой, особенностями архитектуры и различными workflow, можно найти в документации (если в компании она, конечно же, ведется). Но сейчас я говорю о специфических вопросах, ответы на которые можно узнать лишь у коллег. Я могла тратить до 30 минут своего времени на гугл-поиски, поиски в документации компании, просмотр кода и даже иногда пыталась сама додумать ответ на свой вопрос (кстати, так делать не стоит). Итог: много потраченного на поиски времени и, возможно, так и не найденный ответ. Помочь избежать этого могли 510 минут общения с коллегами.

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

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

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

2. Не брать на себя ответственность

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

Вывод

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

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru