HQ Bootcamp

Топ-5 ошибок джуниоров на собеседованиях

2024-02-24T21:21:00.536Z

Всего можно выделить 3 формата проведения собеседований в IT:

1. Вопрос-ответ.

Цель: Понять, есть ли у тебя база для роста, понимаешь ли ты основы программирования и работы систем.

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

Цель: Оценить, как вы мыслите и как вы кодите. Проще всего увидеть это на примере.

3. Лайв-кодинг с комментированием.

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

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

Представьте: вы на собеседовании, и вам задают вопросы о реальных проектах, над которыми вы работали. Вы начинаете выдумывать или сомневаться, а интервьюер всё внимательнее следит за вами. Вопросы становятся всё более конкретными или даже повторяются, а вы всё больше путаетесь в собственных ответах. Результат? Прощай, работа мечты. И снова здравствуй, HeadHunter. Какова же причина?

Собрали топ-5 ошибок:

1. Недостаточная подготовка к техническим вопросам:
Если кандидат не может объяснить базовые концепции или алгоритмы, это вызывает сомнения в его базисе. Общее впечатление - недостаточная квалификация и сомнения в способности кандидата решать реальные задачи.

- Да я так-то хорошо шарю за Python. Просто интервьюер попросил написать простую анонимную функцию, а я запутался в синтаксисе.

2. Преувеличение своего опыта:
Несоответствие заявленных навыков реальности проявляется за пару минут всего несколькими уточняющими вопросами. Разработчик без коммерческого опыта не может представить себе все тонкости профессии. Это подрывает доверие и показывает нечестность кандидата.

- А как вы решали такую-то проблему на прошлом месте работы?
- Брали и решали...

3. Отсутствие вопросов к интервьюеру:
Представьте свидание, где ваш партнёр не задаёт вам никаких вопросов. Как бы это вам показалось? Для нанимателя это может означать, что вы либо не заинтересованы в вакансии, либо не понимаете своих будущих задач. Впечатление - кандидат не заинтересован в долгосрочной перспективе работы.

- Ну я спрошу про зарплату если что.
- Нет. Как вариант, можно задавать вопросы о культуре компании, команде, проектах или технологиях, которые они используют.

4. Слабые коммуникативные навыки:
Кандидатов обычно ищут для работы в команде. Если начинающий специалист не может четко и ясно выражать свои мысли, это может затруднить коммуникацию с ним. Если разработчик не может логично описать задачу или ответить на прямой вопрос, это вызывает сомнения в его способности эффективно сотрудничать с командой.

Если в целом отвечаешь неуверенно на любой вопрос - это уже звоночек.

5. Неподготовленность к вопросам о профессиональных целях и мотивации:
Отсутствие чёткого понимания собственных карьерных целей и мотивации может вызвать вопросы о вашем стремлении к развитию и росту. Это заставляет сомневаться в вашей долгосрочной ценности для компании.

- Какие аспекты работы в IT вас наиболее мотивируют?
- Мне, вообще-то, нравится кодить, ну и, конечно, зарплата.
- А как часто ты кодишь?
- Ну на выходных иногда пишу что-то для себя...

Появилась ли пища для размышлений и улучшений своих интервью?

Ищем вакансию Junior QA

2023-10-09T15:44:36.834Z

Если походить по собеседованиям то, скорее всего, можно заметить, что требования отличаются от описанных в вакансии. Зачастую, в вакансиях указана только часть требований. Но при выборе между кандидатами, решающим может оказаться пункт, который даже не был в изначальных “хотелках” компании. Это может быть: опыт работы с фреймворком, который используется в компании или просто знание технологии, которую компания планирует использовать на проекте.

Чтобы повысить свои шансы в конкуренции на вакансию, посмотрим на объявления и попробуем понять, на что стоит обращать внимание, а что можно пропустить на первое время.

Базовые навыки

Нам нужно понять что бизнесу важно в первую очередь?

Из вакансии на QA можно выделить следующие пункты:

Знание теории тестирования
Понимание жизненного цикла разработки ПО
Основы тест документации. Описание тест кейсов и багов
Знание основных инструментов

Это пункты указываются почти во всех вакансиях. И то, что вы изучали на курсах или пробовали сами. А значит и ваши конкуренты их знают, поэтому, на них не обращаем внимания.

А на следующие пункты я бы обращал внимание:

тест-дизайн
swagger/postman
postgres
allure
мобильные системы
и т.д. более редко встречающиеся

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

