17 вопросов джуну: что должен знать Junior-разработчик

Изучаем основы

Чтобы стать Junior-разработчиком, очевидно, нужно знать основы. С учётом того, что мне никогда прежде не приходилось заниматься программированием, я начал с HTML и CSS.

Мне посчастливилось найти freeCodeCamp. Это потрясающий сайт, с помощью которого вы можете бесплатно научиться веб-разработке, выполняя небольшие задания по программированию. Задания касаются практически всех областей веб-разработки. Самыми лучшими разделами я считаю “Algorithm Scripting” и “Projects”. Вы практикуетесь в изученном материале, создавая реальные веб-страницы. Я прошёл весь курс front-end разработчика.

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

Чтобы стать junior-разработчиком за 4 месяца и устроиться на работу, вам нужно:

• Изучить основы. freeCodeCamp вам в этом поможет.
• Использовать Git и GitHub для хранения и демонстрации вашей работы.
• Сделать портфолио, которое определяет ваши навыки и показывает их.
• Расширить знания в языке.
• Практиковаться в изученном.
• Подавать резюме, не боясь отказов. Зачем ждать?

Поймите что от вас хотят

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

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

Я бы хотел немного объяснить. Я делю программирование на 2 вида – творческое и рабочее. Творческое – это когда ты пишешь для своего Github или просто для себя. Там никто не ограничивает, никто не говорит как правильно. Это хобби.

Рабочее же выполняет задачи бизнеса. Все. Бизнесу плевать на количество паттернов в коде и количество слоев абстракции. Капиталисту с сигарой нужно, чтобы его сервис работал без сбоев и, желательно, уже вчера. В идеале эти 2 вида накладываются друг на друга, в самом плохом случае – не пересекаются вообще.

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

Что я узнал “по другую сторону стола”

Я узнал многое, когда компания, на которую я работал, проводила конкурс на мою должность. Я узнал многое о других разработчиках, чей уровень схож с моим, уровнем Senior-разработчика.

Многие кандидаты, которые проходили собеседование, не знали и не понимали основ. Как бы они смогли создавать компоненты Angular, если они не понимали замыкания?

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

Другой претендент имел поразительное портфолио. Многие проекты были действительно продвинутыми и хорошо сочетались. Он был первым кандидатом на должность. Однако впечатление о нём поменялось во время собеседования. Говоря с ним, было очевидно, что он не понимал большую часть кода в своих проектах. После собеседования, я, погулив, обнаружил, что все его проекты – это step-by-step гайды.

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

Что бы я сделал по-другому

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

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

Я бы меньше выполнял Daily CSS Challenge. Я нашёл Daily CSS Challenge и проводил час или два в день, создавая CSS картинки. Это было довольно забавно, но у меня не было цели становиться дизайнером, т. к. я хотел быть разработчиком. Лучше бы потратил это время на разработку проекта или изучение чего-то нового, что пригодилось бы в моей работе.

Не тратьте много сил на то, чтобы ваши проекты выглядели великолепно. Я потратил около 15 часов на прорабатывание своего второго портфолио. Я перепробовал около 3 или 4 различных цветовых палитр, вариаций дизайна, чтобы сделать портфолио идеальным. Спустя 2 месяца я удалил его и создал портфолио намного лучше прежнего. Я мог бы потратить то время, к примеру, на изучение нужного фреймворка.

Я бы задавал вопросы. Как только мне встречалась проблема в проекте, я часами сидел и искал решение. Иногда у меня это получалось, а иногда я просто ходил кругами по нескольку часов. Я бы решал эти проблемы быстрее и эффективнее, спрашивая людей, у которых есть опыт. Форум freeCodeCamp – потрясающее место, полное опытных и умных людей, которые всегда рады помочь.

Начинаем подавать резюме

Как только вы закончите со среднеуровневыми проектами на freeCodeCamp, у вас будет достаточно опыта, чтобы стать Junor-разработчиком. Начните подавать заявки на эту должность. Взгляните на своё портфолио и решите, хотите ли вы его обновить или переделать. У вас должно быть намного больше опыта с тех пор, как вы его создали.

Подавайте заявки на вакансии, которые вас интересуют. Сначала попробуйте крупные сайты по поиску работы, затем сайты поменьше. Я получил несколько запросов, потому что разместил своё резюме и портфолио в Интернете. Один из телефонных звонков превратился в собеседование, а затем в приглашение на работу. Рекрутеры заинтересованы в человеке, который хочет стать Junior-разработчиком или уже является им.

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

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

