#вопросы_с_собеседований

Компания: Лантан. React. Грейд middle/middle+. ЗП - 250к.

Продолжаем делиться полным списком вопросов и задач на разные позиции в разных компаниях. На сколько вопросов легко бы ответили?)

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

1️⃣ Что такое специфичность в CSS?

2️⃣ Расскажи про SCSS-миксины для медиа-запросов

3️⃣ Использовал сложные функции в SCSS и полифилы?

4️⃣ Как обеспечивается кросс-браузерная поддержка CSS?

5️⃣ Какие архитектуры CSS знаешь и какая нравится больше?

6️⃣ Чем отличаются способы объявления переменных в JS?

7️⃣ Какие способы копирования объекта в JS?

8️⃣ Как организована работа с асинхронным кодом в JS?

9️⃣ Какие браузерные хранилища существуют?

1️⃣0️⃣ Какие уязвимости знаешь и как с ними борешься?

1️⃣1️⃣ Как защититься от XSS?

1️⃣2️⃣ Какими React-хуками пользуешься чаще всего?

1️⃣3️⃣ Чем отличаются useMemo и useCallback?

1️⃣4️⃣ Что такое дженерики в TypeScript?

1️⃣5️⃣ Чем отличаются interface и type в TypeScript?

1️⃣6️⃣ Найди ошибки и реализуй компонент для отображения древовидной структуры:

import React from "react";

const exampleFiles = [
  {
    id: 1,
    name: 'src',
    children: {        
      {
        id: 2, name: 'components', children: [
          { id: 3, name: 'Button.tsx', children: [] }
        ],
      },
      { id: 4, name: 'index.ts', children: [] }
    }
  },
  {
    id: 5,
    name: 'README.md',
    children: []
  }
];

const FileStructure = () => {
  return (
    <div>
      {/* Отобразить дерево */}
    </div>
  )
}

export default FileStructure;

*********** Решение: ***********

const exampleFiles = [
  {
    id: 1,
    name: "src",
    children: [ 
      {
        id: 2,
        name: "components",
        children: [{ id: 3, name: "Button.tsx", children: [] }],
      },
      { id: 4, name: "index.ts", children: [] },
    ],
  },
  { id: 5, name: "README.md", children: [] },
];

const TreeNode = ({ node }) => (
  <li>
    {node.name}
    {node.children.length > 0 && (
      <ul>
        {node.children.map((child) => (
          <TreeNode key={child.id} node={child} />
        ))}
      </ul>
    )}
  </li>
);

const FileStructure = () => (
  <ul>
    {exampleFiles.map((node) => (
      <TreeNode key={node.id} node={node} />
    ))}
  </ul>
);

export default FileStructure;
******************** Разбор ********************
1. TreeNode — рекурсивный компонент: вызывает сам себя для каждого дочернего узла
​2. Базовый случай рекурсии (условие остановки) — children.length > 0
​3. Не забываем про key

1️⃣7️⃣ Виртуализация списков — зачем нужна и как реализуется?

Если нужно разобрать ответы на вопросы с этого собеседования — ставь 🔥, а также пиши в комментарии какой вопрос или задача были интереснее всего.

Уже 66 разработчиков в группе устроились на классные позиции, а в день мы проходим до 10! собеседований, если хочешь подготовиться с нами к интервью в крупную компанию — велком @codepunks_bro)

Компания: МТС Веб-сервисы
Позиция: Middle+ Frontend (Vue), 200–280K 💚

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

Вопрос №1

Какой подход ты выбирал при миграции с Vue 2 на Vue 3?

Слабый ответ:

«Постепенно переписать всё на Vue 3 + TypeScript через Vue 2.7».

Ответ технически корректный, но слишком общий. В нём нет главного: как именно шла миграция, почему был выбран такой путь и как контролировались риски.

Сильный ответ:

Я выбирал поэтапную миграцию. Обычно сначала выделяли участки с понятными границами: отдельные страницы, фичи или модули с минимальной связанностью с legacy-частью. Это позволяло мигрировать систему постепенно и не останавливать продуктовую разработку.

На первом этапе выравнивали базу под миграцию: убирали самые проблемные места, снижали зависимость от mixins, выносили бизнес-логику из компонентов, наводили порядок в слоях данных и состояниях. После этого уже переводили части приложения на Composition API и TypeScript.

Такой подход давал несколько преимуществ:
— меньше риск сломать всё сразу
— проще локализовать ошибки
— можно катить изменения частями
— команда продолжает поставлять фичи параллельно с миграцией

В общем, “мигрировали итеративно, с контролем технического риска”.

Что здесь реально проверяют:
умеешь ли ты планировать сложные изменения, а не просто знаешь, что Vue 3 новее Vue 2.

Вопрос №2

Какие архитектурные улучшения были в проекте и как они применялись — поверх или во время миграции?

Слабый ответ:

«По большей части во время миграции. С монолита на модульную архитектуру».

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