Ищем выделяющие навыки

Посмотрим несколько вакансий и поищем навыки, которые могут сыграть в вашу пользу.

Кейс 1

Тут требуется кандидат умеющий писать автоматизированные тесты, которые будут работать с базой данных и выдавать красивые отчеты. Большим плюсом будет умение работать со swagger и уметь выполнять запросы в базу.

Кейс 2

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

Кейс 3

А в этой вакансии преимущество будет у кандидата с опытом мобильного тестирования. Они даже вынесли это в начало.

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

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

Ваш опыт

Вспоминаем все, что делали на курсах или в личных проектах. Все, что было проделано вашими руками, будет хорошим плюсом на собеседование. Такой опыт всегда весомее голых теоретических знаний. Особенно, выделяем те задачи, которые релевантны для данной компании и пересекаются с их ключевыми требованиями.

Стали ближе к целе

Вы нашли вакансию, которая вам интересна и понятна. Вы написали конкретное, а не шаблонное сопроводительное, что делают только 20% соискателей. И, скорее всего, уже получили приглашение на собеседование. Половина пути уже пройдена.

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

"Мы не теоретики, мы - практики"

Коммерческий опыт

2023-10-09T13:40:26.829Z

Что такое коммерческий опыт разработки?

Для HR и рекрутеров одним из ключевых критериев отбора является наличие коммерческого опыта разработки от 6 месяцев.

Что это значит?

Это значит, что человек участвовал в разработке коммерческого продукта, того, что продается за деньги на рынке. Программирование ради статеек, домашние задания и работы для удовольствия таковыми не считаются. И да - это не когда вам платят за работу, ведь платить вам могут и на фрилансе, а он как коммерческий опыт плохо проходит)

Почему мы даем именно коммерческий опыт?

В нашем проекте мы разрабатываем EdTech проект - платформу для онлайн обучения, которую можно продать и на которой наши заказчики будут зарабатывать деньги. Мы сами возьмем один из проектов и перенесем на него свое же обучение, то есть заработаем деньги на этой платформе - это и есть коммерческий проект.

Специфика такого опыта в том, что есть диктуемые бизнесом требования, есть диктуемые бизнесом сроки, и в условиях ограниченных ресурсов нужно бизнес не подвести. Это ключевое, что нужно всем компаниям на рынке.

Фрилансер - сам себе бигбосс, менеджер проектов, тимлид, миддл и джун одновременно. Он привык тащить кучу всего, не относящегося к разработке. В офисе от этого придется отвыкать, а это бывает довольно болезненно. Это когда ты, весь такой опытный, прекрасно знаешь, что задача А решается способом B, а тимлид говорит, что она должна быть решена способом C - более медленным и затратным, но нужным по каким-то там непонятным соображениям.

В опыте коммерческой разработки особое внимание уделяется пониманию бизнес-процессов и требований заказчика. Разработчики должны иметь глубокие знания о предметной области проекта и уметь анализировать и прогнозировать возможные проблемы и риски. Также, в процессе разработки важно придерживаться принципов чистого кода и модульности, чтобы обеспечить гибкость и удобство последующего сопровождения и модификации программного продукта.

Опыт коммерческой разработки – это не только технические знания, но и умение работать в команде, эффективно планировать рабочий процесс и адаптироваться к изменениям. Он помогает разработчикам стать востребованными на рынке труда и достичь высоких результатов в своей профессии.

Именно эти пункты мы закрываем на BootCamp “Думай, как middle».

Как понять, что опыт коммерческий?

Основные понятия и принципы включают:

Понимание бизнес-целей: разработчик должен иметь ясное представление о том, что ожидается от создаваемого программного продукта, чтобы грамотно определить его функциональность и архитектуру.
Умение работать в команде: разработка коммерческого программного обеспечения требует сотрудничества разработчиков с другими участниками проекта, такими как дизайнеры, менеджеры и тестировщики. Разработчик должен быть готов к коммуникации и совместной работе в рамках команды.
Знание программных технологий и языков программирования: разработчик должен обладать глубокими знаниями в своей области и быть владельцем необходимых навыков и технологий, чтобы эффективно выполнять свою работу.
Разработка с учетом требований заказчика: разработчик должен понимать требования и ожидания заказчика, и способен адаптировать свою работу в соответствии с этими требованиями. Это позволяет создать продукт, который полностью удовлетворяет потребности и цели бизнеса.
Тестирование и отладка: разработчик должен уметь проводить тестирование и отладку созданного программного обеспечения, чтобы обнаружить и исправить ошибки и недочеты.
Умение работать с существующим кодом: часто разработчику приходится встраиваться в уже существующий проект с имеющимся кодом. Понимание и умение работать с чужим кодом является важной составляющей коммерческой разработки.

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

