От джуна до ведущего инженера в 33 года без высшего образования в IT
2026-02-26 20:05 Diff
https://ru.hexlet.io/blog/posts/ot-dzhuna-do-veduschego-inzhenera-v-33-bez-vysshego-obrazovaniya-v-it

Всем привет! Расскажу, как я в 33 стал программистом.

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

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

Содержание

Языки программирования

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

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

С++. Вот тут уже я начал с самых-самых основ – базовый синтаксис, циклы, простые алгоритмы, алгоритмы посложнее, чтение книг – «Объектно-ориентированное программирование в С++» Лафоре и другие, бесплатные обучающие программы на платформах Степик и Интуит. Но практически сразу пришло понимание, что этот язык не подходит для поиска первой работы.

JavaScript. Эх, если бы я начал с него сразу – идеально структурированный учебный материал на learn.javascript.ru, возможность сразу видеть результат в браузере, простота языка, а самое главное – пришло понимание, что требуется от начинающего стажера/джуниора в вакансиях - все это сошлось и буквально через полгода я опубликовал резюме и стал ходить по собеседованиям.

До моего первого трудоустройства оставалось полгода. Основная сложность, с которой я столкнулся: первый этап собеседования обычно проходил нормально, задавались задачи из серии «что такое замыкание», проверить на палиндром строку, а далее давалось тестовое задание, где нужно было сделать приложение с MVC, и это ставило меня в тупик. После пары таких тестовых заданий, когда уже проходили все разумные сроки для отправления работы, знакомый порекомендовал Хекслет и рассказал, как он делает первый проект из профессии Фронтенд.

В общем, все, что было до этого – стало казаться детским садом, а фразу «где же был Хекслет раньше» я мог повторять по несколько раз в день. Было сложно, но я решил все задачи до первого проекта (нужно сказать, что сейчас программа первого модуля сильно упростилась, по сравнению с той, которую проходил я, а на прохождение проекта давалась ровно 1 неделя и ни секунды больше), приступил ко второму модулю.

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

Собеседование в «Учи.ру» на JS-разработчика

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

В компании я проработал примерно год, начал джуном, увольнялся ведущим программистом. Основные задачи, с которыми мне приходилось сталкиваться, решались по большей части описанием поведения (последовательность действий) на чистом JS в функциональном стиле, использовался ES6/ES7, jQuery, Lodash, стили - SCSS, немного верстки и работа с SVG и Canvas, совсем немного UI/UX.

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

Читайте также

Лучшие книги для начинающих программистов по версии наставников Хекслета

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

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

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

Итоги

Для тех, кто только учится

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

Для тех, кто только что вышел на первую работу

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