Не хочу рекламировать именно курс ВК. У многих крупных компаний есть курсы, программы и иногда даже кафедры и факультеты при вузах. У Яндекса, тинькова есть программы, раньше даже были у интела и jetbrains, в общем много всего есть.
В моем случае я учился на программе системного архитектора, это 4 семестра:
1 семестр:
алгоритмы
С/С++
Веб-разработка (тогда это был Джанго)
2 семестр:
Фронтенд
Go-разработка
Базы данных
Навыки деловых коммуникаций
3 семестр:
Проектирование высоконагруженных систем
QA
Безопасность
Андроид / iOS-разработка по выбору
4 семестр:
разработка выпускного проекта
Сейчас программа поменялась и стала более специализированной, периодически запускается трек по ML
Это бесплатная программа при вузе. Компании заинтересованы в выращивании кадров под себя. Если хочешь, можешь после выпуска пособеседоваться в них. Чтобы поступить, нужно пройти отбор и, самое сложное, — не отчислиться
Зависит от позиции, на которую кандидат хочет попасть. От джуна и даже миддла никто куб не ожидает, как и отмечается в статье. Но Nginx — это инструмент, которым должен владеть опытный фронтендер, поэтому если оказывается, что наш сотрудник не шарит за Nginx, мы обязательно ставим в его план обучения практические задания на настройку веб-сервера. Курс по Kubernetes тоже ставим в план, но на более высоких грейдах
Мне повезло учиться здесь: https://park.vk.company/, тут была двухлетняя программа, где действительно всё это изучается, кроме куба. Хотя я давно учился, мб щас курс и по кубу появился.
Но докер, мне кажется, это база в 2024, простой контейнер запустить со своим пет-проектом — это что-то, что можно ожидать от джуна
Как вы и процитировали, статья наценела на джуниоров и миддлов. Подробнее о том, какие навыки на каком грейде пригоятся, ответил в этом комментарии
Мб мне повезло, но большинство из этих тем я просто прошел на курсах в университете еще перед первой стажировкой, включая nginx, docker, solid, паттерны и пр., поэтому ожидаю в т.ч. от младших специалистов
Согласен, что про куб от джуна ничего ожидать не стоит, ровно как это и отмечается в статье
Здрвствуйте! Это обзорный материал, здесь практически нет рассуждений о глубине знаний по каждой из тем. Цель была — дать подсказку, что еще можно изучить, и какие пробелы заполнить.
Отвечая на ваш вопрос, я бы сформировал такое соотношение:
к стажеру без опыта 0 вопросов, он может вообще ничего из этого не знать, главное программировать уметь
от джуна, который уже является самостоятельным сотрудником, можно ожидать, что он знает о существовании каждой из тем, понимает, на решение каких задач они направлены и имеет опыт в тех из них, которые связаны непосредственно с продакшеном и его типовыми задачами
от мидла можно ожидать больше не только знаний, но и опыта в тех темах, которые связаны с архитектурой и инфраструктурой
от синьора можно требовать опыт или способность освоиться в большинстве из этих тем
Здесь пропускаю тему ЗП, т.к. соотношение грейда и зп разное на рынке и колеблется в каком-то общеизвестном диапазоне, эти данные можно поискать на hh, например)
Статья всё же не про вопросы на собеседовании, а про обзор тем, на которые эти вопросы могут быть заданы. Часть тем актуальна миддлам, например, про Docker или CI / CD но если джун и их освоит, то это вообще супер, мб он и не джун тогда)
P.S. Хотя джун всё равно как минимум должен знать о существовании всех этих тем, даже если он не имеет в них опыта.
Infinite scroll — это пример практического приема, реализация которого может быть кейсом на собесе, а не как отдельный топик для изучения
Про анимацию можно добавить, спасибо!
Фреймворки намеренно пропустил, т.к. статья не об этом.
Веб-компоненты и веб-воркеры, на мой взгляд, всё еще остаются экзотикой, которая бывает полезна в очень узких кейсах. Базовое понимание о веб-воркерах формируется, если осознать принципы работы PWA, о котором упоминал в статье.
KISS — проскочило на редактуре, исправил, спасибо)
Про топики: согласен, что невозможно знать всё, и не всё из перечисленного в статье могут спросить на собесе. Например, сомневаюсь, что зайдет разговор о типовых архитектурах веб-сервера.
Мой подход обычно строится так: я спрашиваю кандидата о его собственном опыте и пытаюсь разузнать, как он справлялся со своими задачами. Могу задать доп. вопросы о деталях и мотивации принятых решений, кто эти решения предлагал и почему, спросить, как бы поменялась архитектура, если бы требования отличались каким-то образом. Это хорошо подсвечивает опыт и кругозор.
По полному охвату смежных сфер: в моём случае критерий отбора скорее не «кандидат должен знать всё», а «кандидат осознает проблематику предметной области и знает хоть что-то», а далее проверяем глубину понимания каждой из тех тем, о которых зашел разговор.
И определяющий этап для меня уже не собес, а испытательный срок, на код ревью все становится на свои места.
С этим полностью согласен, но проверить какую-то долю хард-скилов на собесе можно, ровно об этом и материал. Чем раньше определим мэтч, тем лучше и соискателю и работодателю.
Эта статья отталкивается от того, что читатель уже владеет JS и TS, и в первую очередь опирается на то, что нужно уметь помимо программирования. Но TS важен, конечно. В 2024 — это базовый скилл, который ожидаем по умолчанию.
Речь не о плагинах, а о проекте. Запускал фронтенд-монорепозиторий с несколькими runtime-собирающимися NPM-библиотеками, сторибуком и вебпак-дев-сервером. + на проекте несколько сотен файлов с кодом. Для вебшторма этого уже слишком много
я бы еще добавил, что JetBrains потребляет сильно больше ресурсов. Мой мощный мак с большим фронтендом просто умирает с вебштормом, даже индексацию файлов и связей между ними не вывозит, а VS Code спокойно переваривает
Здравствуйте! Согласен с тем, что одна из обязанностей тимлида в развитии команды. Подключение сотрудников к планированиям, декомпозиции и пр. — это тоже один из процессов развития сотрудников и не противоречит содержанию статьи.
Например, менеджер может без участия тимлида пригласить разработчика для декомпозиции какого-то раздела. Разработчик прокачивается, но ответственным за процесс остается именно менеджер. Так же и с лидом, он может делегировать проектирование архитектуры, но ответственность за конечный результат всё равно на лиде.
Немного не согласен с тем, что инициатива должна исходить от разработчика вплоть до создания тикета, потому что здесь может начаться хаос и дублирование задач. Хочется, чтобы был какой-то центр фиксации решений, а вот к процессам, конечно, нужно подключать сотрудников, чтобы они в них вникали, понимали контекст, предпосылки, ограничения, и принимали решения.
Более того, согласен с тем, что нужно поощрять инициативу сотрудников и давать им возможность реализовать свою идею до конца, в том числе с вовлечением других коллег. Но опять же, всё это должно проходить через контроль менеджера и лида, чтобы у них оставалось глубокое понимание процессов на проекте.
Здравствуйте! На самом деле, дело не в регалиях. Базовый принцип я бы сформировал так: увеличиваем эффективность труда сотрудника за счет спецификации его основных обязанностей. Тимлиду — тимлидово, менеджеру — менеджерово ?.
Тимлид отвечает за: — техническое качество — сроки реализации задач — развитие команды — технические процессы в команде — эффективное распределение нетиповых задач
Менеджер отвечает за: — коммуникацию — это в первую очередь, на мой взгляд, т.к. количественно самая объемная работа с самым большим контекстом, который нужно помнить — планирование работ — декомпозицию и распределение типовых задач
В этом случае, конечно, возникают издержки на коммуникацию, поэтому она должна быть эффективной, а для этого нужно выстраивать процессы, чтобы каждый человек понимал свою зону ответственности. Нужно понимать, как без блокировок решить проблему, если менеджер или тимлид сейчас не могут сделать свою работу.
Ровно поэтому тимлид должен также разбираться и в работе менеджера, а менеджер должен уметь что-то из работы тимлида: например, если тимлид выпал на полдня, менеджер должен и без него примерно осознавать возможную сложность нетиповых задач и грамотно их распределить или понять, что их лучше отложить. А тимлид может вместо менеджера провести встречу и подвести её итоги. Но опять же, это скорее для лучшего понимания друг друга и выхода из нестандартных ситуаций.
На самом деле, 30 человек — относительно небольшая команда. Приведу пример одного из проектов, в котором участвовал:
— 6 фронтендеров — 6 бекендеров — 3 менеджера — 2 аналитика — 3 дизайнера — 2 QA — плюс в нашем случае есть сторонние команды, которые разрабатывают модули и встраивают их в ядро, но интеграции настолько плотные, что обсуждения ведутся так, будто мы все в одной команде.
Уже набирается 30 человек точно
— в нашем случае был только веб, но в общем можно добавить к этой команде еще N мобильных разработчиков — инфраструктурой в KTS занимается DevOps отдел, поэтому их не включаем, но опять же в зависимости от задач и специфики иерархии, DevOps-инженеры тоже могу входить в команду
В общем, 30 человек вполне можно переварить, если грамотно декомпозировать роли и выстроить коммуникацию. Еще нужно сделать механизмы интеграции процессов более независимыми, тогда растить команду можно практически неограниченно.
Не хочу рекламировать именно курс ВК. У многих крупных компаний есть курсы, программы и иногда даже кафедры и факультеты при вузах. У Яндекса, тинькова есть программы, раньше даже были у интела и jetbrains, в общем много всего есть.
В моем случае я учился на программе системного архитектора, это 4 семестра:
1 семестр:
алгоритмы
С/С++
Веб-разработка (тогда это был Джанго)
2 семестр:
Фронтенд
Go-разработка
Базы данных
Навыки деловых коммуникаций
3 семестр:
Проектирование высоконагруженных систем
QA
Безопасность
Андроид / iOS-разработка по выбору
4 семестр:
разработка выпускного проекта
Сейчас программа поменялась и стала более специализированной, периодически запускается трек по ML
Это бесплатная программа при вузе. Компании заинтересованы в выращивании кадров под себя. Если хочешь, можешь после выпуска пособеседоваться в них. Чтобы поступить, нужно пройти отбор и, самое сложное, — не отчислиться
По ощущениям, x2 от университета) Но это не пугает, потому что очень интересно и полезно. Неактуального просто нет.
UPD: Актуальная ссылка https://education.vk.company/centrum/2
Основные причины вижу следующие:
Знание основ позволяет более эффективно общаться фронтам и девопсерам
Типовые задачи могут делать и фронтендеры: например, изменить объем аллоцированных ресурсов, настроить проксирование на ингрессе и т.д.
Большая самостоятельность в анализе / локализации проблем, доступе к логам и подам
Это не снимает работу с девопсеров. Они формируют и настраивают окружение, которым как инструментом пользуются фронтендеры и бэкендеры.
учился в университете и учился на курсе
Зависит от позиции, на которую кандидат хочет попасть. От джуна и даже миддла никто куб не ожидает, как и отмечается в статье. Но Nginx — это инструмент, которым должен владеть опытный фронтендер, поэтому если оказывается, что наш сотрудник не шарит за Nginx, мы обязательно ставим в его план обучения практические задания на настройку веб-сервера. Курс по Kubernetes тоже ставим в план, но на более высоких грейдах
Мне повезло учиться здесь: https://park.vk.company/, тут была двухлетняя программа, где действительно всё это изучается, кроме куба. Хотя я давно учился, мб щас курс и по кубу появился.
Но докер, мне кажется, это база в 2024, простой контейнер запустить со своим пет-проектом — это что-то, что можно ожидать от джуна
Как вы и процитировали, статья наценела на джуниоров и миддлов. Подробнее о том, какие навыки на каком грейде пригоятся, ответил в этом комментарии
Мб мне повезло, но большинство из этих тем я просто прошел на курсах в университете еще перед первой стажировкой, включая nginx, docker, solid, паттерны и пр., поэтому ожидаю в т.ч. от младших специалистов
Согласен, что про куб от джуна ничего ожидать не стоит, ровно как это и отмечается в статье
Здрвствуйте! Это обзорный материал, здесь практически нет рассуждений о глубине знаний по каждой из тем. Цель была — дать подсказку, что еще можно изучить, и какие пробелы заполнить.
Отвечая на ваш вопрос, я бы сформировал такое соотношение:
к стажеру без опыта 0 вопросов, он может вообще ничего из этого не знать, главное программировать уметь
от джуна, который уже является самостоятельным сотрудником, можно ожидать, что он знает о существовании каждой из тем, понимает, на решение каких задач они направлены и имеет опыт в тех из них, которые связаны непосредственно с продакшеном и его типовыми задачами
от мидла можно ожидать больше не только знаний, но и опыта в тех темах, которые связаны с архитектурой и инфраструктурой
от синьора можно требовать опыт или способность освоиться в большинстве из этих тем
Здесь пропускаю тему ЗП, т.к. соотношение грейда и зп разное на рынке и колеблется в каком-то общеизвестном диапазоне, эти данные можно поискать на hh, например)
Статья всё же не про вопросы на собеседовании, а про обзор тем, на которые эти вопросы могут быть заданы. Часть тем актуальна миддлам, например, про Docker или CI / CD но если джун и их освоит, то это вообще супер, мб он и не джун тогда)
P.S. Хотя джун всё равно как минимум должен знать о существовании всех этих тем, даже если он не имеет в них опыта.
Infinite scroll — это пример практического приема, реализация которого может быть кейсом на собесе, а не как отдельный топик для изучения
Про анимацию можно добавить, спасибо!
Фреймворки намеренно пропустил, т.к. статья не об этом.
Веб-компоненты и веб-воркеры, на мой взгляд, всё еще остаются экзотикой, которая бывает полезна в очень узких кейсах. Базовое понимание о веб-воркерах формируется, если осознать принципы работы PWA, о котором упоминал в статье.
KISS — проскочило на редактуре, исправил, спасибо)
Мир в целом становится более комплексным, усложняются системы и, следовательно, требования к тем, кто эти системы разрабатывает.
Рад, что материал оказался полезным для вас!
Про топики: согласен, что невозможно знать всё, и не всё из перечисленного в статье могут спросить на собесе. Например, сомневаюсь, что зайдет разговор о типовых архитектурах веб-сервера.
Мой подход обычно строится так: я спрашиваю кандидата о его собственном опыте и пытаюсь разузнать, как он справлялся со своими задачами. Могу задать доп. вопросы о деталях и мотивации принятых решений, кто эти решения предлагал и почему, спросить, как бы поменялась архитектура, если бы требования отличались каким-то образом. Это хорошо подсвечивает опыт и кругозор.
По полному охвату смежных сфер: в моём случае критерий отбора скорее не «кандидат должен знать всё», а «кандидат осознает проблематику предметной области и знает хоть что-то», а далее проверяем глубину понимания каждой из тех тем, о которых зашел разговор.
С этим полностью согласен, но проверить какую-то долю хард-скилов на собесе можно, ровно об этом и материал. Чем раньше определим мэтч, тем лучше и соискателю и работодателю.
Эта статья отталкивается от того, что читатель уже владеет JS и TS, и в первую очередь опирается на то, что нужно уметь помимо программирования. Но TS важен, конечно. В 2024 — это базовый скилл, который ожидаем по умолчанию.
Тогда могу только позавидовать)
Речь не о плагинах, а о проекте. Запускал фронтенд-монорепозиторий с несколькими runtime-собирающимися NPM-библиотеками, сторибуком и вебпак-дев-сервером. + на проекте несколько сотен файлов с кодом. Для вебшторма этого уже слишком много
я бы еще добавил, что JetBrains потребляет сильно больше ресурсов. Мой мощный мак с большим фронтендом просто умирает с вебштормом, даже индексацию файлов и связей между ними не вывозит, а VS Code спокойно переваривает
Здравствуйте! Согласен с тем, что одна из обязанностей тимлида в развитии команды. Подключение сотрудников к планированиям, декомпозиции и пр. — это тоже один из процессов развития сотрудников и не противоречит содержанию статьи.
Например, менеджер может без участия тимлида пригласить разработчика для декомпозиции какого-то раздела. Разработчик прокачивается, но ответственным за процесс остается именно менеджер. Так же и с лидом, он может делегировать проектирование архитектуры, но ответственность за конечный результат всё равно на лиде.
Немного не согласен с тем, что инициатива должна исходить от разработчика вплоть до создания тикета, потому что здесь может начаться хаос и дублирование задач. Хочется, чтобы был какой-то центр фиксации решений, а вот к процессам, конечно, нужно подключать сотрудников, чтобы они в них вникали, понимали контекст, предпосылки, ограничения, и принимали решения.
Более того, согласен с тем, что нужно поощрять инициативу сотрудников и давать им возможность реализовать свою идею до конца, в том числе с вовлечением других коллег. Но опять же, всё это должно проходить через контроль менеджера и лида, чтобы у них оставалось глубокое понимание процессов на проекте.
Здравствуйте! На самом деле, дело не в регалиях. Базовый принцип я бы сформировал так: увеличиваем эффективность труда сотрудника за счет спецификации его основных обязанностей. Тимлиду — тимлидово, менеджеру — менеджерово ?.
Тимлид отвечает за:
— техническое качество
— сроки реализации задач
— развитие команды
— технические процессы в команде
— эффективное распределение нетиповых задач
Менеджер отвечает за:
— коммуникацию — это в первую очередь, на мой взгляд, т.к. количественно самая объемная работа с самым большим контекстом, который нужно помнить
— планирование работ
— декомпозицию и распределение типовых задач
В этом случае, конечно, возникают издержки на коммуникацию, поэтому она должна быть эффективной, а для этого нужно выстраивать процессы, чтобы каждый человек понимал свою зону ответственности. Нужно понимать, как без блокировок решить проблему, если менеджер или тимлид сейчас не могут сделать свою работу.
Ровно поэтому тимлид должен также разбираться и в работе менеджера, а менеджер должен уметь что-то из работы тимлида: например, если тимлид выпал на полдня, менеджер должен и без него примерно осознавать возможную сложность нетиповых задач и грамотно их распределить или понять, что их лучше отложить. А тимлид может вместо менеджера провести встречу и подвести её итоги. Но опять же, это скорее для лучшего понимания друг друга и выхода из нестандартных ситуаций.
На самом деле, 30 человек — относительно небольшая команда. Приведу пример одного из проектов, в котором участвовал:
— 6 фронтендеров
— 6 бекендеров
— 3 менеджера
— 2 аналитика
— 3 дизайнера
— 2 QA
— плюс в нашем случае есть сторонние команды, которые разрабатывают модули и встраивают их в ядро, но интеграции настолько плотные, что обсуждения ведутся так, будто мы все в одной команде.
Уже набирается 30 человек точно
— в нашем случае был только веб, но в общем можно добавить к этой команде еще N мобильных разработчиков
— инфраструктурой в KTS занимается DevOps отдел, поэтому их не включаем, но опять же в зависимости от задач и специфики иерархии, DevOps-инженеры тоже могу входить в команду
В общем, 30 человек вполне можно переварить, если грамотно декомпозировать роли и выстроить коммуникацию. Еще нужно сделать механизмы интеграции процессов более независимыми, тогда растить команду можно практически неограниченно.
Про этот проект есть стать на хабре, кстати, если любопытно, предлагаю изучить: https://habr.com/ru/company/kts/blog/569448/