Поэтому, в BootCamp за каждым разработчиком мы закрепляем:

Команду (backend, frontend, тестировщик)
ТимЛида, который доносит до команды требования бизнеса, планирует сроки и проводит дейлики
Ревьюера, который оценивает код и дает технические материалы для его оптимизации
Бизнес-заказчика, который презентует свои хотелки, вносит изменения в проект и может дополнять свои требования.
Базовый код, который реализует базовый функционал платформы для обучения. С ним необходимо ознакомится и на него стоит опираться при решении новых задач.

Мы даем полноценный 6ти месячный опыт коммерческой разработки, который ждут на рынке.

Мы не теоретики, мы - практики.

Оставить заявку:

https://forms.gle/WKTYtnKjA5Ujt8fk9

Стандартные ошибки при выполнении тестового на позицию React-разработчика

2023-10-08T13:40:03.539Z

Мы получили все ответы на тестовое задание по позиции Frontend-разработчика и целую неделю(или больше...) проводили ревью, чтобы оценить все 240 решений!
Выявили несколько часто встречающихся ошибок, которые вы можете подметить в своих решениях:

Ошибки первого задания:

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

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

— На каждое изменение в инпутах отправлялся запрос, это приводит к высокой нагрузке на бекенд и лишним дерганьям в интерфейсе. Данная проблема решается при помощи подхода называемого debounce.

— Изменение offset и limit производится посредством клика и на них не должен применяться debounce. В таком случае, при нескольких кликах подряд на кнопку следующей страницы, происходит несколько запросов, которые приводят к отрисовке промежуточных страниц. Например, было 2 клика на кнопку следующей страницы, должно быть 2 отрисовки — загрузка и результат 3 страницы, но вместо этого — загрузка и результат 2 и 3 страницы.

Ошибки второго задания:

— Вызов функции по получению книг, пользователей и отзывов производится последовательно. Запросы не зависят друг от друга и должны вызываться параллельно при помощи Promise.all.

— Маппинг данных при помощи map, find, filter. При получении автора, отзыва и автора отзыва для книги при помощи .find(...) сложность алгоритма вырастает до N * M * K * M, где N — кол-во книг, M — кол-во пользователей, K - количество отзывов. То есть, для каждой книги нужно дважды обойти список пользователей и один раз список отзывов. Наиболее оптимальный вариант — составление словаря (хэш таблицы) с ключом в виде id и значением в виде самой сущности. В таком случае сложность алгоритма уменьшается до N + M + K.

— Хранение промежуточных вычислений. Массив с книгами, с пользователями и отзывами не нужен. Достаточно хранить конечный результат — BookInformation[].

— Функции по маппингу toBookInformation, toReviewInformation не выделены либо задекларированы внутри реакт компонента. Данные функцию являются чистыми функциями и должны быть задекларированы вне реакт компонента, в том числе вне файла.

— В списке книг имеется последняя книга без автора, согласно текущему интерфейсу автор должен быть. Замена несуществующего автора на некий стандартный объект является ошибочным. Нужно явно указывать что автор отсутствует, так как это может влиять на бизнес логику, а подмена автора на стандартную заглушку может вводить в заблуждение или приводить к дополнительным проверкам. Поэтому интерфейс книги необходимо исправить и сделать автора необязательным.

Максимальное количество баллов, которое можно было набрать - 50.

Как и когда джун становится мидлом?

2023-10-06T14:46:12.234Z

Существует определенная градация скиллов разработчика:

Junior - может решать мелкие задачи или дорабатывать код

Middle - может придумать новый компонент, либо модуль системы

Senior - способен правильно разработать систему с нуля

Причем, от компании к компании разработчика могут оценить по разному - для одних ты мидл, для других все еще джун:)) Тут все зависят от специфики работы и того, на сколько этот бизнес ИТишный.

Чтобы устроиться на позицию Junior Frontend-разработчика, достаточно знать HTML, CSS и JavaScript, хотя, в последнее время, сюда можно отнести и TypeScript, как новый стандарт. Также, желательно освоить популярные JS-библиотеки и фреймворк вроде Angular, Vue или React.