У меня было огромное количество негативных ответов, в которых работодатели писали, что им нужен человек с X-летним опытом. Несколько сообщений было примерно следующего характера: рекрутеру понравилось моё резюме и портфолио, но работодателю хотелось взять человека помладше. В конце концов, мне позвонили, пригласили на собеседование, а затем дали работу.

Почему вы выбрали этот язык программирования?

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

Что должен знать junior-разработчик? отвечают эксперты

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

Стажёр — человек, который только учится, часто он не имеет опыта разработки. Со стажёрами мы в компании чаще всего имеем дело на наших стажировках, которые мы в разных форматах организовываем с 2021 года. Как правило, значительная часть их аудитории — это студенты без опыта работы.

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

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

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

Если рассматривать hard skills, то, наверное, нужно упомянуть такие профессиональные навыки, как умение искать информацию в поисковых системах, знание средств коллективной разработки (Git и другие), знание IDE, языка и фреймворка.

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

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

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

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

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

По нашему опыту в последние годы требования к Junior-разработчикам у нетоповых компаний снизились. Связано это с кадровым голодом, вызванным, с одной стороны, ростом рынка, с другой, демографическим провалом девяностых–начала 2000-х.

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

Основные хард-скиллы:

• Знать синтаксис языка, на котором предстоит работать.
• Знать основу стандартной библиотеки языка и представлять её структуру в целом.
• Понимать принципы работы технологической платформы и среды исполнения (например jvm).

Дополнительные хард-скиллы:

• Понимать принципы работы реляционных СУБД, иметь навыки работы с ними.
• Знать основы веб-разработки.
• Понимать, как в целом устроен мир: как работает сетевое взаимодействие, какая инфраструктура существует в интернет- и корпоративных сетях, понимать отличия парадигм программирования, скриптовых языков от компилируемых и т. д.

Практические навыки:

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

Софт-скиллы:

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

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

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

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

It-сфера изменчива, постоянно появляются новые технологии. готовы ли вы всё время учиться?

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

Junior expert

Будьте инженерами, а не макаками

Пожалуй, это самый главный пункт. Я часто встречаю на форумах и в беседах “Front-End разработчиков на React/Redux”, которые на деле с трудом отличают javascript от микроволновки. Наша область труда – наукоемкая. Тут не бывает “просто взял и воткнул кнопочку”.

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

Я бы разделил программистов на 3 большие группы. Представьте, если вам задать довольно специфичный вопрос (вроде “Ты слышал что-нибудь о кодах Рида – Соломона”). Программисты могут ответить на него следующими способами:

1. Нет, мне это не надо

2. Нет. Что это такое, расскажи?

3. Да, конечно, это…

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

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

Ваша компания и технологии не хуже других

В один момент жизнь программиста резко меняется. После того, когда та самая компания предложит первый оффер. Вчера вы были студентом или самоучкой, а сегодня уже полноценный программист. В вашей трудовой написано программист. В профиле любой социальной сети можно написать “Developer at %company_name%” и никто не сможет оспорить. Тогда эмоции просто бурлят внутри, чувствуется, что сотни часов за компьютером не были потрачены зря.

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

В этот момент где-то там, на задворках сознания, начинает появляться мысль, что вы не дурак, раз у вас все так хорошо. А дураки-то все остальные. Вот у нас на проекте angular и java. А у моего одногруппника c# и vue. Вообще-то всем известно, что java лучше, чем c#, так почему у них на проекте не так? Наверное, у них в команде слабые спецы.

Скажу честно, я видел ребят, своих ровесников, которые попадали в компании, где HR-бренд сильнее многих в регионе. И я видел, как у них расправлялись плечи. Ведь они работают в компании %company_name%, там и офис круче, и приставка новее.

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

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

Вы командный игрок?

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

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

В удалённой работе гораздо большую роль начинают играть soft skills. Гибкие навыки — это не только умение общаться с коллегами, но и банальное уважение к коллегам, к примеру, в чатах — когда ты отмечаешь коллегу, дублируешь сообщение, которое могло потеряться, и закрепляешь важные ссылки на самом верху.

Где проходили обучение, участвовали ли в реальных проектах?

В Galileosky мы всегда обращаем внимание на следующие моменты:

Говорите со своими коллегами

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

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

