Русский
Русский
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 для сборки будет преимуществом.

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

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

Подробнее..

Как работать с джуниорами?

08.07.2020 14:22:16 | Автор: admin
Если попробовать ответить на вопрос в заголовке одним предложении, то получится доверять, но проверять. Доверьте джуниорам какую-то работу, проверьте, помогите, повторите цикл. Но это грубое и упрощённое правило, потому что в работе с джунами возникает так много тонкостей, что об этом нужно рассказывать обстоятельно.



Рассказывать будет Серёжа Попов, CEO Лига А. и директор по талантам в HTML Academy. В Лига А. работа с джуниорами поставлена на поток: половина фронтендеров компании это выпускники HTML Academy. Выпускники приходят в компанию на стажировку, где им помогают развиваться, а 95% тех, кто после стажировки ищет другую работу трудоустраивается.

Серёжа уже больше 3 лет выполняет роль наставника для джуниор-фронтендеров и научился работать с ними так, чтобы новички быстро росли до крутых специалистов и приносили пользу компании. Нюансами, принципами, правилами и секретами работы, он поделился в докладе на TeamLead Conf 2020, а мы расшифровали.


Кроме цикла дать задачу, проверить, помочь джуниоров нужно: уважать, напоминать, контролировать, думать, что говорить, правильно расставлять задачи, помогать развиваться, указывать на ошибки, но объяснять, быть снисходительным и подбадривать, учить других работать с джуниорами, думать над тоном обратной связи

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

Зачем нужны джуниоры


Перед тем как рассказать о работе с новичками, расскажу, зачем они вообще нужны. Есть несколько причин (или проблем на рынке).

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

Если простую задачу ценой в 1000 рублей выполняет человек со ставкой 2500 рублей в час что-то пошло не так. Поэтому здесь не обойтись без джуниоров они сокращают стоимость производства (продуктов, ПО).

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

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

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

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

Подготовка к джуниору


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

Сформированные задачи важны (или понимание, как их сформировать), потому что джуниор это работник. Он не талисман, который ходит по офису и всех подбадривает, а сотрудник, который должен работать и выполнять задачи.

Джуниор может выполнять что-то простое:

  • правки;
  • модификации готовых компонент;
  • создание простых компонент;
  • работать по инструкции или документации.

Ребята, которые попадают к нам, делают простые вещи: вносят правки или собирают страницы по UI-kit. Потом растут и выполняют задачи сложнее, например, пишут простую логику.

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

Джуниор это не мидл. Ему нельзя поставить задачу с дедлайном через месяц он её не сделает. Джуниора нужно постоянно контролировать. Для этого и нужен ментор, который помогает довести задачи до конца.

  • Помогает настроить окружение, потому что джуниор не разберется в том, как это делал сотрудник до него.
  • Определит и сформулирует задачу.
  • Оценит, как и когда джуниор её выполнит.
  • Поставит задачу.
  • Ответит на уточняющие вопросы и направит к решению.
  • Оценит качество выполнения и поймёт, что человек растет.

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

Для джуниора должна быть работа и человек, который ее контролирует.

Отбор


Второй и самый важный этап, который все недооценивают. На этом этапе придётся научиться многим вещам:

  • привлекать поток джуниоров;

  • просеивать поток до собеседования;
  • собеседовать;
  • отсеивать тестовым заданием;
  • выбирать кандидатов.

Привлечение


Есть три способа: своими силами, силами образовательных площадок и с помощью своей школы.

Своими силами: размещайте вакансии на специализированных площадках вроде hh.ru или Хабр Карьера. Осознанно подойдите к составлению вакансии от неё зависит сколько нерелевантных откликов вы получите (а получите обязательно).

В описании вакансии не добавляйте лишнего. Если просто взять описание для мидла и заменить там одно слово это не сработает. Джуниоры боятся таких вакансий, когда между словами Привет и Печеньки находится много незнакомых терминов. Поэтому для джуниоров важно указывать реальные задачи и стек, которые будет использовать человек. Если человек должен верстать пишите, что кандидат должен знать HTML и CSS. Если надеетесь, что через полгода освоит React не пишите об этом сейчас, спугнете.

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

Своя школа. Например, так делает Яндекс у них своя школа ШРИ Яндекса. Открывать свою школу эффективный путь получения хороших начинающих специалистов. Но долгий, дорогой и сложный:

  • придётся разработать образовательную программу;
  • подготовить онлайн-платформу (или найти помещение, если это не онлайн-школа);
  • записывать видео;
  • тратить часы разработчиков;
  • вкладываться в маркетинг.