На позицию Junior Backend - владение одним из языков программирования (Java, PHP, Python, Go, C++), знание HTML и CSS (да-да, это нужно!), возможность работать с базами данных, понимание, как использовать систему контроля версий, умение работать с Git, понимать сложности миграций.

Дальше разработчик двигается по 3 шкалам нашего авторского треугольника развития:

Глубина - более уверенное знание инструментов и технологий. Middle уже не просто знает, как работает та или иная библиотека, функция и т.д. Он понимает, почему она так работает и в каких случаях она так работать не будет.

Автономность – самостоятельность в работе, навыки находить ответы на возникающие вопросы и придумывать способы решения рабочих задач и подходы к реализации проектов.

Бизнес - умение видеть продукт в целом и понимать механику бизнес-процессов. Это про способность предугадать «подводные камни», на которые можно наткнуться в процессе разработки.

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

А как же опыт, годы, сроки?

Есть градация по срокам, в которых спустя 2-3 года джун уже считается мидлом, но давайте смотреть на это серьезно… в позиции джуна можно сидеть и 10 лет, если никуда по треугольнику не двигаться. При этом даже за год можно показать себя хорошим начинающим мидлом и уже вырасти в деньгах.

Как оценить собственный уровень в разработке?

Есть несколько распространённых вопросов, по которым чаще всего оценивают претендента на повышение:

Сложность задач. Какие задачи решает джуниор-разработчик? Создаёт ли новые функции и модули?
Понимание сути задач. Джун может взять задачу не разобравшись в сути. Тогда как часто затягиваются сроки? Или как много времени уходит на разъяснения у лида?
Качество кода. Как часто после код-ревью или тестирования джуну приходится дорабатывать решение?
Скорость выполнения. Какое количество задач джун закрывает за спринт?
Бизнес-модель. Может ли специалист ответить на вопросы развития и цели бизнеса?
Коммуникация. Принимает ли участие в обсуждении проблем с коллегами и предлагает ли варианты их решения?

Мы как раз создали “Думай, как мидл”, чтобы каждый вопрос проработать в плюс:

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

Список скилов для прокачки будущим Middle-разработчикам

Для мидл-разработчика в приоритете soft skills и глубина.

1. Понимание технологий, которые вы используете

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

2. Самостоятельность в поиске ответов и подходов к решению задач.

Ценность мидла в том, что он сам может выполнить поставленную задачу, продумать ее архитектуру и взаимодействие с другими сервисами. Но еще более важно - способность принимать решения за себя и проект. Такой разработчик не ждет пока его пушнут, за него разберутся или кто то придет на помощь, он и его действия активны, прозрачны и понятны.

3. Навык декомпозировать задачу

Умение разделять большие задачи на отдельные части помогает и планировать спринт, и делегировать и находить более оптимальные решения. Мидл разработчик должен уметь построить в голове связь “буду решать задачу вот так, потому что “причина 1”, “причина 2”. Дедлайн задачи вот такой, поэтому я буду использовать “приём 1”, “приём 2”».

4. Понимание принципов работы бизнеса.

Код — это инструмент. Цель разработчика - технически реализовывать идеи и задачи бизнеса. Мидл разработчик должен знать и понимать, чем занимается компания, как она зарабатывает, какие процессы и решения для нее ключевые, к кому из другого отдела можно обратиться за уточнениями. Чем мы лучше знаем бизнес, тем эффективнее мы предлагаем решения.

5. Насмотренность

Как и в любом деле, насмотренность помогает генерировать идеи. Всегда круто знать, что сейчас происходит в индустрии, как дела у рынка и куда мы движемся. Чем больше мы пишем - тем быстрее продумываем логику, чем больше ошибок - тем оптимальнее код и в копилку, как делать не надо)) Когда мы изучаем чужой код, когда видим что одну и туже штуку можно сделать 20 вариантами и где то будет быстрее, а где то визуально чище, - мы расширяем свои возможности и быстрее растем.

Заключение

Разработка — один из аспектов работы над продуктом. В ней участвует множество других специалистов (дизайнеры, маркетологи, специалисты техподдержки, product-менеджеры). Поэтому, для успешной работы в должности Middle-разработчика, важно умение продуктивно взаимодействовать с коллегами из других отделов и мыслить в масштабах бизнеса в целом.

Лучший способ начать - погрузиться в командную коммерческую разработку.

Как?

Вписаться в нашу команду в буткэмпе - Думай, как мидл

Оставить заявку на консультацию - https://forms.gle/LQEhoFerBsy22HBj9

