Без опыта не берем

2021-07-24 17:13:10 Каким должно быть портфолио джуниор разработчика? Когда качество важнее количества.

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

Как именуете переменные, поддерживаете ли high cohesion low coupling, проводите ли разделение ответственностей.

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

При этом, опыт отбора джуниор ребят в команду показал, что 2/3 не "причесывают" его совершенно.

Список проектов на Github-е — это хорошее начало. При этом, если у вас серьезные намерения устроиться на работу, не имея за плечами опыта — качественно проработанное портфолио увеличит шансы успешно устроиться за разумный срок [1-2 месяца].

Вместо фокуса на разных проектов с низким уровнем, сфокусируйтесь на проработке 1-2 флагманских проектов.

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

1. Выберите подходящую идею для проекта. Проще всего использовать идею проекта с готовым дизайном и требованиями.

2. Первая фаза: "Проектирование". Если проект не разбит на отдельные задачи — разделите самостоятельно [это декомпозиция]. Если не умеет иначе, декомпозируйте проект на задачи по фичам, которые нужно реализовать.

3. Вторая фаза: "Реализация". Используйте сначала подход решения в лоб. Не усложняйте, фокусируйте на простоте решения. Если умеете, пишите тесты по ходу работы над фичами. Они будут полезны на 3й фазе.

4. Третья фаза: "Рефакторинг". Проанализируйте выполненный проект и начните с самых очевидных мест.
Какие могут быть: непонятные названия переменных [прошла всего неделя, а уже непросто ориентироваться в коде], много кусков императивного кода, не организованного в функции [выделять функции с понятными именами полезно].

2я и 3я фазы обычно проводятся итеративно (реализовал → порефакторил → реализовал → ...). Если у вас нет опыта, лучше выполните проект на ~70% — только после пробуйте рефакторить.

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

Без насмотренности [приходит с опытом и практикой, это нормально], легче проводить рефакторинг, когда видишь несколько примеров одной и той же проблемы.

После завершения проекта, задеплойте проект на Netlify или Heroku и приложите ссылку. Убедитесь, что приложение работает без багов.

В README репозитория распишите кратко суть проекта и технологии. Подробно расскажите о проблемах решенных в проекте. В небольших компаниях, на такие вещи обратит внимание тимлид или СТО.

Если в итоге никто из компании не прочтет README — у вас все равно будет структурированное понимание проблем, решенных в проекте. Сможете четко рассказать на интервью.

Фокусируйтесь на качественной проработке и демонстрации скиллов. Не тратьте время на клепание похожих простеньких проектов. Открыть/Комментировать

2021-07-22 22:05:25 Уточняйте детали до реализации

История 1

Пришло оповещение из командного трекера: на вас назначили задачу. Видите что в ней мало деталей. Есть краткое описание функционала формы регистрации, который нужно реализовать и дизайн макет.

Вздыхаете. Приступаете к работе.
Верно поступили?


История 2

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

Вздыхаете. Приступаете к работе.
Верно поступили?


В обоих историях одна ошибка: вы получили задание и сразу перешли к реализации

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

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

В первой истории:
— Спросите про важность фитчи: "Ваня, а зачем нам нужно делать функцию логина в форме с помощью фейсбука?"
— Уточните детали связанные с данными пользователя, это может быть валидация
— Спросите про реализацию формы

В истории с собеседованием, вам надо:
— Уточнить, какие другие форматы данных могут быть
— Спросить про требования по памяти и оптимизации, а может вообще нужна производительность?
— Узнать можно ли использовать готовые функции или нужно реализовать низкоуровневыми средствами языка

Эти уточнения несут в себе огромную пользу, сейчас поясним.

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

Если вы найдете ненужную фичу - сохраните час своего времени + час времени тестировщика + большую сумму денег компании. Так вы будете более ценным работником → сможете быстрее получить повышение, да вам еще и спасибо скажут.

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

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

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

Как начать задавать вопросы?

Зацепитесь за первые мысли, которые возникли после определения задачи. Вам достаточно задать пару вопросов, после ответа на них появится еще пара и так далее.

После ответов сложится более четкое понимание задачи и у вас получится решить ее оптимальным способом. Открыть/Комментировать

2021-07-18 19:08:46 Комментарии к неочевидным вещам или когда комментарии в коде полезны

Код должен быть простым и понятным.

Используйте осмысленные имена переменных и функций. Отвечайте на вопрос "Why" код существует, а не "What" он делает.

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

Разделяйте код по ответственностям [базовый пример, как делает это MVC паттерн].

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

Начну комментировать все подряд. Функции, классы, события. Объясню, что делает этот цикл. Надо пояснить, что этот return возвращает.