Всё для того, чтобы привлечь толпу джуниоров, которые при этом учатся где-то ещё.

Отсев потока


После появления вакансии на площадках с работой, вы получите сотни откликов. Но вы не будете брать на работу всех, нужно как-то их отсеивать. Например, когда в Лига А. мы опубликовали вакансию Начинающий Верстальщик, то получили 164 отклика. Из них до собеседования дошло 10 человек, а вышло на работу 2.

8 человек из 10 не дойдет до собеседования.

Это усредненная статистика: по нашему опыту, по вакансиям Центра Карьеры HTML Academy и по статистике других работодателей. Вас тоже ждёт такая воронка, если не хотите брать на работу всех подряд.

Будьте готовы просеивать подготовьте себя и команду к тому, что будет много заявок, но низкая конверсия (как у нас или ещё ниже). У вас должно быть на это время, ресурсы и моральная готовность. После публикации вакансии поток заявок будет нескончаем в какой-то момент придётся обрубить поток.

Определите, на что будете обращать внимание. Только вы знаете, какого джуниора хотите найти. Отталкивайтесь от важных в вашей компании навыков и ценностей. Смотрите на подходящие навыки. Если нужен PHP-разработчик, не добавляйте в описание работу с HTML. Если ищете в штат, а в резюме соискателя написано Только удаленка, то он не подходит. При этом не важно, насколько хорошо резюме одного критерия достаточно.

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

Не ждите идеального резюме.

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

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

Собеседования


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

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

Брать побольше людей придётся и для того, чтобы у вас был выбор. Но выбирать вам придется не между Ламборджини и Феррари, а между Ладой и Москвичом.

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

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

Зовите больше кандидатов, но меньше коллег.

Не давайте тестовое задание на собеседовании. Мы в Лига А. собираем истории от джуниоров о том, как у них проходит трудоустройство. Один из случаев: новичок пришел на собеседование, а интервьюер даёт ноутбук и говорит:

Сверстай по PSD.

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

Но не отказывайтесь от технических вопросов: спросите, что такое HTML, CSS, как работает JavaScript, что такое браузер:) Но только если видите, что человека не трясет и он не упал в обморок.

Смотрите на развитие и адекватность. Узнайте, как он учился и как узнает новую информацию. Если человек расскажет о важных для сообщества подкастах, митапах, конференциях, блогах, каналах на YouTube это то, что нужно. Если отвечает: Я диплом получил, зачем мне ещё учиться?, то до свидания.

Желание обучаться одна из ценностей компании, по которым мы также отбираем кандидатов. Ещё одна ценность горящие глаза. Горящие глаза подскажут, что человек готов работать. Не сам он горит, а только глаза. Сам он гореть будет, когда устроится на работу.

Тестовое задание


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

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

Трое из четырех джуниоров не возьмутся за сложное тестовое задание.

Разработайте простое задание, которое покажет вам необходимые компетенции кандидата, чтобы его мог сделать джуниор. Например, если ищете верстальщика дайте задание сверстать кнопку, а если JavaScript-разработчика сделать калькулятор тарифов. Слишком сложное задание отпугнет хороших кандидатов.

Расписывайте задание максимально подробно и понятно. У джуниоров нет опыта, на который они могут опираться. Они не делали 10 000 тестовых заданий, не знают нюансов и тонкостей. Скорее всего, ваше будет одним из первых и джуниор будет делать то, что видит. Если нужен результат, опишите его максимально подробно.

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

Ставьте сроки из расчёта 2 к 1. Джуниоры выполняют работу примерно в 2 раза медленнее. Если даёте тестовое задание на 2 часа, рассчитывайте, что джуниор выполнит его за 4.

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

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

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

Выбор кандидата


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

Но не берите несколько человек с расчётом на то, что в конце останется только один. Это не игра на выживание.

Берите на перспективу. Джуниор не выдаёт результат здесь и сейчас. Рассчитывайте на то, что он будет приносить пользу через полгода.

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

Хороший способ не нервничать чем-то заняться: почитать о корпоративной культуре, познакомиться с продуктами, изучить code style. Дайте задание до выхода этими и другими способами подготовиться к работе.

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

Испытательный срок. Первые два месяца новичок работает на 200% своих возможностей, а дальше устаёт и раскрывает свои истинные таланты. Поэтому прописывайте время испытательного срока в три месяца это оптимально.

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