Мы не теоретики, мы - практики.

Эксперимент с поиском работы

2023-10-05T12:44:48.361Z

Мы проводили эксперимент по поиску работы. Мы создали 2 резюме и начали откликаться на вакансии HH.

Входные данные:

1. В первом случае наш соискатель имел год опыта работы на фрилансе + пройденный 12 месячный курс от Яндекс.Практикум

Желаемую ЗП поставили в 50000 руб. и сделали около 20 откликов в компании на позицию Junior в надежде хотя бы на 1 приглашение.

Критерии отбора вакансий, на которые мы откликались:

а) уровень дохода: не имеет значения

б) опыт работы: нет опыта (8 резюме, больше не нашли в МСК) + 12 (опыт от 1 до 3 лет)

Мы получили около 13 отказов за неделю и 7 игноров. Да, мы заполнили резюме базово, так, как заполнил бы любой человек, который работал на фрилансе. Да, мы писали стандартное сопроводительное для всех, как это делали 99% тех, кто нам писал по вакансии Junior Python разработчик. Мы ее специально сделали для этого эксперимента, чтобы все было как оно действительно есть. Таким образом мы постарались совершить все те ошибки, которые совершают джуны при поиске работы.

Возможно, HRы не доверяют девушкам - начинающим разработчикам, но я искренне считаю это сексизмом. У меня в команде 10 девушек и они все прекрасные сотрудники и кодеры. И да, часть из них пришла джунами.

2. Во втором случае наш соискатель имел год опыта на фрилансе + 6 мес коммерческого опыта в HardQode. На hh.ru указано, что 7, но мы имели ввиду работу с середины февраля по середину августа, дальше просто включается округление. В данном случае, это уже парень, т.к. подаваться с того же аккаунта девушки не хотелось.

Входные данные:

Чтобы сделать скидку на то, что это парень, мы указали в резюме желаемую зп в 80000 руб.(т.е. на 30000 руб больше, а это увеличение на 60%) и сделали 5 откликов в компании.

Что поменялось?

Резюме назвали уже не Python, а Django разработчик. Т.е. сделали упор на фреймворк, чтобы у HR сразу по названию нашего резюме был мэтч в голове.
Ключевой опыт в HardQode постарались уместить на одном листе, т.к. все самое важное - должно быть на первой странице. Только на ней ты можешь заинтересовать HRа.
Опыт расписали не из разряда “Делал то-то”, а так, чтобы это было понятно и читаемо бизнесу, примешивая сюда технологические термины. С одной стороны это показывает нашу адекватность и вовлеченность, с другой стороны экспертность. Постарались добавить такие подробности, как чеки на “Предоплату 100%”. Это дает понимать, что мы реально это делали, а не просто чутка трогали. Это доказательство нашей глубокой погруженности в проект, как и указание с какой внешней системой работали(ИС Ferma). Просто те, кто делал оплаты - в курсе что это, т.к. это фермы чеков от самого крупного провайдера OFD.ru На самом деле, это только ЧАСТЬ опыта, которую мы даем в нашем BootCamp. Мы постарались быть максимально приближенными к реальности будущих резюме, которые поможем составить после программы. Саму программу можно посмотреть тут: https://bootcamp.hardqode.com/
Блок “Обо мне” решили сделать чуть фановым. Указали довольно базовые штуки, но решили подкупить HRа реальным понимает философии Agile, а не так, как народ последнее время начал ее воспринимать(спасибо блогерам восхваляющим Agile, но не объясняющим ее ключевую суть)

Критерии поиска вакансий:

опыт работы: от 1 до 3 лет
уровень дохода: от 70000 руб

Но, это только 50% работы, вторые 50% были в сопроводительном:

Тут мы показываем:

Что внимательно прочитали вакансию компании, т.к. первая строчка прям из вакансии взята. Сразу на этот ключевой фактор дали понимание HRу, что тут у нас мэтч.
Показали свою адекватность, как будущего сотрудника(напомню, что ЗП стоит 80000 руб :) ) и опять заложили мэтч для HRа.
Указываем, что мы хотим на продолжительный срок. Доказательство того ,что мы готовы долго работать в п.2 про адекватность. Т.к. мы адекватны - мы не уйдем через пол года.

Тут мы используем:

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

Каков же результат?

2 приглашения на собес по нашим откликам, еще 1 инвайт на преподавателя o_O. Причем, HR нас сам нашел по поиску по резюме. Мы на препода не откликались. Остальные 3 ничего не ответили.

