Ну, я на работе имею дело тоже с большим зоопарком. PHP, JS, RabbitMQ, nginx, apache, bash, zabbix, docker, Astra Linux, Rosa Linux. Это не мешает мне уметь проходить собеседования и решать некоторые задачи по программированию в 20 раз быстрее Вас. Но это не значит, что у Вас прямо все плохо. Может, Вы хороший админ, и это компенсирует незнание базы по программированию, почему нет. Может быть, Ваш темп программирования устраивает работодателя, тоже проблем не вижу.
Да сколько угодно таких задач. Морской бой, тетрис, сапер, игра в дурака, вордли, игра "жизнь", змейка, пасьянс. Практически любая - готовый интересный проект для джуна, что-то полегче (тетрис, сапер), что-то посложнее.
Ну, если у вас проблемы при трудоустройстве на любую должность - то и на должность в IT будут такие же проблемы. Это скорее вопрос общественных стереотипов.
Это иногда требует собрать дополнительной инфы для этой checkVeryDifficultCondition, если у сущностей сложные связи. Но так-то да, можно :) P.S. Миша, привет :)))
Ну, если у технического специалиста так, он должен пойти к HR и задать вопросики. И лично отсматривать резюме, и дать указания, кого пропускать, а кого не пропускать. Я работаю в тесной связке с HR, и мы рассылаем входной тест всем, кто кажется нам мало-мальски годным.
Не надо врать. Просто покажите интересный проект (а лучше два) на гитхабе. Который показывает большинство ваших знаний. Не надо сверстанный сайт, не надо куцый todolist. Что-нибудь типа такого надо: https://battleship-loukianen.vercel.app/ Чтобы одно только ТЗ, если его расписать, потянуло на 9 страниц. И чтобы было понятно, где именно там нужен фронтенд, а не сплошной render с версткой и json-ы в 80% кода.
Знаете, сколько резюме с интересными проектами всего на 500 присланных? Два. И оба получили работу.
Из всех остальных техническое интервью прошел 1 человек. И еще двое "мидлов" формально его прошли, но их уровень по деньгам был намного ниже, чем зарплатные ожидания. Делайте выводы.
Во-первых, я полагаю, что мы не знаем, за что конкретно были заплачены эти деньги. Это как с новым (несколько лет назад) логотипом Сбербанка за 2 млн рублей, в котором всего лишь немного подвинули галочку. Ну так дизайнер и получил свои 20к за работу, а остальные деньги ушли на согласование в высоких инстанциях и десятки презентаций - это тоже рабочее время, оно стоит денег, и затрачено его было гораздо больше, чем рабочего времени дизайнера. Не говоря уже о том, что, возможно, по этому договору были оказаны еще какие-нибудь услуги, которые официально провести нельзя (ну, например).
Во-вторых, я вообще полагаю, что идти джуниорам стоит как раз в веб-студии. Просто действительно надо не вляпаться а) в Битрикс (если человек не хочет идти именно этим путем) и б) в то, что половина работы - на Тильде (это тоже нормальный путь, но это не путь веб-разработчика, тем более фронтендера). Скорее я полагаю, что задача человека, ради которой он трудоустраивается в веб-студию, - это много разноплановых задач разной сложности плюс возможность учиться в рабочее время и зарабаывать конкретно программированием, а не другой основной работой, на которую уходит 8 часов в день. И там за 2 года, практически независимо от задач, если человек дополнительно ботает, он проходит всю основную базу js, получает мощную практику - а потом берет хороший курс или учебник по React, и дальше он реально становится уже low-middle специалистом, которого так ищут в больших компаниях. По-моему, это один из самых понятных путей.
А зарплаты в веб-студиях действительно не ахти, но они соответствуют бизнес-ценности решений задач для тех компаний, для которых делаются сайты. Сейчас очень многим сайт уже не нужен, приоритет - страницы в соцсетях, а если сайт есть - больше вкладывают в раскрутку, чем в разработку. Поэтому да, там платят не очень много. Но платят, и не надо работать менеджером по продажам или кем вы там работали раньше. И это отличный бонус.
Я, скорее всего, согласен здесь с популярным соображением о том, что если у человека есть высшее образование, то, значит, у него хватило терпения минимум четыре года делать то, что необходимо для получения диплома, в том числе некоторые совершенно неинтересные вещи. Это демонстрирует, что у него есть какая-никакая дисциплина, усидчивость и умение добиваться непростых целей.
Но лично я считаю, что в подавляющем большинстве случаев для работы, если не учитывать конкретно скиллы программирования, хватает знаний 8-го класса за глаза. И высшее образование необязательно. Хотя высшее программистское, если оно хорошее, дает большую фору, человек много знает алгоритмы, имеет большой опыт кодинга, что-то понимает про серверную часть и ее настройку, в общем, там много всего полезного. У нас на работе таких людей несколько, и они довольно круты.
Плюс еще это может быть связано с обстоятельствами жизненного цикла предприятия. В госкомпаниях, например, грядет переход на профстандарты, а это значит - нужны не просто дипломы, но правильные дипломы.
Наш принцип такой: если вы что-то используете - вы должны понимать, как это работает. Если вам приспичило использовать getElementsByClassName, да еще и с двумя классами - проверьте сигнатуру. Вот прямо погуглите, прямо на собеседовании. Я же этот вопрос задаю не потому, что требую узких знаний, а потому, что вижу говнокод. Использование двух классов в таком месте - плохая практика, любому следующему программисту, читающему ваш код, придется лезть в гугл, чтобы посмотреть, как это работает. Поэтому это должно быть использовано либо сознательно, либо не быть использовано вовсе. Использование getElementsByClassName - тоже плохая практика. А идеальный ответ - писать нормальный querySelectorAll с одним классом - и вопросов не будет.
Про "var a = 3" я бы для начала ответил, что в компании не внедрен линтер, и было бы неплохо его внедрить. А ответили-то Вы что на этот вопрос? Потому что из общих соображений очевидно, что это выведет 3. Ну, представьте себе, что Вы компилятор, где Вы не можете обойтись без точки с запятой между строками, иначе syntax error? В двух местах. Это компилится? Да. Ну и все, ответ готов. Вы можете оказаться и неправы, но, по крайней мере, будет понятна логика.
Ну и еще - не надо ставить себе планку "пройти любое собеседование". Есть куча собеседований, где спрашивают то, что автор вопроса прошел вчера, или какие-то детали, которые знать совершенно необязательно. Нормально на это сказать "я не знаю, я с этим не сталкивался", если предметная область совершенно незнакома, или попробовать изобрести велосипед на месте, если задача плюс-минус понятна. Но если на собеседовании неадекват - ну и зачем вам туда? Компаний хороших много.
Ну, jquery используется для выборки документов, назначения атрибутов, стилей, перезаписи html, отправки ajax, обработки событий. Когда я начинал делать сайты в 2005, обычный javascript требовал разбираться c XMLHttpRequest. Понятно, что по запросу "как отправить данные на сервер" вылезало первым делом $.ajax. Дальше можно было просто прочитать основы документации по библиотеке - и вуаля! Хочешь - целой коллекции элементов стиль присваивай, хочешь - атрибуты меняй, мне даже в голову не приходило, что это не нативный js, я думал, что это просто удобный нативный синтаксический сахар :) так-то цикл или иф я могу написать, тем более, что я сто раз видел их в других языках.
Давайте так: основная претензия к выпускникам курсов - то, что они не знают материал с курсов. Уверен, что на абсолютно любом курсе JavaScript есть querySelector, addEventListener и fetch. И да, от любого выпускника курса я жду, что он знает, чем отличаются
document.querySelector('.btn [data-id]')
и
document.querySelector('.btn[data-id]')
или, например, что document.querySelectorAll возвращает коллекцию, и поэтому
работать не будет. И на курсах это было, 100%. Или, допустим, человек пишет
document.getElementsByClassName('btn btn-buy');
и не знает даже в этот момент, у него эта функция возвращает коллекцию элементов, у которых есть хотя бы один из этих классов или обязательно оба. А потом читатель кода должен будет думать, зачем человек запихнул сюда два класса, если второго было более чем достаточно. А он просто не знает сигнатуру (и брезгует querySelector-ом) и решил, что и так сойдет.
С кандидатами история другая. Мне же надо взять на работу человека, который будет приносить результат. Мне примерно все равно, что он там закончил - школу, вуз, курсы или сам учился. У меня есть повседневные задачи, которые мне нужно, чтобы он умел выполнять. Делает - беру. Не делает - готов взять в обучение, чтобы человек получил нужный ему опыт. Но это не джуниорство и не стажировка, это оплачиваемое обучение, я беру 20 тысяч в месяц - и трачу на человека свое время и силы. И параллельно человек еще допроходит нужное обучение, частично бесплатное, частично платное, я ему помогаю и объясняю, что так, что не так. И у среднего человека, который ко мне приходит, эта история минимум на полгода. И в какой-то момент, если человек вдумчиво решает задачи, задает вопросы, почему это так работает, и понимает ответы на них, - он становится более-менее специалистом, которому уже можно платить деньги за конкретные результаты. И гитхаб у него становится интересный, и резюме улучшается, и на работу его начинают брать. Но 99% приходящих кандидатов уже уверены, что мне есть за что им платить. А это просто не так, мне нужно делать конкретные вещи в конкретные сроки, и они этого не потянут, поэтому сегодняшнее утро опять началось с "извините, мы не можем предложить вам работу" после 20 минут собеседования.
Для авторов курсов - ну, может быть. Но там другие проблемы начинаются. Как продать сложный и длинный курс, после первой части которого вам еще не будет казаться, что вы что-то умеете. Как заставить людей заплатить за годовое обучение и мотивировать их решать задачки. Как сделать, чтобы диплом было получить сложно, но многие доходили до конца обучения. Это сложные задачи, их довольно непросто решить.
Конечно, простую! Идея именно в том, чтобы человек показал, что он умеет пользоваться циклами, длиной строки, читать и сохранять в массив. Всё, больше ничего не надо :) И в принципе все задачи с нашего собеседования решаются этими знаниями плюс DOM, Events, fetch. У нас очень простое собеседование! :)
Про промис и я бы не ответил. Ну, точнее ответил бы, что это и есть конечный элемент. Может быть, конечно, там есть какое-то внутреннее устройство, но я его не знаю, и за время работы мне это никогда не было нужно. У нас вообще подавляющее большинство промисов в работе - это fetch, я могу даже не понимать, что это промис, там then интуитивно понятен. Не знаю, что им нужно было, возможно, действительно какой-нибудь misunderstanding из-за языка.
И еще скажу про универсальность и плоскую заточенность, таких комментов только открытых было два, а от нехабровцев скрытых еще десяток (почему бы это, интересно? :)))
Вообще у нас на работе сейчас все - фуллстек, JS+PHP, уровень не ниже мидла (и, кстати, все работают очень долго, потому что задачи интересные, коллектив классный). И наша задача - найти еще нескольких человек (мы расширяемся), которые бы хотя бы минимально вписались в этот очень мощный коллектив. И за пару лет очень круто прокачались бы. Собственно, именно до того уровня, когда обучение React-у для них станет именно обучением React-у, а не спотыканием на каждом шагу, потому что человек базы не знает. И как раз это в рамках фронтенда я считаю универсальностью - когда человек умеет и в обычный Javascript, и во фреймворк. В идеале ему бы еще неплохо понимать, как на самом деле внутри реакта реализованы (на чистом js, ха-ха) его компоненты, события и т.д. Потому что тогда он гораздо лучше понимает, что делать, если что-то сломалось.
А в этих комментариях людей почему-то считают универсалами от того, что они не умеют решать какую-то задачу. Но универсальность, по-моему, как раз про умение решать всё.
У Вас универсальность - она про другое, Вы действительно просто работаете с многими технологиями, и путаться иногда в синтаксисе - это нормально. Мы не выгоняем с собеседования за ошибки в синтаксисе :) и с докером у меня, например, похожая ситуация на то, что у Вас: я пару лет назад написал по докеру методичку, но сейчас им пользуюсь довольно мало, на днях снова понадобилось - пришлось даже ключ --name загуглить, хотя казалось бы. Но если мне придется собеседоваться на вакансию, где нужен именно докер и я ожидаю, что про него будут спрашивать - я поботаю и обновлю это в своей голове.
Вообще, во многих случаях важно про какие-то вещи скорее знать, что они существуют. Например, когда-то очень давно я не знал про css-свойство transition и пытался реализовывать слайдер путем подбора скорости движения картинки на js в разные моменты, и это был epic fail. Но, конечно, подробности про это свойство я буду гуглить заново, и буду удивлен, если меня спросят знание этого на собеседовании наизусть. И сам спрашивать не буду.
И про велосипеды. Нам в нашей компании нужно не изобретать велосипеды вместо готовых решений, а изобретать решения там, где их еще нет. И это кратно сложнее делать тем, кто не знает, как устроены, собственно, велосипеды :)
Задача про покраску гласных букв применяется, например, в предметной области упражнений по русскому языку. Наверное, в интернет-магазинах она не нужна, но есть очень много предметных областей с довольно причудливыми задачами, и нужно уметь придумывать для них решения.
Я думаю, что джуниор, который умеет работать с DOM, событиями и отправкой сообщений на сервер, может выжить в компании, в которой собственно алгоритмами занимаются другие люди, а программисты только реализуют то, что им сказали. Вполне возможно, что в каких-то больших компаниях это так и работает. У нас как раз небольшая компания, и нам требуется, чтобы программист совмещал эти две функции.
Все ли, кто смог пройти подобные задания, оказались отличными работниками без исключений? Нет (на самом деле, у отличных работников требуемый уровень гораздо выше, это просто супербаза в нашем понимании), но для меня скорее все, кто не смог, не подходят для работы в нашей компании.
При этом смотрите еще. Я читаю Ваши комментарии, Вы умеете мыслить абстрактно, хорошо формулировать. У Вас, скорее всего, и резюме отличное, несколько мест работы с достижениями и понятными результатами. Таких людей я обычно собеседую глубже, потому что мне всегда интересно, какие задачи человек решал на работе - даже если он нам не подходит, может быть, я понимаю, куда ему порекомендовать собеседоваться.
"Джуны", которые приходят к нам на собеседование, - совсем не такие. Они не в состоянии даже сформулировать вопрос, на который они могут ответить. Когда спрашиваешь человека, что он делал последнее на Реакте - он говорит "оптимизировал запросы". Какие запросы, зачем оптимизировал, надо ли их было вообще оптимизировать, в чем был смысл этой задачи - "ну, я уже не помню". Задачи они всегда формулируют очень неконкретно, начинаем обсуждать детали, крайние случаи - они спрашивают "а зачем это?". Я серьезно таких людей должен считать программистами? Нет, моя задача - их отсеять максимально быстро. Поговорить с ними не о чем, гитхаб пустой, решаемые задачи в резюме, даже если есть опыт, совершенно непонятные (и даже они сами их не понимают). С Вами все-таки немного другая ситуация :)
1) Нет, смотрите, тут идея в другом. Когда у нас в задаче простой фильтр, то, конечно, мы используем filter, никакой проблемы нет. Но когда у нас в задаче суровая предметная область, когда фильтруемые значения и условия завязаны на кучу всего, то filter может стать нечитаемым. К примеру: мы фильтруем данные, допустим, по зарплате в каком-то отчете. И нам нужно фильтровать их с учетом того, что они должны быть не меньше, чем аналогичные данные предыдущего годового отчета; зарплата руководителей должна учитываться с коэффициентом 0,8; внештатные сотрудники должны идти со знаком "минус", а еще надо проверять, есть ли на уровень выше ограничение по общей зарплате на отдел. Ну, я довольно невнятно описал задачу, но упаковывание всего этого еще и в filter требует дополнительного напряжения мозга как того, кто его пишет, так и того, кто будет потом читать. А если развернуть filter по определению, то гораздо проще разбивать это на логические части.
Ну и плюс - собственно, когда объясняют filter, его же как раз и объясняют через написание руками. Array.filter(function(elem) { ... }) - это все равно, что
let resultArr = [];
for (let i = 0; i < srcArr.length; i++) {
if (filterFunction(srcArr[i])) {
resultArr[resultArr.length] = srcArr[i];
}
}
Мне кажется, это очень легко. И это я прямо досконально расписал, что происходит с каждым элементом, используя только взятие длины массива, чтение элемента массива и добавление элемента массива в конец. Можно было писать через forEach, push и так далее, мы бы тоже это приняли. И я это не помню, а просто вывожу "на лету" по смыслу той функции, которую мне нужно расписать. Кажется ли это Вам сложным? Или, может быть, просто задача была мной сформулирована непонятно?
2) Мне кажется гораздо более точной такая аналогия: вы учите химию, но принципиально изучаете сразу только молекулы. И у каждой молекулы вы изучаете свойства, как она реагирует с другими, и так далее. И вам приходится запоминать кучу всего про то, как взаимодействует каждая пара молекул. А я задаю вопрос "а можете собрать из атомов?" И когда вы знаете про атомы, а их меньше, чем молекул (чуть более 100 в таблице Менделеева, и в работе чаще всего нужны не все), вам гораздо легче понимать принципы, почему целый класс вот таких молекул взаимодействует с другим классом примерно одинаковым способом. У вас есть способ это понять, язык это описать, и возможность отлаживать на уровне атомов, а не молекул, если это не работает. Потому что очень часто люди, знающие на уровне молекул, но не знающие на уровне атомов, упираются в какую-то проблему и говорят "а мы не знаем, как ее решить". И гугл, внезапно, тоже не знает, как только начинается сколько-нибудь сложная предментая область. А техникой спуска на уровень атомов человек не владеет.
И таким людям, во-первых, гораздо сложнее объяснять какие-то алгоритмы из предметной области, потому что в самых простых местах возникают вопросы, которых у тех, кто давно программирует, обычно никогда не возникает, им это понятно из общей логики.
А во-вторых, им приходится гораздо больше учить вместо того, чтобы понимать. Это многим подходит, но отлаживать при таком подходе - сложнее. Потому что, в отличие от аналогии с двигателем и сцеплением, ВСЕ молекулы состоят из атомов. И это не значит, что не надо использовать молекулы; но скорее значит, что нужно мочь их декомпозировать до атомов.
И пример с промисом очень интересный. Дело в том, что вы не можете декомпозировать промис до базовых функций javascript, это конструкция, которая реализует нечто принципиально новое, что нельзя было реализовать с помощью предыдущих атомов. Поэтому аналогичная задача про promise не имеет смысла.
Вы знаете, это только мое мнение, но я думаю, что реальная зарплата хорошего программиста JS/PHP, даже в Москве - 50-120 тысяч рублей у джуниора, 100-220 у мидла и 180-300 у сеньора (но, конечно, при загрузке 8 часов, не 16). Я собеседовался как-то на вакансию за 300-500, но это была вакансия девопс, в чистом программировании я таких зарплат просто не знаю. 10к$ обычно получают не за скиллы, а за ответственность, руководящую роль и так далее. Хотя скиллов там тоже очень много, конечно, но в бесконечность уходит именно цена рисков и ответственности.
И чистый мидл-фронтендер - это как раз положенное на хорошее знание базы js знание React или Angular. И это довольно спокойно поднимается за 2-3 года. И с этим берут прямо в чистый фронтенд. Но зарплата там будет 150-200к, до 3.000$ Ваших это не дотянет :) Поэтому Вам, скорее всего, и не нужен этот путь.
А если Вы прямо хотите куда-то устроиться, то надо просто брать две недели перед собеседованием и вспоминать конкретно синтаксис всего, что написано в вакансии. Тогда, с Вашими знаниями, шансы на прохождение технического собеседования я бы оценил навскидку в 80%. Но если Вы работаете 16 часов в день, то это очень тяжело сделать. Но, возможно, Вам больше подойдет работа за 150, но 8 часов в день, чем за 220, но 16 часов.
На мой взгляд, примерно какой угодно бэкенд позволяет вам гораздо лучше мочь тестировать ваши проекты, управлять их функциональностью и лучше понимать их изнутри. Node.js довольно непрост, но почему бы и нет.
Что касается всего остального: понимаете, в нашей компании от хорошего программиста, помимо знания собственно языка и базы, требуется еще внимательность и трудолюбие (даже на уровне джуна) и умение выходить на высокий уровень абстракции (для мидла).
И принципиальная разница между typeof и выборкой элементов, обработкой событий и отправкой данных на сервер состоит в том, что последними тремя вещами фронтендер занимается каждый день, 80% своего времени. Поэтому, если у человека есть опыт или хотя бы практика - да, я ожидаю, что он напишет это наизусть с закрытыми глазами. А typeof я использую в практике гораздо реже - и да, конечно, мы разрешаем это погуглить, если надо.
А что касается уровня абстракции - то хороший мидл понимает, какой примерно класс задач с хорошей вероятностью умеет решать человек, если он может вручную написать filter-map-reduce. И эти задачи тоже встречаются в работе если не ежедневно, то еженедельно. И мы этой задачей очень быстро проверяем умение решать задачи именно этого класса. Если человек не понимает, как вручную написать filter - то задачи этого класса он не решит никогда.
>Я так и не смог найти работу где платили бы строго за знания нативного javascript. Когда у вас есть хорошее знание нативного javascript-а и базы, добавить чуть-чуть знаний php, буквально на 4-5 занятий, - и каждая вторая вакансия годится. Да, там платят как джуниору, но человек на этом уровне и есть джуниор. И через пару лет уже дойти до React и идти нормально мидл-фронтенд-разработчиком.
За только знание нативного джаваскрипта действительно нужно поискать (хотя тоже реально), но проблема чуть-чуть добить знания под конкретную приятную вакансию при реальном знании нативного джаваскрипта - на месяц работы. Не на любую, конечно, на соответствующую уровню человека, но это не проблема, это задача. :) И все равно какие-то смежные технологии всегда пригодятся - Websocket там, например.
Мой же текст - он про тот уровень, который нужен, чтобы хоть как-нибудь начать работать на боевых проектах. Конечно, дальше надо продолжать активно учиться, вопрос - как сделать, чтобы вас куда-то взяли, и у вас были деньги на дальнейшее обучение и возможность учиться в рабочее время (хотя бы частично). Если вас уже взяли - окей, у вас свой путь, кто я такой, чтобы его осуждать :)
>Я конечно плохой программист Слушайте, а что Вам мешает стать хорошим программистом? Потому что хороший программист как раз может выбирать задачи. Необязательно между фронтендом и бэкендом, фуллстеком быть, разумеется, лучше. Но я уже 18 лет в веб-программировании (а до этого еще 6 лет в школе, где мне дали суперотличную базу), и всё это время я тоже делаю задачи, за которые платят. И со временем я вышел на задачи, за которые платят очень хорошо. И в процессе этого я а) стал хорошим программистом, б) выработал критерии, какие программисты, по моему мнению, хорошие, а какие - слабые. С ними можно соглашаться или нет, но для меня они многократно проверены опытом и рабочими результатами. Можете рассказать, почему у Вас не получается?
Я за себя, например, могу сказать, что я всегда считал себя неплохим программистом и уже в 2009 мог сделать на сайте практически всё. Но когда меня в 2015 году коллеги нормально научили пользоваться классами и ООП на PHP, а в 2017 году я разобрался в теории javascript, я поразился тому, насколько медленно и неэффективно (хотя все еще хорошо и оплачиваемо) работал раньше. Тогда я был джуном, сейчас - крепкий мидл (у меня есть некоторые сеньорские навыки, но их, на мой взгляд, недостаточно, плюс я сейчас больше занят управленческой работой). И если Вы много лет в программировании, то нет никакой проблемы стать хорошим специалистом.
У нас очень хорошо заходят кандидаты из Хекслета, и довольно плохо - со всех остальных курсов, которые я видел в резюме. Но я, разумеется, видел далеко не все варианты. Про критерии выбора курсов я писал выше в комментариях, поищите по слову Хекслет и найдете.
Но дело не только в программе курса, хотя у них местами есть очень полезные штуки, которых почти ни у кого-то другого нет (линтер, например). Дело в том, что им как-то удается построить обучение так, что студент очень много практикуется. Там два с половиной десятка курсов только по PHP, каждый на 15+ занятий, это тупо много. Плюс когда студент пишет проект, он сначала его пишет полностью до рабочего состояния, а потом ещё шесть раз переписывает по рекомендациям куратора (я сам проходил один проект, переписывание идёт реально почти под ноль, чтобы усвоить некоторые полезные принципы). Если вы можете себе организовать такой объем правильных задач - хоть сами, хоть с ментором, хоть с репетитором, - то вы можете идти на любые курсы, а после них брать два-три месяца на практику. Ну, я, например, понимаю, какие задачи нужно подобрать, как их проверять, как советовать, поэтому веду несколько человек в формате менторства/репетиторства - и я понимаю и подсказываю, когда уже по уровню пора начинать ходить на собеседования, и дальше трудоустройство должно произойти относительно быстро; если надо будет что-то доучить, мы проанализируем с человеком собеседования, я ему дообъясню все, что потребуется. И самое важное, на мой взгляд, что появляется у моих студентов - ощущение, что они реально могут решать боевые задачи. Что простые задачи не вызывают у них проблем на собеседованиях. Что они в восторге от того, что у них получается! Да, на каких-то собеседованиях из могут завалить на сложных задачах или нюансах теории, но они точно будут уверены, что базу они ответили хорошо, и что прикладные задачи они решать умеют. И просто надо пройти несколько собеседований, чтобы получить мэтч - студент нравится компании, компания студенту, и он подходит под ее задачи.
Мне кажется, что самостоятельно это сделать очень трудно. Поэтому я рекомендую либо репетиторство/менторства, либо см. выше. :)
Понимаете, есть несколько причин, по которым мы не берём таких людей.
Во-первых, если крутой мидл получает ну пусть 250 (оценка сверху) и пишет эту задачу в 15 раз быстрее, то такой джун должен получать 250/15 - меньше 20 тысяч в месяц. Не говоря уже о том, что на его обучение тратится в разы больше времени гораздо более дорогих специалистов, которые в это время могли бы что-то написать. И срок, за который мотивированный джун догонит нужный уровень, я оцениваю примерно в полгода. И я полагаю, что за эти полгода платить должен обучаемый, а не обучающий. Ментор в этом случае будет намного дешевле :)
Во-вторых, у нас просто есть опыт приема такого человека на работу. Он продержался полтора месяца, и каждую неделю (!) 1-2 наших программиста подходили ко мне и говорили, что он не тянет, и на нужный уровень не выйдет примерно никогда.
В-третьих, очень важной штукой является мотивация учиться и работать. Мы берём джуна, описанного в статье, и первые полгода ему приходится ботать и вкалывать сильнее, чем было на курсах (просто в рабочее время, а не по вечерам). И если у него нет мотивации вкалывать, чтобы сделать два интересных проекта на гитхабе, - так у него и мотивации пахать на работе не будет. Поэтому и не берём.
А что касается олимпиадного программирования, то никто из тех 15+ человек, которые прошли через нашу фирму за эти годы или работают нам сейчас, никогда им не занимался. Можно без проблем стать сеньором без олимпиадного программирования.
Ну, я на работе имею дело тоже с большим зоопарком. PHP, JS, RabbitMQ, nginx, apache, bash, zabbix, docker, Astra Linux, Rosa Linux. Это не мешает мне уметь проходить собеседования и решать некоторые задачи по программированию в 20 раз быстрее Вас. Но это не значит, что у Вас прямо все плохо. Может, Вы хороший админ, и это компенсирует незнание базы по программированию, почему нет. Может быть, Ваш темп программирования устраивает работодателя, тоже проблем не вижу.
Да сколько угодно таких задач. Морской бой, тетрис, сапер, игра в дурака, вордли, игра "жизнь", змейка, пасьянс. Практически любая - готовый интересный проект для джуна, что-то полегче (тетрис, сапер), что-то посложнее.
Ну, если у вас проблемы при трудоустройстве на любую должность - то и на должность в IT будут такие же проблемы. Это скорее вопрос общественных стереотипов.
Это иногда требует собрать дополнительной инфы для этой checkVeryDifficultCondition, если у сущностей сложные связи. Но так-то да, можно :)
P.S. Миша, привет :)))
Ну, если у технического специалиста так, он должен пойти к HR и задать вопросики. И лично отсматривать резюме, и дать указания, кого пропускать, а кого не пропускать. Я работаю в тесной связке с HR, и мы рассылаем входной тест всем, кто кажется нам мало-мальски годным.
Не надо врать. Просто покажите интересный проект (а лучше два) на гитхабе. Который показывает большинство ваших знаний. Не надо сверстанный сайт, не надо куцый todolist. Что-нибудь типа такого надо: https://battleship-loukianen.vercel.app/ Чтобы одно только ТЗ, если его расписать, потянуло на 9 страниц. И чтобы было понятно, где именно там нужен фронтенд, а не сплошной render с версткой и json-ы в 80% кода.
Знаете, сколько резюме с интересными проектами всего на 500 присланных? Два. И оба получили работу.
Из всех остальных техническое интервью прошел 1 человек. И еще двое "мидлов" формально его прошли, но их уровень по деньгам был намного ниже, чем зарплатные ожидания. Делайте выводы.
Слушайте, а в чем проблема?
Во-первых, я полагаю, что мы не знаем, за что конкретно были заплачены эти деньги. Это как с новым (несколько лет назад) логотипом Сбербанка за 2 млн рублей, в котором всего лишь немного подвинули галочку. Ну так дизайнер и получил свои 20к за работу, а остальные деньги ушли на согласование в высоких инстанциях и десятки презентаций - это тоже рабочее время, оно стоит денег, и затрачено его было гораздо больше, чем рабочего времени дизайнера. Не говоря уже о том, что, возможно, по этому договору были оказаны еще какие-нибудь услуги, которые официально провести нельзя (ну, например).
Во-вторых, я вообще полагаю, что идти джуниорам стоит как раз в веб-студии. Просто действительно надо не вляпаться а) в Битрикс (если человек не хочет идти именно этим путем) и б) в то, что половина работы - на Тильде (это тоже нормальный путь, но это не путь веб-разработчика, тем более фронтендера). Скорее я полагаю, что задача человека, ради которой он трудоустраивается в веб-студию, - это много разноплановых задач разной сложности плюс возможность учиться в рабочее время и зарабаывать конкретно программированием, а не другой основной работой, на которую уходит 8 часов в день. И там за 2 года, практически независимо от задач, если человек дополнительно ботает, он проходит всю основную базу js, получает мощную практику - а потом берет хороший курс или учебник по React, и дальше он реально становится уже low-middle специалистом, которого так ищут в больших компаниях. По-моему, это один из самых понятных путей.
А зарплаты в веб-студиях действительно не ахти, но они соответствуют бизнес-ценности решений задач для тех компаний, для которых делаются сайты. Сейчас очень многим сайт уже не нужен, приоритет - страницы в соцсетях, а если сайт есть - больше вкладывают в раскрутку, чем в разработку. Поэтому да, там платят не очень много. Но платят, и не надо работать менеджером по продажам или кем вы там работали раньше. И это отличный бонус.
Я, скорее всего, согласен здесь с популярным соображением о том, что если у человека есть высшее образование, то, значит, у него хватило терпения минимум четыре года делать то, что необходимо для получения диплома, в том числе некоторые совершенно неинтересные вещи. Это демонстрирует, что у него есть какая-никакая дисциплина, усидчивость и умение добиваться непростых целей.
Но лично я считаю, что в подавляющем большинстве случаев для работы, если не учитывать конкретно скиллы программирования, хватает знаний 8-го класса за глаза. И высшее образование необязательно. Хотя высшее программистское, если оно хорошее, дает большую фору, человек много знает алгоритмы, имеет большой опыт кодинга, что-то понимает про серверную часть и ее настройку, в общем, там много всего полезного. У нас на работе таких людей несколько, и они довольно круты.
Плюс еще это может быть связано с обстоятельствами жизненного цикла предприятия. В госкомпаниях, например, грядет переход на профстандарты, а это значит - нужны не просто дипломы, но правильные дипломы.
Да нет, Вы не улавливаете наш принцип :)
Наш принцип такой: если вы что-то используете - вы должны понимать, как это работает. Если вам приспичило использовать getElementsByClassName, да еще и с двумя классами - проверьте сигнатуру. Вот прямо погуглите, прямо на собеседовании. Я же этот вопрос задаю не потому, что требую узких знаний, а потому, что вижу говнокод. Использование двух классов в таком месте - плохая практика, любому следующему программисту, читающему ваш код, придется лезть в гугл, чтобы посмотреть, как это работает. Поэтому это должно быть использовано либо сознательно, либо не быть использовано вовсе. Использование getElementsByClassName - тоже плохая практика. А идеальный ответ - писать нормальный querySelectorAll с одним классом - и вопросов не будет.
Про "var a = 3" я бы для начала ответил, что в компании не внедрен линтер, и было бы неплохо его внедрить. А ответили-то Вы что на этот вопрос? Потому что из общих соображений очевидно, что это выведет 3. Ну, представьте себе, что Вы компилятор, где Вы не можете обойтись без точки с запятой между строками, иначе syntax error? В двух местах. Это компилится? Да. Ну и все, ответ готов. Вы можете оказаться и неправы, но, по крайней мере, будет понятна логика.
Ну и еще - не надо ставить себе планку "пройти любое собеседование". Есть куча собеседований, где спрашивают то, что автор вопроса прошел вчера, или какие-то детали, которые знать совершенно необязательно. Нормально на это сказать "я не знаю, я с этим не сталкивался", если предметная область совершенно незнакома, или попробовать изобрести велосипед на месте, если задача плюс-минус понятна. Но если на собеседовании неадекват - ну и зачем вам туда? Компаний хороших много.
Ну, jquery используется для выборки документов, назначения атрибутов, стилей, перезаписи html, отправки ajax, обработки событий. Когда я начинал делать сайты в 2005, обычный javascript требовал разбираться c XMLHttpRequest. Понятно, что по запросу "как отправить данные на сервер" вылезало первым делом $.ajax. Дальше можно было просто прочитать основы документации по библиотеке - и вуаля! Хочешь - целой коллекции элементов стиль присваивай, хочешь - атрибуты меняй, мне даже в голову не приходило, что это не нативный js, я думал, что это просто удобный нативный синтаксический сахар :) так-то цикл или иф я могу написать, тем более, что я сто раз видел их в других языках.
Под JS я понимаю просто JavaScript.
Давайте так: основная претензия к выпускникам курсов - то, что они не знают материал с курсов. Уверен, что на абсолютно любом курсе JavaScript есть querySelector, addEventListener и fetch. И да, от любого выпускника курса я жду, что он знает, чем отличаются
или, например, что document.querySelectorAll возвращает коллекцию, и поэтому
работать не будет. И на курсах это было, 100%. Или, допустим, человек пишет
и не знает даже в этот момент, у него эта функция возвращает коллекцию элементов, у которых есть хотя бы один из этих классов или обязательно оба. А потом читатель кода должен будет думать, зачем человек запихнул сюда два класса, если второго было более чем достаточно. А он просто не знает сигнатуру (и брезгует querySelector-ом) и решил, что и так сойдет.
С кандидатами история другая. Мне же надо взять на работу человека, который будет приносить результат. Мне примерно все равно, что он там закончил - школу, вуз, курсы или сам учился. У меня есть повседневные задачи, которые мне нужно, чтобы он умел выполнять. Делает - беру. Не делает - готов взять в обучение, чтобы человек получил нужный ему опыт. Но это не джуниорство и не стажировка, это оплачиваемое обучение, я беру 20 тысяч в месяц - и трачу на человека свое время и силы. И параллельно человек еще допроходит нужное обучение, частично бесплатное, частично платное, я ему помогаю и объясняю, что так, что не так. И у среднего человека, который ко мне приходит, эта история минимум на полгода. И в какой-то момент, если человек вдумчиво решает задачи, задает вопросы, почему это так работает, и понимает ответы на них, - он становится более-менее специалистом, которому уже можно платить деньги за конкретные результаты. И гитхаб у него становится интересный, и резюме улучшается, и на работу его начинают брать. Но 99% приходящих кандидатов уже уверены, что мне есть за что им платить. А это просто не так, мне нужно делать конкретные вещи в конкретные сроки, и они этого не потянут, поэтому сегодняшнее утро опять началось с "извините, мы не можем предложить вам работу" после 20 минут собеседования.
Для авторов курсов - ну, может быть. Но там другие проблемы начинаются. Как продать сложный и длинный курс, после первой части которого вам еще не будет казаться, что вы что-то умеете. Как заставить людей заплатить за годовое обучение и мотивировать их решать задачки. Как сделать, чтобы диплом было получить сложно, но многие доходили до конца обучения. Это сложные задачи, их довольно непросто решить.
Конечно, простую! Идея именно в том, чтобы человек показал, что он умеет пользоваться циклами, длиной строки, читать и сохранять в массив. Всё, больше ничего не надо :) И в принципе все задачи с нашего собеседования решаются этими знаниями плюс DOM, Events, fetch. У нас очень простое собеседование! :)
Про промис и я бы не ответил. Ну, точнее ответил бы, что это и есть конечный элемент. Может быть, конечно, там есть какое-то внутреннее устройство, но я его не знаю, и за время работы мне это никогда не было нужно. У нас вообще подавляющее большинство промисов в работе - это fetch, я могу даже не понимать, что это промис, там then интуитивно понятен. Не знаю, что им нужно было, возможно, действительно какой-нибудь misunderstanding из-за языка.
И еще скажу про универсальность и плоскую заточенность, таких комментов только открытых было два, а от нехабровцев скрытых еще десяток (почему бы это, интересно? :)))
Вообще у нас на работе сейчас все - фуллстек, JS+PHP, уровень не ниже мидла (и, кстати, все работают очень долго, потому что задачи интересные, коллектив классный). И наша задача - найти еще нескольких человек (мы расширяемся), которые бы хотя бы минимально вписались в этот очень мощный коллектив. И за пару лет очень круто прокачались бы. Собственно, именно до того уровня, когда обучение React-у для них станет именно обучением React-у, а не спотыканием на каждом шагу, потому что человек базы не знает. И как раз это в рамках фронтенда я считаю универсальностью - когда человек умеет и в обычный Javascript, и во фреймворк. В идеале ему бы еще неплохо понимать, как на самом деле внутри реакта реализованы (на чистом js, ха-ха) его компоненты, события и т.д. Потому что тогда он гораздо лучше понимает, что делать, если что-то сломалось.
А в этих комментариях людей почему-то считают универсалами от того, что они не умеют решать какую-то задачу. Но универсальность, по-моему, как раз про умение решать всё.
У Вас универсальность - она про другое, Вы действительно просто работаете с многими технологиями, и путаться иногда в синтаксисе - это нормально. Мы не выгоняем с собеседования за ошибки в синтаксисе :) и с докером у меня, например, похожая ситуация на то, что у Вас: я пару лет назад написал по докеру методичку, но сейчас им пользуюсь довольно мало, на днях снова понадобилось - пришлось даже ключ --name загуглить, хотя казалось бы. Но если мне придется собеседоваться на вакансию, где нужен именно докер и я ожидаю, что про него будут спрашивать - я поботаю и обновлю это в своей голове.
Вообще, во многих случаях важно про какие-то вещи скорее знать, что они существуют. Например, когда-то очень давно я не знал про css-свойство transition и пытался реализовывать слайдер путем подбора скорости движения картинки на js в разные моменты, и это был epic fail. Но, конечно, подробности про это свойство я буду гуглить заново, и буду удивлен, если меня спросят знание этого на собеседовании наизусть. И сам спрашивать не буду.
И про велосипеды. Нам в нашей компании нужно не изобретать велосипеды вместо готовых решений, а изобретать решения там, где их еще нет. И это кратно сложнее делать тем, кто не знает, как устроены, собственно, велосипеды :)
Задача про покраску гласных букв применяется, например, в предметной области упражнений по русскому языку. Наверное, в интернет-магазинах она не нужна, но есть очень много предметных областей с довольно причудливыми задачами, и нужно уметь придумывать для них решения.
Я думаю, что джуниор, который умеет работать с DOM, событиями и отправкой сообщений на сервер, может выжить в компании, в которой собственно алгоритмами занимаются другие люди, а программисты только реализуют то, что им сказали. Вполне возможно, что в каких-то больших компаниях это так и работает. У нас как раз небольшая компания, и нам требуется, чтобы программист совмещал эти две функции.
Все ли, кто смог пройти подобные задания, оказались отличными работниками без исключений? Нет (на самом деле, у отличных работников требуемый уровень гораздо выше, это просто супербаза в нашем понимании), но для меня скорее все, кто не смог, не подходят для работы в нашей компании.
При этом смотрите еще. Я читаю Ваши комментарии, Вы умеете мыслить абстрактно, хорошо формулировать. У Вас, скорее всего, и резюме отличное, несколько мест работы с достижениями и понятными результатами. Таких людей я обычно собеседую глубже, потому что мне всегда интересно, какие задачи человек решал на работе - даже если он нам не подходит, может быть, я понимаю, куда ему порекомендовать собеседоваться.
"Джуны", которые приходят к нам на собеседование, - совсем не такие. Они не в состоянии даже сформулировать вопрос, на который они могут ответить. Когда спрашиваешь человека, что он делал последнее на Реакте - он говорит "оптимизировал запросы". Какие запросы, зачем оптимизировал, надо ли их было вообще оптимизировать, в чем был смысл этой задачи - "ну, я уже не помню". Задачи они всегда формулируют очень неконкретно, начинаем обсуждать детали, крайние случаи - они спрашивают "а зачем это?". Я серьезно таких людей должен считать программистами? Нет, моя задача - их отсеять максимально быстро. Поговорить с ними не о чем, гитхаб пустой, решаемые задачи в резюме, даже если есть опыт, совершенно непонятные (и даже они сами их не понимают). С Вами все-таки немного другая ситуация :)
Отвечаю :)
1) Нет, смотрите, тут идея в другом. Когда у нас в задаче простой фильтр, то, конечно, мы используем filter, никакой проблемы нет. Но когда у нас в задаче суровая предметная область, когда фильтруемые значения и условия завязаны на кучу всего, то filter может стать нечитаемым. К примеру: мы фильтруем данные, допустим, по зарплате в каком-то отчете. И нам нужно фильтровать их с учетом того, что они должны быть не меньше, чем аналогичные данные предыдущего годового отчета; зарплата руководителей должна учитываться с коэффициентом 0,8; внештатные сотрудники должны идти со знаком "минус", а еще надо проверять, есть ли на уровень выше ограничение по общей зарплате на отдел. Ну, я довольно невнятно описал задачу, но упаковывание всего этого еще и в filter требует дополнительного напряжения мозга как того, кто его пишет, так и того, кто будет потом читать. А если развернуть filter по определению, то гораздо проще разбивать это на логические части.
Ну и плюс - собственно, когда объясняют filter, его же как раз и объясняют через написание руками. Array.filter(function(elem) { ... }) - это все равно, что
Мне кажется, это очень легко. И это я прямо досконально расписал, что происходит с каждым элементом, используя только взятие длины массива, чтение элемента массива и добавление элемента массива в конец. Можно было писать через forEach, push и так далее, мы бы тоже это приняли. И я это не помню, а просто вывожу "на лету" по смыслу той функции, которую мне нужно расписать. Кажется ли это Вам сложным? Или, может быть, просто задача была мной сформулирована непонятно?
2) Мне кажется гораздо более точной такая аналогия: вы учите химию, но принципиально изучаете сразу только молекулы. И у каждой молекулы вы изучаете свойства, как она реагирует с другими, и так далее. И вам приходится запоминать кучу всего про то, как взаимодействует каждая пара молекул. А я задаю вопрос "а можете собрать из атомов?" И когда вы знаете про атомы, а их меньше, чем молекул (чуть более 100 в таблице Менделеева, и в работе чаще всего нужны не все), вам гораздо легче понимать принципы, почему целый класс вот таких молекул взаимодействует с другим классом примерно одинаковым способом. У вас есть способ это понять, язык это описать, и возможность отлаживать на уровне атомов, а не молекул, если это не работает. Потому что очень часто люди, знающие на уровне молекул, но не знающие на уровне атомов, упираются в какую-то проблему и говорят "а мы не знаем, как ее решить". И гугл, внезапно, тоже не знает, как только начинается сколько-нибудь сложная предментая область. А техникой спуска на уровень атомов человек не владеет.
И таким людям, во-первых, гораздо сложнее объяснять какие-то алгоритмы из предметной области, потому что в самых простых местах возникают вопросы, которых у тех, кто давно программирует, обычно никогда не возникает, им это понятно из общей логики.
А во-вторых, им приходится гораздо больше учить вместо того, чтобы понимать. Это многим подходит, но отлаживать при таком подходе - сложнее. Потому что, в отличие от аналогии с двигателем и сцеплением, ВСЕ молекулы состоят из атомов. И это не значит, что не надо использовать молекулы; но скорее значит, что нужно мочь их декомпозировать до атомов.
И пример с промисом очень интересный. Дело в том, что вы не можете декомпозировать промис до базовых функций javascript, это конструкция, которая реализует нечто принципиально новое, что нельзя было реализовать с помощью предыдущих атомов. Поэтому аналогичная задача про promise не имеет смысла.
Окончание отдельным комментарием :)
Вы знаете, это только мое мнение, но я думаю, что реальная зарплата хорошего программиста JS/PHP, даже в Москве - 50-120 тысяч рублей у джуниора, 100-220 у мидла и 180-300 у сеньора (но, конечно, при загрузке 8 часов, не 16). Я собеседовался как-то на вакансию за 300-500, но это была вакансия девопс, в чистом программировании я таких зарплат просто не знаю. 10к$ обычно получают не за скиллы, а за ответственность, руководящую роль и так далее. Хотя скиллов там тоже очень много, конечно, но в бесконечность уходит именно цена рисков и ответственности.
И чистый мидл-фронтендер - это как раз положенное на хорошее знание базы js знание React или Angular. И это довольно спокойно поднимается за 2-3 года. И с этим берут прямо в чистый фронтенд. Но зарплата там будет 150-200к, до 3.000$ Ваших это не дотянет :) Поэтому Вам, скорее всего, и не нужен этот путь.
А если Вы прямо хотите куда-то устроиться, то надо просто брать две недели перед собеседованием и вспоминать конкретно синтаксис всего, что написано в вакансии. Тогда, с Вашими знаниями, шансы на прохождение технического собеседования я бы оценил навскидку в 80%. Но если Вы работаете 16 часов в день, то это очень тяжело сделать. Но, возможно, Вам больше подойдет работа за 150, но 8 часов в день, чем за 220, но 16 часов.
На мой взгляд, примерно какой угодно бэкенд позволяет вам гораздо лучше мочь тестировать ваши проекты, управлять их функциональностью и лучше понимать их изнутри. Node.js довольно непрост, но почему бы и нет.
Что касается всего остального: понимаете, в нашей компании от хорошего программиста, помимо знания собственно языка и базы, требуется еще внимательность и трудолюбие (даже на уровне джуна) и умение выходить на высокий уровень абстракции (для мидла).
И принципиальная разница между typeof и выборкой элементов, обработкой событий и отправкой данных на сервер состоит в том, что последними тремя вещами фронтендер занимается каждый день, 80% своего времени. Поэтому, если у человека есть опыт или хотя бы практика - да, я ожидаю, что он напишет это наизусть с закрытыми глазами. А typeof я использую в практике гораздо реже - и да, конечно, мы разрешаем это погуглить, если надо.
А что касается уровня абстракции - то хороший мидл понимает, какой примерно класс задач с хорошей вероятностью умеет решать человек, если он может вручную написать filter-map-reduce. И эти задачи тоже встречаются в работе если не ежедневно, то еженедельно. И мы этой задачей очень быстро проверяем умение решать задачи именно этого класса. Если человек не понимает, как вручную написать filter - то задачи этого класса он не решит никогда.
>Я так и не смог найти работу где платили бы строго за знания нативного javascript.
Когда у вас есть хорошее знание нативного javascript-а и базы, добавить чуть-чуть знаний php, буквально на 4-5 занятий, - и каждая вторая вакансия годится. Да, там платят как джуниору, но человек на этом уровне и есть джуниор. И через пару лет уже дойти до React и идти нормально мидл-фронтенд-разработчиком.
За только знание нативного джаваскрипта действительно нужно поискать (хотя тоже реально), но проблема чуть-чуть добить знания под конкретную приятную вакансию при реальном знании нативного джаваскрипта - на месяц работы. Не на любую, конечно, на соответствующую уровню человека, но это не проблема, это задача. :) И все равно какие-то смежные технологии всегда пригодятся - Websocket там, например.
Мой же текст - он про тот уровень, который нужен, чтобы хоть как-нибудь начать работать на боевых проектах. Конечно, дальше надо продолжать активно учиться, вопрос - как сделать, чтобы вас куда-то взяли, и у вас были деньги на дальнейшее обучение и возможность учиться в рабочее время (хотя бы частично). Если вас уже взяли - окей, у вас свой путь, кто я такой, чтобы его осуждать :)
>Я конечно плохой программист
Слушайте, а что Вам мешает стать хорошим программистом? Потому что хороший программист как раз может выбирать задачи. Необязательно между фронтендом и бэкендом, фуллстеком быть, разумеется, лучше. Но я уже 18 лет в веб-программировании (а до этого еще 6 лет в школе, где мне дали суперотличную базу), и всё это время я тоже делаю задачи, за которые платят. И со временем я вышел на задачи, за которые платят очень хорошо. И в процессе этого я а) стал хорошим программистом, б) выработал критерии, какие программисты, по моему мнению, хорошие, а какие - слабые. С ними можно соглашаться или нет, но для меня они многократно проверены опытом и рабочими результатами. Можете рассказать, почему у Вас не получается?
Я за себя, например, могу сказать, что я всегда считал себя неплохим программистом и уже в 2009 мог сделать на сайте практически всё. Но когда меня в 2015 году коллеги нормально научили пользоваться классами и ООП на PHP, а в 2017 году я разобрался в теории javascript, я поразился тому, насколько медленно и неэффективно (хотя все еще хорошо и оплачиваемо) работал раньше. Тогда я был джуном, сейчас - крепкий мидл (у меня есть некоторые сеньорские навыки, но их, на мой взгляд, недостаточно, плюс я сейчас больше занят управленческой работой). И если Вы много лет в программировании, то нет никакой проблемы стать хорошим специалистом.
У нас очень хорошо заходят кандидаты из Хекслета, и довольно плохо - со всех остальных курсов, которые я видел в резюме. Но я, разумеется, видел далеко не все варианты. Про критерии выбора курсов я писал выше в комментариях, поищите по слову Хекслет и найдете.
Но дело не только в программе курса, хотя у них местами есть очень полезные штуки, которых почти ни у кого-то другого нет (линтер, например). Дело в том, что им как-то удается построить обучение так, что студент очень много практикуется. Там два с половиной десятка курсов только по PHP, каждый на 15+ занятий, это тупо много. Плюс когда студент пишет проект, он сначала его пишет полностью до рабочего состояния, а потом ещё шесть раз переписывает по рекомендациям куратора (я сам проходил один проект, переписывание идёт реально почти под ноль, чтобы усвоить некоторые полезные принципы). Если вы можете себе организовать такой объем правильных задач - хоть сами, хоть с ментором, хоть с репетитором, - то вы можете идти на любые курсы, а после них брать два-три месяца на практику. Ну, я, например, понимаю, какие задачи нужно подобрать, как их проверять, как советовать, поэтому веду несколько человек в формате менторства/репетиторства - и я понимаю и подсказываю, когда уже по уровню пора начинать ходить на собеседования, и дальше трудоустройство должно произойти относительно быстро; если надо будет что-то доучить, мы проанализируем с человеком собеседования, я ему дообъясню все, что потребуется. И самое важное, на мой взгляд, что появляется у моих студентов - ощущение, что они реально могут решать боевые задачи. Что простые задачи не вызывают у них проблем на собеседованиях. Что они в восторге от того, что у них получается! Да, на каких-то собеседованиях из могут завалить на сложных задачах или нюансах теории, но они точно будут уверены, что базу они ответили хорошо, и что прикладные задачи они решать умеют. И просто надо пройти несколько собеседований, чтобы получить мэтч - студент нравится компании, компания студенту, и он подходит под ее задачи.
Мне кажется, что самостоятельно это сделать очень трудно. Поэтому я рекомендую либо репетиторство/менторства, либо см. выше. :)
Понимаете, есть несколько причин, по которым мы не берём таких людей.
Во-первых, если крутой мидл получает ну пусть 250 (оценка сверху) и пишет эту задачу в 15 раз быстрее, то такой джун должен получать 250/15 - меньше 20 тысяч в месяц. Не говоря уже о том, что на его обучение тратится в разы больше времени гораздо более дорогих специалистов, которые в это время могли бы что-то написать. И срок, за который мотивированный джун догонит нужный уровень, я оцениваю примерно в полгода. И я полагаю, что за эти полгода платить должен обучаемый, а не обучающий. Ментор в этом случае будет намного дешевле :)
Во-вторых, у нас просто есть опыт приема такого человека на работу. Он продержался полтора месяца, и каждую неделю (!) 1-2 наших программиста подходили ко мне и говорили, что он не тянет, и на нужный уровень не выйдет примерно никогда.
В-третьих, очень важной штукой является мотивация учиться и работать. Мы берём джуна, описанного в статье, и первые полгода ему приходится ботать и вкалывать сильнее, чем было на курсах (просто в рабочее время, а не по вечерам). И если у него нет мотивации вкалывать, чтобы сделать два интересных проекта на гитхабе, - так у него и мотивации пахать на работе не будет. Поэтому и не берём.
А что касается олимпиадного программирования, то никто из тех 15+ человек, которые прошли через нашу фирму за эти годы или работают нам сейчас, никогда им не занимался. Можно без проблем стать сеньором без олимпиадного программирования.