Эта статья была первоначально опубликована на Hashnode в рамках конкурса «4 статьи за 4 недели — Hashnode Writeathon». Она была опубликована на Hashnode и daily.dev. Найти ссылку на оригинальный пост можно ниже 👇.

- Как я получил свою первую работу разработчика, делая простые проекты большими
- Оглавление
- 1. Что можно получить от одного проекта
- 2. Как написать об этом проекте в резюме
- Как написать перспективное резюме
- 𝕁𝕦𝕝𝕚𝕒 👩🏻💻 ・ Oct 27 ’21 ・ 4 min read
- 3. Разговор о проекте
- Интеграция доступности в процесс веб-разработки
- 𝕁𝕦𝕝𝕚𝕒 👩🏻💻 ・ Aug 10 ・ 6 min read
- 4. Мой совет всем начинающим разработчикам
Как я получил свою первую работу разработчика, делая простые проекты большими
Получите свою первую работу разработчика, сосредоточившись не только на технических навыках, но и на деловых и мягких навыках. Получите знания об отрасли, инструментах и технологиях.

Я твердо убежден, что безупречное прохождение технических собеседований и умение писать качественный код — не единственные способы получить первую работу в качестве разработчика.
Вместо того чтобы сосредоточиться исключительно на технических навыках, которые я знал, что не смогу приобрести (и, скорее всего, все еще не приобрел 🙊) всего за год, я сосредоточился на деловых и мягких навыках, чтобы показать, какую ценность я могу принести компании.
И это принесло свои плоды.
Оглавление
- Что можно получить от одного проекта
- Как написать об этом проекте в резюме
- Рассказывая о проекте
- Мой совет всем начинающим разработчикам
Здравствуйте, меня зовут Юлия, и я фронтенд-разработчик-самоучка в возрасте тридцати лет, который сменил профессию на техническую после изучения японского языка и музыковедения, работая на полставки в казино.
В этой статье я хочу поделиться своим опытом о том, как я получила свою первую работу в качестве разработчика. Я продемонстрирую навыки, о которых только что говорил, на примере проекта, который, думаю, разрабатывали все мы: Калькулятор.
1. Что можно получить от одного проекта
Я часто читаю, что калькулятор не должен оказаться в вашем портфолио, потому что он прост и недостаточно уникален, и, возможно, они правы. Но сам проект может быть гораздо больше, чем просто код.
Прикладные навыки вы можете показать и продемонстрировать на собеседовании и убедить интервьюера, что вы знаете гораздо больше, чем то, как писать код — который, как мы все знаем, можно нагуглить в любой момент, а деловые и социальные навыки — нет.
Чтобы показать, насколько важны другие навыки, помимо программирования, я создал простой калькулятор на JavaScript.
Подсказка: если вы хотите добавить калькулятор в свое портфолио, вам обязательно нужно добавить больше функций, таких как
- десятичные числа
- чтобы отображение текущего числа оставалось на экране, когда пользователь нажимает на оператор
- перезапуск при нажатии на число после последнего результата без необходимости использовать клавишу удаления
- или все уже нажатые числа и операторы в небольшом формате над текущим значением, чтобы знать, что было вычислено до сих пор
Выберите 0.5x в середине нижнего ряда, чтобы полностью отобразить калькулятор.
Вот ссылка на репозиторий GitHub.
Вы приобретете навыки в области отраслевых знаний, а также инструментов и технологий, таких как
Знание отрасли
- управление проектами
- Управление временем
- Agile методологии (например, Scrum).
Инструменты и технологии
- HTML/CSS/JavaScript
- Контроль версий Git
- GitHub
- Доступность
- Тестирование
- Хостинг (например, страницы GitHub)
Довольно много, не так ли? Теперь, когда вы знаете, чего вы достигли, вам нужно профессионально это продать.
Но сначала я хочу показать вам, как представить ваш проект в резюме.
Затем я покажу вам, как бы я использовал вышеупомянутые термины во время интервью, чтобы проект, то, как я работаю, и я сам казались профессиональными и ценными для работы.
2. Как написать об этом проекте в резюме
Проект: Функциональный калькулятор (Посмотреть на GitHub)
- Построил функциональный калькулятор, который не только выполняет основные вычисления, но и … (все, что он может делать сверх этого, если добавлена дополнительная функциональность).
- Для работы приложения использовал HTML, SCSS, JavaScript, размещенные на GitHub страницы.
- Использовал Git для контроля версий, писал тесты с помощью Jest и тестировал для клавиатуры и скринридера, чтобы приложение было полностью доступным.
- Работал по методологии agile, отслеживая прогресс проекта с помощью проектов GitHub: создал проект, создал и разметил проблемы, работал в спринтах, проводил обзоры и ретроспективы спринтов, писал документацию (readme).
Навыки: HTML — SCSS — JavaScript — Git — GitHub — Jest — a11y — Scrum
Представляя свои простые проекты таким образом и рассказывая о них в профессиональной манере, я смог не только убедить людей своим резюме и получить интервью в первую очередь, но и найти работу довольно скоро после того, как начал ее искать.
Больше советов о том, как составить перспективное резюме, читайте в моей статье 👇.