К сожалению, так тоже не сработает. Для джуниор разработчика комментарий — индикатор, что код написан плохо в 9/10 случаев. Пометили свой код комментарием? Значит код нечитаемый, его избыточно много, он плохо организован или слишком сложен.

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

9/10 — может, это тот самый случай, когда комментарий нужен?

name = user.getName(); // user's name

Нет, здесь не нужен. Нужен в другом случае.

// FIGMA_FILE_URL_PATTERN явно поддерживает только ссылки
// на Figma Files,
// ссылки на прототипы не работают

const FIGMA_FILE_URL_PATTERN = `^сложный regex$`;

Или например

// Дата завершения предотвращает коллизии, когда проект
// завершен повторно и был удален из БД, но не из Github
// организации с проектами
const completedAtTimestamp = DateHelpers.getUTCUnixTimestamp(now);

Более простой сценарий

{
/* Центрирует иконку относительно имени пользователя по вертикали,
без нее align-items не справляется,
визуально все равно они на разных уровнях */
margin-top: -6px;
}

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

Если в вашем коде содержится такое неочевидное поведение — подумайте, как можно подсказать через сам код. Не выходит? Тогда свободно пишите комментарий — в дальнейшем будет легче разобраться с подводными камнями проекта. Открыть/Комментировать

2021-07-16 19:35:19 Менторы. Часть 3: Как найти ментора?

Предыдущие части
— Менторы. Часть 1: Зачем нужен ментор?
— Менторы. Часть 2: Мотивация менторов

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

Сервисы для поиска ментора
Самый простой путь связаться с экспертом [Senior JS developer, проектировщик, продакт менеджер, etc.]. Цены на услуги менторов варьируются.

Если вы уже понимаете, в каком направлении будете развиваться [технология, компания], то ищите ментора, связанного с этим направлением.

— https://solvery.io/ - самая большая площадка с менторами и экспертами, можно найти менторов из самых разнообразных компаний

— https://getmentor.dev/ - некоммерческий проект, коммисию сервис не берет, цену назначает сам ментор

— https://nengens.ru/ - относительно новая площадка с менторами, цены несколько ниже, чем на Solvery

Чаты ИТ сообществ
Опубликуйте сообщение в локальных чатах сообществ [если в одном городе — встречи в живую тоже приятны]. Расскажите про себя, объясните почему ищите ментора, чего уже достигли самостоятельно и/или над чем работаете сейчас.

Ваша проактивность может привлечет внимание и отклик 2-3 разработчиков.

— JavaScript — русскооворящее сообщество - сфокусированно JS

— Сообщество Junior/Middle Фронтенд Чата - сообщество джуниор и миддл разработчиков

— Список локальных ИТ сообществ от Hexlet - большая коллекция со ссылками на локальные русскоязычные сообщества

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

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

Нетворкинг помогает завести полезные знакомства, в том числе найти ментора или найти работу.

— https://github.com/web-standards-ru/calendar - календарь событий от сообщества Веб-Стандартов. Не нашел веб-версии — но там есть инструкция, как настроить свое приложение календарь, чтобы подтягивать данные в него.

В соц. сетях: Twitter/Instagram/Facebook
Соберите список авторов, которые пишут статьи, делают видео ролики и так далее в соц. сетях. Особенно часто можно встретить разработчиков, публикующих интересные мысли в Twitter и Instagram - можно оценить их опыт и навыки.

После проходитесь по списку и пишите личное сообщение каждому.

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

Не спрашивайте в заголовке "Не найдется ли у вас время?", "Можно задать вопрос?" — сфокусируйтесь, чтобы сделать одно первое сообщение максимально информативным и по делу.

Это подкупает, правда. Мессенджеры и соц. сети дают ассинхронное общение, которое требует прерывания от других дел. Много нервов тратится, когда приходится многократно прерываться на небольшие сообщения в попытке докопаться до сути.

— https://nometa.xyz/ - пример, как задавать вопросы

Что писать ментору?
Начинайте знакомство с ментором с конкретных вопросов. Не стоит сразу бросаться с криком "Станьте моим ментором!".

Постарайтесь не задавать абстрактные вопросы, вроде "Что нужно, чтобы устроиться джуниор разработчиком?" - на такие вопросы ответить почти невозможно коротко и однозначно.

Например, попросите ресурсы для обучения по опредленной теме — получите рекомендации. Изучите и напишите фидбек со своим прогрессом, что узнали, что было интересно, что не поняли.

Усилия с вашей стороны — первичный индикатор для ментора, что вы интересны.

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

Не пугайтесь, если приходится требовать внимания, это нормально. Если вы будете слишком давить — ментор об этом скажет. Открыть/Комментировать