Как (и возможно ли) дотянуться до Junior JavaScript Developer в кратчайшие сроки? — Хабр Q&A
Во первых: совершенству нет предела.Во вторых: невозможно объять необъятное и впихнуть невпихуемое.
В третьих: как ты не крутись, а технологии развиваются быстрее, поэтому отставание неминуемо, как следствие приходится всегда чем-то жертвовать ради чего-то более важного.
Итого: заказчика не интересуют твои философские страдания. Его интересует как быстро, качественно и за какие деньги ты решишь его проблемы. Решаешь за разумное время, адекватный ценник и с удовлетворительным качеством — не важно как ты себя именуешь, спрос на тебя будет.
Джуниористость/синьористость конкретного разработчика — штука весьма условно субъективная. На собственном опыте скажу, что одно дело, когда ты первый и единственный парень на деревне — ты почти что бог, потом с той же головой, теми же руками, опытом и знаниями оказываешься в среде подобных себе, разной степени синьористости божков, и, внезапно, ты сырой джун но с очень хорошим потенциалом.
Я не очень понимаю, чего вдруг тебя потянуло в разработку. В целом дело это весьма муторное и рутинное, и его надо бы, по хорошему, очень сильно любить, чтобы прям вот пёрло, тогда есть шанс зацепиться, удержаться и даже эволюционировать как разработчик.
Я бы, для начала, досконально убедился, что это вот именно прям вот то самое, чем я бы хотел заниматься ближайшие лет пять, а то и десять, потому что иначе не стоит даже и начинать.
Меня на программирование пропёрло весьма рано, лет в 14-15. Я ощущал собственное безграничное могущество, послушная железяка выполняла любое моё повеление, любой мой каприз, при условии, что он правильно сформулирован. Если железка не делала что нужно, или делала что не нужно, то это всегда была моя вина, это значило что я прокосячился. Подобное осознание настигло меня весьма скоропалительно, после чего мозг начал усиленно дисциплинироваться, и количество лютых фейлов пошло на убыль.
Коммерческая разработка — это, примерно, от 70% времени/сил на дебаг и фиксы, потому что мало где процессы поставлены грамотно. По хорошему до сего дня (а мне под 40) я только одну команду видел, где процессы прям вообще очень хорошо поставлены и мне посчастливилось какое-то время с ними поработать. За эти несколько месяцев я подрос на целую голову. Самостоятельно достичь сходных результатов было бы весьма затруднительно.
Сам я сменил стек совсем недавно, начал в конце 15 года, и процесс продолжается до сих пор. Сменил я по одной простой причине — во всех моих прежних проектах большая часть логики с бэка уехала на фронт, и прекраснейший jQuery перестал справляться чуть более чем полностью. Он, по прежнему, хорош, но задачи, которые приходится решать, требуют совершенно других подходов. Для себя я выбрал React, но в целом на рынке имеются альтернативы. По моим данным очень большим спросом пользуется Angular 2+.
Когда говорят о фронтенд разработке, постоянно говорят о технологиях, стеке, но почти никто не упоминает, что не стеком единым… Существенная часть разработки — это, для начала, понять задачу и построить у себя в голове модель. Заказчики бывают разные, от очень толковых, до очень безтолковых. Соотношение первых ко вторым примерно 1% и всё остальное… Т.е. в большинстве случаев тебе скажут минимум, своеобразно, плюс ты это поймёшь по своему. Потом, по ходу пьесы, в самые неподходящие моменты, начнут всплывать подробности, которые: забыли упомянуть; ну это же очевидно, ты же профи; мы сами не знали, это только выяснилось; ну это же мелочи, мы думаем тебе это будет не сложно; а ты не спрашивал; и т.п….
В результате, по своему опыту скажу, частенько проекты примерно на середине выглядят ужасно и обложены костылями. На моем опыте бывало не раз, что нормально получалось только раза с третьего-четвертого…
Казалось бы, а какое это имеет отношение к джуну? Да прямейшее, потому, что, редко в какой команде джуна возьмут как джуна. Обычно джуна берут чтобы платить поменьше, а работы накинут где как мидлу, а где и как синьору, потому что, нередко, бизнес не жирует, ресурсы жестко ограничены, задачи нужно решать хоть как-то, а решения принимают люди, которые ничего в нашем деле не понимают…
Если ты попадешь в команду, где люди будут понимающие, квалифицированные, процессы выстроены, а джуну задачи будут сгружать джунские, то, считай, тебе крупно повезло. Шансов на это примерно 1%. Особенно учитывая, что джуны это обычно студенты лет в районе 20…
Когда я менял стек, то я тоже был какое-то время 35-летним джуном. С этим ничего не поделать, потому что, внезапно, стек это не просто так, и имеется масса нюансов, которые с наскоку не освоишь. Чтобы все пощупать, попробовать на зубок, понять и осознать требуется время и усилия, иногда много времени и много усилий. Да, весь прежний багаж служит опорой и поддержкой, и там, где настоящий джун будет копаться недели, ты за пару часов по аналогии поймаешь идею и двинешь дальше. Но эти пару часов никто не отменял, а идей которые нужно отловить сотни, если не тысячи…
Сложнее всего разобраться в архитектуре конкретного проекта, потому что, внезапно, стиль кодирования и конвенции чрезвычайно важны, если ты не один работаешь над проектом от и до. Если до тебя, вместе с тобой или после тебя кто-то будет работать над проектом, дорабатывать, поддерживать это дело, исправлять баги, в конце концов (а они бывают всегда и везде), то очень желательно, чтобы любой разработчик мог в кратчайшие сроки, оперативно и легко вникнуть, разобраться и понять, что там к чему, откуда, куда, зачем и почему. Чаще всего у проектов с этим проблемы, поэтому накладные расходы множатся, а эффект сходит на нет, усугубляясь текучкой кадров.
Даже если тебе попадается практически идеальный проект, внезапно оказывается, что твоя оперативная память это 5-7+-2 объекта, а удерживать в голове одновременно нужно сотни…
Зачем я все это рассказываю? Затем, что это реальность, которая для джунов не делает исключений.
Термин «фигак-фигак и в продакшен» встречается повсеместно, т.к. ресурсы (деньги, время, кадры) практически всегда весьма жестко ограничены и ничего ты с этим не поделаешь.
У верстальщика в этом плане все проще, потому что его работу видно сразу и невооруженным взглядом. Но просто верстальщик и хороший верстальщик — это земля и небо.
С другой стороны сейчас предпочитают фронта, который еще и неплохо верстает. Слава флексбоксам и современным браузерам, сейчас это делать намного проще, чем годы назад.
Теперь относительно того что делать — если в бэкграунде нет сильных скиллов по алгоритмике и структурам данных (олимпиады по программированию, универский курс информатики), то прям очень сильно рекомендую прокачать. Будучи наставником на нескольких курсах фронтенда я постоянно встречают студентов, которые «вроде бы» знают язык, но затрудняются скомпоновать пару циклов с условиями, вот буквально просто виснут на неопределенное время, причем без результата. Лично я рекомендую кодварс. Своих студентов я прокачиваю именно там. Достаточно прорешать 30-40 задачек, чтобы базовые скиллы ушли на уровень рефлексов и перестали парить мозг. Правда желательно решать это все с наставником.
Косвенный бонус тут будет в том, что ты привыкнешь решать задачи на JavaScript. Я когда менял стек, поначалу мыслил на PHP, и подобный финт на кодварс позволил мне переформатировать мышление на JS. Вот мой профиль на кодварс как пруф: https://www.codewars.com/users/iCoderXXI
Далее, когда ты освоишься в JS практически, очень неплохо будет досконально разобраться в том как работают замыкания и прототипное наследование. Это прям основа основ, и это спрашивают на каждом первом собесе.
Понять надо настолько глубоко, чтобы легко и просто, с юморком, рассказывать это любой первой встречной бабушке, да так, чтобы та всё поняла… Это вот прям залог успеха в JS, потому что все остальное держится на этих двух китах. В ютубе имеется курс Зоракса (Zorax) и JavaScript Weird Parts, оба про то же самое, первый на русском, второй на инглише. Кантор, безусловно, крут, но эти двое объясняют попроще и понятнее (имхо).
После этого прокачиваемся в использовании встроенных методов JS, таких как map, reduce, includes, replace и пр. (на том же кодварс)
После этого нужно прокачаться в ES6+, стрелочные функции, let/const, деструктурирование, рест оператор, классы, промисы, генераторы, async/await, декораторы — без этих продвинутых штук в современных фреймворках ловить нечего.
После этого снова идем на кодварс, и все то же самое прорешываем уже с использованием новых знаний. Внезапно код становится в разы лаконичнее, понятнее и читабельнее.
Потом уже заостряемся на API форм, DOM, AJAX (fetch/axios), вебсокетах, Localstorage и пр.
И вот только теперь можно переключаться на фреймворки. Проще всего освоить Vue (по слухам), наибольшим спросом пользуются React и Angular, для общего развития так же неплохо бы немного послушать про Ember.JS.
React только на первый взгляд выглядит простым, на самом деле это только view-библиотека, а в любом нормальном SPA есть много чего еще кроме view, поэтому React всегда идет в компании Redux, Router, и еще целой толпы всего, что тоже придется осваивать, не только с точки зрения API, но и с точки зрения философии (а нахрена оно вообще сдалось?)
Перед походами на собесы очень желательно иметь портфолио из нескольких готовых проектов, вылизанных стилистически.
Далее освежаем базу по JS — типы, замыкания, прототипы, и смело топаем по собесам, будучи морально готовыми завалить первые десять.
Вообще джуновых вакансий не густо, точно гораздо меньше, чем джунов на них претендующих. А вот синьоров и мидлов на рынке остро не хватает, поэтому стратегия такая — качаться до мидла без вариантов.
Еще вроде большие компании вроде Яндекса устраивают летнее обучение, с последующим трудоустройством лучших кандидатов, но это не точно.
Оптимистичный прогноз — 6-12 месяцев плотного фигачинга и ты в тренде.
Советы для начинающего Java-разработчика. Подготовка к собеседованию — часть 2
В первой части цикла мы рассмотрели важность составления плана обучения, вопросы по Java Core и работе с БД. В этой части обсудим вопросы в комментариях и поговорим о двух популярных фреймворках: Spring и Hibernate.
Вопросы в комментариях
О происхождении вопросов для подготовки
Все они были заданы мне или моим коллегам на собеседованиях на позицию Junior/Middle людьми с уровнем Middle/Senior/Lead. Проекты: два крупных банка, сотовый оператор, внутренние квалификационные собеседования.
Вопросы придумывал не я, и оценивать их качество без конкретного контекста имеет мало смысла. Практически каждый из них прозвучал в общей сложности больше двух раз за все время прохождения собеседований. Какие-то были в разных вариантах, но с одним подтекстом.
Зачем джуну знать про <любая технология или принцип>?
Один из уроков, который можно вынести из первой части: очевидные вещи очевидны не для всех. Ответ на любой из вопросов для подготовки не нужно знать как daily basis. Его нужно знать, чтобы обойти конкурентов на позицию в хорошей компании. Даже если память плохая и через время забывается большинство изученного материала, то перед собеседованием имеет смысл эти знания освежить.
Выбор стратегии при подготовке
В девелопменте можно выделить две основные стратегии поиска работы:
а) Куда возьмут, туда пойду. Чем быстрее начну получать опыт, параллельно подтягивая недостающие знания, тем лучше.
б) Куда пойду, туда возьмут. Плюсы очевидны. Среди минусов — больше времени на подготовку. В некоторых случаях — значительно больше.
Первая стратегия сильно доминирует и давно себя зарекомендовала. Не всем нравятся сложные цели, и не каждому они под силу. У кого-то семья, домашние заботы, сторонние занятия и банально некогда выкладываться на 150%. Да и, говоря на чистоту, стратегия трудоустройства в нетоповые компании имеет мало минусов. Ну попадется вам как-бы-сеньор в наставники, поделаете некоторое время ерундовые задачи исключительно на умение серфить Stack Overflow. Зато уже с зарплатой, опыт какой-никакой в копилку капает, и свободного времени для самообразования больше.
Вторая стратегия гораздо консервативнее: меньше свободных часов в сутках при подготовке, значительно меньше их же в рабочем дне на первых порах. Но ускорение на старте профессионального развития более качественное и, чаще всего, выше зарплата.
Судя по комментариям к первой части, очень мало кто придерживается второй стратегии. Очень мало кто даже рассматривает ее как один из вариантов. Но это не хорошо и не плохо, берем ношу по себе.
«Что дозволено Юпитеру, не дозволено быку»
Техлиды и сеньоры не обязаны знать ответы на все вопросы для джуна. Они больше не конкурируют с полусотней других претендентов на место, каждый из которых решает элементарные задачи и запинается на неэлементарных. А тот претендент, который не запнулся, просто видел похожую задачу на днях и плавает в других темах.
Техлидов хантят месяцами и цепляются за хорошего, как за спасательный круг. И, как я подозреваю, о хешмапах на собеседованиях их не спрашивают. С джунами все более печально: компаний в среднестатистическом городе (не мегаполисе), готовых взять стажера/джуна, — раз-два и обчелся. А ездить в поисках по городам на начальном этапе карьеры — не всегда позволительная роскошь. Сидеть без работы, естественно, тоже.
Претендуешь — соответствуй
Компании с интересными проектами, крутой командой и высокими зарплатами имеют право требовать знание не только каких-то паттернов разработки, но и алгоритмов, логических задач, синтаксиса — да чего угодно.
Поэтому о TreeMap, LinkedHashMap, работе кучи, стека, синхронизированных коллекций и прочей мало применяемой скуке можно и не знать. Идти туда, где прямым текстом в вакансии указано: «Об алгоритмах не спрашиваем». При этом помнить, что не спрашивают чаще всего там, где нет большой конкуренции за место: если начнут много спрашивать, не из кого будет выбирать.
Кстати, утверждение о необходимости соответствовать при высокой конкуренции одинаково верно для всех уровней. Егор Бугаенко в недавнем интервью рассказывал, что на собеседовании в Amazon ему давали алгоритмические задачи (архитектору с более чем 20-летним опытом), которые он решать отказался. Собеседование он не прошел. А взяли кого-то, кто наверняка уступает в качестве профильных знаний, но подготовился лучше и изучил потенциальные вопросы. И кому, скажите, от этого хуже?
Потеряно время на переписку, минимальную подготовку, посещение офиса — стресс до и осадок в виде неприятного ощущения после. И если архитекторам все дороги открыты («куда пойду, туда возьмут» в большинстве случаев), то у джунов ставки в несколько раз выше: только что было три шанса устроиться на хорошую позицию в родном городе, а вот их осталось уже два. Пора начинать собирать чемоданы.
Выбирайте стратегию обдуманно и слушайте только близких вам по мировоззрению и духу людей. «Не каждый совет ценен, но каждый озвучен неспроста».
Приступим к темам и вопросам.
Spring
Фреймворк, без знания основ которого вас практически никуда не возьмут. Пугает на старте всех, кто никогда его не видел, и чаще всего из-за непонимания его основных целей и механизмов работы. Это и неудивительно: на просторах интернета пересекаются тонны как совсем свежей, так и безнадежно устаревшей информации. А возможность сконфигурировать один и тот же механизм работы несколькими абсолютно разными способами еще больше усложняет изучение.
Обо всем перечисленном могу сказать одно: все приходит с опытом. Я остановился на следующем подходе: выбрать один-два модуля Spring для детального изучения, а в остальных разобраться поверхностно. Под детальным изучением подразумевается изучение реальных примеров на гите, за которым следует собственная реализация практической задачи с запоминанием или записью используемых в процессе аннотаций.
На сайте Spring есть очень неплохая документация с описанием всех внутренностей и популярные примеры реализации определенного функционала.
Обычно, когда на собеседовании дело доходит до Spring, происходит примерно следующий диалог:
- Из Spring с чем-то работали?
- Да, изучал вот это и вот то.
- Хорошо, давайте немного поговорим на эти темы.
Иногда будут спрашивать прямо: знаете ли, например, Spring Data? Если знаете на достаточном для обсуждения уровне, считайте, что повезло. Если нет, всегда можно честно сказать, что понимаете их суть и необходимость использования, видели примеры кода, но самостоятельного применения не было. И заранее позаботиться о том, чтобы это было правдой: посмотреть и поверхностно вникнуть в работу любого спрингового модуля придется в любом случае. Вопрос только в том, насколько глубоко.
О чем меня спрашивали часто: core, data, mvc.
Чуть реже — boot, security.
О чем не спросили ни разу за все время: aop, test.
Это статистические данные, не более.
Разделение по уровням джуновости достаточно условное.
Недоджун (он же претендент на стажировку) и младший джун — поверхностные знания о модулях спринга и какой за что отвечает. Изучить их работу на практике и предоставленные возможности конфигурации.
Крепкий джун — спринговый код и конфиги смущать не должны. Видим аннотацию и понимаем, что она из конкретного модуля и нужна для таких-то целей, и какие шаги необходимо предпринять, если понадобится изменить определенную логику.
Дальше вперемешку немного вопросов, связанных с перечисленными темами (только те, которые повторялись):
- Опишите механизм dependency injection простыми словами.
- Как работает модуль спринга <такой-то>, какой флоу выполнения (что куда заходит и как обрабатывается в процессе)?
- Как создается контекст? Каков порядок инициализации в контексте?
- Какие знаете различные способы конфигурации бина? Дефолтный скоуп бина? Какие вообще скоупы бывают? Для чего они используются?
- Какая разница между BeanFactory и FactoryBean?
- Расскажите об autowired-аннотации. Есть поле, помеченное autowired, как Spring находит бин и инжектит, какой алгоритм? Что, если реализаций интерфейса две? Можно ли вешать autowired на несколько конструкторов?
- Для чего нужен @PostConstruct? Что выполнится раньше — @PostConstruct или конструктор?
- Аннотация @Transactional, что знаете о ней? Какие у нее параметры? На что ее можно повесить? Какой паттерн используется как основа (прокси)? Опишите требования к методу, на который хотим повесить эту аннотацию.
- Дефолтные property в Spring boot: для чего они, где конфигурируются?
- Какой паттерн используется в основе spring security (chain of responsibility в виде цепочки фильтров)?
- Перечислите виды авторизации в Spring security. За что отвечает аннотация @Preauthorize?
Hibernate
Изначально я хотел объединить темы Spring и Hibernate в одну, но в итоге решил не создавать хаос в относительно структурированном подходе. После штудирования статей о том, что это за фреймворк и какие его функции, обязательно погуглите разницу между JPA, Spring Data JPA и Hibernate. И обязательно поймите ее, это сильно упростит процесс понимания взаимодействия Spring и Hibernate.
Вопросы:
- Как Hibernate формирует запросы? Что такое фетчинг, батчинг?
- В каких состояниях может быть entity? Расскажите немного о них.
- Кеш запросов — расскажите о всех уровнях.
- Когда возникает lazy initialization exception?
- Расскажите об известной в Hibernate проблеме N+1 select.
- Расскажите о стратегиях наследования сущностей.
- Если внутри сущности есть коллекции, подгружаются ли они по умолчанию?
Конечно, как и для любого фреймворка, любят спрашивать, для чего он нужен и в каких случаях можно обойтись без него. Разобраться в этой теме всегда будет полезно.
P. S. Спасибо всем, кто дочитал. Значит, хоть какая-то польза, но будет. В третьей части постараюсь раскрыть все оставшиеся темы.
Иллюстрация Дарины Скульской
Предыдущая статья: Советы для начинающего Java-разработчика. Подготовка к собеседованию — часть 1
java — Какие актуальные технологии нужно знать для позиции Intern/junior
Stack Overflow на русскомLoading…
- 0
- +0
- Тур Начните с этой страницы, чтобы быстро ознакомиться с сайтом
- Справка Подробные ответы на любые возможные вопросы
- Мета Обсудить принципы работы и политику сайта
- О нас Узнать больше о компании Stack Overflow
- Бизнес Узнать больше о поиске разработчиков или рекламе на сайте
Профессия Junior Java Developer
Описание квалификации Junior Java Developer
Junior’ом обычно называют разработчика, который только начинает серьезно работать в определенной области технологий. У такого разработчика есть знания, позволяющие ему работать над реальным проектом, но очень мало (или нет) опыта такой разработки. Поэтому, зачастую в технических аспектах он советуется с более опытным разработчиком. Накопив достаточно знаний и опыта Junior становится mid-level разработчиком.
Если говорить о Junior Java Developer’е, то необходимы такие знания:
- Программирование (системы исчисления, чем оператор отличается от операции, некоторые алгоритмы)
- Язык Java (синтаксис, ООП возможности, многопоточность, стандартная библиотека)
- OOP и OOD (парадигмы, основные паттерны проектирования)
- Базы данных (JDBC, язык SQL)
Обычно для Java Junior’а не обязательно знание какой-либо конкретной технологии или фреймворка (например веб-сервисов или Spring). Достаточно знать зачем та или иная технология нужна, какие задачи с помощью нее решают, преимущества/недостатки в сравнении с похожими технологиями. Junior детально знакомится с такими технологиями/фреймворками в процессе работы над очередным проектом.
Необходимые тесты
Программирование — Основы
Тест, необходимый для прохождения любому, кто имеет дело с программированием. Здесь собраны довольно элементарные вопросы по булевой алгебре, системам исчисления (особенно двоичной и шестнадцатиричной), простым алгоритмам.
Java — Основы
Тест содержит достаточно большое количество вопросов, но не только по синтаксису языка так и по практическому использованию той или иной возможности. Вопросы теста преимущественно простые, но есть и довольно «хитрые» вопросы, которые проверяют понимание.
ООП — Основы
Знание ООП парадигм на базовом уровне безусловно необходимо для Junior’а. Данный тест ставит себе задачу это проверить. Вопросы в основном теоретического плана и требуют соответствующего уровня подготовки.
ООП в Java
Тест посвящен ООП возможностям Java. Проверяет знание вопросов которые часто задают на собеседованиях Junior’ам: «как реализовать множественное наследование в Java», «в чем отличие абстрактного класса от интерфейса» и т.п. Содержит в основном практические примеры и неплохо дополняет предыдущий тест по теоретическому ООП.
SQL — Основы
На данный момент, базы данных используются в большинстве промышленных приложений. Поэтому эти знания довольно востребованы и Java Junior’у сейчас нужно иметь представление о JDBC и SQL. Тест проверяет базовые знания SQL и наиболее используемые его возможности.
Написание статьи
Тематика статьи предлагается администрации и либо принимается либо отвергается с предложением альтернативной. Тематика должна касаться предметной области. Это требование проверяет умение Junior’а быстро вникнуть в суть проблемы, а также способность излагать мысли последовательно и методично. Как вариант можно предложить на рассмотрение администрации 3-4 темы для статьи, а администрация предложит для написания одну из них. Написанная вами статья не должна быть ранее опубликова на других ресурсах.
Составление вопросов
Необходимость составления вопросов преследует ту же цель что и написание статьи: умение аналитически подходить к изучению нового, отделять главное от второстепенного. Тематики вопросов также согласовываются с администрацией (это нужно так как в некоторых тестах довольно много вопросов и при добавлении еще одного высока вероятность, что похожий вопрос уже есть).
Важно: Вопросы насчет статьи можно задавать в комментариях на странице Вашей квалификации (не перепутайте с публичной страницей описания), на которую можно зайти из ссылки на профиле в блоке Квалификации.
Ждем Ваших комментариев и отзывов.