Как написать перспективное резюме
𝕁𝕦𝕝𝕚𝕒 👩🏻💻 ・ Oct 27 ’21 ・ 4 min read
3. Разговор о проекте
Допустим, интервьюер спрашивает вас о конкретном проекте во время собеседования, примерно так:
Интервьюер: Можете ли вы рассказать мне, как вы создали этот проект, с чего начали, провести меня через процесс разработки и ваш код, поделившись своими мыслями?
Я бы ответил примерно так, поделился своим экраном и показал проект и те части, о которых я сейчас говорю, на GitHub (и я действительно делал это во время интервью):
Я старался быть максимально кратким, упоминая только самые важные моменты, и писать в разговорном стиле. Я также выделил все слова, благодаря использованию которых вы выглядите более профессионально.
В начале проекта я думал обо всем процессе веб-разработки, архитектуре и настройке, а также о том, как отслеживать прогресс, чтобы обеспечить завершение проекта в определенный срок. Конечно, для такого маленького проекта это кажется излишеством, но я хотел привыкнуть к реальному процессу разработки в компании в scrum-команде, как это работает на самом деле (или, по крайней мере, так я себе это представляю), даже если сейчас я работаю в команде из одного человека.
И я подумал, что лучший способ сделать это — представить, что этот калькулятор должен стать готовым к производству приложением, которое должно пройти через весь процесс веб-разработки.
Я решил построить проект, используя HTML, CSS (пока что) и JavaScript. Чтобы немного глубже погрузиться в SCSS, я позже обновил код и создал несколько миксинов для ознакомления с ним. Конечно, SCSS — это уже излишество для данного конкретного проекта, но я сделал это для практики, потому что часто вижу в описаниях вакансий, что требуется знание SCSS.
Я также подумал об использовании TypeScript, потому что этот язык также часто встречается в описаниях вакансий, и я могу добавить его, чтобы изучить язык, поскольку я никогда не использовал его раньше. Хотя я еще не знаком с TypeScript, я знаю, что это более безопасный способ программирования, чем ванильный JavaScript, из-за его типов и т. д. (читателю: вы должны рассказать обо всем, что вы знаете о TS на этом этапе). Кроме того, это хорошее упражнение для того, чтобы мне было удобнее читать документацию.
Обычно для такого небольшого проекта я использую CodePen. Я думаю, что онлайн-редакторы кода, такие как CodePen или CodeSandbox, — это отличные инструменты для того, чтобы быстро создать небольшой проект и сразу же увидеть результат. Но, как я уже сказал в начале, я хотел создать калькулятор в реальной среде. Вот почему я выбрал для этого GitHub.
Я знаю, что есть еще один замечательный инструмент под названием Gitlab, который часто используется компаниями, но лично я предпочитаю GitHub, в основном из-за его сообщества, а также потому, что в последнее время там произошли большие изменения.
Поэтому я использую GitHub для управления контролем версий git, который, как я знаю, используется для отслеживания всего, что происходит с кодом. Из того, что я слышал от других разработчиков, обычно существует основная ветка, а разработчики создают из нее свою собственную ветку для работы над своей проблемой, и когда все готово, они создают запрос на слияние своей ветки с основной веткой.
Поскольку я хотел попрактиковаться в использовании некоторых общих команд git, я сделал то же самое и в этом проекте. Для каждой проблемы я создавал отдельную ветку, писал код, и когда он меня устраивал, я создавал запрос на притяжение, прежде чем слить его с основной веткой.
Команды git, которые я использовал, были, например, такими: git checkout -b my-branch
, git commit -m "what did I do"
, git push
, git pull
, git merge
. Я знаю, что есть еще много команд, но, думаю, мне никогда не приходилось их использовать из-за размера проекта и команды. Так как в мастер всегда сливалась только одна ветка, скорее всего, конфликтов не было. Но я уверен, что буду использовать более продвинутые команды git должным образом.
Для структуры папок проекта я решил создать две папки (или три, когда писались тесты), одну для активов, то есть изображений, и одну для исходного кода. Чем больше будет становиться проект, тем больше будет папок и тем глубже будет структура, я думаю. Мне очень интересно научиться думать об архитектуре и системе дизайна в реальном проекте. Я нахожу этот способ мышления очень интересным.
Насколько я знаю, в компании есть небольшие команды, которые вместе работают над проектом. И, как я уже говорил, есть темы, которые создаются, и каждый разработчик берет тему, над которой он работает. И команды работают по принципу agile, как scrum, который я нахожу очень интересным, весь scrum framework. Поэтому я представляю себе ежедневное совещание продолжительностью около 15 минут, где все вкратце рассказывают о том, чего они достигли вчера и что собираются делать сегодня.
Я хотел создать такую ситуацию и для себя. Я подумал, что лучший способ сделать это — создать проект и проблемы, которые предоставляет GitHub. Я знаю, что есть инструмент под названием Jira, часто используемый компаниями, который позволяет создать целый проект и проблемы и подписать разработчиков на проблемы.
Я думаю, что проект GitHub — это очень хороший инструмент для управления проектами, и если я пойму процесс и функции здесь, то наверняка смогу быстро разобраться с Jira.
Поэтому я создал несколько задач, таких как настройка проекта, написание HTML для калькулятора, создание дизайна с помощью инструмента дизайна под названием Figma (я думаю, что в больших командах есть дизайнеры, которые занимаются этим, а мне нужно преобразовать дизайн в код, но поскольку я команда из одного человека, я сделал это один), преобразование дизайна в CSS-код, добавление функций в калькулятор, задачи вроде этих.
В своем самообразовании я часто встречаю тему веб-доступности и того, насколько она важна. Поэтому я хотел сделать приложение доступным, используя только достаточно контрастные цвета. Я также убедился, что калькулятором можно управлять только с помощью клавиатуры и что фокус отображается правильно.
Я сохранил значение по умолчанию для контура, но я часто вижу, как компании используют свой основной цвет для отображения контура, когда он находится в фокусе. На мой взгляд, это имеет смысл, в зависимости от цветов приложения.
Существует расширение под названием Lighthouse, которое можно запустить на проекте и которое показывает, насколько сайт доступен, или насколько хороша производительность и SEO. Я старался получить 100% в каждой области. Но я слышал, что даже если вы достигли 100% в доступности, это не обязательно означает, что сайт действительно полностью доступен. Сейчас я не так много знаю об этом, но надеюсь узнать в будущем, потому что считаю, что это важная тема.
Я подумал о том, сколько времени мне потребуется на выполнение каждой задачи и проекта в целом, добавил этапы, пометил пункты как улучшение или новая функция и назначил их. Проект на GitHub — действительно хорошая вещь, обеспечивающая обзор всех проблем. Думаю, в большом проекте гораздо больше ярлыков, таких как ошибки, дефекты и прочее.
Я слышал, что в проекте обычно есть спринт продолжительностью около двух недель, где команда должна завершить определенное количество проблем. И что существуют такие встречи, как обзор спринта или ретроспектива, на которых скрам-команда рассказывает о том, как все прошло за последние две недели, или представляет завершенные вопросы заинтересованным сторонам.
Даже когда у меня не было заинтересованных сторон или такого длительного процесса разработки, я думал о том, что прошло хорошо или что я мог бы улучшить в своем следующем проекте. Я обнаружил, что часто недооценивал время. Я думал, что решение этого вопроса займет у меня около 20 минут, но на самом деле это заняло от 1 до 1,5 часов. Это было удивительно для меня. Но, заметив это, я буду лучше оценивать время на выполнение задания в будущем.
Вы также можете установить стиль проекта, например, Kanban. Как типичный список дел: Какие дела открыты, что я делаю прямо сейчас, какие дела выполнены. Это помогло мне хорошо следить за ходом проекта.
Я также написал несколько тестов для проекта (для читателя: пока что для проекта не написано ни одного теста. Но это не обязательно означает, что на данном этапе нельзя говорить о тестировании). Я знаю, что существует множество тестов, таких как юнит-тесты, интеграционные тесты, сквозные тесты, которые используются в больших проектах. И я также слышал о множестве автоматизированных инструментов, таких как предотвращение фиксации кода из-за того, что сообщение начинается не с того, что предложила компания, или предотвращение слияния, если никто из старших не просмотрел PR.
Мне не терпится поработать над большим проектом, где я смогу увидеть подобное автоматизированное тестирование в реальной жизни. Я думаю, что это действительно полезно для качества кода.
Я также разместил проект на GitHub, чтобы другие могли увидеть мой проект и попробовать его. Я также добавил файл readme, где подробно описал проект, добавил скриншот и показал, как другие могут использовать мой код. Я добавил информацию в раздел «О репозитории» и добавил теги, чтобы другие могли найти проект. А также ссылку на живой предварительный просмотр здесь и в файле readme.
Я думаю, что важно использовать инструмент по максимуму. На GitHub можно сделать так много, чтобы ваш проект выделялся на профессиональном уровне.
Теперь давайте посмотрим на код. В HTML-файле я постарался использовать различные метатеги по соображениям SEO, что означает, что мой сайт будет легче найти, и я установил область просмотра, чтобы обеспечить хорошее использование на мобильных устройствах.
Я разделил код на секции для каждой строки калькулятора, что облегчает последующее использование CSS-сеток.
Для SCSS я сохранил значения цвета, шрифта, градиента и границ в переменных, чтобы их было легче использовать. Это сделано для того, чтобы, например, если вы захотите изменить базовый цвет, вам пришлось сделать это только один раз, а не для каждого класса, в котором вы используете этот цвет. В CSS вы также можете хранить цвета в переменных.
Я также использовал миксины, которые позволяют создать базовый стиль, который затем корректируется для определенных целей. Я расположил значения в алфавитном порядке, чтобы было удобнее читать. Это предотвращает повторение кода. Но, конечно, как я уже говорил в начале, CSS вполне подошел бы для проекта такого размера. Но я узнал много нового о SCSS, что очень полезно.
Теперь давайте посмотрим на код JavaScript. Во-первых, я создал функцию для различения того, нажимает ли пользователь на оператор или на число, чтобы решить, какую функцию вызывать. В случае, когда пользователь нажимает на оператор (или символ), оператор switch берет на себя функцию.
Я выбрал оператор switch вместо оператора if else, поскольку считаю, что комбинированный последний switch (функциональность которого обрабатывается в отдельной функции flushOperation
, начинающейся в строке 64) более читабелен. В конце я добавил функциональность eventListener
к кнопкам.
Вот и все. Если у вас есть еще вопросы по коду или процессу веб-разработки, пожалуйста, дайте мне знать.
Многовато мы поговорили об этом простом калькуляторе, не находите? И так много всего можно добавить, например, рассказать больше о тестировании, больше об автоматизации GitHub, мета, SEO, доступности, или о темах, в которых вы разбираетесь лучше, чем я здесь.
Для получения дополнительной информации о процессах разработки посмотрите мою статью 👇