Плюс дополнительный странный оффер, который прилетел на вакансию тоже прикрепляем:

Вот, такие результаты. Выводы делайте сами. Для нас это было достаточным результатом и больше откликов мы решили не делать. Ну, и еще один важный нюанс. На тот момент мы из всех соцсетей Аделя убрали упоминание о том, что он тимлид и т.д. для чистоты эксперимента. А на hh у него до этого были только джуновские резюме, т.к. Адель пришел к нам джуном)

Важно: опыт это не только месяцы и годы работы, это конкретные действия, результаты и технологии, которые были использованы)

Мы не теоретики, мы - практики.

Требования в вакансиях на Junior React: что реально ценно и нужно прокачать, а что hr пишут для галочки.

2023-10-04T15:48:32.847Z

Если вы уже ходили на собеседования, то, скорее всего, уже столкнулись с тем, что вакансия со своими требованиями сильно отличается от того, на что рекрутер/hr в итоге обращает внимание. В вакансии, например, указаны 10 пунктов и вы точно по 9 из них понимаете в чем дело, а на практике этот 1 пункт может как раз оказаться решающим, по которому вас будут отсматривать. Т.к. пока мало кто пишет вакансии так, чтобы ты читал и сразу понимал интересно тебе это или нет. Или осознаешь, что не подходишь, но понятно куда и как расти.

Разбираем вакансии. Что хотим?

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

1 этап. Чистка.

Нам нужно понять по вакансии, а что бизнесу в первую очередь важно?

Из вакансии на фронта выделяем пункты, которые пересекаются со следующими ключевыми словами:

JS
HTML/CSS
GIT/Github
HTTP, JSON, SVG
базовые или базовый
умения
Понимание каких-то основ

На них не обращаем внимания, они нам понадобятся дай бог только на собесе. А у нас сейчас цель - добраться до собеса.

2 этап. Поиск братьев.

Из того, что осталось смотрим, что повторяется. Если такое найдете, то это, скорее всего, самое ключевое, что им нужно.

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

Тут у нас ключевым является принцип Mobile First. Скорее всего, предпочтение отдадут кандидату, который расскажет про него.

Тут явно заметны 3 пересечения:

Юзабилити и UI/UX
Ревью и умение читать и понимать чужой код
SQL, BI-системы, опыт работы с аналитическими системами

Таким образом, упор в сопроводительном предстоит делать на эти знания.

Если пересечений нет, то смотрим на задачи или на профиль компании и какие есть открытые позиции и пытаемся найти какие-то пересечения с ними.

То, с чем нет пересечений, тоже сохраняем. Что-то из них возьмем в сопроводительное.

3 этап. Вспоминаем опыт.

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

Если ключевика не выявили, то описываем более глубинные технологии которые использовали, типа Redux, Recoil, Typescript, NoSQL, PWA, Websockets, Unit-тесты (jest и т.д.)

На позиции мидлов сюда может залететь code review. Как правило, если это указано в вакансии, то это очень важно для нанимателя.

4 этап. Успех.

Поздравляю! Вы нашли вакансию, которая вам интересна и понятна. Вы написали конкретное, а не шаблонное сопроводительное, что делают только 20% соискателей. И, скорее всего, уже получили приглашение на собеседование. Половина пути уже пройдена🔥

Мы не теоретики, мы - практики.

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

2023-10-03T12:08:54.192Z

Как определить сроки на задачу, если ты никогда ничего подобного не делал? И когда эти сроки становятся критически важными?

Поехали! Время чтения статьи 2 минуты, а может 10, ну или давайте оценим ее на 5 поинтов в стиле Agile 😂

Допустим у нас появился новенький Джун, назовем его Олег . Мы даем ему задачу, он смотрит на нее и ставит предположительный срок выполнения 3 часа.

На что он опирается? На внутренние ощущение, карты таро, голос интуиции или желание показать себя гением? Мы не знаем, поэтому выдаем ему калькулятор времени:

если не можешь по шагам рассказать, что будешь делать + 2 часа
если не понял суть/результат задачи + 2 часа
если выяснилось, что недостаточно данных в тз + 4 часа
если документация и реальный код проекта расходятся + 10 часов

Ну прям реально 10 часов? Да.

Пример:

Задача - подключение к внешнему сервису. Документация есть. Беремся делать, ставим срок 8 часов.

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