Через две закрытые вакансии вы научитесь отбирать джуниоров.

Работа


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

Онбординг


Не бросайте в мясорубку. Как избавиться от джуниора? Кидаете в него в первый день боевую задачу, например, развернуть окружение, и уходите. У него начинается паника. Приходите через неделю за результатом, а у вас мёртвый джуниор (если он еще не уволился) и невыполненная задача.

Не оставляйте одного. Моя первая работа разработчиком в большой компании проходила в Veeam Software. Тогда мне не нравилось, что меня таскали на дурацкие планёрки: полно народу, все что-то говорят, какие-то странные люди по Skype разговаривают на английском, ничего не понятно, что происходит. Но сейчас я понимаю, что это помогло мне окрепнуть, окунуться в рабочий процесс и стать частью коллектива.

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

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

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

Процесс работы


Прошла неделя, две джуниор окреп и привык. Что изменилось в нашем подходе?

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

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

  • Берите на все командные и рабочие мероприятия даже в качестве слушателя.
  • Возьмите джуна в релиз пусть сидит и смотрит, как все бегают в огне. На третий релиз он начнет помогать.
  • Учите работать в команде. Джуниоры умеют писать код и работать с системой контроля версий, но не в команде. Будьте к этому готовы, учитывайте это и помогайте наладить взаимодействию.
  • Не позволяйте команде обижать джунов. Если у вас есть джуниор, значит он нужен. Следите, чтобы другие разработчики не грубили и не отказывали в помощи.
  • Не позволяйте джунам обижать команду. Когда джуниор не принимает правила работы, вступает в конфликты и споры со старшими специалистами, говорит:Я Дартаньян, а вы нет, и работа с ним превращается в ад меняйте. За дверью стоит очередь из таких же.
  • Не доверяйте. Настраивайте безопасное окружение, отдельные ветки, запрет на коммит в мастер все на уровне системы, а не на честное слово.

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

Джуниор никогда не расспросит о задаче, не уточнит, а будет пытаться все решить сам. Когда джуниор сидит 3 дня над задачей и не задаёт вопросы это обычная ситуация. Многие не умеют и боятся задавать вопрос.

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

В то же время, не беспокойте джуниора слишком часто. Джуниоры работают медленнее в 1,5-2 раза медленнее, по статистике Лига А., HTML Academy и других проектов на выборке в 500 джунов. Учитывайте это при постановке задач и планировании. Если джуниор будет систематически не успевать за вашими сроками, это будет его демотивировать.

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

Как вы посмели провести код-ревью моего кода! Я не привык к тому, что мне указывают на мои ошибки!

Это выдержка из рабочего чата от разгневанного джуниора. Джуниоры не привыкли к разбору их кода, в отличии от опытных разработчиков.

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

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

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

Мотивация


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

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

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

Никто не хочет быть вечным джуном.

Не держите джуна долго в статусе начинающего специалиста, растите внутри компании. Через 3-6 месяцев новичок вырастает в крепкого специалиста.

Но всё это работает при наличии зарплаты. Джунам надо платить деньги. Возможны бесплатные стажировки, но без денег джун долго не протянет.

Что дальше?


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

Не бойтесь джуниоров и процесса их поиска. У них есть плюсы.

  • Горящие глаза и способность давать результат. Если учтете все нюансы и выберете правильного человека, то результат будет.
  • Стартовая зарплата в два-три раза ниже рынка.
  • Трудно мотивировать человека, который работает только за деньги. Джуниоров мотивируют не только деньги.
  • Нет предубеждений относительно рынка и компании. Для большинства джуниоров ваша компания будет первой. У него не будет опыта работы в других компаниях и будет проще их приучить к вашей культуре.

Джунов много.

Будет из кого выбрать. У вас не будет моей ситуации, когда 4 кадровых агентства искали мне сеньора 2,5 года. С джунами проще: заходите в метро, берете первого попавшегося человека это готовый фронтендер-джуниор.

Приготовьтесь к тому, что джуниоры будут:

  • бесить;
  • задавать тупые вопросы;
  • остро реагировать на критику;
  • медленно работать;
  • подвергать сомнению ваше доверие к ним;
  • бесить.

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

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

Вторую TeamLead Conf в этом году мы снова проведем в Москве, 16 и 17 ноября. Это будет очная встреча со всеми атрибутами: спикерами на сцене, кулуарным общением, митапами-воркшопами и кофебрейками.

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

Три ошибки, которые я совершала как 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