Интеграция доступности в процесс веб-разработки
𝕁𝕦𝕝𝕚𝕒 👩🏻💻 ・ Aug 10 ・ 6 min read
Надеюсь, теперь вы получили представление о том, что входит в процесс разработки. Дело не только в коде, есть много других вещей, о которых можно поговорить, и, возможно, как и я, вы чувствуете себя гораздо более комфортно с этими темами, чем с разговорами о коде.
Кроме того, не ждите, пока вас спросят об определенных вещах, чтобы продемонстрировать свои навыки и знания. Потому что вопросы могут быть никогда не заданы, или заданы не так, как вы надеетесь.
4. Мой совет всем начинающим разработчикам
Не сосредотачивайтесь только на коде, потому что большую часть времени в своей работе вы все равно будете искать решение проблемы в гугле или обсуждать концепции и возможности с другими разработчиками. Сосредоточьтесь на том, как решать проблемы, на менталитете разработки продукта (от начала планирования, до самой разработки и завершения всего процесса), на деловых и социальных навыках.
Кроме того, найдите нишу, что-то, в чем вы хороши, и сосредоточьтесь на этом как можно больше (как я делал с доступностью и UX-дизайном в качестве front-end разработчика). Существует так много языков программирования, так много всего нужно изучить. Найти работу в сфере технологий — значит, в любом случае, отправиться в путешествие за знаниями на всю жизнь.
Помните о своих навыках и открыто и честно говорите о своих сильных и слабых сторонах, о том, что вы знаете и чего не знаете, и как бы вы поступили в ситуации, если бы не были знакомы с каким-то предметом. Это поможет интервьюеру получить представление о том, кто вы и как вы впишетесь в коллектив. В команде разработчиков есть множество позиций, так что для вас обязательно найдется место.
Спасибо, что прочитали и уделили мне время. Я очень ценю это!