Сильный ответ:

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

Например, если система была слишком монолитной, то в процессе миграции мы начинали разрезать её на более понятные модули или доменные зоны: отдельно выделяли UI-слой, работу с данными, бизнес-логику, сторы, API-клиенты. Это снижало связанность и делало код предсказуемее.

Также обычно пересматривали:
— структуру модулей и границы ответственности
— организацию состояния
— слой работы с API
— переиспользуемую логику
— общие UI-примитивы и паттерны композиции

То есть миграция была не отдельной задачей “обновить Vue”, а точкой входа для нормализации архитектуры.

Что здесь реально проверяют:
видишь ли ты миграцию как техническую операцию или как возможность улучшить устойчивость системы.

Вопрос №3

Что ты считаешь важным знанием или навыком при работе с Vue?

Слабый ответ:

«Знание синтаксиса, новых фич, Teleport, Suspense, Composition API, composables, Vapor...»

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

Сильный ответ:

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

Во-вторых, важно понимать композицию приложения: где должна жить бизнес-логика, что оставить в компоненте, что вынести в composable, а что вообще должно быть на уровне сервисов или data layer. Именно это отличает поддерживаемый проект от набора компонентов, которые “как-то работают”.

В-третьих, важно понимать рендеринг и производительность:
как работают обновления, что даёт правильная декомпозиция, где появляются лишние перерендеры, как влияют вычисления в шаблоне, watchers, асинхронные компоненты, lazy loading, SSR и hydration.

И уже после этого идут сами фичи фреймворка: Composition API, Suspense, Teleport и экосистема вокруг Vue.

Что здесь реально проверяют:
понимаешь ли ты Vue как систему, а не как набор удобных хуков.

===================

Если нужен полный список задач, которые спрашивали в МТС, ставь 🔥

На связи тут @codepunks_bro

Через 5 минут начинаем стрим с HR, будем показывать рекуртерам резюме и смотреть на обратную связь)

Ссылка должна быть в боте)

Тут будет чат 👇👇👇

Summary встречи с HR:

Дисклеймер:

Целью звонка было получить прямой фидбэк от рекуртеров, не перемешивая мнение с менторами или мной, поэтому ответы на вопросы дальше — это чистое мнение HR по поводу рынка и ответы на вопросы.

Небольшой, но важный момент, который хотим подсветить из саммари сразу. Красивое резюме и резюме в топе HH в выдаче — разные вещи. Это важно)

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

Фишка:

Отклики и перепиcки можно автоматизировать скриптами или через браузер Comet. Не обязательно делать это руками и тратить свое время.

Вопрос 1:
У вас есть запрос на разработчика, что дальше?

Ответ от HR 1:
1. Рекуртер идет на HH и выставляет фильтры.
2. Самые частые фильтры: опыт и стек.
3. Смотрит первые 50-100 резюме в выдаче HH на первой странице, и пишет 5-10 кандидатам сразу.
4. До второй страницы часто не доходят.

Фишка:

Если вы ниже 100-й позиции в выдаче на hh — рекуртеры будут меньше писать. Желательно пользоваться фишкой выше чтобы постоянно быть в выдаче.

Вопрос 2:
Стоит ли указывать возраст и есть ли эйджизм?

Ответ от HR 2:
Эйджизм есть и очень сильный.
Возраст стоит указывать если вам 25-39 лет.
Если больше или меньше — не стоит.
Также на возраст указывают дата окончания вуза и фото.
Если вам до 25 — выбирайте фото где выглядите старше, и наоборот.

Фишка:

Фото и фон можно чуть подредачить в Photoshop/нейронкой. Не обязательно идти в студию)

Вопрос 3:
Какие аргументы можно использовать, чтобы оформиться вместо трудового договора по ип/сз/гпх?

Ответ от HR 3:
Намного важнее аргументов именно момент, когда вы просите. Если просить до HR скрининга — шансов почти нет, когда компания рассматривает ТК. Если вы уже на финальном этапе оформления — есть реальный шанс договориться. (привели несколько историй из реальной практики)

Фишка:

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

Вопрос 4:
Насколько важно иметь свои пет проекты и ссылку на них в гитхаб? На это сильно обращают внимание?

Ответ от HR 4:
Оба рекуртера отметили что гит в профиле это плюс. Рекуртеры могут из интереса пройти по ссылке и посмотреть оформление и активность.

Фишка:

Сами проекты и их сложность рекуртеры не смотрят.

Если вам понравился стрим + общение с HR напрямую без напряжения и найм-контекста, то накидайте реакции и мы постараемся звать больше рекуртеров из разных компаний 🤝

Я на связи тут: @codepunks_bro

Умеешь верстать? Значит не программист.

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

Справедливый отказ или неверная трактовка ответа?)

На днях вместо HR-скрининга нам отправили вот такой тест.

Никогда не догадался бы до правильных ответов 😅