Всем привет. Я фронтенд. JS, TS, React, Next.js — стандартный джентльменский набор. Но всегда хотел попробовать геймдев. Руки не доходили. И вот — дошли.
Встал вопрос: какой движок брать?
Unity — мощно, но тяжело и с лицензией пляски. Unreal — это ракетостроение. А Godot я скачал на пробу — и меня затянуло.
Почему Godot для бывшего фронта — зашло:
1. GDScript — как Python, только проще. Забудь про this, bind, бесконечные useCallback. Просто пишешь speed += 5 — и работает.
2. Сцены = компоненты. Делаешь машину → сохраняешь как сцену → кидаешь на карту. Знакомо по React, только визуально и без лишнего бойлерплейта.
3. Сигналы вместо EventEmitter. Всё то же самое, но встроено и не течёт.
4. Бесплатно и открыто. Не надо думать о лицензиях и «когда потребуют деньги». Качай и делай.
5. Физика из коробки. В вебе ты подключаешь библиотеку и молишься. Тут добавил CharacterBody3D — ходит. VehicleBody — машина с подвеской и колёсами. Без танцев с бубном.
Что ломало мозг:
· Нет npm install. Первое время рука тянулась к терминалу.
· Визуальный редактор вместо vim. Но привыкаешь за пару дней.
· Ось Y — высота. Первые объекты улетали в небо, потому что я тыкал y как в вебе.
Что в итоге:
За пару вечеров — работающий персонаж, машина с физикой, посадка/высадка, запуск двигателя. И кайф. Такого кайфа от кодинга у меня давно не было.
Godot — лучший вход в геймдев для веб-разработчика. Просто бери и делай. Никакой магии.
Всю жизнь пилю сайты на React. Лендинги, админки, фриланс. Но с детства была одна мечта — сделать свою игру.
Не ради денег. Ради того самого чувства, когда кто-то запускает твой мир и говорит: «Ого, круто же».
Год думал. Месяц назад начал.
Делаю симулятор российской глубинки. Деревня, старая копейка в гараже, дедова тайна. Без донатных помоек, без «заплати чтобы ускорить». Просто игра, в которую сам бы играл ночами.
Пока есть только прототип: персонаж ходит, машина заводится, можно ездить. Впереди — разборка двигателя по болтам, деревня с живыми соседями и много русского колорита.
Не знаю, взлетит или нет. Но кайфую от процесса как никогда.
Если вам тоже нравится идея — подписывайтесь, буду делиться прогрессом. И критика очень нужна.
Привет! Меня зовут Антон Назаров, я создатель сообщества «Осознанная Меркантильность», кратко — ОМ. В нем мы даем максимум пользы для IT-специалистов на любом этапе карьеры: от тех, кто только вкатывается в сферу, до айтишников, которые хотят пробить зарплатный потолок.
Сегодня разберемся с темой перехода в другое направление IT. Смена направления — стандартная практика для айтишников. Кто-то выгорел на текущей работе, другие хотят больше возможностей, третьи скучают в текущем профиле.
Мы провели масштабный опрос среди подписчиков сообщества. В статье внимательно рассмотрим статистику, узнаем, почему специалисты меняли направления, какие возникали сложности и оправдались ли ожидания.
В исследовании участвовало 1570 человек, из них главные текущие направления среди респондентов: backend, frontend и QA.
Откуда → куда айтишники хотят переходить и почему
Большинство опрошенных думают сменить направление, но не решаются — таких 43%. Еще 34% планируют поменять профиль, а тех, кто уже успешно это сделал, довольно мало — только 3%.
Главные причины решения:
перспективы нового направления — 33%;
размер зарплаты — 25%;
отсутствие роста в текущей специализации — 20%.
Респонденты планируют уходить в backend, ML / DS / NLP, DevOps и продуктовый менеджмент. При этом любопытно, что backend также оказался и среди топ-3 направлений, из которых опрошенные хотят перейти куда-то еще.
Вот какие специализации сегодня кажутся респондентам наиболее перспективным:
ML / DS / NLP — 51%;
backend — 41,5%;
информационная безопасность — 30%;
DevOps — 26%.
Многие айтишники хотят сначала досконально изучить все возможные направления, а потом решить, куда переходить. Такой ресерч может занять так много времени, что исчезает само желание менять профиль.
Мы подготовили лаконичную профориентацию по всем направлениям. Простыми словами объяснили, что предстоит делать на каждой должности и какие навыки понадобятся. Например, нужно ли писать код, придется ли общаться с людьми, какое направление легче / сложнее, и что там по деньгам и количеству вакансий.
Опыт тех, кто сменил направление: какие профили выбирали и чем руководствовались
Чаще всего респонденты уходили из frontend, backend и тестирования. А перекатывались — в backend, аналитику (System, Fullstack, BI) и ML.
Ниже полный список, откуда и куда переходили респонденты, изменившие направление 👇
Backend → DevOps
Swift developer → Sales manager
Frontend → System Analyst
Gamedev → FinTech
Техническая поддержка и ручное тестирование → Нагрузочное тестирование
Frontend → Backend
Android Dev → Fullstack Analytics
Backend → ML-Engineer
Backend → QA
Game Designer → Operations Manager
Backend → QA (в результате человек вернулся обратно в Backend)
Frontend → GO
QA → System Analyst
QA → Backend
Frontend → ML
ML → Backend
iOS → ML/NLP
Frontend → Backend
Frontend → Backend Go
Frontend → AQA
Верстальщик → Frontend
Backend → Gamedev
QA → Backend engineer
System Analyst → Data engineering
Android → Backend
Backend → DevOps
Системное администрирование и архитектура → Информационная безопасность
Аналитик внедрения → BI аналитик
Frontend → Backend → в итоге ML/DS
Backend → Frontend
Desktop → Backend
Маркетинг → Backend
Systems Analyst → Backend
QA Auto → Java developer → в итоге Golang developer
iOS → Backend Go
QA Automation → Project Manager (в результате человек вернулся обратно в QA Automation)
Frontend Developer → Project Manager
Руководитель проектов по внедрению СЭД → QA → в итоге AQA
Analyst → System Analyst
Среди основных причин выделяли:
перспективы нового направления — 22,5%
размер зарплаты — 21%
отсутствие роста — 15%
выгорание — 13%
С выгоранием сталкивается львиная доля айтишников.
Убитый режим, желание просто отдохнуть и ничего не делать хотя бы денек и постоянные мысли об увольнении — всё это спутники эмоционального истощения.
У большинства респондентов переход занял не так уж много времени: 41,5% справились с ним за 3 месяца и меньше. Еще у 32% ушло до полугода на смену направления. 19% пришлось потратить от 6-ти до 12-ти месяцев.
В числе главных сложностей оказались:
Страх и неуверенность — 32%
Необходимость учить новую область с нуля — 21%
Возможность попасть на собеседование и пройти его — 15%
Неожиданные подводные камни, с которыми столкнулись участники опроса:
«Больше ответственности и больше проектируешь фичи».
«Завышенные ожидания от перехода: по факту руководство командой и ответственность не означают высокий доход. Очень много политики и подлизывания, о которых даже не задумываешься при переходе».
«Руководитель выбирает тебя под себя. Если он сменяется — высок риск не ужиться с новым».
Результаты специалистов, которые сменили направления
У большинства респондентов зарплата выросла в половину и больше: об этом рассказали 47% опрошенных. У 21% доход вырос немного, а у 19% он не изменился. Были и те, кто просел по заработку при переходе на новое место — таких 13%.
Соотношение ожидания и реальности после смены направления показывают реалистичные результаты. У 43% опрошенных надежды оправдались на 4 балла из 5, еще у 38% на 5.
Часть респондентов говорит, что ничего бы не стали менять при переходе заново, другие подчеркивают, что стоило бы начать раньше и делать больший упор именно на прохождение собеседований.
Что еще респонденты сделали бы иначе при переходе:
«Анализировал бы рынок заранее, работал 4 года в компании и не наблюдал за рынком, что frontend так переполнен, даже с хорошим резюме, опытом хорошим и подтвержденным через госуслуги откликов не получаешь вообще, нужно было смотреть динамику откликов на вакансию и их количество, вовремя уйти с frontend разработки».
«Больше погружался бы в свой стек, так как тут меньшие усилий по учёбе дают кратно больший результат, нежели начинать с нуля. Сразу бы начал "Волчарить", а не стесняться».
«Больше бы прокачивал скиллы общения с топами, и учился математически считать риски, ибо внезапно, в ИБ это важнее самого ИБ — цифры показать, а не про технологии рассказывать».
Если от смены направления останавливает отсутствие опыта — смотрите большой гайд по накрутке опыта в резюме. Даем пошаговый план действий и ответы на все вопросы на основе тысяч удачных кейсов.
Выводы
Опрос показал: смена направления скоро станет новой нормой рынка. Большинство специалистов либо уже задумываются о переходе, либо активно планируют его. Главным образом из-за желания расти в доходе, получить больше перспектив и выйти из профессионального тупика.
Самыми привлекательными направлениями сегодня выглядят ML / DS / NLP, backend, DevOps и информационная безопасность. Интересно, что backend одновременно остается и одним из самых популярных направлений для входа, и одним из профилей, из которых специалисты хотят уйти. Это говорит о высокой конкуренции, нагрузке и неоднозначности ожиданий от роли backend-разработчика.
Опыт тех, кто уже сменил специализацию, показывает: переход чаще всего реален даже за несколько месяцев. Многие респонденты отмечают, что ожидания от новой роли в большинстве случаев оправдываются, а у значительной части специалистов переход приводит к заметному росту дохода.
Смену направления вполне можно считать эффективным инструментом карьерного роста в IT. Рассказывайте, думали ли вы о переходе в другую специализацию и почему?
Реклама. ИП Назаров Антон Владиславович, ИНН 780542845801
Телеграм, ВКонтакте, Дзен, Макс — площадок становится все больше, а вот внимание аудитории по-прежнему ограничено. Что делать? Продвигать!
На Пикабу можно рекламировать свои каналы прямо в лентах сайта. Находите новую аудиторию и получайте живые переходы без сложных рекламных кабинетов.
Подойдет для:
авторских и экспертных блогов
бизнеса
медиа и новостных каналов
мемных и развлекательных сообществ
Запускается просто: добавляете ссылку, пишете заголовок и краткое описание и выбираете географию для показов. А дальше о вашем канале узнают тысячи пользователей Пикабу!
Каждый раз, когда начинаешь новый веб-проект, встаёт один и тот же вопрос: как рендерить страницы? CSR, SSR, SSG — звучит как аббревиатуры из учебника, но на практике именно этот выбор определяет скорость сайта, позиции в поиске и удобство разработки.
CSR — Client-Side Rendering
Сервер отдаёт почти пустой HTML с одним тегом div и большим JS-бандлом. Браузер скачивает JavaScript, выполняет его, делает запросы к API — и только после этого пользователь видит контент.
Плюсы:
Быстрая навигация после загрузки
Богатые интерактивные интерфейсы
Минусы:
Долгая первая загрузка (Time to Interactive)Долгая первая загрузка (Time to Interactive)
Плохо для SEO — боты видят пустой HTML
Требует хорошего интернета у пользователя
Главная проблема CSR — поисковые боты. Googlebot умеет выполнять JavaScript, но делает это с задержкой и не всегда корректно. Яндекс справляется хуже. В итоге страницы индексируются медленнее и хуже.
Когда CSR — правильный выбор:
• Дашборды и админки за авторизацией — SEO не нужен
• SPA с богатой интерактивностью: редакторы, конструкторы, таблицы
• Внутренние инструменты компании
• Приложения, где пользователь авторизован и контент персональный
SSR — Server-Side Rendering
При каждом запросе сервер генерирует готовый HTML с данными и отдаёт его браузеру. Пользователь сразу видит контент — не надо ждать, пока выполнится JavaScript.
Плюсы:
Отличный SEO — боты видят готовый HTML
Актуальные данные на каждый запрос
Минусы:
Нагрузка на сервер при каждом запросе
Медленнее навигация, чем CSR
Нужен сервер — хостинг дороже
SSR — лучший выбор для SEO-важных страниц. Поисковик получает готовый HTML с контентом, мета-тегами и структурированными данными. Индексация быстрее и надёжнее, чем при CSR.
Когда SSR — правильный выбор:
• Интернет-магазины — карточки товаров должны индексироваться
• Новостные сайты и блоги с часто меняющимся контентом
• Страницы с персонализированным контентом (лента, рекомендации)
• Любые публичные страницы, где важен SEO и актуальность данных
SSG — Static Site Generation
HTML генерируется один раз — во время сборки проекта. Готовые файлы раздаются с CDN без участия сервера. Это самый быстрый способ доставить контент пользователю.
Плюсы:
Максимальная скорость
Отличный SEO
Дешёвый хостинг — просто файлы
Высокая надёжность — нет сервера
Минусы:
Данные могут быть устаревшими
Долгая сборка при большом числе страниц
Не подходит для часто меняющихся данных
Когда SSG — правильный выбор:
• Лендинги и маркетинговые сайты
• Документация и справочники
• Блоги и портфолио
• Сайты, где контент меняется редко или по расписанию
Главное про SEO
SEO — это часто решающий фактор при выборе рендеринга. Вот простое правило:
• Страница публичная и должна находиться в поиске → SSR или SSG
• Страница за авторизацией или контент персональный → CSR
• Контент меняется часто → SSR
• Контент меняется редко → SSG
Отдельно про Core Web Vitals — Google учитывает LCP, FID и CLS в ранжировании. SSG и SSR дают лучшие показатели, чем CSR по умолчанию, но и CSR можно оптимизировать через lazy loading, code splitting и prefetching.
Хорошая новость: Next.js позволяет миксовать все подходы в одном проекте. Лендинг — SSG, карточка товара — SSR, личный кабинет — CSR. Именно поэтому он стал стандартом индустрии.
Больше материалов про разработку и запуск своих продуктов — в Telegram-канале @deep_in_prod
Современный Frontend давно перестал быть слоем поверх API. В реальном продукте он решает те же вопросы, что и любая распределённая система: где живут данные, когда они считаются свежими, как пережить задержку сети, что показать при частичном отказе, где провести границу между сервером и клиентом, как не превратить локальное состояние в теневую базу данных.
Проблема в том, что мы всё ещё говорим о Frontend языком интерфейса, хотя строим уже не интерфейс. Мы строим систему доставки смысла пользователю.
Классическая схема была понятной. Сервер собирает страницу, браузер показывает HTML, пользователь кликает ссылку, сервер отдаёт новую страницу. Почти вся сложность жила на сервере: маршруты, права, данные, шаблоны, ошибки.
Потом интерфейсы стали богаче, и мы перенесли часть логики в браузер. Страница перестала быть документом и стала приложением. Браузер начал хранить состояние, валидировать формы, строить маршруты, кэшировать данные, оптимистично обновлять UI. Это дало скорость и интерактивность - и заодно растащило Frontend по нескольким слоям.
Часть живёт на сервере: рендеринг, подготовка данных, проверка прав. Часть - в браузере: интерактивность, ввод, мгновенная обратная связь. Часть - в кэше: CDN, query cache, prefetch, service worker. А часть вообще не выглядит как Frontend: она в контракте API, в схеме данных, в дизайн-системе, в правилах релиза.
Когда всё работает, пользователь видит простую вещь: страница открылась, кнопка нажалась, действие сохранилось. Когда ломается, выясняется, что «кнопка» была последним звеном в длинной цепочке решений.
Кнопка не просто вызывает onClick. Она может запускать optimistic update, инвалидировать кэш, отправлять событие аналитики, менять URL, зависеть от прав пользователя, показывать pending-состояние, откатывать UI после ошибки или повторять запрос.
Это уже не «покрасить кнопку». Это проектирование поведения системы в условиях неопределённости.
Ernest Peixotto (American, 1869–1940)
Компоненты не спасают архитектуру
Когда Frontend стал сложнее, мы нашли удобный ответ - компонентную модель. Разбей интерфейс на части, переиспользуй их, собери экран из маленьких элементов. Сильная идея, но без неё современные интерфейсы было бы трудно поддерживать.
Но компонентная модель хорошо описывает форму интерфейса и плохо описывает поведение продукта. Компонент может быть маленьким, типизированным и красивым, а архитектура всё равно слабой, потому что настоящая сложность живёт между компонентами.
Самая частая ошибка - смешать UI-состояние, серверные данные, процесс сохранения, ошибки и производные значения в одном месте. Тогда форма знает про API, кнопка - про бизнес-правила, таблица - про инвалидирование кэша, а страница хранит копию данных из query cache «на всякий случай». Дальше начинаются исключения, быстрые фиксы, дублирование, страх менять экран и фраза «проще переписать».
Redux, Zustand, React Query, SWR, Signals, Context - ни один инструмент не решит за команду главный вопрос: где источник правды.
Если правда на сервере, Frontend должен уважать сервер и не показывать пользователю фантомное состояние. Если правда в пользовательском вводе, нельзя терять его после refetch. Если правда в URL, состояние должно переживать перезагрузку и передаваться ссылкой. Плохая архитектура начинается там, где источник не выбран: сервер говорит одно, кэш помнит другое, форма хранит третье, URL показывает четвёртое, а компонент делает пятое, потому что «так быстрее».
Near Richmond, Yorkshire (1877)
Где должна жить логика
Главный вопрос: кто за что отвечает, и что произойдёт, когда что-то пойдёт не так.
Возьмём простой сценарий - пользователь переименовывает проект.
Слабая версия: Пользователь жмёт «Сохранить». Форма отправляет PATCH, показывает спиннер. Через 800 мс ответ приходит, спиннер исчезает, имя в форме обновляется. Хорошо. Но в сайдбаре имя меняется ещё через секунду, потому что список проектов перезапрашивается отдельно. А в соседней вкладке, открытой час назад, имя вообще старое. Пользователь видит три разных состояния одной сущности и не понимает, какому верить.
Сильная версия: То же действие. Имя в инпуте меняется мгновенно - здесь источник правды сам пользователь. После сабмита UI сразу показывает новое имя во всех местах: в сайдбаре, в заголовке, в хлебных крошках, но визуально помечает его как ещё не сохранённое (например, приглушённым цветом). Если сервер подтвердил, тогда пометка исчезает. Если вернул ошибку - UI откатывается к старому имени и показывает причину человеческим языком: «нет прав» или «имя уже занято». Список проектов в кэше обновляется по одному правилу, а не по совпадению.
Из этого вытекает несколько практических правил.
Источник правды - один на каждое значение. Если правда на сервере, Frontend читает её оттуда и не хранит копий «на всякий случай». Если правда в URL - фильтры, поиск, выбранная вкладка, она переживает перезагрузку и передаётся ссылкой. Если правда во вводе пользователя, её нельзя потерять при refetch. Дублирование источников - это не ускорение, это будущий баг.
Frontend не решает то, за что не отвечает. Он может скрыть кнопку под роль пользователя, но не должен сам определять, разрешено ли действие. Это решает сервер. Frontend может показать бизнес-правило и объяснить его, но само правило живёт в домене, а не в компоненте. Если правило про деньги, права или статусы случайно осело в JSX, его рано или поздно нарушат.
Кэш это договор, а не оптимизация. Когда мы держим данные в query cache, мы говорим пользователю: «верь этому, пока я не скажу обратное». У договора должны быть условия: сколько данным можно верить, кто их обновляет, когда инвалидировать, что показывать, если они устарели. Быстрый интерфейс не должен быстро врать.
Производительность и ошибки
Производительность часто сводят к Lighthouse, Core Web Vitals и размеру бандла. Метрики полезны, но не объясняют главного.
Пользователь не обязан ждать. Медленный Frontend почти всегда - сумма решений: слишком много клиентского кода, тяжёлая дизайн-система, водопад запросов, дорогой рендер, небрежная гидратация. Это нельзя починить в конце. Это проектируется в начале: что отдать с сервера, что загрузить заранее, что отложить, какой экран остаётся полезным при частичном отказе.
С ошибками то же самое. В продакшене сеть медленная, API отвечает не сразу, сессия истекает, пользователь кликает быстро, данные меняются в другой вкладке. Ошибка валидации должна жить рядом с формой. Ошибка прав - приходить от сервера. Ошибка сети - объяснять, можно ли повторить действие. Ошибка бизнес-правила должно быть написана по-человечески: не «400 Bad Request», а «Нельзя удалить проект, пока в нём есть активные задачи».
Надёжность Frontend - это не отсутствие ошибок в консоли. Это способность интерфейса вести себя предсказуемо, когда мир вокруг неидеален.
A Winter Scene (mid 1640s)
Что отличает сильного Frontend-инженера
Не количество выученных хуков и не скорость написания компонентов. Он понимает границы: где заканчивается серверное состояние и начинается клиентское, где данные можно кэшировать, где нужна мгновенная реакция, а где честный loading, где типы помогают, а где нужна runtime-проверка, где абстракция снижает стоимость изменений, а где делает код мутным.
Он проектирует не только компоненты, но и договоры: между клиентом и сервером, между страницей и компонентом, между системой и пользователем.
Плохая архитектура почти всегда выглядит нормально в первый месяц. Потом она начинает требовать всё больше энергии за всё меньший результат. Переписывать приходится не потому, что React плохой или Vue плохой. Чаще всего в начале никто не ответил на скучные вопросы: что является источником правды, какие данные могут устареть, что пользователь увидит при медленной сети, что произойдёт, если запрос выполнится дважды, какая логика принадлежит домену, а какая - интерфейсу.
Заключение
Frontend больше не тонкая оболочка вокруг API. Он стал местом, где техническая архитектура встречается с человеческим ожиданием. Пользователь не видит server components, query cache, hydration и source of truth. Он видит другое: страница открылась или нет, действие сохранилось или потерялось, ошибка объяснена или спрятана, интерфейс помогает или заставляет сомневаться.
Frontend - это слой доверия. Он отвечает за договор между человеком и системой: нажал - увидел реакцию, сохранил - понял результат, ошибся - понял, как исправить, вернулся - попал туда, где ожидал быть. Хорошая архитектура не убирает сложность. Она кладёт её туда, где её можно понять.
Этой вводной статьёй я хотел поделиться мыслями и начать этот блог. Всем спокойных релизов и поменьше багов в продакшене ❤
Вы же вроде зарплаты хорошие платите? Почему не смогли схантить с рынка JS-кнопкодавов, которые понимают как делать поля ввода так, чтобы при вводе символов оно не тормозило? Или вы нанимаете норм, а потом манагеры им не дают работать и гоняют по созвонам? Или ускорение софта - не целевая работа, а целевая - плодить новые фичи, приносящие деньги? Так ведь эта хрень тормозит так, до новых фич дело даже не доходит. Мы буквально не успеваем зайти в ваше заведение, получаем сразу по морде. Еще немного и знакомые разрабы пойдут создавать свой сайтик для торговли БУ-хламом подобный CraigsList, а про Авито забудут навсегда.
Попробуйте ввести сюда какой-то текст. Одно нажатие клавиши запускает лютейший рассчёт напряжений чугунного моста через Енисей. Количество вычислений, происходящих от одного нажатия клавиши сравнимо со всеми вычислениями, произошедшими при высадке проклятых пендосов на Луну. Вы чо, на каждое нажатие в том же потоке, блокируя его, запросы в сеть в свои тормозные базы отправляете и пузырьковой сортировкой на клиенте процессите 50К строк? Всю эту вашу петушню, пребывающей в интеллектуальной дремоте, напилившую это тормозное поделие, пора уже нешуточно репрессировать.
Почему гугл-то не тормозит при вводе в поиск буковок? У вас поиск серьёзнее гугла? Уметь посылать запросы в сеть в другом потоке/воркере, никогда не блокируя пользовательские потоки - это ваши патлатые сеньёры-архитекты-техлиды так не не научились? А чем они заняты? На работе по созвонам весь день уши дрочат, а дома в сраные компутерные игры наяривают, работать некогда? Может им перестать платить 550 тыр в месяц, ведь на эти деньги они игровые видяхи домой покупают и потом деградируют в танчиках до 5 утра и приходят на работку не выспавшись и отупев. Тут же поделка уровня джуна за 60 тыр в месяц.
В общем, вам надо как-то серьёзно взяться за своих пузатых жирных престарелых техлидов, у которых в голове неиллюзорно насрано толпой бомжей, или возможно их в детстве за гаражами чечены палками шевелили, к коням привязывали за ногу? Прыгыли с гаражей в сугроб, который успел обледенеть? Жгли костры с гептилом? Тяжело понять как можно было так изговнять один сраный элемент ввода.
Я уже молчу про ту шайку гомодрилов, которые умудрились сделать неработоспособным выбор типа сортировки объявлений до тех пор, пока не подгрузится 100500 каких-то JS-оперденей. И даже кеширование не помогает, то есть как будто ты каждый раз жмёшь CTRL + F5, хотя это был просто F5. Мне кажется, на собесе в гугл ваших инженеров, задействованных в проектировании и реализайии фронтенда бы просто из двустволки застрелили и даже хоронить бы не стали, в реку выкинули тела. Ваши JS-кнопкодавы - яркий пример мальчика, совравшего маме в ответе на вопрос "а тебе точно для учёбы" при покупке компутера. Явно без уважения ваши ребята относятся к достижениям в микроэлектронике.
Решил поделиться опытом поиска работы за последние полгода. Уточню: я не ставлю цель этого поста кого-то винить. Тут будет только мой опыт поиска работы на должность фронтенд разработчика с опытом 3+ года. И ещё, я не накручиваю опыт, в резюме указал только реальные задачи, и не кидал отклики на всё подряд. В целом стараюсь быть честным на рынке труда, да и статистику это делает только интереснее. Конечно же все совпадения случайны, и сами истории выдуманные, но верить мне или нет - решать вам.
Если честно, я никогда не думал, что решу написать пост на тему нынешнего найма. Сейчас в целом и так достаточно статей на эту тему, но интересных ситуаций у меня становится всё больше и больше. Так что почему бы не скинуться на общак своими историями.
Первая попытка устроиться была ещё в октябре. Тогда уже были заметны проблемы с наймом, поэтому я решил начать с поиска знакомых. Пообщавшись, смог найти человека, который работает в компании "со свободными кассами". Мне тогда сказали, что откликаться через кого-то у них нет смысла, и можно просто закинуть резюме через их сайт, и мне обязательно ответят. Судя по всему, это не так, но и человека докучать я не стал, всё-таки откликов сейчас много, подумал тогда я. Дублирование отклика на почту не помогло. Правда и сама вакансия висела несколько месяцев, может она была чисто для галочки.
Затем я так же через знакомого решил откликнуться на вакансию в один популярный финансовый сервис. И тут уже появилась капля надежды, так как мне напрямую написала HR, и сразу же предложила созвониться. На тот момент я находился в соседнем городе, так как не ожидал, что мне вообще хоть кто-то напишет. Мне предложили созвон на следующий день, и я согласился, чтобы точно не упустить этот шанс. К счастью я успел приехать домой за час до созвона, быстренько подготовиться, и вот наступил долгожданный момент. Первый же вопрос: "будет ли вам удобно ездить до станции метро ...". Я ничего не понимаю, так как живу в городе без метро, и тут же сообщаю об этом. После пары секунд неловкой тишины добавляю, что мой нынешний город проживания указан в резюме. В ответ HR извинилась, и сказала, что изначально город не увидела. По итогу разговор завершился за 3 минуты. Если офис обязателен, почему бы сразу не проверить указанный в резюме город... "Все ж мы люди", так что ладно, человеческий фактор никто не отменял, но осадок остался.
После этого я увидел вакансию в компанию, у которой офис на Пхукете. Тут я вспомнил, что и там был один дружочек-пирожочек. Пишу ему, он говорит, что рефералки у них нет, и "просто упомяни меня при отклике". Я благодарю за помощь, и отправляю отклик. Через пару дней на почту прилетает отказ. Если честно, то тогда я расстроился, так как подходил как минимум на 80%, и в целом хотел туда попасть. После этого я решил на всякий продублировать отклик им на почту, но ответа не последовало. Конкуренция сейчас высокая, так что причину тишины понять можно, но и эта вакансия потом была открыта почти месяц. Зато эта ситуация научила меня проще относиться к откликам, и не надеяться заранее. С одной стороны это прописная истина, но в то же время в моменте иметь мечту тоже приятно.
И последняя попытка на данный момент попасть куда-то через кого-то была в убыточную компанию любителей синего цвета. У них я замечал достаточно часто вакансии на фронта, поэтому подумал, что вероятно хотя бы на 1 из 10 можно будет попасть. Попыток было две с промежутком в 4 месяца, и результат один и тот же. По вакансиям, где я точно не подходил отказ приходил почти сразу, но на них я и не надеялся. А вот с другими ситуация была интереснее, спустя неделю-две на почту прилетало письмо о том, что мы уже нашли другого кандидата. Недавно пришло такое письмо спустя две недели после отклика. Такая картина может показаться удручающей, но в то же время если откликаться просто через их сайт - в ответ тишина. Так что так хоть приходит отказ, а не бесконечная тишина. Кстати недавно смог найти прямой контакт HR, и решил ей написать напрямую. Это тоже не особо рабочий способ, моё сообщение просто не прочитали.
Кстати об одном красно-белом сайте. Его я тоже использовал. Из ±50 откликов 3 были в статусе "собеседование", что наверное может показаться хорошим результатом на данный момент, но реальность чуть иначе, чем хотелось бы.
В первом таком "собесе" в компанию по подготовке к экзаменам меня попросили заполнить гугл форму. Я наивно успел обрадоваться, так как это было первое приглашение за всё время. Мне обещали ответить в течение 3 рабочих дней, но ответа не последовало даже спустя неделю. Сама вакансия висела до конца февраля, потом ушла в архив. Два других были в одну и ту же компанию по продаже электроники. Сначала они создали одну вакансию, затем через неделю точно такую же. По первой и второй меня тоже поставили в статус "собеседование", и обещали ответить в течение 10 дней. Результат тот же - тишина.
Подвести итог всем этим ситуациям можно по разному, но я подводить не буду, так как работу я ещё не нашёл. В любом случае рыночек порешает, как говорится, и когда-то проблема с наймом станет частью истории. А так, от себя хочу лишь пожелать удачи всем, кто в данный момент ищет работу. Как мне кажется, остаётся только верить в лучшее и дальше откликаться. Остаётся только один вопрос, как постоянно помнить всю теорию для собесов без постоянных повторений на протяжении нескольких месяцев...