Если возникла проблема, как вы будете её решать?

Это больше вопрос на самостоятельность, нежели на способы решения.

Хочется поделиться советом: прежде чем идти к более опытным коллегам с вопросом, постарайтесь сами разобраться в проблеме. Во всех командах очень ценится, когда человек подходит не просто с вопросом «А как это сделать?», а уже обладает какой-то информацией, прикинул варианты решения и обращается за советом, как решить проблему правильнее.

Есть ли опыт работы с git? какой веб-сервис для хостинга проектов вы используете?

Неважно, GitHub это, GitLab или BitBucket. Интервьюера интересует главное — разбираетесь ли вы в системе контроля версий.

Есть ли опыт работы с базами данных? сколько нормальных форм вы знаете и чем они отличаются?

Знать, как обращаться к БД, нужно, а вот что касается нормальных форм — это, скорее, плюс, чем необходимость. Будет хорошо, если вы назовёте СУБД, с которыми работали, обозначите их ключевые особенности.

Также к навыкам стоит добавить SQL. Да, на SQL сейчас никто не пишет, но без SQL невозможно понимание логики работы СУБД.

Изучаем git и github

Я начал использовать Git и GitHub, поэтому смог работать над своими проектами во время обеденного перерыва на работе. Знание того, что он делает, и как его использовать, значительно упрощает программистам жизнь.

Я бы порекомендовал начать использовать Git сразу же, как только вы создадите свой первый проект. Вам нужно знать только основы, чтобы продвигать его в GitHub. Наличие вашего кода онлайн позволит будущим работодателям оценить ваши знания и кодстайл.

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

Как стать джуниором, которого возьмут на работу в ит-компанию? спросите эксперта

Какие алгоритмы сортировки вы знаете? напишите код с использованием быстрой сортировки.

Ох уж эти алгоритмы сортировки — понять бы, где они пригодятся в реальной жизни. А зачем вообще Junior-разработчику это знать? Тут всё просто: понимание принципов и гибкость мышления. Опять же, с помощью небольшого примера вы покажете, что владеете синтаксисом языка и умеете объяснять, что происходит в вашем коде.

Какие методологии создания продукта вы знаете? назовите несколько принципов agile

Да, вам стоит почитать об Agile. Даже если вы твёрдо уверены, что никогда не столкнётесь с командной разработкой, поверьте — столкнётесь. Это не то, что обязательно знать Junior-разработчику, но будет плюсом, если вы разбираетесь.

Какие технологии вы знаете?

Для работы на реальном проекте мало знать сам язык программирования. Младшему разработчику необходим большой багаж знаний. Если мы рассматриваем разработчика на Java, кроме  самого языка, необходимо иметь хотя бы начальные знания о Spring, базах данных, SQL, системах контроля версий. Это не означает глубокое изучение всех аспектов, но представление о работе с этими технологиями быть должно, даже если нет реальной практики. Зачастую разница между Middle- и Junior-разработчиком — это реальный опыт.

Если говорить о знании конкретных технологий, от начинающего разработчика требуется опыт разработки на каком-то классическом языке программирования со строгой типизацией — подойдёт Java, C , C#. При этом не так важно, на каком языке программирования придётся писать в будущем: синтаксис языка выучить легко, а вот понимание, что «можно» делать, а чего «нельзя» — нет.

Каков ваш уровень английского языка?

Для нас, в EPAM, важным фактором является также уровень английского языка — не ниже Intermediate, поскольку после обучения можно попасть на проект с распределённой командой, с разработчиками из других стран.

Кроме того, аутсорсинговые компании зачастую работают с иностранными заказчиками, организовывают с ними встречи и созвоны. И вообще, читать и писать документацию стоит на английском, да и на Stack Overflow лежит всё, что нужно знать Junior-разработчику. Поэтому перед собеседованием обязательно подтяните английский язык.

Можете ли вы оценить время выполнения задачи?

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

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

Назовите принципы ооп

Старо как мир, но всё так же актуально. Держите шпаргалку по принципам ООП: там всё разложено по полочкам. Если вы хорошо разбираетесь в ООП, можете рассказать о своём опыте их применения на практике. Идеально, если вы также расскажете, почему те или иные принципы не стоит применять в некоторых ситуациях.

Подготовка к собеседованию

Знайте основы. Практикуйте основы.

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

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

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

Помните про эффект даннинга — крюгера

