Wasilliy Beliaev @devleader-pro
Team lead of frontend
Информация
- В рейтинге
- 783-й
- Откуда
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Зарегистрирован
- Активность
Специализация
Frontend Developer, Team lead frontend
Lead
JavaScript
Vue.js
TypeScript
Nuxt.js
HTML
CSS
SCSS
LESS
Git
Nginx
В некоторых случаях да - относиться к свиданиям стоит, как к собеседованиям )))
Ну а что, разработчиком на сайте знакомств я уже когда-то работал )
Из личного опыта: то, что наваливается почтой - меня не смогло удовлетворить по условиям работы. Я в конечно просматриваю такие письма, но больше воспринимаю, как спам. Ну и в статье я указал, что это на основе личной статистике по системе: отправил отклики => пригласили на собеседование => прислали оффер.
Тут на самом деле момент спорный. Раньше я указывал такие моменты. Сейчас указываю формулировки к примеру так:
"Разработал и поддерживал корпоративный портал для общения сотрудников на Vue" - тут я указал, что: сам; с нуля, а затем поддерживал
"Участвовал в разработке клиент-серверного Web-приложения: ДБО для физических лиц на Vue" - в команде, активная статдия разработки
"Организовал команду на хакатон" - во главе команды, с нуля
Когда я перестал указывать пункты "в команде", "с нуля" и т.д, то и вопросов от интервьюверов меньше стало на эти темы)
И после этого работа стала еще и удовольствие приносить =)
Во многих компаниях, где я работал, оставляли тесты на технический долг, если нет времени заниматься именно сейчас
Довольно интересно. Но отвечу: замеры производились на основе результатов до начала работы с задачей и ее окончания. Измерялось покрытием unit тестами в % величинах.
Оценка является приблизительной, т.к. да, кодовая база могла меняться в режиме "срочно" и тесты отодвигали на второй план
Я выделял время на покрытие тестами, когда были паузы между задачами. Почему в качестве закрытия техдолга решил брать тесты - в будущем это сэкономит команде время.
Но тут не совсем корректная формулировка, потому что, если у меня за год опыта работы только работа с тестами, то возможно, я не умею раскрывать свой опыт, или почему-то в компании меня не допускали до более интересных задач
Экзамен тоже может проходить в разной форме. На личной практике убедился, что если кандидат приходит на собеседование с желанием пообщаться, узнать о компании и поговорить о технология, то оно проходит в приятной форме. Иногда даже если по хардам не подходит человек при таком общении, то тяжело дается написать отказ.
Это работает и в случае, когда я являюсь кандидатом
Как много таких было собеседований у меня, что в какой-то момент я стал прерывать их. Одно из воспоминаний: один "Frontend Team lead" и "Совет Директоров" их (!)6 человек. Отвечая на вопросы и подкрепляя их ссылками из документации, уже в открытую говоря, что буду гуглить - мне доказывали МОЮ "неправоту"... Собеседование было прервано спустя 20 минут после начала с обращением к "Совету Директоров" с формулировкой "Извините, я не смогу работать с данным человеком по причине того, что он не может аргументировать свою точку зрения"
Бывает такое. Рекомендую искать место, где будет комфортно работать. Если на общении спрашивают, как на экзамене, то что будет в реальной работе?
А можно во время общения, в случае вопроса про то, что Вы не знаете, ответить: "Извините, с данной технологией не работал или работал давно/мало/т.п... и, если она интересная - высказать свое желание ее изучить
Никто не требует от Вас абсолютно все покрыть метриками. Выше я описал конкретные случаи, когда метрику стоит приводить, в остальных случаях метрика может быть из разряда:
В данной ситуации вы уже показываете работодателю, с чем вы работали и с чем, возможно, хотите работать. Это уже может создать тему для будущего разговора
К таким значениям стоит относится с умом. Тоже читал резюме после платной услуги по его составлению - стало понятно, что оно того не стоило.
Метрики должны быть обоснованными: покрытие тестами (%), скорость загрузки (время, %), скорость сборки (время, %), размер бандла (время, %). В большинстве случаев у разработчиков это факт совершеннолетия действия: «Реализовал», «Поддержал», «Внедрил» без количественных метрик
Почему? Откликаться на вакансии, но приходить не с настроением "на экзамен к строгому преподавателю", а с настроением "познакомиться с компанией и командой"
Буквально в ответ на комментарий от @alexthetiger примеры формулировок, что можно расписать. Вам не надо писать формулировки из разряда "спасли мир позавчера", вам надо раскрыть ключевые моменты, чем занимались, какие фичи были интересны и чем Вам нравится заниматься. Если вы писали компонент карт, которыми Вам не нравится заниматься, то и указывать не стоит, а если Вам было интересно заниматься графиками, то можно указать. Про рутинные задачи спокойно можно использовать формулировку: "Реализовывал и дорабатывал функционал на проекте аналитической системы с использованием D3 и Vue" - тут сразу раскроете какие core библиотеки были и какой смысл проекта
Добрый вечер!
Лично я, когда просматриваю резюме - хочу составить предварительный портрет кандидата по разным скилам. Это позволяет мне попросить кандидата рассказать про тот опыт, который интересен для меня. Вопрос не в цифрах, а в достижениях, про которые кандидат хочет рассказать.
Как раз про тесты стоит указывать в резюме - это важный фактор. Достаточно 1-2 строчек от "Покрыл Unit (Jest) и скриншот(Cypress) тестами" до "Внедрил скриншот тестирование с помощью Cypress" и "Покрыл проект unit тестами на 80%"
Про формулировки:
- "реализовал внутренний проект" можно указать общие подробности "реализовал внутренний таск трекер, который покрывает в бизнес-процессы компании"
- "оптимизировал скорость" - очень круто будет указать за счет чего? Например: "...с помощью рефакторинга кода", "... путем подбора более подходящих библиотек", и т.д.
- "реализовал локализацию" - "реализовал локализацию дашборда по аналитике на..." и количество языков, а если он 1, то указать на какой. У меня был опыт перевода личного кабинета на язык Фарси - для компаний, работающих с Ираном - очень важный момент
- "интегрировал CI/CD" - лучше в ключевые навыки вынести, если участвовал в процессе оптимизации или перехода на новый workflow - можно расписать.
Абсолютно спокойно можно написать: "пилил фичи и фиксил баги для дашборда на D3 и React". Да рутина, но везде была, есть и будет
Описывать: ключевые фичи, фичи с которыми нравилось работать, фичи про которые хочется рассказать - этого будет достаточно
Да, к сожалению бывают и такие. Но с теорией все легко и просто - начинаешь ходить по собеседованиям, понимаешь где в теории проседаешь и повторяешь. Я сейчас понял, что у нас на фронт теория не спрашивается. У нас сразу идет live coding после общения
Спасибо, с 403 ошибкой поправим отображение. Но Вы сидите скорее из под VPN.
Наоборот, перестать относиться, как к экзамену, а отнестись как к знакомству с людьми, с которыми Вам предстоит общаться на протяжении длительного промежутка времени до 40 часов в неделю.
Как раз, да, так писать: "Уменьшил нагрузку на сервис авторизации два раза путем оптимизации кода". Работодатели не знают, чем вы занимались на предыдущем месте работы, может мы предыдущие 2 года только рекламные баннеры делали или лендинги?
Если вы описываете свои обязанности на последних местах работы, то вы уже работодателю даете оценить свои практические навыки на этапе отбора резюме + даете больше тем для общения с Вами