Про образование
Как и многие заинтересованные в профессии программиста люди, я с детства увлекался различного рода деятельностью с ЭВМ: сборка компьютеров, программирование на Basic’e для решения задач по математике, верстка сайтов в Microsoft Frontpage, игры в БД и каталогизирование с Microsoft Access и т.д. Таким образом, выбор специальности был предопределен - Вычислительная техника и информатика. Поступление в ВУЗ осуществилось, в дополнению к курсу Pascal был куплен томик ANSI C Кернигана и Ритчи. И дальше случилась жизнь.
Про работу
В начале второго курса пришлось срочно искать работу, за которую платили бы больше 15 000 (2010 г.). После какого-то времени череда случайностей и моих решений привела меня в продажи. За последующие 7 лет я побывал в разных сферах торговли - от розницы до корпоративных продаж. По большому счету единственной задачей для продавцов всегда остается "найти кого-то, у кого есть деньги и сделать так, чтобы он с ними расстался". Желательно законно. Для некоторых компаний решение проблем клиента было второстепенным, для остальных - в десятую очередь.
Все время меня в той или иной мере не отпускало ощущение, что я не делаю ничего полезного, а в течение последних пары лет тлела мысль, что хорошо бы разогнать мозги и «когда-нибудь» вернуться в разработку. Соломинкой для спины верблюда стала идея помочь другу с сайтом, работу по которому запарывает фрилансер. И понеслось. Цель - стать программистом.
Вдруг вспомнилось, что сайт и сервис это две большие разницы. Оказалось, что сейчас большинство решений построено на таких страшных и непонятных вещах как Bootstrap, CDN, React, Angular, Flux/Redux, NodeJS, RESTfull, SOAP. Кажется, в самом начале изучения тематики, мне попалась та самая статья. Но я еще слабо понимал во что вляпываюсь...
Обучение
Было потрачено какое-то количество (к счастью не очень большое) времени для поиска методов и ресурсов для обучения. К счастью, в одном из топиков на Тостере мне попался ответ какого-то чувака с ссылкой на Hexlet. Этим
чуваком был Дэвид Стетхэм со-основатель сервиса Кирилл Мокевнин.
Hexlet здорово приземляет и в отношении оценки своих сил, и в отношении реалий будущей работы. Чудес не происходит на обучении и дальше они вряд ли появятся. Вы не создадите пресловутый «клон фейсбука», под инструкции из видеокурса. Собственно, вряд ли вы вообще доберетесь до конца курса по фронтенду/бэкенду. Спустя полгода от начала обучения я все еще этого не сделал.
Но.
В процессе обучения, команда Hexlet дает кое-что гораздо более ценное, чем пачка типовых лендингов и ToDo/Phonebook приложений. Она дает осознание, что всё не так просто, как заявляют иные рекламирующие самообучение проекты. Недостаточно выучить методы работы с популярными инструментами, чтобы на самом деле уметь ими пользоваться, а уж тем более этого недостаточно, чтобы понимать, когда их следует применять, а когда лучше подумать о другом подходе. Даже в ограниченной предметной области набор огромен, что уж говорить про всю индустрию. Вы никогда не сможете знать все инструменты, но стоит попытаться отнестись к ним именно как к средству выполнения задачи.
Наверное самое мое яркое впечатление было от первого проекта. Цитата из моего же отзыва «Еще никогда я столько раз подряд не ощущал себя обезьяной с гранатой». Та неделя буквально перевернул мое представление о разработке с ног на голову.
Собеседования
Бесспорно Hexlet дает не только курсы. Тут присутствует обширное сообщество в Telegram, ведется блог и записываются подкасты. Моему трудоустройству очень способствовали статья и позиция, которую часто высказывает Кирилл:
Если вы прошли курс Основы программирования, вы уже готовы ходить на собеседования
Это не значит, что после курса вас возьмут, но ходить вы точно сможете :) Вы сможете понять какие вещи действительно стоит учить, чего от вас ждут и, что очень важно, чего ждать вам.
Сам по себе процесс поиска вакансий и отправка запроса не являются ничем сверхъестественным. В блоге Hexlet есть чудесные статьи о составлении резюме и важности сопроводительного письма. В Slack на канале собеседований всегда дадут советы и отклики о вашем творении.
От себя рекомендую всегда в сопроводительном письме запрашивать тестовое задание, иначе можно попасть в ситуацию, когда HR, дабы выполнить план, сообщает общую информацию, приглашает вас на собеседование с собой, затем на собеседование с тех. специалистом, а потом оказывается, что компании нужен junior с опытом работы в несколько лет.
Представьте, что в ваше резюме не вникают, если вообще читают. Или не верят. Будьте готовы отвечать на очевидные вопросы о своей квалификации.
Почему я написал, что важно понимать, чего вам ждать от собеседований? Речь не о вопросах и заданиях, которые вам там будут давать - к этому можно подготовиться, речь о вещах, которые могут показаться обескураживающими людям работающим в "белых" компаниях и компаниях с поставленными бизнеспроцессами.
Пример 1.
JavaScript Backend. Некая телемедиарадио компания.
1 этап.
- Формат: удаленное подключение интервьювера с наблюдением за экраном.
- Задача: решить случайное задание с англоязычнго сайта-сборника математических задач (про НОД, НОК и прочие последовательности с делителями)
- Прохождение: писать код в любой онлайн среде (я использовал repl.it). Из информации - чтение вики, но не гугление решения.
2 этап.
- Формат: собеседование в офисе, за чьим-то рабочим местом.
- Задача: решить несколько задач формата "построить n строк треугольника Паскаля", "как нибудь хитро отсортировать такой-то массив".
- Прохождение: писать код в любой онлайн среде, запрет на использование бумаги.
3 этап.
- Формат: собеседование в офисе с руководителем отдела.
- Задача: дать комментарии по выбранному участку кода из твоего github-репозитория.
- Прохождение: мне пришлось ответить на вопрос "зачем нужны уши в строке
Property '${name}' was ${action}${addInformation}
". После чего я узнал, что на самом деле лучше бы работать на удаленке, а не в офисе. И оплата почасовая. Ну и "можно еще ради бумажки что-то подписать", а пока нужно ждатьу моря погодыпока мне не расшарят местный git-репозиторий, для первого тикета.
Итог: через пару дней перестали отвечать.
Пример 2.
PHP everywhere. Некое агенство-конвеер по выпуску сайтов.
- Формат - собеседование в рабочем пространстве в офисе, за столом без компьютера.
- Задача - написать на бумаге валидный код, решающий задачи. Задачи разные, от рефакторинга чьего то кода, до построения схемы БД, записи SQL-запросов и реализации прикладных вопросов вроде работы с jQuery и рекурсивного обхода дерева каталогов с какой то целью(счет, правка по условию).
- Прохождение - узнать, что интервьювер уехал, попросить найти замену. В процессе беседы получить просьбу переписать часть задач без использования рекурсии, потому что "мы так не делаем, это непонятно". Получить просьбу подождать пару недель и самостоятельно набрать, если про меня забудут.
Итог: про меня забыли.
Текущая работа
Про формат, задачи и прохождение собеседования писать особо нечего - все четко, без эксцессов. Проходило 2 раза - сначала в группу стажеров, но по результатам предложили отсобеседоваться еще раз и миновать общую стадию обучения. Оба раза проходили в переговорке в офисе. Практическая часть задач - по большей части заковыристые и не очень вопросы про SQL. Теоритическая - обсуждение понятий трехзвенной архитектуры, принципов ООП и общих понятий разработки ПО.
Спустя 4 месяца после старта обучения я устроился разработчиком Oracle CRM и баз данных. Несмотря на то, что инструменты и окружение несколько далеки от JavaScript и Web-разработки, концепции, которые я усвоил благодаря Hexlet, здорово помогают в рабочих буднях. У меня есть понимание, что писать код можно иначе, что сам процесс разработки может быть удобнее, а главное, есть понимание, что нужно для этого сделать.