Про данную психологическую особенность написано очень много статей. Проще всего продемонстрировать его следующей картинкой:

Картинка честно взята отсюда.

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

Это, увы, не так. У вас еще очень большой путь путь впереди, вам многое предстоит узнать и пощупать. Помните – вы не король разработки. Король разработки у нас один и имя его многим из нас хорошо знакомо. Старайтесь провести на пике уверенности как можно меньше времени.

Портфолио

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

Когда вы в первый раз создаёте своё портфолио, сделайте так, чтобы оно работало и выглядело хорошо. Не тратьте слишком много времени, разрабатывая его.

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

Практикуемся в изученном

Это одна из самых важных вещей для получения работы. Лучший способ практиковаться – использовать изученные вещи в реальных проектах. Например, если вы изучили адаптивный дизайн, сделайте простой адаптивный веб-сайт. Необязательно, чтобы у сайта был какой-то смысл. Практика с использованием новых знаний – важная вещь.

Чтобы практиковаться в JavaScript, выполняйте алгоритмические задания на freeCodeCamp. Когда закончите, попробуйте Code Wars и Coding Game. Это отличные сайты, на которых есть задачи для любого уровня знаний.

Прекратите смотреть на чужие зарплаты

Однажды мне наш HR рассказала историю, как она общалась с соискателем, у которого было чуть меньше года опыта. И он попросил заработную плату от 150 тысяч рублей. Я, откровенно говоря, был слегка шокирован соотношением цифр и релевантного опыта. Как правило, у начинающих специалистов разбегаются глаза от цифр в вакансиях.

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

Расскажите, с какими ide вы работали

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

Расширяем наши знания

Использовать JavaScript для создания веб-страниц – одно дело, понимать, а как это работает – совсем другое. Я искал в интернете лучшие книги для более глубокого изучения JavaScript и остановился на серии книг You Don’t Know JS. Они находятся в открытом доступе и совершенно бесплатны.

Серия этих книг освещает наиболее важные аспекты в JavaScript, объясняя, как всё работает. Для первой работы вам достаточно будет прочитать и понять Up & Going и Scope & Closures. Остальные книги из серии лучше всего читать, уже будучи Junior-разработчиком. Некоторые темы трудно понять, не встретив их на практике.

В некоторых фрагментах книг вам будет необходимо решить несколько задач. Это делается для того, чтобы повысить уровень понимания материала. Таких фрагментов будет довольно много, особенно в Scope & Closures.

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

Также вас могут попросить решить несколько несложных задач

Минимальный испытательный набор состоит из трёх тестов.

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

Во-вторых, смотрят, как кандидат усваивает информацию, как работает его внимание и память. Обычно перед разработчиком ставится задача из 5–6 вводных пунктов, после чего идёт обсуждение её решения. Кандидат должен резюмировать задачу, описать своё решение, а затем сделать выводы.

В-третьих, по косвенным признакам, оценивается коммуникабельность кандидата — развитие его речевых навыков и способность работать в команде. Часто от соискателей на Junior-позицию требуется проактивность (её оценят, предложив несколько «поведенческих» задач) и скорость мышления.

У вас был свой проект? в чём заключалась задача и как вы её решали?

Чтобы стать Junior-разработчиком, нужно знать теорию и применять её на практике. Разумеется, вы как джун уже должны были что-то писать, будь то на курсах или для себя. Перед собеседованием стоит разобрать один из самых сложных проектов, вспомнить, какие проблемы возникали в процессе работы над ним, и как вы их решали.

Умеете ли вы справляться со стрессом?

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

Эпилог

Итак, я всего лишь поделился своим видением этого мира. Я уверен, что многим опытным специалистам есть что сказать, так что буду рад дискуссии в комментариях. А всем, кто только начинает свой путь в странном мире разработки ПО – желаю успеха и умопомрачительного карьерного роста!

Выводы

Мнения насчёт того, завышены требования к джунам или нет, очень разнятся. Но практически все эксперты сходятся в том, что Junior-разработчик должен знать о преимуществах и сферах применения выбранного языка или технологии, уметь работать с Git, знать основные алгоритмы, библиотеки и фреймворки в своей сфере, быть в курсе возможностей хотя бы одной IDE, знать английский не ниже уровня Intermediate и уметь работать в команде.

А вот что должен знать Middle-разработчик.

Читайте уже наконец чужой код

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

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

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