Привет! Меня зовут Виталий, я тимлид в KTS, и за годы работы я провел больше 100 собеседований.
В своей статье я расскажу о своем подходе к найму сотрудников. Разумеется, у каждого работодателя свои требования к соискателям, и эта статья не может быть универсальным гайдом по трудоустройству. Кто-то на собеседованиях от вас может ожидать знание 50-го аргумента функции callKek(), но это не мой подход, потому что в реальной жизни глубокого знания JavaScript не всегда бывает достаточно, а отдельные его тонкости и вовсе пригождаются крайне редко.
Сегодня поговорим о ключевых навыках соискателя, на которые обращают внимание при приеме фронтендера на работу помимо JS. Будем исходить из установки, что вы его уже хорошо знаете, и вам нужно понять, что нужно ещё. Материал нацелен преимущественно на джунов и мидлов, однако я настоятельно рекомендую к прочтению и опытным разработчикам. Спойлер: про софт скиллз поговорим как-нибудь в другой раз, в этом тексте речь пойдет исключительно о хардах.
Оглавление
Какой разработчик нужен бизнесу
Если вы хотите убедить работодателя, что взять ему следует именно вас, то вам нужно понимать, какого сотрудника он ищет. От фронтендера работодатель ожидает, что он сможет сделать качественный фронтенд и долгосрочно поддерживать его развитие.
Какому разработчику под силу такая задача? Тому, кто умеет настраивать webpack за 5 минут? Безусловно, это важный скилл, однако не менее важно, чтобы фронтендер знал и основы смежных сфер. К примеру, общее представление об архитектуре бэкенда и владение инструментами дизайнеров никогда не будут лишними, даже если они не касаются его деятельности напрямую.
При этом широкий кругозор – не единственное качество идеального кандидата. Для того, чтобы долго и прогнозируемо разрабатывать фронтенд, специалист должен понимать ключевые принципы его развития. Именно об этих принципах и пойдет речь ниже.
Но для начала нам нужно договориться о терминах. Никакой продукт, включая фронтенд, не может быть «качественным» в вакууме, ведь у каждой заинтересованной стороны будут свои критерии, определяющие это самое качество. Чтобы не запутаться, я предлагаю рассматривать фронтенд в трех плоскостях: с точки зрения пользователя, с точки зрения разработчика и с точки зрения системы.
Качество для пользователя
Поскольку наша конечная цель – разработать продукт для бизнеса, то в первую очередь мы посмотрим на фронтенд именно с точки зрения клиента такого бизнеса, то есть пользователя. Основные параметры, на которых стоит сосредоточиться в плоскости юзера – это:
скорость;
красота и удобство;
доступность;
безопасность.
Давайте разбираться в этих параметрах по порядку.
Скорость
Быстрый сайт – это сайт, который быстро загружается и быстро работает. Чтобы фронтенд работал с комфортной для пользователя скоростью, разработчику нужно грамотно его оптимизировать.
Сперва изучим шаг загрузки. Его можно оптимизировать на нескольких этапах.
Построение архитектуры фронтенда. В зависимости от целей и задач разработчик должен уметь делать выбор между разными типами архитектуры. Разумеется, это не означает, что от джуна на собеседовании будут ожидать знание тонких особенностей SSR-приложений, однако при этом ему необходимо хотя бы в теории понимать разницу между SSR и SPA, ориентироваться в их возможностях и уметь выделять сильные и слабые стороны различных решений. В свою очередь, от соискателей-синьоров работодатель будет ожидать наличия опыта работы сразу с несколькими подходами к построению архитектуры, систем микрофронтендов, дизайн-систем и библиотек.
Сборка проекта. После того, как фронтенд уже закодирован, его необходимо собрать. Сделать это нужно так, чтобы сайт потреблял меньше данных при загрузке, чтобы он подгружал только необходимую информацию, чтобы его не тормозили лишние неиспользуемые шрифты и так далее. Поэтому на собеседовании работодатель может проверить соискателя на знание следующих подходов и техник:
минификация;
транспиляция;
code splitting;
lazy loading;
tree shaking;
форматы статики (Woff2, Progressive JPEG, WebP, SVG);
способы подключения ресурсов (async/defer, prefetch/preload);
оптимизация изображений.
Безусловно, список можно продолжать, однако именно на эти навыки я рекомендую обращать внимание в первую очередь.
Выбор места хранения. Стоит оговориться, что фронтендеры обычно не управляют настройкой серверов, на которых хранится статика. Тем не менее, знать, что такое S3 и Firebase, и понимать принципы работы CDN также бывает очень полезно.
Настройка передачи по сети. Оптимизировать можно не только способ хранения данных, но и механизм их передачи. С этой задачей сможет справиться тот фронтендер, который знает:
протоколы коммуникации: в первую очередь я бы выделил знакомство с протоколами HTTP разных версий и с WebSocket для настройки асинхронного общения. В зависимости от ваших целей вы можете дополнить этот список знанием WebRTC и особенностей низкоуровневых протоколов – TCP и UDP; Эти знания пригодятся, если вы, например, хотите попасть в геймдев или в стриминг.
механизмы кэширования: чтобы не распыляться, я подсвечу два ключевых слова – [contenthash] и заголовки Expires & Etag. Если они ничего вам не говорят, очень советую выделить время на изучение темы, так как это позволит вам не только овладеть мастерством ускорения загрузки, но и понять устройство фронтенда сразу на нескольких уровнях. Важно понимать всю цепочку настройки кэширования – от настройки сборки и сервера статики до того, как данные кэширует браузер. Также в контексте кэширования полезно знать о том, что такое Progressive Web Applications и Service Worker.
механизмы сжатия: загрузку сайта можно сделать быстрее и с помощью сжатия данных, а реализовать его вам помогут подключение gzip или brotli на сервере статики;
GraphQL — еще один актуальный способ коммуникации с сервером. В первую очередь знание этой технологии пригодится, если её используют в компании, в которую вы целитесь.
Настройка работы браузера. Наконец, можно оптимизировать загрузку сайта на стороне браузера. Для этого стоит понимать, где и какие данные браузер хранит, что такое Local Storage, Cookie и Browser Cache, а в некоторых случаях вам также могут пригодиться инструменты Session Storage и браузерные базы данных. Progressive Web Applications (PWA) также актуальны в этом перечне.
Также для настройки оптимального взаимодействия браузера с сервером нужно понимать, что такое Network Waterfall и какие у него ограничения. Не уверен, спросят ли у вас о нём на собесе.
С загрузкой разобрались, и теперь можем переходить к следующей составляющей быстрого фронтенда – к скорости работы его кода. Работать быстро будет тот сайт, который был оптимально написан, так что на этом этапе мы все же возвращаемся к JavaScript (куда же без него). Рассмотрим скиллы, которые обязательно понадобятся разработчику для написания оптимального кода.
Работа с событиями:
JS Event Loop a.k.a. база фронтенд-разработки: понимание того, как устроен событийный цикл JavaScript позволит вам сделать страницу, которая не повиснет в самый неподходящий момент и не крашнет браузер пользователя, так что будьте уверены – на собесе о нем спросят. Вместе с ним рекомендую также изучить критические этапы рендеринга и Forced Reflow;
События жизненного цикла страницы: их нужно знать, чтобы интегрировать ваш сайт со встраиваемыми окружениями или рационально управлять загружаемыми ресурсами. Тема небольшая и несложная, но крайне полезная;
Событийная модель: стадии погружения и всплытия, prventDefault и stopPropagation, события DOM и события коммуникации типа ‘storage’ или ‘message’ – все это тоже может ожидать вас на собеседовании, потому что это действительно важные и практически применимые знания.
Верстка: да, она может быть не только красивой, но и эффективной с точки зрения потребления ресурсов. Грамотно разместить все элементы на вашей странице вы сможете благодаря знаниям об HTML Stacking Context, так что будьте готовы ответить работодателю на вопросы о свойстве z-index или will-change.
Исследование производительности в DevTools: эта тема скорее не для джунов, а для уверенных мидлов и синьоров, однако я не могу обойти ее стороной. С помощью инструментов браузера вы можете измерять производительность своего фронтенда, и в этом вам помогут вкладки Performance и Performance Insights. Еще обратите внимание на функцию CPU throttling, которая искусственно замедляет браузер, на отслеживание моментов подвисания через анализ JS Long Tasks и точное описание загрузки страницы через метрики Web Vitals.
Красота и удобство
Вроде как, со скоростью все более-менее понятно. А что нужно знать, чтобы сделать фронтенд красивым и удобным для юзера?
Что ж, работой над UI/UX, как правило, занимаются дизайнеры и аналитики, так что лично вас на собесе вряд ли будут осыпать вопросами на эту тему. Однако для полноты картины предлагаю разобраться и в ней – на практике эти знания вам тоже пригодятся.
Во-первых, крайне желательно, чтобы фронтендер умел примерять на себя роль аналитика и проходить полный пользовательский сценарий по дизайнерским макетам. В работе этот навык позволит вам расширить зону своей ответственности и зашагать вперед по карьерной лестнице, а на собеседовании он однозначно будет полезен, если вы претендуете на высокие грейды.
Не лишним будет разобраться и в UI-тестировании. Предлагаю по крайней мере погуглить и почитать на досуге о том, что это такое и как оно проводится.
И, наконец, фронтендеру стоит знать о различных способах верстки. Здорово, когда разработчик отличает адаптивную верстку от резиновой, а если он знает тонкости вроде Px to Rem или практикует Pixel Perfect, это еще сильнее отличает его в лучшую сторону.
Доступность
Нельзя забывать о том, что бизнес-продукт мы создаем не для самих себя, а для пользователей. Пользователи же, в свою очередь, могут не обладать теми же возможностями восприятия контента, которыми обладаем мы.
Так, например, не всякий испаноязычный юзер владеет русским или английским языком на том уровне, который обеспечил бы ему беспрепятственное использование вашего продукта. Предусмотреть подобные сценарии можно в рамках процесса i18n (сокращение от internationalization). Он подразумевает создание приложения таким образом, чтобы оно могло поддерживать разные языки и культурные особенности целевой аудитории. Следовательно, вас могут проверить на знание этой темы.
К слову, адаптировать продукт можно не только для тех, кто говорит на других языках. Фронтенд может также учитывать потребности людей с дополнительными потребностями. Несмотря на то, что такие пользователи представляют очень малую долю рынка, большому бизнесу даже скромный процент от общего числа потребителей приносит значительную прибыль. Так что будьте готовы рассказать про стандарты WSAG 2.2 и ARIA на собеседовании в крупную компанию.
Безопасность
Наконец, важно, чтобы сайт был безопасным. Этот параметр я предлагаю разделить на две основных составляющих: security и safety. Казалось бы, термины похожие, однако в действительности они обозначают совершенно разные вещи.
Security – это устойчивость системы к несанкционированному доступу. Для ее обеспечения фронтендер должен быть знаком с обширным рядом понятий.
Аутентификация и авторизация. Эти понятия тоже довольно часто путают. На этапе аутентификации система определяет, какой конкретно пользователь к ней обращается; в свою очередь, при авторизации система выясняет, какими правами обладает этот пользователь.
Чтобы настроить аутентификацию, разработчик должен ориентироваться в соответствующих методах и протоколах. Три ключевых – это Basic, OAuth 2.0 и API Token. Также следует понимать, каким образом работают токены (например, JWT или Session Token); в этой статье я не буду погружаться в подробности, но рекомендую ознакомиться с ними отдельно.HTTPS. Протокол, с помощью которого любая современная веб-страница общается с сервером, «обертка» вокруг HTTP, использующая TLS для асинхронного шифрования. Если вы не уверены, что понимаете, как работает асинхронное шифрование, обязательно восполните этот пробел при подготовке к собеседованию.
Обязательные практики. Следуя ряду общепринятых стандартов, вы сразу будете писать безопасный код, который сложнее эксплуатировать злоумышленнику. В частности, рекомендую ознакомиться с процессом Sanitize и разобраться в семантической и технической разнице между запросами POST и GET.
Виды атак. Чтобы противостоять зловреду, нужно знать, какие техники могут быть в его арсенале. Чаще всего на собеседованиях спрашивают об атаках XSS, MITM и Clickjacking. Почитайте о способах их предотвращения.
Браузерные и сетевые ограничения. Веб-сообщество разработало огромное количество сетевых политик для того, чтобы фронтенд можно было сделать безопаснее, и если вы претендуете на позицию мидла или синьора, вам нужно в них ориентироваться. Чтобы не запутаться в этой обширной теме, предлагаю гуглить в следующем порядке:
CORS, CSP, CSRF (включая особенности WebSocket и ограничения на загрузку статики);
Local Storage + IFrame = Storage Partitioning;
Пользовательские данные и Cookie (в особенности – HTTP-only и Secure);
Отличия контекста исполнения JS на сервере (NodeJS) и в песочнице браузера.
Safety – отказоустойчивость, надежность фронтенда. Чтобы ваша быстрая, доступная, красивая и защищенная от злоумышленников система в один прекрасный момент не превратилась в тыкву, вы должны знать, какими методами можно избежать такого печального сценария.
Настройка систем мониторинга. Для отслеживания нагрузки на систему и выявления ошибок фронтенд-разработчики чаще всего используют инструменты Sentry и Error Boundary. Чуть реже фронтендеры обращаются к Grafana из DevOps-арсенала, однако знакомство с ней тоже не будет избыточным.
Использование инструментов предотвращения ошибок. Найти и исправить ошибки намного сложнее, чем просто не допускать их. Чтобы избежать мелких оплошностей, при разработке фронтенда можно воспользоваться статическими анализаторами вроде ESLint, Prettier и Stylelint. Также желательно уметь настраивать pre-commit-хуки, которые будут проверять ваш код перед отправкой в репозиторий. Далеко не факт, что речь о них зайдет на собеседовании, но в работе эти навыки однозначно будут вам полезны.
Тестирование. По сути это целая отдельная вселенная, поэтому мы не будем погружаться в нее с головой. Отмечу лишь, что опыт написания тестов у соискателей ценится работодателями, и если с темой тестирования вы совсем не знакомы, то обязательно почитайте хотя бы о том, как выполнять его вручную и как можно его автоматизировать.
Снижение человеческого фактора. В отличие от человека, бездушный компьютер не допустит ошибку по невнимательности. Следовательно, часть задач по сборке и доставке нашего кода мы можем делегировать машине с помощью CI (Continuous Integration), и знакомство с этим подходом представит вас в выгодном свете на собесе. Рекомендую изучить основные принципы работы GitHub Actions и GitLab CI.
Качество для разработчика
Вернемся к разговору о том, что развитие фронтенда должно быть долгосрочным и предсказуемым. Чтобы команда могла работать над проектом на большом отрезке времени, он должен быть:
раз – надежным;
два – поддерживаемым;
три – удобным для разработки и отладки.
Опять же, в чем выражаются эти понятия на практике и как показать работодателю, что вы в них ориентируетесь?
Кто внимательно читал предыдущий раздел, тот наверняка заметил, что в нем уже шла речь о надежности (safety). Надежность фронтенда для разработчика повышается теми же самыми методами: тесты, мониторинг, чекеры ошибок и автоматизация. Так что не будем повторяться и перейдем сразу ко второму критерию.
Поддерживаемость
Само собой, чтобы фронтенд было удобно развивать, он должен быть построен на адекватных технологиях. Проблема в том, что для реализации разных проектов технологии будут подходить тоже разные, поэтому здесь совет один: откликайтесь на вакансии, требующие стека, в котором вы чувствуете себя уверенно.
Зато построение качественной архитектуры фронтенда – концепция более универсальная, и разобраться в ней не помешает никому. Да, мы вновь возвращаемся к JavaScript, но при этом важно понимать, что одним лишь кодом качество архитектуры не измеряется.
Во-первых, чтобы ваш фронтенд работал как часы, следует руководствоваться несколькими простыми принципами его написания. Вот некоторые из них:
SOLID (Single-responsibility, Open-closed, Liskov substitution, Interface segregation, Dependency inversion) – обобщающая аббревиатура для нескольких ключевых принципов разработки;
KISS (Keep it simple, stupid) – делать как можно проще;
DRY (Don’t repeat yourself) – не повторять одно и то же;
YAGNI (You aren’t gonna need it) – писать и сохранять только то, что необходимо сейчас.
Будьте уверены, на собеседовании вас могут погонять по этим аббревиатурам. Сам я в первую очередь проверяю понимание принципа SOLID. Чтобы потренировать SOLID, предлагаю вам самостоятельно придумать по несколько примеров кода, который нарушает каждый из этих принципов.
Во-вторых, важно знать о существовании паттернов проектирования качественной архитектуры. На мой практике, чаще всего можно встретить эти:
Фабрика и фабричный метод;
Декоратор;
Фасад;
Observer & Pub Sub;
Singleton;
State Machine (довольно редкая и необязательная штука, но если вы работаете над компьютерной игрой, она становится незаменимой).
Подробнее читайте в книге «Приемы объектно-ориентированного проектирования. Паттерны проектирования» Банды Четырёх. Всего выделяют 23 классических паттернов проектирования.
В-третьих, совершенно не лишним будет знакомство с типовыми архитектурами. Здесь я бы выделил два актуальных подхода:
Clean Architecture;
FSD (Feature Sliced Design).
Оба подхода представляют собой наборы рекомендаций по организации кода, следование которым поможет не морочить голову себе и команде.
И, наконец, в работе фронтендера очень пригождаются принципы реализации стандартных фич. Вот некоторые из них:
Virtual list – не путать с виртуальным деревом;
Infinite scroll – его вас могут попросить запрограммировать;
Debounce, throttle, requestAnimationFrame – нужно понимать, для чего нужны эти утилиты и уметь пользоваться ими на практике.
Нередко работодатель может предложить реализовать или применить что-то из перечисленного выше в качестве практического задания, так что я настоятельно рекомендую изучить и поискать практические кейсы их использования.
Удобство для разработки и отладки
Очень важно помнить о том, что ваш проект не должен превращаться в темный лес из перепутавшихся версий и конфликтующих обновлений. Для этого разработчику нужно знать, как работают системы контроля версий, которые помогают организовать командную работу. Как наиболее универсальную и самую распространенную я бы выделил Git. С ней связаны несколько ключевых понятий:
Merge/Rebase;
Git flow;
Conflicts resolving.
Навыки работы с ними используются в работе каждый день, так что опытным девелоперам они однозначно знакомы. Если же вы только собираетесь пробиться на стажировку, и работать с Git вам еще не приходилось, то вам стоит незамедлительно освоить ее. Очень советую пощупать инструмент на практике, локально погенерировать конфликты и научиться их разруливать.
Еще одна тема, которой я хочу коснуться в рамках этого раздела – способы организации кода. Не факт, что она всплывет у вас на собеседовании, но если вы претендуете на позицию в компании, где люди работают над масштабными проектами, то обсудить ее, скорее всего, придется. Для этого я советую вам разобраться в том, что такое:
монорепозиторий и каким образом в нем организуется хранение кода разных проектов;
git-модули и как с ними работать;
типовые архитектуры микрофронтендов.
Также разработку и масштабирование проекта можно сделать удобнее с помощью создания UI-kit – набора компонентов, которые используются чаще всего. Наверное, самый распространенный инструмент для их организации – это Storybook. Если вам приходилось работать с готовыми наборами компонентов вроде Bootstrap или Material UI, скорее всего, именно с помощью Storybook были оформлены их витрины.
И, разумеется, отлаживать фронтенд вам рано или поздно придется с помощью DevTools внутри браузера, которые я уже упомянул выше. Поверьте, если вы разберетесь с назначением и функционалом каждой вкладки, вы начнете намного глубже понимать устройство фронтенда в целом и сможете работать намного эффективнее.
Качество для системы
Теперь, когда мы разобрались с тем, как повысить качество проекта для конечного пользователя и для вашей команды, следует поговорить о том, какой девелопер сможет без особых затруднений подружить фронтенд с остальной инфраструктурой. Конечно, рассуждать на эту тему можно бесконечно, поэтому в своей статье я отмечу лишь несколько наиболее актуальных для фронтенд-разработчиков пунктов.
В первую очередь вы должны быть продвинутым пользователем ПК и не падать в обморок, услышав слово Unix. Если вы пишете фронтенд только на винде, я бы рекомендовал попробовать Ubuntu; разобраться в том, что такое Bash и как в нем работать; познакомиться с системой пользователей и групп. Дело в том, что в индустрии очень распространена работа в Unix-системах, и многие инструменты можно без проблем накатить именно на них, в то время как Windows нередко вынуждает устраивать пляски с бубном.
Еще один лучший друг фронтендера – Docker. Волшебная коробка, в которую вы складываете проект по кускам и прикладываете инструкцию, как его собрать, после чего он будет стабильно и одинаково разворачиваться на любом сервере. Пользуются ей и бэкенд-разработчики. Они могут прислать вам свою аналогичную коробку, чтобы вы провели испытания, и на этот случай вы должны уметь самостоятельно запустить ее. Помимо основного принципа работы, про Docker стоит знать, как его оптимизировать. Вот основные ключевые слова:
Registry/Container/Image;
Compose;
Multistage-сборка;
кэширование слоев;
alpine-образы.
Идем дальше. Наверняка ваш сайт будет хоститься в интернете не с одной, а с нескольких машин, которые дублируют друг друга. Делается это для повышения скорости и надежности. Несмотря на то, что настройка таких систем обычно лежит в зоне ответственности девопсеров, на собеседовании у вас все же могут проверить знание основ систем оркестрации (в частности, Kubernetes), поскольку в перспективе понимание принципов их работы сильно упростит вам жизнь.
А вот про основы CI/CD вас спросят с заметно большей вероятностью. Если CI и сборку я уже упоминал выше, то в контексте разговора о качественной работе фронтенда внутри инфраструктуры я добавлю еще и CD к перечню необходимых компетенций. Здорово, когда разработчик понимает, как машина собирает части проекта воедино, и еще лучше – когда он знает, каким образом она доставляет готовый проект до целевых хостов.
Однако самым важным аспектом инфраструктуры я бы выделил веб-серверы. Вопрос о том, насколько фронтендеру важно в них ориентироваться, остается дискуссионным. На мой взгляд, без достаточного багажа знаний о веб-серверах работать над цифровым продуктом невозможно по определению.
Так, например, если вы научитесь настраивать Nginx, то сможете без сторонней помощи поднять свой первый простой сайт, который будет раздавать картинки и другой статический контент. На собеседовании же вас могут погонять по следующим составляющим Nginx:
проксирование;
раздача статики;
кэширование;
балансировка;
логи;
сжатие.
При этом важно понимать, что Nginx – это сервер, который отдает клиенту статику, а запросы за данными перенаправляются на сервер приложения (Application Server). Следовательно, для работы с динамическим контентом нужно будет настраивать сервер приложения, и в этом вам поможет платформа Node.js. Опыт показывает, что владение JavaScript не только на уровне браузера, но и на уровне сервера тоже приносит фронтендеру практическую пользу (особенно если в работе вы будете разрабатывать приложение с Server Side Rendering).
Если вы захотите углубиться в тему веб-серверов, предлагаю разобраться в их архитектуре. В частности, что такое Event Loop, на которой работает тот же Nginx, а также познакомиться с понятиями Thread pool и Workers pool.
Поверьте, все эти вопросы работодатель задает не от скуки. Владение стеком перечисленных технологий позволит вам разрабатывать фронтенд, который удобно интегрируется в инфраструктуру, рационально использует возможности системы и не шатается на сотне бессмысленных костылей. Соответственно, чем больше вы знаете об устройстве инфраструктуры, тем выше ваши шансы запрыгнуть на заветную вакансию.
Выводы
Как видите, фронтендеру мало знать один только JavaScript. Разработчик, который ориентируется в понятиях из этого чеклиста, намного ценнее для команды, чем «энтузиаст», прорешавший тысячу задач на leetcode, поскольку владение нужными навыками и хотя бы базовое знакомство со смежными технологиями позволяет видеть и понимать фронтенд намного глубже, чем просто в разрезе голого кода. Благодаря перечисленным компетенциям опытный девелопер способен учесть запросы пользователя, потребности команды и возможности системы, а значит – сделать качественный фронтенд.
Хорошая новость состоит в том, что при собеседовании на позицию стажера или джуна вам понадобятся не все пункты из этого списка. Плохая новость (на самом деле, тоже хорошая) – с каждым из них рано или поздно предстоит столкнуться в работе. Не откладывайте изучение вспомогательных инструментов и смежных сфер в долгий ящик, поскольку именно они определяют вас как специалиста и заставляют работодателя охотиться за вами, а не наоборот.
На Хабре уже есть наши публикации, в которых мы раскрываем нюансы работы с некоторыми из упомянутых технологий, и просто полезные статьи для фронтендеров про JS. Предлагаю вашему вниманию:
Если по прочтении этой статьи вы чувствуете, что владеете нужными для своего грейда навыками, я предлагаю вам попробовать свои силы на реальном собесе. Мы сами нанимаем фронтендеров, так что можете откликаться на открытые вакансии через форму. В комменте не забудьте указать, что пришли с Хабра.
В заключение скажу, что я постарался перечислить темы, которые проверяю сам, и дополнил список темами, знание которых проверяют мои коллеги. Не исключаю, что мог что-то упустить. Если вам есть, что добавить, welcome to the comment section.
К слову, об этом перечне хард скиллз я недавно рассказывал для сервиса развития карьеры Эйч. Если вам захочется освежить материал, можете не только перечитать статью, но и посмотреть запись эфира на ютубе или изучить майндмэп на фигме.
И главное – никогда не прекращайте учиться, и удачи вам на собеседованиях!