И есть 2 варианта решения: либо писать в техподдержку, либо методом тыка пробовать. Об этом заранее так и не подумаешь, а сроки уже поставлены. Тут явно + 10 часов нужно ставить, смотря что произойдет быстрее - мы попадем пальцем в небо или нам ответят?

В этом калькуляторе, как и в настоящем, есть и более сложные функции:

Можно плюсовать все и всех, кто может помешать твоим срокам:

кот лег на тебя и мурлыкает + 1 час
хочется кушать + 1 час
позвали на созвон + 1 час
ревьюер + 10 часов

Ревью может затянуться, а без него ты слить задачу не сможешь. Время идет, а ты ждешь тех, кто сможет проверить.

бизнес требования/логика + 10 часов

Заказчики могут дать задачу, которая противоречит сама себе, а ты взял…)

Пример:

Задача - вывести список сущностей уроков, у которых дедлайн не прошел. И прописано, что после дедлайна уроки выводить не надо. Но есть один нюанс. К урокам у нас могут крепиться домашки. Естественно, про домашки в ТЗ ничего нет.

Пошли к заказчику. Подождали 2 дня. Сели разбираться. Оказывается, надо. Вывели)

Но если снизить градус напряжения, то по сути джун может совершить только 2 ошибки, которые сильно сдвинут его первоначальную оценку:

он не разобрался в технологии или инструменте.
свернул не туда (сам себя запутал)

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

Что тут поможет?

1. Оценить степень неизвестности задачи.

То есть то, что вы точно не знаете, и что точно нельзя погуглить.

Если знаний на задачу и описания тз достаточно - сроки оценить реально.

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

2. Декомпозировать задачу.

Задача «создать онлайн-школу рисования» сама по себе большая и влечет поток вопросов, которые навлекают на нас одно большое «не знаааааю». А с чего начать, а какие будут сервисы, а какие роли, а какие технологии нужны? На каждый вопрос мы придумываем отдельную задачу, а к ней еще, и так далее. Чем проще задачи, тем выше шансы у всего проекта быть сделанным вообще.

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

А тут к нам приходит Agile))

Это новый уровень для нашего джуна Олега. Он раскроет опыт работы с командой.

Как в команде оцениваются сроки?

В отличии от пет проектов, фриланса и задачек на курсах на работе в Ит компании вместе с командой в жизнь Джуна приходит БИЗНЕС.

Бизнес ставит отделу ИТ задачу и ждет оценку по срокам(когда будет выпущен функционал?). На эту дату они радостно планируют и продажи и маркетинг и активности на платформе, а почему бы и нет? Бизнес придумал, заплатил и ждет фичу, чтобы всем показать как мы можем…)

Как мы работали в Умскул?

ТимЛид, PO(если он на проекте есть) и бизнес-аналитик садятся и начинают думать, а насколько может быть растянут этот проект?

Задача ТимЛида - оценить сроки и риски проекта. И проговорить их перед бизнесом.

Уже в этом моменте задача делится на составляющие, которые могут быть сделаны за спринт. А потом планируется спринт, где задачи делятся по разработчикам.

И тут уже сам разработчик оценивает сколько сил у него займет та или иная задача.

Спринты, силы..

Куда делось время в часах?)))

На практике, в Agile задача по времени не оценивается. Проблема оценки в часах - она всегда будет ошибочной. Просто примите это как факт при работе в команде) Ты можешь оценить свою работу в часах и уложится в этот срок, но в рамках команды - это практически нереально.

В Agile оценка идет через стори поинты(story points), это абстрактная единица оценки. Это, условно, силы, которая команда должна вложить.

Есть два варианта оценки:
1. Линейная, т.е. когда у нас поинты ставятся от 1 до 10.

2. По последовательности Фибоначчи, когда поинты ставятся в рамках некоторой прогрессии. Это 1,2,3,5,8 и т.д.

Мы придерживаемся второго формата, т.к. при линейной оценке через некоторое время мы внутри себя подсознательно адаптируем цифры к часам, что недопустимо с точки зрения Agile. Фибоначчи в этом плане усложняет нашему подсознанию эту задачу и мы продолжаем давать более абстрактную оценку.

Например, в линейно оценке ты поставишь 5, а команда 7 и 9. Среднее выйдет 7.

В Фибоначчи идет 5, дальше 8, дальше 13. Разброс с каждым разом больше и скорее всего оценка команды сойдется. Ты думаешь, а вдруг задача на 8. Но мы заранее договариваемся, что 5 - это средняя сложность, а 8 это когда больше неизвестных, 13 - это прям что-то сложное, 21 - это вообще бесперспективная хрень с точки зрения оценки)

