Насчет репозиториев – принято, в следующий раз продумаем этот момент. В этом году решили так не делать. Мы не договаривались об этом с участниками, а кто-то уже успел удалить проекты.
Но небольшой обзор проектов победителей скоро появится на сайте, может быть уже сегодня
Нам хотелось собрать коммьюнити в одном пространстве, познакомиться лично, плюс наградить победителей на сцене - чего нельзя было бы сделать на разделенных площадках, поэтому провели финал в Москве
Остальных в открытом доступе нет, только у участников конференции (или приобрести доступ к видео отдельно). Если заинтересовал доклад не из публичного списка, можно поспрашивать знакомых…
По некоторым темам можно найти статьи или прошлые связанные доклады того же спикера (например, про конструктивную конфронтацию с воркшопа видео полно).
Спасибо за фидбек )
Про самолюбование — честно говоря, даже мысли не было, что это так воспринимается. Хотела привести пример, выходящий за рамки онлайн-курсов. Ну и я проходила коротенький курс, ничего пафосного ))
Не-не, это я говорю про симптомы «слабых навыков написания кода». С этого интервью джуна начнется. И уметь писать код — must have даже для студента с нулевым опытом.
И кандидат не знает как подступиться вообще или не может реализовать озвученное на словах, потому что плохо представляет работу с циклами, переменными, условиями.
Будет полезнее дома задачки покодить, чем выходить на работу и сразу нырять в реальные задачи, где помимо синтаксиса языка еще фреймворк, бизнес-логика, большой объем кода, тесты надо учиться писать… Не до изучения циклов :)
Ну, я имела в виду, что если вы действительно хотите фидбэк, и есть код, чтобы предъявить, то можете его опубликовать где-то и напрямую задать вопрос об этом коде другим разработчикам. Будет ли это код с codewars? Не обязательно. Кажется, для качественного фидбэка надо чуточку больше кода… На самом codewars тоже есть некие дискуссии, но не уверена, что там часто дают ответ.
Вообще в последнее время LeetCode больше нравится )
Еще помню пару интервью, когда попадались вроде бы хорошие мотивированные ребята, но со слабыми навыками написания кода, взять их в команду не могли. И я им сама говорила, что надо попрактиковаться и можно задавать вопросы мне, если что. Никто, правда, с вопросами не обращался :-D
Сэкономит время интервьверу, но я не узнаю о своих косяках и ошибках.
И вам тоже время сэкономит, не надо лишний раз ехать на интервью (даже если по скайпу — тоже время). Кажется, что получить фидбэк по коду можно менее энергозатратным способом — опубликовать код на тематическом сайте или напрямую написать специалистам и попросить совета.
Опять же, интервью в разных местах по-разному проводят — где-то объяснят подробно что не так, где-то толком ничего не скажут, где-то дадут рекомендации и список материалов для подготовки, где-то нет… Но тут личный выбор каждого, каким способом искать фидбэк.
«начинать закрывать таски с первого дня»
Может грубовато прозвучало ) Идея в том, что иногда нужен разработчик опытный (уверенный миддл или выше), способный быстро влиться в команду и не требующий много опеки и обучения — вот это я назвала «начинать закрывать таски с первого дня». Иногда можно взять менее опытного миддла, есть возможность менторить и растить. Иногда готовы брать джунов без опыта, понимая, что обучать придется много, но зато и перспективы отличные.
Но так-то да, обычно джуны тоже приступают к работе над реальными задачами с первого дня. Просто это задачи другого уровня.
А, понятно, выше я подумала, что это в контексте «говнокод или отсутствие ссылки» для джунов, но вы, похоже, говорите о другой ситуации — когда опыт есть, просто в других языках )
Чисто по-человечески, я бы не смогла отправить ссылку на код, который заведомо считаю плохим, потенциальному работодателю. А с другой стороны, если вы видите проблему, значит можете попытаться ее исправить и показать наилучший код, который способны написать сейчас.
Со стороны интервьюера — понимая, что у кандидата опыт в других технологиях, но сейчас он хочет переквалифицироваться, я бы, наверно, хотела посмотреть код — в худшем случае, кандидата не пригласят на собеседование, но зато все сэкономят время — кандидат в том числе (и может дело даже не в говнокоде, а в том, что в проект прямо сейчас нужен опытный разработчик, который начнет закрывать таски с первого дня). В теории, по коду могут дать фидбэк (или его можно попросить явно).
> Совет явно от человека который не в теме уж извините
Извините, но я все-таки не соглашусь, я не HR, и надеюсь, что все же немного в теме )) У многих есть и старые проекты, и проекты на языках или с использованием технологий, с которыми больше не хотим работать, и студенческие курсовые…
Так ведь и код не машина смотрит, а смотрим мы — разработчики, будущие коллеги кандидата (тимлиды или другие опытные разработчики команды).
Отличить старый проект от нового нет проблемы. Если команда ищет фронтендера, а у вас и фронт, и бэк, и может вы еще увлекаетесь ML — разберемся куда смотреть. Если есть readme с пояснениями — прочитаем. Для простоты лучше самые интересные репозитории запинить, можно про них явно написать в резюме/письме или что-то скрыть в приватные… Ну мы же все разумные люди :)
Но когда кандидат сам приложил гитхаб, а код ну совсем не очень (code smells, явное незнание возможностей языка, фреймворка и т.п.) — это производит плохое впечатление. Вы сами разве захотели бы работать с коллегой, код которого считаете грязным или неоптимальным? Вот поэтому и советую привести то, что собираетесь демонстрировать, в хороший по вашим нынешним меркам код (не 25 проектов за 10 лет, конечно).
Тут у меня нет большого опыта, но расскажу, что знаю.
На Coursera мне очень нравятся курсы по алгоритмам, позволяют освежить знания. Особенно те, что ведет Седжвик — мы по его книге в универе учились, а тут он почти живьем читает лекции! Из прикладных курсов по разработке я пробовала только Python и что-то про мобильную разработку — просто для общего развития. Дело было давно, и тогда уровень мне не очень понравился. Как будто это были курсы программирования для непрограммистов, очень просто и медленно. Но возможно сейчас все поменялось.
С edx вообще не было опыта.
Из прикладных предпочитаю Pluralsight (за него плачу сама). Angular University и egghead у нас корпоративные, иногда там смотрю что-нибудь.
Про школы и курсы с живыми преподавателями — когда мне было актуально, это еще не было развито, поэтому сама обучение не проходила. На собеседовании встречалась с выпускниками некоторых онлайн-школ, уровень был пониже ожиданий. Но я прекрасно понимаю, что в любой школе можно плохо учиться, здесь во многом от студента зависит, его работы и мотивации.
Кстати, вот такую школу мы с коллегами проводим fintech.tinkoff.ru Но она не онлайн, занятия проходят раз в неделю в офисе + домашка.
Если говорить про резюме — при отсутствии опыта, я бы указала пройденные курсы (я и указывала, когда искала работу на фронтенде, а опыт у меня был с другими технологиями).
> Зайдите на ХХ.РУ там в 90% вакансий «стрессоустойчивость» отдельно выделена, так же как и «динамично развивающаяся, лидер рынка» и «молодой-дружный коллектив». То есть Ваши коллеги не согласны с Вами чуть менее чем полностью.
Честно говоря, «стрессоустойчивость» в требованиях к разработчикам мне не попадалась как минимум очень давно. Для примера, я проверила актуальные вакансии для фронтендеров в Яндексе, Мейле, Авито…
И как разработчик, могу сказать, что на меня «стрессоустойчивость» и подобные фразы не производят впечатления — ни хорошего, ни плохого. Решает опыт и навыки, стэк технологий, сложные задачи, которые приходилось решать. Именно об этом и хочется читать в резюме, чтобы прикинуть насколько опыт матчится с работой в нашей команде.
На сайтах типа LeetCode, CodeWars решение обычно небольшая функция, вряд ли именно там научишься писать говнокод. А вот закрепить знание синтаксиса и умение реализовать решение в коде — бесценно.
Тут еще замечу, что все джуны разные — кто-то джуниор во фронтенде, но до этого 4 года в университете занимался программированием, а кто-то раньше не программировал и пришел совсем из другой профессии. И как раз для тех, кто раньше не программировал, практика просто необходима.
Я всегда прошу стажеров и джуниоров писать код, и ожидаю, что кандидат понимает, что такое массив, цикл, условие… Это как минимум.
PS: на CodeWars среди решений других участников иногда вижу однострочные, но плохо читаемые функции, с большим числом голосов «Clever»… Если учиться исключительно на таких решениях, то можно нахвататься странных идей, но это прямо надо постараться.
PPS: Кстати, я нигде не писала, что отсутствие ссылки — это очень плохо ) В большинстве случаев такой ссылки нет, будем честными. Но это мой совет — практиковаться, и об этом активном желании развиваться сообщить потенциальному работодателю.
Если аккаунты не совсем пустые, а реального рабочего опыта нет или мало — я бы точно указала. Да даже если и опыт есть — why not… Мы с коллегами, уже взрослые разработчики-тимлиды, тоже иногда решаем/обсуждаем и рекомендуем нашим джунам для развития.
Когда общаюсь с джунами / стажерами с прицелом в свою команду, я на аккаунты очень хорошо реагирую :)
Но даже если не указывать, такие сайты здорово помогают набить руку.
Мне кажется, вы меня не до конца поняли, или я недостаточно ясно донесла свою мысль. Если вы окончили не топовый вуз, это не проблема, я лично никогда не делала из этого каких-то плохих выводов. Главное, чтобы у вас были знания и навыки. Наоборот, в статье я никому не советую учиться только ради корочки. Это время можно потратить на самообразование и практику.
Как раз в статье я писала, что лично знаю несколько топовых коллег не окончивших ВУЗ. И также знаю очень скилловых ребят, учившихся не по IT-специальности.
Но если возможность такой топовый ВУЗ окончить есть — почему бы это не сделать? Это и база, и знакомства, и возможность стажировки и первого трудоустройства в хорошую компанию.
Признаюсь, мысленно я ставлю дополнительный плюсик кандидатам с профильным образованием в топовых вузах.
Дополнительный — ключевое слово. Приятно знать, что кандидат окончил ВУЗ, где дают хорошую базу, или выпускники этого ВУЗа у нас уже успешно работают.
Код на гитхабе смотрят живые люди — опытные разработчики, часто тимлиды команд, куда ищем новых коллег (по-крайней мере, так происходит у нас). Если по коду/readme/комментариям понятно, что это декомпилированные исходники, то никто не будет придираться к чистоте.
Имхо — наоборот, интересно узнать как, зачем и почему вы этим занимались, я бы обсудила на собеседовании :)
Тяжело развивать и поддерживать. Это важно для работы в команде и над долгоживущими проектами. Роберт Мартин в книге «Чистый код» дает хорошие рекомендации по организации кода с наглядными примерами.
это лишь визуальное сходство
Визуальное сходство — это одно. А вот копипасту одних и тех же блоков лучше избегать.
Просто для примера, допустим, проверяем, что код високосный в нескольких местах. И везде пишем:
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)) {
// …
}
И вообще, хорошие бывают?
Конечно, бывают. Но, к примеру, однобуквенные названия в большинстве случаев — плохой выбор.
Бóльшая часть нашего кода также хранится в приватных репозиториях, это норма, и мы все это понимаем :)
Мой посыл такой:
— Если вы изучаете что-то новое, бывает удобно сделать pet-проект, это и практика, и будет код, который можно показать.
— Если собираетесь давать ссылку на код в резюме, лучше, чтобы это был хороший код.
— Pet-проект — не требование, а способ попрактиковаться и привлечь к себе внимание. Рекомендую начинающим разработчикам или тем, кто меняет сферу работы.
А еще, об этом не было в статье, но иногда pet-проекты бывают такие классные, что сразу хочется общаться — видно, что человек горит своим делом.
С этим я не буду спорить. Обычно я смотрю самое свежее из того, что есть, 1-3 проекта, в зависимости от объема и времени изменений.
Если проектов много, можно явно указать в резюме один или несколько наиболее интересных.
В статье я хотела обратить внимание на ситуацию, когда все проекты достаточно старые или все новые, и автор указал GitHub, но никак не выделил, какой код стоит посмотреть.
Да, мы действительно рассматривали разные варианты, чтобы не делать две реализации. Но в итоге остановились на подходе с отдельными версиями.
Так можем в полную меру использовать возможности фреймворка.
Разрабатывать проще, потому что есть экспертиза в Angular. И наоборот, работая над китом, разработчики кита еще сильнее прокачиваются Angular и дают ценные советы коллегам из других команд.
Разработчики из команд-пользователей могут присылать пулл-реквесты. У нас есть выделенная команда для поддержки кита, но мы поддерживаем и «внутренний open source». Для других ребят это возможность быстрее занести свои изменения и попробовать новый вид задач, не похожий на то, что делают в своем проекте.
Если бы кит внутри был основан на другом легковесном фреймворке или даже написан на чистом JS, развивать и поддерживать его было бы сложнее. Да и легковесный фреймворк так же может выйти из моды через год.
Спасибо за ваш фидбэк ))
Насчет репозиториев – принято, в следующий раз продумаем этот момент. В этом году решили так не делать. Мы не договаривались об этом с участниками, а кто-то уже успел удалить проекты.
Но небольшой обзор проектов победителей скоро появится на сайте, может быть уже сегодня
Нам хотелось собрать коммьюнити в одном пространстве, познакомиться лично, плюс наградить победителей на сцене - чего нельзя было бы сделать на разделенных площадках, поэтому провели финал в Москве
Остальных в открытом доступе нет, только у участников конференции (или приобрести доступ к видео отдельно). Если заинтересовал доклад не из публичного списка, можно поспрашивать знакомых…
По некоторым темам можно найти статьи или прошлые связанные доклады того же спикера (например, про конструктивную конфронтацию с воркшопа видео полно).
Про самолюбование — честно говоря, даже мысли не было, что это так воспринимается. Хотела привести пример, выходящий за рамки онлайн-курсов. Ну и я проходила коротенький курс, ничего пафосного ))
Но это далеко не конец… ))
Допустим, решаем задачу, не требующую специальных знаний. Тот же fizzbuzz или что-то вроде этого leetcode.com/problems/valid-anagram
И кандидат не знает как подступиться вообще или не может реализовать озвученное на словах, потому что плохо представляет работу с циклами, переменными, условиями.
Будет полезнее дома задачки покодить, чем выходить на работу и сразу нырять в реальные задачи, где помимо синтаксиса языка еще фреймворк, бизнес-логика, большой объем кода, тесты надо учиться писать… Не до изучения циклов :)
Вообще в последнее время LeetCode больше нравится )
Еще помню пару интервью, когда попадались вроде бы хорошие мотивированные ребята, но со слабыми навыками написания кода, взять их в команду не могли. И я им сама говорила, что надо попрактиковаться и можно задавать вопросы мне, если что. Никто, правда, с вопросами не обращался :-D
И вам тоже время сэкономит, не надо лишний раз ехать на интервью (даже если по скайпу — тоже время). Кажется, что получить фидбэк по коду можно менее энергозатратным способом — опубликовать код на тематическом сайте или напрямую написать специалистам и попросить совета.
Опять же, интервью в разных местах по-разному проводят — где-то объяснят подробно что не так, где-то толком ничего не скажут, где-то дадут рекомендации и список материалов для подготовки, где-то нет… Но тут личный выбор каждого, каким способом искать фидбэк.
Может грубовато прозвучало ) Идея в том, что иногда нужен разработчик опытный (уверенный миддл или выше), способный быстро влиться в команду и не требующий много опеки и обучения — вот это я назвала «начинать закрывать таски с первого дня». Иногда можно взять менее опытного миддла, есть возможность менторить и растить. Иногда готовы брать джунов без опыта, понимая, что обучать придется много, но зато и перспективы отличные.
Но так-то да, обычно джуны тоже приступают к работе над реальными задачами с первого дня. Просто это задачи другого уровня.
Чисто по-человечески, я бы не смогла отправить ссылку на код, который заведомо считаю плохим, потенциальному работодателю. А с другой стороны, если вы видите проблему, значит можете попытаться ее исправить и показать наилучший код, который способны написать сейчас.
Со стороны интервьюера — понимая, что у кандидата опыт в других технологиях, но сейчас он хочет переквалифицироваться, я бы, наверно, хотела посмотреть код — в худшем случае, кандидата не пригласят на собеседование, но зато все сэкономят время — кандидат в том числе (и может дело даже не в говнокоде, а в том, что в проект прямо сейчас нужен опытный разработчик, который начнет закрывать таски с первого дня). В теории, по коду могут дать фидбэк (или его можно попросить явно).
Извините, но я все-таки не соглашусь, я не HR, и надеюсь, что все же немного в теме )) У многих есть и старые проекты, и проекты на языках или с использованием технологий, с которыми больше не хотим работать, и студенческие курсовые…
Так ведь и код не машина смотрит, а смотрим мы — разработчики, будущие коллеги кандидата (тимлиды или другие опытные разработчики команды).
Отличить старый проект от нового нет проблемы. Если команда ищет фронтендера, а у вас и фронт, и бэк, и может вы еще увлекаетесь ML — разберемся куда смотреть. Если есть readme с пояснениями — прочитаем. Для простоты лучше самые интересные репозитории запинить, можно про них явно написать в резюме/письме или что-то скрыть в приватные… Ну мы же все разумные люди :)
Но когда кандидат сам приложил гитхаб, а код ну совсем не очень (code smells, явное незнание возможностей языка, фреймворка и т.п.) — это производит плохое впечатление. Вы сами разве захотели бы работать с коллегой, код которого считаете грязным или неоптимальным? Вот поэтому и советую привести то, что собираетесь демонстрировать, в хороший по вашим нынешним меркам код (не 25 проектов за 10 лет, конечно).
На Coursera мне очень нравятся курсы по алгоритмам, позволяют освежить знания. Особенно те, что ведет Седжвик — мы по его книге в универе учились, а тут он почти живьем читает лекции! Из прикладных курсов по разработке я пробовала только Python и что-то про мобильную разработку — просто для общего развития. Дело было давно, и тогда уровень мне не очень понравился. Как будто это были курсы программирования для непрограммистов, очень просто и медленно. Но возможно сейчас все поменялось.
С edx вообще не было опыта.
Из прикладных предпочитаю Pluralsight (за него плачу сама). Angular University и egghead у нас корпоративные, иногда там смотрю что-нибудь.
Про школы и курсы с живыми преподавателями — когда мне было актуально, это еще не было развито, поэтому сама обучение не проходила. На собеседовании встречалась с выпускниками некоторых онлайн-школ, уровень был пониже ожиданий. Но я прекрасно понимаю, что в любой школе можно плохо учиться, здесь во многом от студента зависит, его работы и мотивации.
Кстати, вот такую школу мы с коллегами проводим fintech.tinkoff.ru Но она не онлайн, занятия проходят раз в неделю в офисе + домашка.
Если говорить про резюме — при отсутствии опыта, я бы указала пройденные курсы (я и указывала, когда искала работу на фронтенде, а опыт у меня был с другими технологиями).
Честно говоря, «стрессоустойчивость» в требованиях к разработчикам мне не попадалась как минимум очень давно. Для примера, я проверила актуальные вакансии для фронтендеров в Яндексе, Мейле, Авито…
И как разработчик, могу сказать, что на меня «стрессоустойчивость» и подобные фразы не производят впечатления — ни хорошего, ни плохого. Решает опыт и навыки, стэк технологий, сложные задачи, которые приходилось решать. Именно об этом и хочется читать в резюме, чтобы прикинуть насколько опыт матчится с работой в нашей команде.
Тут еще замечу, что все джуны разные — кто-то джуниор во фронтенде, но до этого 4 года в университете занимался программированием, а кто-то раньше не программировал и пришел совсем из другой профессии. И как раз для тех, кто раньше не программировал, практика просто необходима.
Я всегда прошу стажеров и джуниоров писать код, и ожидаю, что кандидат понимает, что такое массив, цикл, условие… Это как минимум.
PS: на CodeWars среди решений других участников иногда вижу однострочные, но плохо читаемые функции, с большим числом голосов «Clever»… Если учиться исключительно на таких решениях, то можно нахвататься странных идей, но это прямо надо постараться.
PPS: Кстати, я нигде не писала, что отсутствие ссылки — это очень плохо ) В большинстве случаев такой ссылки нет, будем честными. Но это мой совет — практиковаться, и об этом активном желании развиваться сообщить потенциальному работодателю.
Когда общаюсь с джунами / стажерами с прицелом в свою команду, я на аккаунты очень хорошо реагирую :)
Но даже если не указывать, такие сайты здорово помогают набить руку.
Как раз в статье я писала, что лично знаю несколько топовых коллег не окончивших ВУЗ. И также знаю очень скилловых ребят, учившихся не по IT-специальности.
Но если возможность такой топовый ВУЗ окончить есть — почему бы это не сделать? Это и база, и знакомства, и возможность стажировки и первого трудоустройства в хорошую компанию.
Дополнительный — ключевое слово. Приятно знать, что кандидат окончил ВУЗ, где дают хорошую базу, или выпускники этого ВУЗа у нас уже успешно работают.
Имхо — наоборот, интересно узнать как, зачем и почему вы этим занимались, я бы обсудила на собеседовании :)
Тяжело развивать и поддерживать. Это важно для работы в команде и над долгоживущими проектами. Роберт Мартин в книге «Чистый код» дает хорошие рекомендации по организации кода с наглядными примерами.
Визуальное сходство — это одно. А вот копипасту одних и тех же блоков лучше избегать.
Просто для примера, допустим, проверяем, что код високосный в нескольких местах. И везде пишем:
Лучше вынести в функцию с понятным названием и использовать ее:
Конечно, бывают. Но, к примеру, однобуквенные названия в большинстве случаев — плохой выбор.
Мой посыл такой:
— Если вы изучаете что-то новое, бывает удобно сделать pet-проект, это и практика, и будет код, который можно показать.
— Если собираетесь давать ссылку на код в резюме, лучше, чтобы это был хороший код.
— Pet-проект — не требование, а способ попрактиковаться и привлечь к себе внимание. Рекомендую начинающим разработчикам или тем, кто меняет сферу работы.
А еще, об этом не было в статье, но иногда pet-проекты бывают такие классные, что сразу хочется общаться — видно, что человек горит своим делом.
Если проектов много, можно явно указать в резюме один или несколько наиболее интересных.
В статье я хотела обратить внимание на ситуацию, когда все проекты достаточно старые или все новые, и автор указал GitHub, но никак не выделил, какой код стоит посмотреть.
Если бы кит внутри был основан на другом легковесном фреймворке или даже написан на чистом JS, развивать и поддерживать его было бы сложнее. Да и легковесный фреймворк так же может выйти из моды через год.