Статьи «Как составить резюме» отчасти были полезны, а отчасти путали и нагоняли страх: их авторы утверждали, что мое письмо может попасть в корзину, если не выдержана структура или ответственный сотрудник не увидел в нем ключевых слов за первые 5 секунд чтения.
Прошли годы, сейчас я сама участвую в найме фронтенд-разработчиков и просматриваю резюме вместе с другими тимлидами.
В этой статье я хочу рассказать:
- На какие моменты мы обращаем внимание, прежде чем пригласить кандидата на интервью, и как можно выгодно подать свой опыт.
- Что, вопреки популярным мифам о поиске работы, наоборот, не оказывает влияния на решение работодателя.
- Что делать, если нынешнего опыта объективно не хватает для позиции мечты.
А главное — хочу объяснить логику, которой мы руководствуемся, чтобы процесс больше не выглядел магией.
Не воспринимайте написанное как универсальный рецепт или требования. Скорее это дружеские советы и взгляд со стороны. У вас вообще может не быть резюме, если вы топовый разработчик, звезда конференций, у вас крутой профиль на GitHub, вас рекомендует друг и так далее. Эта статья — для начинающих специалистов и тех, кто впервые сталкивается с поиском работы.
Структура резюме
Стандартное резюме состоит из следующих блоков:
- ФИО, контактные данные, желаемая позиция (опционально — возраст);
- опыт работы;
- образование;
- дополнительная информация, которую вы хотите сообщить.
Чтобы испортить часть, касающуюся ФИО и желаемой позиции, надо здoрово постараться. Поэтому обратимся сразу ко второму блоку.
Опыт работы
Очевидно, это самый важный раздел резюме (исключение — специалисты без опыта, советы для них ниже). На основании этой информации мы оцениваем, насколько кандидат подходит или не подходит нашей команде. Есть несколько способов описать свой опыт, рассмотрим каждый из них.
Вариант 1. Минималистичный
Из такого резюме мы выяснили, что кандидат был фронтенд-разработчиком. Но каким? Какой он использовал фреймворк? Писал ли тесты? Какие задачи приходилось решать?
Хорошо, если «Рожки да ножки» — всем известная ИТ-компания. Скажем, если вы работали в Google, то, в принципе, можете больше ничего не писать, на это «клюнут» многие работодатели. В противном случае, стоит указать больше информации.
Конечно, есть вариант позвать такого кандидата на собеседование и выяснить все лично или попросить коллег из HR связаться и узнать подробности. Но, придавая себе такую загадочность, вы увеличиваете шанс, что ваш потенциальный лид додумает все сам и не все его догадки будут в вашу пользу.
Вариант 2. С указанием технологий
Указав технологии, которыми владеете, вы сразу сняли много вопросов. Теперь мы понимаем, насколько ваши навыки пересекаются с нашим стэком. Только без фанатизма, не надо перечислять технологии всех соседних отделов. Слишком длинный список выглядит неправдоподобно. Укажите то, с чем работали лично вы и что готовы обсудить на интервью.
Не стоит бояться неполного соответствия стэка. Например, вы работали с NGXS, мы работаем с NgRx. Знание близких технологий все равно будет плюсом. И чем больше ваш опыт похож на наши проекты — тем вероятнее, что мы захотим с вами познакомиться.
Но все же хотелось бы знать, какие конкретно задачи вы решали.
Вариант 3. С указанием обязанностей
Теперь мы лучше представляем, что вы делали на прошлой работе, и можем сопоставить это с открытыми позициями. Если вы занимались чем-то похожим — это добавит плюсик в вашу воображаемую карму. Но даже если задачи сильно отличались от наших проектов, описание предыдущих обязанностей поможет составить о вас хотя бы первоначальное представление и станет отправной точкой на очном интервью.
Могу с уверенностью сказать, что кандидат с таким резюме получит больше приглашений на собеседование. Но можно ли сделать еще лучше? Оказывается, да.
Вариант 4. С указанием достижений
Ну вот, теперь мы знаем не только то, чем вы занимались, но и что вы действительно сделали. Это особенно важно, если вы senior или тимлид. От сотрудников на таких позициях мы всегда ждем решающего вклада в техническое развитие проекта или управление командой. Но и менее опытным разработчикам часто есть чем поделиться.
Признаюсь, что, меняя работу первый раз, я стеснялась описывать свои достижения: ну и что, что я провожу статусы, оцениваю сроки и курирую менее опытного коллегу, ведь официально я еще «младший программист»! Сейчас я могу авторитетно заявить — стесняться точно не надо: сделали что-то важное — напишите об этом, даже (и тем более) если это не соответствует вашей нынешней позиции.
Сомневаетесь, что считать достижениями? Вот несколько идей:
- внедрил TypeScript (ES6, юнит-тесты, код-ревью, code style и т. д.);
- оптимизировал загрузку сайта;
- сформировал команду, осознанно выбрал фреймворк;
- организовал внутреннее обучение (митапы, походы на внешние конференции);
- выступил на митапе, конференции.
Этот список можно продолжать. Но дам еще один совет. Помните притчу про три сита, через которые надо пропустить то, что хочешь сказать? Так вот, достижения стоит пропустить через сито адекватности.
Например, вы пишете, что руководите отделом фронтенд-разработки. А потом выясняется, что отдел состоит из вас и вашего друга Пети. Выглядит так себе. Или приводите малозначимые факты: за время работы написал 30 тысяч строк кода, закрыл 125 тикетов, отревьювил 1500 пулл-реквестов.
Если посмотреть на распределение последних полученных нами резюме по указанным категориям, мы увидим такую картину:
Как минимум 28 из 100 резюме можно было бы существенно улучшить.
Хочу заметить, что плохо подготовленное резюме не всегда означает менее подходящего кандидата, как и наоборот: автор прекрасного резюме может не пройти техническое собеседование или не сработаться с командой. Но если вы даже не стараетесь рассказать о себе — как ваши потенциальные коллеги заметят вас среди других кандидатов?
Проблемы при указании опыта
Иногда у человека достаточно лет опыта, но, читая резюме, мы все равно думаем, что это «не наш кандидат». Что может быть не так?
Частая смена работы
Кажется, всем уже известно, что частая смена работы не красит соискателя. Для меня частая смена работы — три и более мест, где вы работали меньше года. Это не является безоговорочным основанием для отказа, тем более если причины были нейтральные. Например, вы работали над проектом и он завершился. Это можно сразу указать в резюме, чтобы потенциальный лид не додумывал от себя.
Тем не менее я предлагаю задуматься об этом, меняя работу в следующий раз: действительно ли ваше новое место лучше старого, есть ли там перспективы и возможности для роста, делает ли оно вас ближе к вашим глобальным карьерным целям? И есть ли они у вас?
Опыт в нерелевантных технологиях
Бывает, что у кандидата большой стаж, но даже многолетний и хорошо описанный опыт может быть нерелевантен позиции.
Мы ищем Angular- и React-разработчиков (но часто готовы рассматривать и разработчиков с опытом в других фреймворках), а в резюме, например, только блоги на WordPress. Или вы разрабатывали бэкэнд, а теперь хотите переквалифицироваться во фронтендера. Я и сама была в такой ситуации несколько лет назад и понимаю, какие проблемы вас ждут: опыт разработки есть, но практического опыта в веб-разработке нет. Пройти собеседование по новой специальности может быть непросто.
Что делать? Поднять лапки кверху и смириться? Продолжать делать то, что вы уже успели разлюбить? Конечно же нет. Переходим к следующему разделу.
А если мало опыта?
Хороших разработчиков всегда не хватает. А интервьюеры тоже люди и тоже когда-то начинали с нуля. Поэтому часто готовы рассматривать кандидатов пусть и с недостаточным опытом, но с желанием расти. Надо всего лишь это желание подкрепить делом и прозрачно намекнуть об этом в резюме.
Саморазвитие
Если вам не хватает знаний смежных или более современных технологий, начните изучать их сами. Пройдите видеокурсы, сейчас их много на любой вкус (я люблю Pluralsight, но можно найти и бесплатные видео прекрасного качества). Напишите о желаемом пути развития и своих усилиях в резюме — например, в разделе «Дополнительная информация» или в сопроводительном письме. Например:
На текущем месте работы мы не используем фреймворки, но я слежу за современными технологиями и изучаю Angular (React, Vue — здесь ориентируемся на свои интересы и желаемое место работы). Прошел такие-то курсы.
И снова без фанатизма! Если вы указываете 50 курсов, начиная от верстки и заканчивая оптимизацией запросов к БД, это выглядит странно (если только вы не fullstack). Подумайте, чем на самом деле вы хотите заниматься и чего вам сейчас не хватает.
Кстати, если вы собираетесь искать работу, потому что вас не устраивают устаревшие технологии или отсутствие хороших командных практик, предлагаю на минутку задуматься: а вы пытались это изменить? Если нет, то рекомендую попробовать. Неожиданно это может оказаться и возможностью для роста, и способом получить практический опыт в реальных рабочих условиях.
Pet-project
Допустим, вы проходите или уже прошли какое-то обучение: посмотрели курсы, прочитали книгу или статьи. Вы, конечно же, понимаете, что такой «теоретической» подготовки недостаточно. Я всегда советую по мере просмотра видео или чтения книги отрабатывать новые знания на практике. Например, завести pet-проект.
Что это может быть? В принципе, что угодно.
Вы увлекаетесь футболом? Сделайте сайт о предстоящем чемпионате. Изучаете иностранный язык? Напишите приложение для повторения слов. Любите путешествовать? Сделайте карту мест, где вы были. Есть множество открытых API, данные которых можно использовать. Например, неплохой список API вы найдете в репозитории public-APIs.
Кроме закрепления изученного материала pet-проект дает еще одну интересную возможность: его можно выложить на GitHub и дать ссылку на ваш профиль в резюме. Хороший код скажет о вас больше, чем тысяча слов, а в некоторых случаях избавит от тестового задания. Но убедитесь, что ваш GitHub не свидетельствует против вас.
Ваш профиль на GitHub
Несколько раз мне попадались резюме, автор которых указал ссылку на GitHub (что само по себе очень здoрово и выделяет резюме в глазах потенциальных интервьюеров), но просмотр кода напрочь отбивал желание общаться. Вот самые простые причины, почему так может произойти:
- Много кода в одном файле, огромные функции, большая вложенность.
- Очевидное дублирование кода.
- Откровенно плохие названия переменных и функций.
- Неиспользуемые переменные, функции, импорты.
И это только те code smells, которые сразу бросаются в глаза, еще до того, как я спуллю код. Кстати, очень удобно, если ваш проект где-то развернут и можно посмотреть демо, не запуская у себя. Простейший вариант — github pages.
Конечно, ваше право хранить в своих репозиториях код, который вы набросали на коленке, код, который вы написали давно и сейчас бы все сделали по-другому, код без тестов и без типов.
Но помните, что если вы сами дали ссылку на ваш GitHub, то для интервьюера это приглашение оценить его и сделать вывод. Поэтому мой совет: приведите код в порядок, чтобы он показывал лучшие из известных вам практик. Хотя бы для одного проекта, который вы и будете демонстрировать как эталон.
Ресурсы для практики
Pet-проект — история про создание проекта с нуля, работу с фреймворком, с API. В общем, это нечто напоминающее реальный проект в миниатюре. Кроме работы над pet-проектом советую практиковаться в решении задач на написание кода. Это особенно важно для джуниор-разработчиков или разработчиков, меняющих специализацию (например, при переходе с C# на javascript), — так можно набить руку и привыкнуть к новым конструкциям.
Есть много сайтов с подходящими задачами и автоматической системой проверки. Мои любимые — Codewars и LeetCode.
Вообще этот совет больше касается саморазвития и подготовки к интервью, чем написания резюме.
Образование
С образованием все просто: либо оно есть, либо его нет, просто пишем правду. Если вы проходили дополнительное обучение, прямо или косвенно связанное с работой, также стоит это указать. В моем случае это, например, курс UX&UI Design, пройденный в Британской высшей школе дизайна.
Недавно меня спросили, насколько важно в принципе иметь высшее образование для работы в ИТ.
Думаю, это холиварный вопрос, со мной могут не согласиться даже некоторые коллеги. Мой ответ: если есть возможность закончить хороший вуз — лучше это сделать. Но наличие образования не решающий фактор (а вот знаний — да). И уж точно я никому не советую поступать в малоизвестный институт только ради корочки.
Признаюсь, мысленно я ставлю дополнительный плюсик кандидатам с профильным образованием
в топовых вузах. Тем не менее я знаю несколько прекрасных разработчиков без высшего образования, и отсутствие диплома им никак не мешает.
Дополнительная информация
Многие резюме заканчиваются блоком с дополнительной информацией о кандидате. Здесь можно указать все, что по формату не подходит для других разделов. Например:
- чем интересуетесь и в какую сторону хотите развиваться (можно написать, что для вас особенно важен UX или что вам нравится менторить менее опытных коллег);
- дать ссылку на GitHub или портфолио;
- рассказать о ваших статьях или выступлениях;
- объяснить, что, хоть у вас и нет опыта в определенной технологии, вы готовы ее освоить и что-то делаете для этого (см. раздел «А если мало опыта?»);
- рассказать о любых других достижениях (в олимпиадном программировании, решении бизнес-кейсов и др.).
Вы спросите: «А что насчет стандартных формулировок „стрессоустойчив“, „легко обучаем“ и подобных определений, которые все еще можно подсмотреть в примерах резюме?» На меня они не производят никакого впечатления, и я искренне не понимаю, почему их все еще используют. В конце концов, мы не предполагаем по умолчанию, что кандидаты особенно подвержены стрессу, да и некомфортных ситуаций в команде стараемся избегать.
Выводы
В заключение приведу несколько идей, которые я хотела донести этой статьей:
- В резюме подробно опишите свой опыт: укажите технологии, основные задачи и ваши достижения, если они есть.
- Если опыта не хватает — учитесь сами и покажите это потенциальному работодателю.
- Для практики заведите pet-проект.
- Опубликуйте его на GitHub, чтобы показать пример кода, который вы пишете.
- Если указываете GitHub в резюме, доведите код до совершенства.
Комментарии (101)
panteleymonov
12.11.2019 17:51Тем не менее я предлагаю задуматься об этом, меняя работу в следующий раз: действительно ли ваше новое место лучше старого, есть ли там перспективы и возможности для роста, делает ли оно вас ближе к вашим глобальным карьерным целям? И есть ли они у вас?
К примеру. Я работаю на себя, и все из перечисленного присутствует. Поэтому меня может многое не устроить на любом месте работы. Конечно по большому счету это компромисс, но мне кажется что многие самостоятельные товарищи думают с этой точки зрения.
Кстати, если вы собираетесь искать работу, потому что вас не устраивают устаревшие технологии или отсутствие хороших командных практик, предлагаю на минутку задуматься: а вы пытались это изменить? Если нет, то рекомендую попробовать. Неожиданно это может оказаться и возможностью для роста, и способом получить практический опыт в реальных рабочих условиях.
Это то о чем потом, с уходом, можно сильно пожалеть. Те кто хотят получить опыт и научиться, будут скорее смотреть на других, делать как все или вышестоящий. Это правильная модель поведения для общества не больного моральным уродством, с беготней впереди повозки.
А если нужен отдел инноваций, то он для этого и создается. Там можно вполне оправданно фейлиться, если не получится. И не мучиться в статусе белой вороны, если вперед других убежал. Опять же реструктуризация и улучшения это общая работа.
Shoom3301
12.11.2019 19:36Поэтому меня может многое не устроить на любом месте работы
Не понял взаимосвязь того, что вы работаете на себя и того, что вас может многое не устроить на любом месте работы? В чем корреляция?
Те кто хотят получить опыт и научиться, будут скорее смотреть на других, делать как все или вышестоящий
Сейчас куча информации в интернете и передача знаний из уст в уста уже не является основным способом обучения. Любой разработчик может узнать в интернете что-то новое и применить в своей работе.
А если нужен отдел инноваций
Инновации придумывают разработчики с высоким уровнем знаний, большинству остается только брать эти инновации и использовать.panteleymonov
12.11.2019 23:22В чем корреляция?
А в чем смысл задумывается над условиями? Если мне на себя удобней работать чем в текущей компании. Мое следующее место работы это я сам. Из расчета условий которые я сам себе предоставляю, мне удобнее, перспективнее и продуктивнее. Действительно может быть, что на следующем месте работы, который мне захочется поискать, не будет так удобно как на текущем, но я всегда могу работать на себя. В этом смысле, я не буду задерживаться на любой работе, которая меня не устроит без каких либо обдумываний.
Любой разработчик может узнать в интернете что-то новое и применить в своей работе.
Узнать может, а применить не всегда может быть к месту, все от общества зависит и от проекта. Одни кричат «не читай википедию — козленочком станешь», другие «читай википедию раз не знаешь». А если во главе нет опытного и знающего и каждый себе начальник и руководитель научного проекта, то «запчасти ракеты явно начинают лететь каждая по своей траектории». Децентрализованное обучение интересно для саморазвития, но не всегда помогает проекту который разрабатывают разные люди.
Инновации придумывают разработчики с высоким уровнем знаний, большинству остается только брать эти инновации и использовать.
А я о чем по вашему написал? Или вы предлагаете каждому, как в статье, проявить себя в модернизации производства? Тем не менее отдел инноваций не куда не делся, а как раз работает, в том числе и над оценкой целесообразности внедрения того что может придумать разработчик с высоким уровнем знаний. И из-за его отсутствия, совсем не значит, что нужно внедрять все что предлагает товарищ с высоким уровнем знаний.
rboots
12.11.2019 19:42По поводу качества кода — довольно неблагодарное дело давать примеры, так как обычно разработчик считает плохим кодом либо тот код, который он перерос и видит проблемы, или тот, до которого он недорос и не понимает. Есть маленький слой кода, который попадает под определение хорошего для данного разработчика в данный момент, и попасть в него — всё равно, что играть в лотерею. Гораздо содержательнее побеседовать, почему в том или ином участке кода было принято решение написать именно так, на основе чего принималось решение? Это просто копирка или осознанное решение, лучшая практика не используется потому, что кандидат о ней не знает или потому, что в данном случае видит больше аргументов за другой подход, сразу становится понятен уровень кандидата.
Nehc
13.11.2019 10:58Ну общее-то представление о правилах «хорошего тона» есть…
Думаю автор имел ввиду, что если ты даешь ссылку на свои проекты, то это должен быть пример того, как ты видишь свой «стиль» прямо здесь и сейчас, и именно так это воспринимается…
quaer
12.11.2019 20:20-1Много кода в одном файле, огромные функции, большая вложенность.
Чем это всё плохо? Пример: код кодека Opus, opus_encode.c и, например, в нём opus_encode_native. Вы бы не взяли на работу разработчика этого кода?
Для сравнения в этом же кодеке есть код, написанный в другом стиле, в пакете silk.
Очевидное дублирование кода.
Часто так делается подразумевая, что будут вносится изменения или потому что это лишь визуальное сходство. Это бывает лучше, чем лишние условия в общем коде, наставленные ради создания общего кода.
Откровенно плохие названия переменных и функций.
Рассказать бы это тем, кто даёт названия консольным утилитам или тем, кто даёт названия стандартным функциям. И вообще, хорошие бывают?
Неиспользуемые переменные, функции, импорты.
Такое может быть на этапе работы над кодом, что в этом плохого?
Mayurifag
12.11.2019 20:40+1Почему бы не пользоваться линтером(-ами) своей(-их) технологии(-й), чтобы исключить совсем «детские» code smell?
Чем это всё плохо?
Поддерживать такое тяжело. Даже автору через определенное время.
Такое может быть на этапе работы над кодом, что в этом плохого?
В WIP ветке — пожалуй, ничего плохого, разве что CI красный.
yuliatsareva Автор
12.11.2019 21:06+1Чем это всё плохо?
Тяжело развивать и поддерживать. Это важно для работы в команде и над долгоживущими проектами. Роберт Мартин в книге «Чистый код» дает хорошие рекомендации по организации кода с наглядными примерами.
это лишь визуальное сходство
Визуальное сходство — это одно. А вот копипасту одних и тех же блоков лучше избегать.
Просто для примера, допустим, проверяем, что код високосный в нескольких местах. И везде пишем:
if (year % 4 === 0 && year % 100 !== 0 || year % 400 === 0) { // … }
Лучше вынести в функцию с понятным названием и использовать ее:
function isLeapYear(year) { return year % 4 === 0 && year % 100 !== 0 || year % 400 === 0; } // места использования if (isLeapYear(year)) { // … }
И вообще, хорошие бывают?
Конечно, бывают. Но, к примеру, однобуквенные названия в большинстве случаев — плохой выбор.quaer
12.11.2019 22:07К сожалению, вы ушли от ответов и дали сверхочевидные примеры.
Могу дать аналогично цитаты, например, из С. Макконнелл, «Совершенный код»:
«Одному из моих клиентов поручили разделить самый объемный метод унаследованной системы, включающий более 12 000 строк. Приложив немалые усилия, он смог уменьшить объем этого метода только примерно до 4000 строк.»
v2kxyz
12.11.2019 23:28Из любого правила существуют исключения, из рекомендаций тем более. Я думаю, что 4000 строк в одном методе это действительно редкое исключение, заслуживающие объемного комментария в самом начале о том почему так вышло. В любом случае большие куски кода — минимум повод подумать, а не стоит ли их разделить на кусочки поменьше.
michael_vostrikov
13.11.2019 08:14Чем это всё плохо?
Разбираться и вносить изменения сложно.
Вы бы не взяли на работу разработчика этого кода?
Я собеседования никогда не проводил, но работать с тем, кто пишет такой код, я бы не хотел. По вышеуказанным причинам.
Это бывает лучше, чем лишние условия в общем коде, наставленные ради создания общего кода
Если у вас условия в общем коде, созданные для этой цели, значит вы написали неправильно. Общий код на то и общий, что везде работает одинаково.
И вообще, хорошие бывают?
Бывают. Например, не
Fs, аframe_size.
Такое может быть на этапе работы над кодом, что в этом плохого?
То, что вы в резюме показываете не этап работы над кодом, а законченный код. Если у вас законченный код находится в таком же беспорядке, как незаконченный, то не надо удивляться, что другие не хотят работать с таким кодом.
quaer
13.11.2019 11:29Переформулирую вопрос: как на взгляд рекрутера выглядит код open source проектов и достойны ли их авторы быть нанятыми?
Примеры: Linux, Open JDK, Opus, Android SDK.
Или по-другому, какой проект по мнению рекрутера может быть рекомендован для подражания?
Разбираться и вносить изменения сложно.
А разве не бывает наоборот? Читаешь как книжку без сносок на другие страницы и видишь связный текст.
Другой пример: обработка ввода пользователя в утилитах командой строки.
Я собеседования никогда не проводил, но работать с тем, кто пишет такой код, я бы не хотел. По вышеуказанным причинам.
Может, тут просто есть еще разница, одни мыслят как Лев Толстой, а другие смс-ками?
Общий код на то и общий, что везде работает одинаково.
Теория хороша, а на практике что делать если надо так же, но чуть по-другому?
Копировать код и вносить изменения или добавлять переменную?
Бывают. Например, не Fs, а frame_size.
Вы забыли про аргументы функции, название нельзя рассматривать в отрыве от них.
Ну и «ls -l» наверно знаете? Название функции из одной буквы (l) и сама буква та ещё.
То, что вы в резюме показываете не этап работы над кодом, а законченный код.
Странное утверждение.
Neikist
13.11.2019 12:00Ну, код Android SDK первых версий был тем еще ужасом, да и сейчас местами не блещет. Пусть со временем они и постарались немного выправить его, не сильно обратную совместимость ломая.
v2kxyz
13.11.2019 12:24Переформулирую вопрос: как на взгляд рекрутера выглядит код open source проектов и достойны ли их авторы быть нанятыми?
Примеры: Linux, Open JDK, Opus, Android SDK.
Или по-другому, какой проект по мнению рекрутера может быть рекомендован для подражания?
А у вас есть данные по медианной длине функции в этих проектах? Может там функции не такие уж и длинные?
Ну не стоит сравнивать фронтэнд(да и бизнес-бэкэнд и вообще кровавый энтрпрайз), которым заведует автор, и низкоуровневое системное ПО, где вызов функции иногда считается дорогой операцией в плане производительности.
Ну и «ls -l» наверно знаете? Название функции из одной буквы (l) и сама буква та ещё.
ls — это не название функции в коде, а программа, которая обычно используется как команда в терминале. Т.е. ls как команда — чаще набирается и почти никогда не читается и самое главное она используется постоянно, функция ls где-то в коде в основном читается и очень редко набирается и используется крайне редко в расчете количество раз в год и в другом проекте может значить совершенно другое, в отличии от команды ls, которая во всех Unix-like ОС значит одно и тоже. Поэтому название функции ls — ужасное, лучше list_files или list_sockets или make_list т.е. то что она на самом делает. С аргументами команд/функций — аналогично.
michael_vostrikov
13.11.2019 12:39+2как на взгляд рекрутера выглядит код open source проектов и достойны ли их авторы быть нанятыми?
Участие в open source не означает, что разработчик пишет хороший код, и что любого из них можно нанять. Кто-то пишет хороший, кто-то плохой, кто-то для себя пишет хороший, а в других проектах плохой, потому что там так исторически сложилось.
Или по-другому, какой проект по мнению рекрутера может быть рекомендован для подражания?
Не знаю как у рекрутеров, но я бы порекомендовал следовать рекомендациям из книги "Совершенный код". Или как выше "Чистый код" советуют.
Другой пример: обработка ввода пользователя в утилитах командной строки.
Я не понимаю, что этот пример должен показывать. Ввод пользователя нельзя на функции разбить? Параметры командной строки нельзя в структуру объединить? Сформулируйте словами пожалуйста.
А разве не бывает наоборот? Читаешь как книжку без сносок на другие страницы и видишь связный текст.
Что если в книге написано, что герой влюбился в блондинку, а на следующей странице что в брюнетку? Или что получил ранение в руку, а на следующей странице говорится, что в ногу? От этого становится понятнее, что в книге происходит?
Дело в том, что код это не книга, он делает работу. Просто так код обычно никто не читает, читают когда надо его изменить, или разобраться как он работает, чтобы изменить в другом месте. Копипаста и большие блоки этому мешают. Особенно если скопировано с небольшими изменениями.
Может, тут просто есть еще разница, одни мыслят как Лев Толстой, а другие смс-ками?
Разговор не о литературных изысканиях, а о работе. Есть работа, и ее надо сделать, желательно быстро. Если ваш код мешает работе, значит с вашим кодом никто не захочет работать. Все просто.
что делать если надо так же, но чуть по-другому? Копировать код и вносить изменения или добавлять переменную?
Разбить на функции и вызывать нужные. Если разбить почему-то нельзя, ну тогда только переменные добавлять. Копировать с незначительными изменениями точно не надо. А то потом в одном месте поменяют, а в другом нет, потому что не нашли.
Вы забыли про аргументы функции, название нельзя рассматривать в отрыве от них.
Ну аргумент функции так и называется
Fs. И в вызывающей функции он называетсяFs. И в вызывающей ее функции называетсяFs. Что дальше?
Ну и «ls -l» наверно знаете?
Знаю. Что это должно доказывать? Сформулируйте словами пожалуйста.
Странное утверждение.
Нет. В продакшн идет законченный код, а не промежуточный. С этим кодом потом работают другие. Все промежуточные этапы должны оставаться только на вашей машине. Если вы показываете код, ожидается, что он законченный и работающий. Потому что такой же код вы должны будете показывать на pull-реквестах.
Neikist
13.11.2019 12:44Разбить на функции и вызывать нужные. Если разбить почему-то нельзя, ну тогда только переменные добавлять. Копировать с незначительными изменениями точно не надо. А то потом в одном месте поменяют, а в другом нет, потому что не нашли.
Не согласен. Копирование это вполне нормально. Если ожидается что в дальнейшем этот код будет меняться и не будет никак связан с тем местом из которого скопирован. Т.е. если это просто так совпало что код похож, но делает он совершенно разное для разных частей бизнес логики. Как раз в случаях когда предполагается что если будут менять кусок в месте из которого копировали — это не должно повлиять на новый код.michael_vostrikov
13.11.2019 13:02В такой формулировке согласен. Но это требуется совсем не "часто". Ну и говорил я больше про условия в общем коде. Всякие флаги, меняющие режим работы, это обычно неправильный подход. Это потом разрастается, в вызывающих функциях появляются свои флаги, и потом не разберешься, что надо поменять, чтобы работало как надо. По-моему, у Макконнелла про это было.
Neikist
13.11.2019 13:04Угу. Я кажется от Макконнела и почерпнул что мое старое стремление выносить вообще весь повторяющийся код в соответствии с DRY — не совсем верный подход в части случаев.
dustdevil
14.11.2019 03:19Правильный подход в этом случае — «вот когда будет меняться, тогда и скопирую». А то, о чем говорите Вы — overenginering, и это отнюдь не хорошо. Поскольку если код таки не поменяется в будущем (нашли другое решение, задачу вообще сняли и т.д.) — у вас явное нарушение принципа DRY.
Neikist
14.11.2019 08:36Ну так обычно такой код сразу и меняется после копирования. Иначе зачем его копировать? Т.е. пишем новый код, видим что часть бизнес логики похожа на бизнес логику в другом месте, копируем и правим.
quaer
13.11.2019 20:58Программист пишет код на придуманном кем-то языке, в среде, которая постоянно меняется. Как решается, что хорошо?
Хороший код — конкурентное преимущество. Что вас заставит растаться с этим знанием?
Чем человек зарабатывает, который учит вас как хорошо писать код?
Параметры командной строки нельзя в структуру объединить? Сформулируйте словами пожалуйста.
Посмотрите код утилит командной строки, который разбирает входные флаги. Там как правило на несколько экранов if-else.
Авторов таких утилит сразу никуда не брать?
Есть работа, и ее надо сделать, желательно быстро.
Как сделать работу быстро? Утрировано: отрефакторив кучу кода, чтоб выделить функцию, или скопировать кусок? Что первично: работоспособность программы или отформатированный по придуманным кем-то, постоянно меняющимся правилам, текст кода? (Вечная проблема...)
Ну аргумент функции так и называется Fs. И в вызывающей функции он называется Fs. И в вызывающей ее функции называется Fs. Что дальше?
Речь о том, что название frame_size нельзя признать хорошим не видя аргументов функции и не зная, для чего она предназначена. frame_size( bool flag ). И всё, название уже не выглядит столь хорошим, правда?
Что это должно доказывать? Сформулируйте словами пожалуйста.
Это пример названия функции, предоставленной пользователю. На него тоже должны правила распространятся, нет? И разве это не более важно, чем то, что внутри?
Вот вроде и приходим к тому, что не спросив, почему сделано именно так, невозможно понять, хороший код или плохой, так?
А желание иметь код простым и понятным наталкивается на суровые требования к тому, что и как программа должна делать, за какое время должна быть написана и за какое вознаграждение?
Может, надо просить кандидата написать сочинение на родном языке и тогда станет понятно, может он мыслить связно или нет?
И проверять способен он учиться и учить других?michael_vostrikov
13.11.2019 22:09Как решается, что хорошо?
Практикой. С одним чужим кодом проще работать, с другим сложнее.
Остальные вопросы я не понял, извините.
Там как правило на несколько экранов if-else. Авторов таких утилит сразу никуда не брать?
Если человек не приводит этот проект в качестве примера своего кода, то это не должно иметь значения. Если приводит, то если работодателю не нужен человек, который пишет такой код, то не брать. Если нужен, то брать. Если не нужен, но другие аспекты это компенсируют, то брать. Все как обычно.
Утрировано: отрефакторив кучу кода, чтоб выделить функцию, или скопировать кусок?
Вот в ваших рассуждениях в том и проблема, что утрировано. Вы не рассматриваете что произойдет дальше. Сегодня вы скопировали кусок и сэкономили время, завтра другой человек поменял в одном месте, а в другом не поменял, данные в базе попортились, пришлось отдельно исправлять код во втором месте, исправлять данные, компания получила недовольных клиентов и понесла убытки. В каком случае работа сделана быстрее и качественнее?
Что первично: работоспособность программы или отформатированный по придуманным кем-то, постоянно меняющимся правилам, текст кода?
Вы никак не поймете то, что вам несколько человек пытаются объяснить. Цель не в соответствии кода правилам оформления, а именно в его работоспособности, в том, что правильно написанный код улучшает эту работоспособность. В которую входит и приведение в работоспособное состояние при изменениях требований. Правила как раз для того и используют, потому что код, написанный по правилам, лучше работает, проще меняется и реже ломается.
Речь о том, что название frame_size нельзя признать хорошим не видя аргументов функции и не зная, для чего она предназначена.
Можно.
frame_sizeв любом случае лучше, чемFs, потому из него можно предположить назнчение переменной, а из названияFsнельзя. Не должно быть необходимости изучать сотню строк, чтобы разобраться, для чего нужна переменная. Код, который этого требует, считается плохим. Потому что отнимает больше времени и внимания при анализе, чем код с понятными названиями.
Кроме того, я взял его из вашего примера, и говорю это из практического опыта анализа этого кода. Я потратил 10 минут, чтобы разобраться, что это действительно
frame_size, а не сокращение отframes, выискивая, где эти функции вызываются и что туда передается. Зачем работать с человеком, который пишет непонятно, если можно работать с человеком, который сразу пишет понятно?
И всё, название уже не выглядит столь хорошим, правда?
Неправда.
frame_sizeвсе равно лучше чемFs. Потому что понятнее.
Это пример названия функции, предоставленной пользователю. На него тоже должны правила распространятся, нет?
Мне все равно непонятна ваша логика. Если некий известный Вася написал плохой код, значит все должны писать плохой код?
Как вам написали выше, это команда командной строки, которая в большинстве случаев печатается вручную, и короткое название оправдано. Но мне бы больше понравилось название
list, оно тоже достаточно короткое и при этом более понятное.
Вот вроде и приходим к тому, что не спросив, почему сделано именно так, невозможно понять, хороший код или плохой, так?
Нет. Переменные с непонятными названиями это всегда плохой код. Потому что написать понятное название несложно, а усилий на анализ требует меньше.
наталкивается на суровые требования к тому, что и как программа должна делать, за какое время должна быть написана и за какое вознаграждение?
Мы говорим о коде, который можно показывать работодателю. Если вы написали плохой код из-за финансовых или временных ограничений, просто не надо его показывать. Но финансовые или временные ограничения не делают плохой код хорошим.
Может, надо просить кандидата написать сочинение на родном языке и тогда станет понятно, может он мыслить связно или нет?
Как это поможет в проверке качества кода, который пишет кандидат? Никак. Значит и просить об этом не надо.
iPingvo
12.11.2019 20:20+1Интересная статья, спасибо. Но как быть тем, у кого в последние годы все проекты за NDA и код показать нельзя)
yuliatsareva Автор
12.11.2019 20:36Бoльшая часть нашего кода также хранится в приватных репозиториях, это норма, и мы все это понимаем :)
Мой посыл такой:
— Если вы изучаете что-то новое, бывает удобно сделать pet-проект, это и практика, и будет код, который можно показать.
— Если собираетесь давать ссылку на код в резюме, лучше, чтобы это был хороший код.
— Pet-проект — не требование, а способ попрактиковаться и привлечь к себе внимание. Рекомендую начинающим разработчикам или тем, кто меняет сферу работы.
А еще, об этом не было в статье, но иногда pet-проекты бывают такие классные, что сразу хочется общаться — видно, что человек горит своим делом.
Knightt
13.11.2019 16:55— Если вы изучаете что-то новое, бывает удобно сделать pet-проект, это и практика, и будет код, который можно показать.
Никогда так не делайте! :)
Если «изучаешь», то не надо это показывать всем — там такой говнокод иногда остается :)
Показывать можно то, что УЖЕ изучил!
panteleymonov
13.11.2019 01:57Тут и без NDA если не сохранил себе все что делал на работе, то считай что сам себе NDA устроил. На самом деле спустя годы практики, фанатично сохранять себе то, что сделал в N-ый раз кому то на чужих условиях, это стремно. Либо за свою практику сделал очень мало, что каждая реализация кажется неповторимой, либо просто ничего ни делал, поэтому сохранял чтоб хоть что то было.
У меня нет привычки тырить свой же код с предприятия где я работал, и так своего хватает. И чаще получается наоборот, я прихожу и внедряю свое решение, которое тестил для своих нужд. Какое тут может быть NDA? Ты уже этот алгоритм использовал у «дяди Пети с тетей Васей», а теперь ты не должен вспопинать про них, потому что использовал тоже самое на новом месте работы с NDA. Может еще про реализацию деревьев напрочь забыть.
На самом деле NDA не запрещает демонстрировать и свой код и знания. Помимо срока годности, если у кого то «бога боязнь» NDA, свободно демонстрируйте свой код как часть проекта не относящегося к работе где либо. Если работодатель хочет знать на каком предприятии вы это писали — нафиг такого работодателя.
Pro-invader
13.11.2019 07:54Для меня проблема выбрать, что писать. Хочу в процессе изучения Kotlin начать писать pet-project для Android, обязательно сетевое с использованием API, но не могу определится что. Уже просмотрел кучу списков с API, но идеи нет.
DrZ0idberg
13.11.2019 14:21+1Можно просто взять любое существующее приложение, и попробовать его повторить. Не целиком, конечно, а отдельные экраны или фичи.
411
13.11.2019 10:34Я бы сказал, что в самом начале важнее не содержание опыта, а скорей стаж и набор ключевых навыков, по которым вы себя позиционируете, а детальный опыт можно указать ниже вместе с технологиями и достижениями.
Всё таки описание опыта может занять не одну страничку и не всегда сходу можно понять, а в чем кандидат хорош, а на самой первой стоит дать сразу понять HR или тех специалисту на собеседовании, какими навыками обладаете и как себя позиционируете.
darkAlert
13.11.2019 12:07Признаюсь, мысленно я ставлю дополнительный плюсик кандидатам с профильным образованием в топовых вузах.
Всегда такие требования раздражают, особенно когда еще просят PhD из топовых вузов. Ну вот не жил я в топовом городе с топовым вузом, а закончил обычный провинциальный вуз, и что, теперь на мне метка неполноценного специалиста?!yuliatsareva Автор
13.11.2019 14:57Мне кажется, вы меня не до конца поняли, или я недостаточно ясно донесла свою мысль. Если вы окончили не топовый вуз, это не проблема, я лично никогда не делала из этого каких-то плохих выводов. Главное, чтобы у вас были знания и навыки. Наоборот, в статье я никому не советую учиться только ради корочки. Это время можно потратить на самообразование и практику.
Как раз в статье я писала, что лично знаю несколько топовых коллег не окончивших ВУЗ. И также знаю очень скилловых ребят, учившихся не по IT-специальности.
Но если возможность такой топовый ВУЗ окончить есть — почему бы это не сделать? Это и база, и знакомства, и возможность стажировки и первого трудоустройства в хорошую компанию.
Признаюсь, мысленно я ставлю дополнительный плюсик кандидатам с профильным образованием в топовых вузах.
Дополнительный — ключевое слово. Приятно знать, что кандидат окончил ВУЗ, где дают хорошую базу, или выпускники этого ВУЗа у нас уже успешно работают.
atercygnus
13.11.2019 12:09А как насчёт разнообразных mooc? Coursera там, stepic, edx, и прочее?
Или более основательные школы и курсы, где живые преподаватели чему-то обучают за деньгу?yuliatsareva Автор
14.11.2019 00:30Тут у меня нет большого опыта, но расскажу, что знаю.
На Coursera мне очень нравятся курсы по алгоритмам, позволяют освежить знания. Особенно те, что ведет Седжвик — мы по его книге в универе учились, а тут он почти живьем читает лекции! Из прикладных курсов по разработке я пробовала только Python и что-то про мобильную разработку — просто для общего развития. Дело было давно, и тогда уровень мне не очень понравился. Как будто это были курсы программирования для непрограммистов, очень просто и медленно. Но возможно сейчас все поменялось.
С edx вообще не было опыта.
Из прикладных предпочитаю Pluralsight (за него плачу сама). Angular University и egghead у нас корпоративные, иногда там смотрю что-нибудь.
Про школы и курсы с живыми преподавателями — когда мне было актуально, это еще не было развито, поэтому сама обучение не проходила. На собеседовании встречалась с выпускниками некоторых онлайн-школ, уровень был пониже ожиданий. Но я прекрасно понимаю, что в любой школе можно плохо учиться, здесь во многом от студента зависит, его работы и мотивации.
Кстати, вот такую школу мы с коллегами проводим fintech.tinkoff.ru Но она не онлайн, занятия проходят раз в неделю в офисе + домашка.
Если говорить про резюме — при отсутствии опыта, я бы указала пройденные курсы (я и указывала, когда искала работу на фронтенде, а опыт у меня был с другими технологиями).
kamirra_s
13.11.2019 12:10С удовольствием прочитала статью и решила написать вам спасибо. По делу, просто и понятно.
У самой проблема с кодом на ГитХабе, все проекты под NDA, работа кипит и свободного времени писать свое пока нет. Можно запилить конечно что-то простое и легкое, но не хочется.
Eldhenn
13.11.2019 12:34> Сомневаетесь, что считать достижениями? Вот несколько идей:
> Этот список можно продолжать
А если я не внедрял тайпскрипт, не летал на луну, не изобретал велосипед, а решал задачи и закрывал тикеты? Всё, негоден к строевой службе?
GeBoN
13.11.2019 13:19А если я не внедрял тайпскрипт, не летал на луну, не изобретал велосипед, а решал задачи и закрывал тикеты? Всё, негоден к строевой службе?
Пиши — «Боец невидимого фронта»-(енда). ))
musicriffstudio
13.11.2019 12:34Работники отдела кадров хвалят методику отдела кадров.
С точки зрения работника такие статьи смысла не имеют. В соседнем таком же офисе что и автор сидит точно такая же кадровичка, но с диаметрально противоположными требованиями.
Эти требуют наличия проектов на гитхабе, другие наоборот ставят минус, типа тратит рабочее время на безделушки. Ну и т.д.Neikist
13.11.2019 12:47другие наоборот ставят минус, типа тратит рабочее время на безделушки
Ну вообще ожидается что проекты на гитхабе в свободное время делаются (если это не руководитель поставил задачу внутреннюю либу или софт в open source выложить).GeBoN
13.11.2019 13:39Ну вообще ожидается что проекты на гитхабе в свободное время делаются
Любой проект, если это не страничка любимого кота в инете или новый калькулятор-медиаплеер с «нескучными скинами», занимает некоторое «место в голове».
Если после дня программирования вечером заняться художественным выпиливанием лобзиком — это переключение и отдых голове, а программировать на работе и дома уже нет, мне так кажется.Neikist
13.11.2019 13:47С одной стороны да, с другой не на работе же пробовать новые подходы на привычных задачах или же пробовать вообще незнакомые задачи решать (не всегда на работе могут предоставить разнообразие задач, а расти хочется).
GeBoN
13.11.2019 15:13не всегда на работе могут предоставить разнообразие задач, а расти хочется
Это бес-порно))
Я к тому что чрезмерное увлечение может привести к повышенной усталости.
Про «выгорание» не говорю, потому как если делаешь для себя «в охотку», то всё в кайф.
0xd34df00d
13.11.2019 17:09Если работодатель претендует на моё время и голову после работы, то пусть платит не за 8 часов в сутки, а за 16 (ну и за выходные).
А лучше, действительно, пусть сразу даст об этом знать, потому что опыт «ну ты же вчера после работы опенсорс свой пилил, а мог бы остаться и доделать рабочую таску» у меня есть, и нормальным я это не нахожу.
Crafter2012
13.11.2019 19:45«ну ты же вчера после работы опенсорс свой пилил, а мог бы остаться и доделать рабочую таску»
Опенсорсу время, работе час.0xd34df00d
13.11.2019 21:20Не час, а восемь. Но, если я обычный наёмный работник без доли, то именно так, да.
Knightt
13.11.2019 17:04Как-то искал новую работу, работая на «текущей»…
Дали тестовое задания — ну и получалось, что на работе половину времени (а то и все) в голове крутились решения тестовых задач, а не текущих. Хотя весь код тестовых писался дома.
Но по факту я выпал из работы компании на 3 дня — до сих пор совесть мучает :(
Так что я хз как люди могут полностью отключится на работе от своих pet-проектов с «интереснейшими» задачами и заниматься текущими -«рутинными»Neikist
13.11.2019 17:13Почти никогда такой проблемы не было. Может потому как раз, что если мне приходит мысль с чем-то поэкспериментировать то я это записываю в таск лист и не думаю эту мысль на работе, так как знаю что дома у меня еще будет на это время. Иногда конечно бывает что на работе что-то прорывается, но обычно что-то в стиле: о, применил то же что и дома; или: так, вот это я тут так сделал, можно будет дома поиграться на одном из игрушечных проектов с этим решением. И дальше иду.
Может это еще и от человека зависит. Кто-то вот на удаленке отвлекается на домашние дела, а кто-то нет.
Впрочем, хз как оно будет если буду тестовое делать для кого нибудь. Скорее всего тоже буду отвлекаться в рабочее время на подумать ибо там и сроки, и требования к коду и прочее.
GeBoN
13.11.2019 13:17+3С точки зрения работника такие статьи смысла не имеют. В соседнем таком же офисе что и автор сидит точно такая же кадровичка, но с диаметрально противоположными требованиями.
Соглашусь — статья «В пользу бедных», с банальной идеей что «Лучше быть богатым и здоровым, чем бедным и больным».
Например:
Вы спросите: «А что насчет стандартных формулировок „стрессоустойчив“, „легко обучаем“ и подобных определений, которые все еще можно подсмотреть в примерах резюме?» На меня они не производят никакого впечатления, и я искренне не понимаю, почему их все еще используют.
Зайдите на ХХ.РУ там в 90% вакансий «стрессоустойчивость» отдельно выделена, так же как и «динамично развивающаяся, лидер рынка» и «молодой-дружный коллектив». То есть Ваши коллеги не согласны с Вами чуть менее чем полностью.
PS По моему мнению, при отборе на технические специальности отдел кадров должен проверить справки из психушки-алкашки, а собеседование-тесты дело профессионалов.
Часто кадровицы сидят и из-за всех сил пытаются «обозначить свою значимость», находят какие-нибудь дебильные тесты в инете или просто додумывают за кандидата его историю и мнят себя великими психологами.Кажется, всем уже известно, что частая смена работы не красит соискателя. Для меня частая смена работы — три и более мест, где вы работали меньше года
а если человека кинули три раза подряд с работой? А может человек приехал с «провинции», из города который «загибается»? надо подробно описывать все детали предыдущих увольнений? Кто-нить будет это читать? Или скажут сопли в резюме нам не нужны?
Ну конечно если речь идет о принятии нового работника в отдел кадров, то тут пусть развлекаются в полный рост, хоть с тестами Роршаха.))yuliatsareva Автор
14.11.2019 00:13> Зайдите на ХХ.РУ там в 90% вакансий «стрессоустойчивость» отдельно выделена, так же как и «динамично развивающаяся, лидер рынка» и «молодой-дружный коллектив». То есть Ваши коллеги не согласны с Вами чуть менее чем полностью.
Честно говоря, «стрессоустойчивость» в требованиях к разработчикам мне не попадалась как минимум очень давно. Для примера, я проверила актуальные вакансии для фронтендеров в Яндексе, Мейле, Авито…
И как разработчик, могу сказать, что на меня «стрессоустойчивость» и подобные фразы не производят впечатления — ни хорошего, ни плохого. Решает опыт и навыки, стэк технологий, сложные задачи, которые приходилось решать. Именно об этом и хочется читать в резюме, чтобы прикинуть насколько опыт матчится с работой в нашей команде.GeBoN
14.11.2019 00:26+1. Решает опыт и навыки, стэк технологий, сложные задачи, которые приходилось решать. Именно об этом и хочется читать в резюме, чтобы прикинуть насколько опыт матчится с работой в нашей команде.
Значит Вы приятное исключение.
Часто «стрессоустойчивость» маскируют «круглыми фразами», типа «умение работать в многозадачном режиме», «умение ориентироваться в динамично меняющейся обстановке », «способность быстро переключаться между задачами» и тд
Последний перл который мне попался, не помню уж чья вакансия — «Способность работать под давлением». Прям сразу перед глазами всплыл финальный эпизод из первого Терминатора, когда Т800 попал «под давление», но на последнем заряде батареи пытался выполнить задачу ))
dyadyaSerezha
15.11.2019 14:38Зайдите на ХХ.РУ там в 90% вакансий «стрессоустойчивость» отдельно выделена, так же как и «динамично развивающаяся, лидер рынка» и «молодой-дружный коллектив». То есть Ваши коллеги не согласны с Вами чуть менее чем полностью.
Значит, 90% коллег автора пишут булшит, потому что я не видел ни одного резюме с самоописанием типа «нервный, не уверенный в себе, быстро впадаю в панику, не могу общаться с коллегами» и прочее.GeBoN
15.11.2019 18:35Значит, 90% коллег автора пишут булшит, потому что я не видел ни одного резюме с самоописанием типа «нервный, не уверенный в себе, быстро впадаю в панику, не могу общаться с коллегами» и прочее.
Я как-то писал в отклике что хотел бы добавить в их «молодой и дружный коллектив» немного «старости и склочности».
Почему-то мне не ответили. ))
i360u
13.11.2019 14:19Любой состоявшийся специалист имеет специализацию, предпочитает какой-то конкретный стек технологий и позиционирует себя как носитель конкретного набора скилов. На мой взгляд, описание всех этих моментов — самая важная часть резюме. Однако, эта часть часто бывает либо полностью пропущена, либо отнесена к маловажным «дополнительным сведениям», типа «прав категории Б» и «стрессоустойчивости». Как и в данной статье.
river-fall
13.11.2019 14:33+2Вообще, когда пишешь резюме, часто есть такое ощущение, что кроме тебя еще сотня кандидатов на какое-нибудь место.
В реальности (если вы не гугл), то на миддл-сеньор позицию вам пришлют дай боб штук 10 резюме, достойных внимания, плюс еще человек 5-10 смогут привести рекрутёры или сам тимлид поищет по профильным сообществам и сможет кого-то найти.
Мне понравилась фраза о том, что резюме — это как трейлер к фильму. Главная его задача — так, чтобы после прочтения было интересно поговорить еще.
Но на рынке такая ситуация, что если у вас там не написано совсем дикой дичи, на первый тур вас скорее всего позовут. А дальше оно уже не играет никакой роли.GeBoN
13.11.2019 15:33Мне понравилась фраза о том, что резюме — это как трейлер к фильму. Главная его задача — так, чтобы после прочтения было интересно поговорить еще.
Проблема только в том что пишешь трейлер для будущего «научного руководителя», а читает твой сценарий ( и принимает решение пущать/не пущать дальше ) «секретарь зама по хозяйственной части.»
PS Есть конечно специализированные кадровые агентства, при крупных софтовых конторах.
Там ХР-ы постоянно варятся в этой среде, знают все тонкости и толстости момента, ну и главное имеют возможность оперативно консультироваться со специалистами своей фирмы.river-fall
13.11.2019 15:46Если у нанимающего руководителя есть такое желание (например, не хватает кандидатов), он всегда может просмотреть отфильтрованные на первом этапе резюме
GeBoN
13.11.2019 16:05Если пришло 20 резюме и ХР-ы передали «на верх» только 10, то начальник будет выбирать из этих 10, до просмотра «фильтрата» дело не дойдет.
Если совсем плохо с кандидатами, то заряжают поиск по новой — вакансия не поднимается, а выставляется как новая.
AndreiR98
13.11.2019 14:58Такой вопрос, если ты идёшь на джуна, есть ли смысл указывать в резюме свои аккаунты на codewars, hackerRank и т.п.?
yuliatsareva Автор
13.11.2019 21:11Если аккаунты не совсем пустые, а реального рабочего опыта нет или мало — я бы точно указала. Да даже если и опыт есть — why not… Мы с коллегами, уже взрослые разработчики-тимлиды, тоже иногда решаем/обсуждаем и рекомендуем нашим джунам для развития.
Когда общаюсь с джунами / стажерами с прицелом в свою команду, я на аккаунты очень хорошо реагирую :)
Но даже если не указывать, такие сайты здорово помогают набить руку.
Mogwaika
13.11.2019 22:27Без обратной связи только больше научишься писать говнокод…
yuliatsareva Автор
13.11.2019 23:39На сайтах типа LeetCode, CodeWars решение обычно небольшая функция, вряд ли именно там научишься писать говнокод. А вот закрепить знание синтаксиса и умение реализовать решение в коде — бесценно.
Тут еще замечу, что все джуны разные — кто-то джуниор во фронтенде, но до этого 4 года в университете занимался программированием, а кто-то раньше не программировал и пришел совсем из другой профессии. И как раз для тех, кто раньше не программировал, практика просто необходима.
Я всегда прошу стажеров и джуниоров писать код, и ожидаю, что кандидат понимает, что такое массив, цикл, условие… Это как минимум.
PS: на CodeWars среди решений других участников иногда вижу однострочные, но плохо читаемые функции, с большим числом голосов «Clever»… Если учиться исключительно на таких решениях, то можно нахвататься странных идей, но это прямо надо постараться.
PPS: Кстати, я нигде не писала, что отсутствие ссылки — это очень плохо ) В большинстве случаев такой ссылки нет, будем честными. Но это мой совет — практиковаться, и об этом активном желании развиваться сообщить потенциальному работодателю.Mogwaika
13.11.2019 23:52Ну у меня как раз ситуация, что я полез играться с высокоуровневыми языками после низкого уровня и у меня получается индусский код и я очень завидую этим однострочным решениям. А большинство хитрого синтаксиса всегда можно расписать простым.
p.s. я и спросил выше, что лучше, говнокод или отсутствие ссылки на него?yuliatsareva Автор
14.11.2019 03:50А, понятно, выше я подумала, что это в контексте «говнокод или отсутствие ссылки» для джунов, но вы, похоже, говорите о другой ситуации — когда опыт есть, просто в других языках )
Чисто по-человечески, я бы не смогла отправить ссылку на код, который заведомо считаю плохим, потенциальному работодателю. А с другой стороны, если вы видите проблему, значит можете попытаться ее исправить и показать наилучший код, который способны написать сейчас.
Со стороны интервьюера — понимая, что у кандидата опыт в других технологиях, но сейчас он хочет переквалифицироваться, я бы, наверно, хотела посмотреть код — в худшем случае, кандидата не пригласят на собеседование, но зато все сэкономят время — кандидат в том числе (и может дело даже не в говнокоде, а в том, что в проект прямо сейчас нужен опытный разработчик, который начнет закрывать таски с первого дня). В теории, по коду могут дать фидбэк (или его можно попросить явно).Mogwaika
14.11.2019 14:23Для джунов, если я переквалифицируюсь, то естественно, что знания на уровне джуна или ниже… Или вы их тоже отправляете «начинать закрывать таски с первого дня»?
Сэкономит время интервьверу, но я не узнаю о своих косяках и ошибках.yuliatsareva Автор
15.11.2019 00:49+1Сэкономит время интервьверу, но я не узнаю о своих косяках и ошибках.
И вам тоже время сэкономит, не надо лишний раз ехать на интервью (даже если по скайпу — тоже время). Кажется, что получить фидбэк по коду можно менее энергозатратным способом — опубликовать код на тематическом сайте или напрямую написать специалистам и попросить совета.
Опять же, интервью в разных местах по-разному проводят — где-то объяснят подробно что не так, где-то толком ничего не скажут, где-то дадут рекомендации и список материалов для подготовки, где-то нет… Но тут личный выбор каждого, каким способом искать фидбэк.
«начинать закрывать таски с первого дня»
Может грубовато прозвучало ) Идея в том, что иногда нужен разработчик опытный (уверенный миддл или выше), способный быстро влиться в команду и не требующий много опеки и обучения — вот это я назвала «начинать закрывать таски с первого дня». Иногда можно взять менее опытного миддла, есть возможность менторить и растить. Иногда готовы брать джунов без опыта, понимая, что обучать придется много, но зато и перспективы отличные.
Но так-то да, обычно джуны тоже приступают к работе над реальными задачами с первого дня. Просто это задачи другого уровня.Mogwaika
15.11.2019 00:58Спасибо за развёрнутый ответ.
Хотя я и не очень понял про публикацию кода с codewars на другом тематическом сайте ради фидбека))yuliatsareva Автор
15.11.2019 01:15Ну, я имела в виду, что если вы действительно хотите фидбэк, и есть код, чтобы предъявить, то можете его опубликовать где-то и напрямую задать вопрос об этом коде другим разработчикам. Будет ли это код с codewars? Не обязательно. Кажется, для качественного фидбэка надо чуточку больше кода… На самом codewars тоже есть некие дискуссии, но не уверена, что там часто дают ответ.
Вообще в последнее время LeetCode больше нравится )
Еще помню пару интервью, когда попадались вроде бы хорошие мотивированные ребята, но со слабыми навыками написания кода, взять их в команду не могли. И я им сама говорила, что надо попрактиковаться и можно задавать вопросы мне, если что. Никто, правда, с вопросами не обращался :-DMogwaika
15.11.2019 01:26со слабыми навыками написания кода, взять их в команду не могли. И я им сама говорила, что надо попрактиковаться
Каковы симптомы подобного? Ну и вы же понимаете, что без реальных задач практиковаться сложно, тем более джуну.yuliatsareva Автор
15.11.2019 03:22Каковы симптомы подобного?
Допустим, решаем задачу, не требующую специальных знаний. Тот же fizzbuzz или что-то вроде этого leetcode.com/problems/valid-anagram
И кандидат не знает как подступиться вообще или не может реализовать озвученное на словах, потому что плохо представляет работу с циклами, переменными, условиями.
Будет полезнее дома задачки покодить, чем выходить на работу и сразу нырять в реальные задачи, где помимо синтаксиса языка еще фреймворк, бизнес-логика, большой объем кода, тесты надо учиться писать… Не до изучения циклов :)Mogwaika
15.11.2019 10:09Как-то у вас слишком просто получается, что вы готовы брать джунами тех, кто кое-как сможет написать такой код, про оптимальность которого вы даже не заикнулись, по сравнению с авито в соседней статье, которым нужны миддлы по цене джунов…
yuliatsareva Автор
15.11.2019 10:24Не-не, это я говорю про симптомы «слабых навыков написания кода». С этого интервью джуна начнется. И уметь писать код — must have даже для студента с нулевым опытом.
Но это далеко не конец… ))Mogwaika
15.11.2019 10:28Ок, я просто это понял, как если бы хорошие мотивированные ребята написали, то их бы взяли. Тогда интересны задачки на заключительном этапе интервью джуна, по которым можно уже что-то решить, не необходимое, а ближе к достаточному условие)))
Knightt
13.11.2019 17:13вот у меня сейчас «конфликтное» резюме… из-за того, что решил изучать новую технологию…
писал довольно долго на С++ на фрилансе, но решил выйти в «белую зп», а в своем городе смог найти только php-разработку
в итоге: с php разобрался довольно быстро, ну и менял работы раз в 6-9 месяцев по причине зарплатных хотелок (обычно +30-35% от текущей зп), потом пара сартапов не взлетело… итого куча смен мест работы…
вот как мне теперь быть, чтоб не пасть «лицом в грязь» перед HR?GeBoN
13.11.2019 17:21вот как мне теперь быть, чтоб не пасть «лицом в грязь» перед HR?
Устроится на «галеру» и отпахать там 3-4 года, чтобы «смыть позор» пОтом и кровью стертых пальцев.
michael_vostrikov
13.11.2019 17:37+1Оставьте пару более-менее нормальных мест, про остальные напишите "фриланс". Понятно, что это не совсем соответствует положению дел, но раз рекрутеры игнорируют, что так может быть по объективным причинам, то по-другому не получается.
dyadyaSerezha
15.11.2019 14:44+1Автор молодец, толковая статья. Вот только не надо было как бы невзначай впихивать эту «Британскую высшую школу дизайна» — слишком выпирает самолюбование. В-)
yuliatsareva Автор
15.11.2019 14:52Спасибо за фидбек )
Про самолюбование — честно говоря, даже мысли не было, что это так воспринимается. Хотела привести пример, выходящий за рамки онлайн-курсов. Ну и я проходила коротенький курс, ничего пафосного ))
ISVir
По поводу гитхаба, немного, не согласен. Если у меня там есть какие-то древние проекты, которые я бы, на сегодняшний день, сделал совсем иначе — это не значит, что им там не место. У вас есть возможность посмотреть дату создания проекта, дату последнего коммита и самостоятельно отыскать самое свежее из представленного.
yuliatsareva Автор
С этим я не буду спорить. Обычно я смотрю самое свежее из того, что есть, 1-3 проекта, в зависимости от объема и времени изменений.
Если проектов много, можно явно указать в резюме один или несколько наиболее интересных.
В статье я хотела обратить внимание на ситуацию, когда все проекты достаточно старые или все новые, и автор указал GitHub, но никак не выделил, какой код стоит посмотреть.
Waterplea
На гитхабе можно запинить несколько репозиториев. Мне кажется, хороший вариант.
undersunich
Приведу пример.У меня как разработчика в моем репозитарии более 25 проектов за 10 лет.Это части проектов, так что бы показать где и чем я занимался.Из них 5 только лично мои.Остальные это отражение требований заказчика и хода движения проекта.Как я их должен привести в порядок? Совет явно от человека который не в теме уж извините.Вот начитаются HR-ры таких советов а потом на работу тебя не берут из за того что ты в таких проектах участвовал.Это при том что проекты реальные и прибыль заказчикам приносят.Умейте читать между строк.И не ешьте на ночь сырых помидоров(как классик советовал) ))
EvilsInterrupt
А зачем те репозитории, которые вы не хотите показывать делать открытыми? Разве нельзя сделать закрытым и добавить только того, кого этот репозиторий касается?
undersunich
Так это проекты за 10 лет.Закроешь — говорят у Вас мало опыта.Откроешь говорят — фу-так уже никто не пишет.При этом на те проекты под которыми реальный бизнес бегает
EvilsInterrupt
Я бы порекомендовал поправить readme.md, который лежит в корне с точным описанием почему так все страшно выглядит и зачем именно так надо
0xd34df00d
Так там же видно, когда эти проекты последний раз трогали, и сколько им лет.
У меня есть что-то, что я начинал писать лет в 15, у чего есть очень косячные решения и легаси, и так далее, и ни у кого никаких вопросов вообще не было.
yuliatsareva Автор
> Совет явно от человека который не в теме уж извините
Извините, но я все-таки не соглашусь, я не HR, и надеюсь, что все же немного в теме )) У многих есть и старые проекты, и проекты на языках или с использованием технологий, с которыми больше не хотим работать, и студенческие курсовые…
Так ведь и код не машина смотрит, а смотрим мы — разработчики, будущие коллеги кандидата (тимлиды или другие опытные разработчики команды).
Отличить старый проект от нового нет проблемы. Если команда ищет фронтендера, а у вас и фронт, и бэк, и может вы еще увлекаетесь ML — разберемся куда смотреть. Если есть readme с пояснениями — прочитаем. Для простоты лучше самые интересные репозитории запинить, можно про них явно написать в резюме/письме или что-то скрыть в приватные… Ну мы же все разумные люди :)
Но когда кандидат сам приложил гитхаб, а код ну совсем не очень (code smells, явное незнание возможностей языка, фреймворка и т.п.) — это производит плохое впечатление. Вы сами разве захотели бы работать с коллегой, код которого считаете грязным или неоптимальным? Вот поэтому и советую привести то, что собираетесь демонстрировать, в хороший по вашим нынешним меркам код (не 25 проектов за 10 лет, конечно).
undersunich
Еще раз для тех кто не прошел 25 проектов: код отражает требования проекта.Это зеркало тех условий в которых работает разработчик.Если на проекте принята идеалогия скрупулезной чистоты, следование последним техно-трендам так и будет.Зачастую для решения задачи хватает минимум средств и минимум вложений.В этом суть бизнеса.За минимум вложений получить максимум результата.Идеальный код возможен в идеальном мире.Дайте мне неограниченное время, неограниченные финансы и я Вам дам идеальный код.Вы HR-ры и тимлиды стали техно-роботами, Вы про человека забыли.Я тоже неоднократно был лидом с разными людьми и это мой Вам ответ
michael_vostrikov
Тут вот какое дело. Тот факт, что ваш код кому-то приносит прибыль, сам по себе ничего не означает. У фирмы, которая ищет работника, есть свой код, который приносит прибыль. Ваш код приносит прибыль, и код кого-то другого приносит прибыль. Если в вашем коде сложнее разобраться, а в коде другого человека проще, то возьмут его, а не вас.
undersunich
В чьем коде можно лучше разобраться можно понять когда Вы в проекте УЖЕ работаете достаточное время.Только тогда можно сравнивать.Если на проект ищется человек (если это не юниор) то я гарантирую Вам как человек с достаточным опытом, что Вы изначально не знаете всех возможностей человека и принимать его судя только по коду этой информации недостаточно.
michael_vostrikov
Нет. Вы подменяете понятия архитектуры и оформления, хорошего кода и кода, правильно выполняющего задачу. Оценить архитектуру можно после знакомства с проектом, и это все понимают, но и то во многих случаях достаточно описания. А если вы пишете однобуквенные переменные и показываете этот код в качестве "смотрите, вот как я пишу", то совершенно неважно, какой был проект и какие у вас возможности, другим людям с таким кодом будет сложно работать.
Судя только по коду никто не принимает. В данной статье описано много разных моментов. А вот отказать могут. Кроме вас есть и другие кандидаты, чьи возможности тоже неизвестны. Зачем кому-то проверять, есть ли у вас возможности, которые будут компенсировать плохой код, если можно проверить другого кандидата, который точно пишет нормальный код.
undersunich
Дальше спорить и приводить аргументы уже не имеет смысла.Каждый комментирует в силу своих знаний, умений и опыта.Я привел доводя с которыми сталкивался на протяжении последних 15 лет, Вы свои.Текущие тенденции понятны и менятся надо всем,HR-рам, техно-лидам в том числе а не только разработчику который посути раб проекта(если только это не его от и до проект)
Neikist
Хе, последнее что я делал на гитхабе, буквально на днях — реверсинг мобильного приложения, и часть классов там тупо восстановлены из декомпилированных исходников, с переменными типа var1, var2 и методами aaz и подобными, после минификации. Вот никакого желания их переименовывать нет)) Если посмотреть на код с т.з. чистоты — ужос ужос.
yuliatsareva Автор
Код на гитхабе смотрят живые люди — опытные разработчики, часто тимлиды команд, куда ищем новых коллег (по-крайней мере, так происходит у нас). Если по коду/readme/комментариям понятно, что это декомпилированные исходники, то никто не будет придираться к чистоте.
Имхо — наоборот, интересно узнать как, зачем и почему вы этим занимались, я бы обсудила на собеседовании :)
Neikist
Ну, справедливости ради в том же проекте и gradle файл который сам писал — тоже довольно грязный, тут уже не оправдаться что сорцы декомпилированные)
Maccimo
Как-то странно вы его реверсили,
classes.dex4Мб, а в репозитории всего-то с дюжину*.java-файлов, да и те стандартные андроидовские, из SDK.fernflower -ren=1 ...да-urc=...по необходимости и железяка возьмёт всю рутину по переименованию на себя.Потом пройтись с
Shift-F6наперевес в Android Studio и допилить до приемлемого состояния, попутно выкинув все SDK-шные классы.Neikist
А у меня не было цели разобраться что к чему в приложении, была цель просто процессу ковыряния в apk научиться))
Revolt27
Хранить на гитхабе старый код не просто можно, а даже нужно.
Это уникальная возможность посмотреть чему научился кандидат за какой-то промежуток времени, а одинаковые ошибки в коде недельной и годовой давности скажут сами за вас.