Когда ты делаешь линейно ты больше сомневаешься в оценке, вдаешься в детали. Фибоначчи защищает нас и команду от этих мыслей. Так, оценка происходит значительно быстрее. Числа Фибоначчи - это понятные числовые значения, к тому же с приятным бонусом: элементы этой последовательности хорошо отражают рост неопределенности, который возникает с ростом сложности оцениваемой задачи.

Если айтишник говорит что опоздает на 10 минут, то возможно он делает это по Фибоначчи)) сравнивает ну ближе 20 минут опоздания к 10 или к часу)) выбирает 10👌

В начале работы команды - оценки самые неверные, но, по прошествии нескольких месяцев точность сильно возрастает, т.к. появляется командный опыт. И вы уже чувствуете, что правильно, а что нет.

Что лучше?

Лучше ставить большую оценку, тогда ты сможешь уложиться в намеченный график.

Бизнесу лучше иметь негативную оценку, но ту, в которую ты точно сделаешь.

Бизнес, в нашем понимании, это и отдельный заказчик и твоя же компания. Точнее все то, что в ней, кроме IT. Это и отдел продаж, отдел образования и маркетинга. И у них на текущий план-график уже есть свои планы))) Поэтому, HR и ищут в компании ребят с опытом. Опытом работы с командой и бизнесом. Такой опыт мы даем в продукте, даже сильно больше. Мы сделали продукт, где команда из 7 человек разных направлений разработки в течении 6 месяцев работает над EdTech проектом. Можно будет прочувствовать и как твой лид оценивает сроки и как команда, и как ты сам. И насколько все это бьется с реальностью.

Можно ли, опираясь на прошлый опыт, оценить сроки задачи?

Оценка задачи производится на текущем проекте. Прошлые проекты не имеют большого значения, особенно, если ты делал это в соло. В команде работа идет всегда медленнее, чем если бы ты работал один. Сроки тянутся, но одновременно выполняется больший объем задач.

Что-то еще?

Бизнес всегда нестабилен. Эту мысль надо принять. Он адаптируется под текущие условия. Он всегда может сказать, что этот функционал нам не нравится. Мы провели демо и результат оказался не тот, который мы ожидали. И тут появляется дополнительный пул задач на переделку. И для методологии Agile это ок. Он и создан, чтобы адаптироваться под это.

Есть, конечно, еще waterfall. Но там все медленнее происходит. Для этого подхода нужна более четкая оценка. По waterfall обычно работают гос компании, которым важна точность, а не гибкость. Там оценка чаще в человеко-часах. И много бюрократии, чтоб согласовать задачу.

Мы не теоретики, мы - практики.

Требования в Вакансиях: что реально ценно и нужно прокачать, а что hr пишут для галочки.

2023-09-27T18:36:04.974Z

Разбираем вакансии. Что хотим?

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

1 этап. Чистка.

Нам нужно понять по вакансии, а что бизнесу в первую очередь важно?

Из вакансии на бекэндера выделяем пункты, которые пересекаются со следующими ключевыми словами:

ООП
http
TCP/UDP
HTML, CSS, XML
базовые или базовый
Навыки
Понимание каких-то основ
API, REST, если нет указания в будущем на DRF или Fast API или явного указания на умение работать с API.
Django, Flask, Fast API если все вместе указаны в одной вакансии
PostgreSQL, MySQL
Linux, bash, Ubuntu
Git, CI/CD

2 этап. Поиск братьев.

Вот в качестве примера ссылка на вакансию: https://kazan.hh.ru/vacancy/86288456

Тут явно заметны 2 пересечения:

"Знание Redis", "Знание Celery" и "Представляете, что такое система очередей и зачем она нужна".
"Знание, что такое REST" и "Понимаете, что такое API и есть опыт работы с API различных сервисов/сайтов /систем;"

Это все про одно и то же, поэтому, я готов сделать ставку, что тут в приоритете будет кандидат, который работал с очередями/умеет их мониторить и знает, как правильно строить API.

То, с чем нет пересечений, тоже сохраняем. Что-то из них возьмем в сопроводительное.

3 этап. Вспоминаем опыт.

Если ключевика не выявили, то описываем более глубинные технологии которые использовали, типа DRF, Docker, Ansible, async, aiohttp, Grafana, Mongo DB или, потенциально, различные интеграции.

4 этап. Успех.

Мы не теоретики, мы - практики.