— Апрувни мой PR, пожалуйста.
— Сейчас... оставляет 25 комментариев
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
😁55❤8👍6
channelName := "WBTECH"
channelName =
strings.ReplaceAll(channelName, "WBTECH", "WB Tech")
fmt.Printf("Канал %s готов к работе. Дальше — интереснее!\n", channelName)
🔥49😁21❤6👍1
Мини-интервью — ниже.
Какие самые большие мифы вокруг фронтенд-разработки тебе встречались?
Миф 1. Фронтенд обязательно должен быть «глупым». Получили данные — отрисовали, изменили — отправили обратно на сервер.
В масштабах маркетплейса Wildberries фронтенд, наоборот, должен быть «умным»: мы сознательно выносим часть бизнес-логики на устройства клиентов, чтобы снизить нагрузку на серверные мощности. При этом сами микросервисы стараемся упрощать.
На таких высоконагруженных проектах, как наш, фронтенд — это сложная инженерия: управление состоянием тысяч динамических элементов, оптимизация времени загрузки на медленных соединениях, построение архитектуры, которая масштабируется вместе с ростом бизнеса, а также прямое влияние на конверсию и Core Web Vitals.
Миф 2. Мобильная и десктопная версии могут сильно отличаться.
Для нас критически важна консистентность. Пользователь может начать покупку в приложении или мобильном браузере, а завершить её на десктопе. Поэтому единая логика, дизайн-система и API — это не nice to have, а обязательное требование.
Миф 3. Производительность фронтенда — это забота только фронтенд-разработчиков.
На практике — это командная работа. Бэкенд должен отдавать оптимальные данные, дизайнеры — учитывать производительность своих решений, менеджеры — закладывать время на оптимизацию.
Мы уделяем этому направлению много внимания, потому что наш фронтенд должен одинаково хорошо работать на самых разных устройствах и с самыми разными техническими характеристиками.
Какое самое необычное решение по оптимизации фронтенда тебе когда-либо приходилось применять?
Это была не моя идея, но эффект меня действительно удивил. В некоторых местах мы сознательно пошли против парадигмы SPA и стали заранее держать в DOM-дереве подготовленные в фоне части приложения. Смысл подхода в том, чтобы при переходе пользователя в раздел не начинать рендер с нуля, а как можно быстрее показать заготовленный контент.
Мы измерили метрики для обоих подходов — классического и «революционного» — и увидели, что пользователи значительно чаще совершают заказы, если могут максимально быстро увидеть страницу и начать с ней взаимодействовать.
Какие изменения произошли в экосистеме фронтенд-технологий за последнее десятилетие и как они повлияли на твою работу?
Десять лет для мира фронтенда — это целая вечность. Мы прошли путь от MVC-фреймворков к компонентному подходу, пережили расцвет TypeScript, серверного рендеринга и его эволюции к гибридным моделям. Вслед за бэкендом научились строить микросервисы на фронтенде — микрофронтенды, и это лишь часть изменений.
Существенно выросла кривая входа: сегодня уже нельзя сказать, что фронтенд — это просто вёрстка и кнопочки. При этом в самой работе радикальных изменений не произошло. Что-то стало удобнее и проще, где-то требуется больше знаний, чтобы понимать, как всё работает под капотом.
Я отношусь к новым технологиям как к инструментам. Здорово, когда у тебя есть удобный «мультитул» — молоток с фонариком и отвёрткой в одном устройстве. Но настоящий инженер должен уметь работать с любым инструментом и выбирать тот, который лучше всего подходит под конкретную задачу.
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥19❤10👍10
Какое главное качество отличает хорошего фронтенд-разработчика в крупной команде?
Системное мышление — умение видеть не только свою текущую задачу, но и то, как она соотносится с предыдущими решениями команды и как повлияет на реализацию следующих задач. Инженеры с таким мышлением способны строить гибкие системы, готовые к трансформации и масштабированию.
Как выбрать правильный стек технологий для нового большого проекта?
Всё начинается ещё до разработки. Необходимо понимать две базовые вещи: текущий технологический ландшафт и ситуацию на рынке.
Важно учитывать экосистему и долгосрочную жизнеспособность выбранных решений: есть ли активное сообщество, кто стоит за технологией, насколько легко найти разработчиков, какие отзывы о ней дают практикующие инженеры и техлиды.
Далее следует анализ бизнес-требований: нужен ли серверный рендеринг для SEO, какая требуется интерактивность, какие браузеры необходимо поддерживать. Если проект нужно запустить в сжатые сроки, критичным фактором становится совместимость с существующей инфраструктурой: будет ли выбранная технология работать с текущими CI/CD-процессами, мониторингом и бэкендом.
И, наконец, ключевой вопрос — экспертиза команды. Есть ли внутри необходимые компетенции? Если нет, готовы ли мы инвестировать в обучение и дополнительный найм?
В целом, для нашей компании важны стабильность, производительность и возможность найма предсказуемо сильных специалистов.
Какие методы применяют в твоей команде для поддержания высокопроизводительного фронтенда?
На этапе разработки мы активно используем профилирование, следим за количеством и скоростью запросов, временем выполнения кода и системно применяем кэширование.
В продакшене — постоянно мониторим Core Web Vitals (LCP, FCP, CLS и другие) в реальном времени и на всех типах устройств. Мы не ориентируемся исключительно на показатели Lighthouse, поэтому особое внимание уделяем телеметрии с реальных пользовательских устройств.
Как ты мотивируешь команду оставаться креативной и находить нестандартные решения?
В компании выстроена культура, в которой разумный эксперимент, даже если он не привёл к ожидаемому результату, воспринимается не как провал, а как ценный опыт. Ключевое — уметь быстро откатиться и сделать выводы.
Внутри команды создана среда, где каждый может предложить нестандартное решение или техническую инициативу — и быть услышанным. Мы регулярно проводим техновстречи: любой участник команды может выступить в роли спикера и поделиться своим опытом. При этом ключевые технические решения не принимаются в одиночку — их обсуждает коллегия наиболее опытных разработчиков, где идеи проходят совместное обсуждение и взвешенное принятие.
🔥 — если хотите больше такого формата
В комментариях пишите, кого из технической команды хотите поспрашивать и о чём!
Please open Telegram to view this post
VIEW IN TELEGRAM
3🔥38❤10🎉6👍1
middle/гибрид
Ищем специалиста с опытом работы с LLM, включая тонкую настройку GPT-подобных архитектур. Обязательное знание стека: PyTorch, NumPy, Scikit-learn, библиотека transformers, а также практические навыки в классических ML-задачах
senior/гибрид
Ищем специалиста, который владеет классическим стеком (Pandas, scikit-learn, NumPy, XGBoost/LightGBM/CatBoost, statsmodels). Обязательно глубокое понимание алгоритмов, структур данных и работы с большими данными на SQL и PySpark, включая оптимизацию. Мы ждём профессионала, который видит путь от исследовательской гипотезы до рабочего продукта, приносящего ценность.
senior/гибрид
Ищем специалиста с опытом на Python и Spark для работы с полным циклом данных: от построения, дообучения LLM (GPT-like, RAG, классический NLP) и классических ML-моделей до их промышленного внедрения. Важны системное мышление, опыт внедрения с измеримым бизнес-результатом и умение коммуницировать с бизнесом.
senior/удаленно
Ищем специалиста со знанием методологии управления проектами, навыками коммуникации и опытом работы с инструментами управления проектами (Jira, Trello, YouTrack).
middle/гибрид
Ищем специалиста с опытом разработки на Golang, опытом работы с реляционными базами данных (PostgreSQL) и с шинами данных (Kafka) для построения отказоустойчивых и масштабируемых систем.
middle/гибрид
Ищем специалиста с умением определять ключевые метрики продукта и выстраивать связи между ними, пониманием принципов A/B-тестирования и статистической значимости.
middle/гибрид
Ищем специалиста с глубоким понимание SRE-принципов, навыки работы с Kubernetes и распределенными системами, а также опыт настройки и анализа метрик/логов (PromQL, Loki, Elasticsearch).
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🔥5🤩3