Комментарии 106
По поводу гитхаба, немного, не согласен. Если у меня там есть какие-то древние проекты, которые я бы, на сегодняшний день, сделал совсем иначе — это не значит, что им там не место. У вас есть возможность посмотреть дату создания проекта, дату последнего коммита и самостоятельно отыскать самое свежее из представленного.
С этим я не буду спорить. Обычно я смотрю самое свежее из того, что есть, 1-3 проекта, в зависимости от объема и времени изменений.
Если проектов много, можно явно указать в резюме один или несколько наиболее интересных.
В статье я хотела обратить внимание на ситуацию, когда все проекты достаточно старые или все новые, и автор указал GitHub, но никак не выделил, какой код стоит посмотреть.
Если проектов много, можно явно указать в резюме один или несколько наиболее интересных.
В статье я хотела обратить внимание на ситуацию, когда все проекты достаточно старые или все новые, и автор указал GitHub, но никак не выделил, какой код стоит посмотреть.
На гитхабе можно запинить несколько репозиториев. Мне кажется, хороший вариант.
Приведу пример.У меня как разработчика в моем репозитарии более 25 проектов за 10 лет.Это части проектов, так что бы показать где и чем я занимался.Из них 5 только лично мои.Остальные это отражение требований заказчика и хода движения проекта.Как я их должен привести в порядок? Совет явно от человека который не в теме уж извините.Вот начитаются HR-ры таких советов а потом на работу тебя не берут из за того что ты в таких проектах участвовал.Это при том что проекты реальные и прибыль заказчикам приносят.Умейте читать между строк.И не ешьте на ночь сырых помидоров(как классик советовал) ))
А зачем те репозитории, которые вы не хотите показывать делать открытыми? Разве нельзя сделать закрытым и добавить только того, кого этот репозиторий касается?
Так это проекты за 10 лет.Закроешь — говорят у Вас мало опыта.Откроешь говорят — фу-так уже никто не пишет.При этом на те проекты под которыми реальный бизнес бегает
Бесплатным аккаунтам вроде не разрешается закрывать проекты. Да и зачем? Я никогда не понимал этих пряток. Мало ли кому полезным окажется кусок кода в древнючем коде.
Пиннить такие проекты, конечно, не стоит. Но и скрывать не надо.
НЛО прилетело и опубликовало эту надпись здесь
Вы какую задачу решаете? Угодить «мало ли кому» или же дать действительно полезные сведения о себе и помочь тем, кто нуждается в ваших решениях?
Если уж так хочется помочь «мало ли кому», то если человек хочет решить задачу и будет гуглить, то он будет ожидать в виде заверешенной библиотеки, которую можно поставить, к примеру с помощью «npm install» или в виде куска кода в Github Gist. А копаться в коде незнакомого проекта вряд ли кто будет без особой на той надобности.
Если уж так хочется помочь «мало ли кому», то если человек хочет решить задачу и будет гуглить, то он будет ожидать в виде заверешенной библиотеки, которую можно поставить, к примеру с помощью «npm install» или в виде куска кода в Github Gist. А копаться в коде незнакомого проекта вряд ли кто будет без особой на той надобности.
> Совет явно от человека который не в теме уж извините
Извините, но я все-таки не соглашусь, я не HR, и надеюсь, что все же немного в теме )) У многих есть и старые проекты, и проекты на языках или с использованием технологий, с которыми больше не хотим работать, и студенческие курсовые…
Так ведь и код не машина смотрит, а смотрим мы — разработчики, будущие коллеги кандидата (тимлиды или другие опытные разработчики команды).
Отличить старый проект от нового нет проблемы. Если команда ищет фронтендера, а у вас и фронт, и бэк, и может вы еще увлекаетесь ML — разберемся куда смотреть. Если есть readme с пояснениями — прочитаем. Для простоты лучше самые интересные репозитории запинить, можно про них явно написать в резюме/письме или что-то скрыть в приватные… Ну мы же все разумные люди :)
Но когда кандидат сам приложил гитхаб, а код ну совсем не очень (code smells, явное незнание возможностей языка, фреймворка и т.п.) — это производит плохое впечатление. Вы сами разве захотели бы работать с коллегой, код которого считаете грязным или неоптимальным? Вот поэтому и советую привести то, что собираетесь демонстрировать, в хороший по вашим нынешним меркам код (не 25 проектов за 10 лет, конечно).
Извините, но я все-таки не соглашусь, я не HR, и надеюсь, что все же немного в теме )) У многих есть и старые проекты, и проекты на языках или с использованием технологий, с которыми больше не хотим работать, и студенческие курсовые…
Так ведь и код не машина смотрит, а смотрим мы — разработчики, будущие коллеги кандидата (тимлиды или другие опытные разработчики команды).
Отличить старый проект от нового нет проблемы. Если команда ищет фронтендера, а у вас и фронт, и бэк, и может вы еще увлекаетесь ML — разберемся куда смотреть. Если есть readme с пояснениями — прочитаем. Для простоты лучше самые интересные репозитории запинить, можно про них явно написать в резюме/письме или что-то скрыть в приватные… Ну мы же все разумные люди :)
Но когда кандидат сам приложил гитхаб, а код ну совсем не очень (code smells, явное незнание возможностей языка, фреймворка и т.п.) — это производит плохое впечатление. Вы сами разве захотели бы работать с коллегой, код которого считаете грязным или неоптимальным? Вот поэтому и советую привести то, что собираетесь демонстрировать, в хороший по вашим нынешним меркам код (не 25 проектов за 10 лет, конечно).
Еще раз для тех кто не прошел 25 проектов: код отражает требования проекта.Это зеркало тех условий в которых работает разработчик.Если на проекте принята идеалогия скрупулезной чистоты, следование последним техно-трендам так и будет.Зачастую для решения задачи хватает минимум средств и минимум вложений.В этом суть бизнеса.За минимум вложений получить максимум результата.Идеальный код возможен в идеальном мире.Дайте мне неограниченное время, неограниченные финансы и я Вам дам идеальный код.Вы HR-ры и тимлиды стали техно-роботами, Вы про человека забыли.Я тоже неоднократно был лидом с разными людьми и это мой Вам ответ
Это при том что проекты реальные и прибыль заказчикам приносят. Умейте читать между строк.
Тут вот какое дело. Тот факт, что ваш код кому-то приносит прибыль, сам по себе ничего не означает. У фирмы, которая ищет работника, есть свой код, который приносит прибыль. Ваш код приносит прибыль, и код кого-то другого приносит прибыль. Если в вашем коде сложнее разобраться, а в коде другого человека проще, то возьмут его, а не вас.
В чьем коде можно лучше разобраться можно понять когда Вы в проекте УЖЕ работаете достаточное время.Только тогда можно сравнивать.Если на проект ищется человек (если это не юниор) то я гарантирую Вам как человек с достаточным опытом, что Вы изначально не знаете всех возможностей человека и принимать его судя только по коду этой информации недостаточно.
В чьем коде можно лучше разобраться можно понять когда Вы в проекте УЖЕ работаете достаточное время. Только тогда можно сравнивать.
Нет. Вы подменяете понятия архитектуры и оформления, хорошего кода и кода, правильно выполняющего задачу. Оценить архитектуру можно после знакомства с проектом, и это все понимают, но и то во многих случаях достаточно описания. А если вы пишете однобуквенные переменные и показываете этот код в качестве "смотрите, вот как я пишу", то совершенно неважно, какой был проект и какие у вас возможности, другим людям с таким кодом будет сложно работать.
Судя только по коду никто не принимает. В данной статье описано много разных моментов. А вот отказать могут. Кроме вас есть и другие кандидаты, чьи возможности тоже неизвестны. Зачем кому-то проверять, есть ли у вас возможности, которые будут компенсировать плохой код, если можно проверить другого кандидата, который точно пишет нормальный код.
Дальше спорить и приводить аргументы уже не имеет смысла.Каждый комментирует в силу своих знаний, умений и опыта.Я привел доводя с которыми сталкивался на протяжении последних 15 лет, Вы свои.Текущие тенденции понятны и менятся надо всем,HR-рам, техно-лидам в том числе а не только разработчику который посути раб проекта(если только это не его от и до проект)
Хе, последнее что я делал на гитхабе, буквально на днях — реверсинг мобильного приложения, и часть классов там тупо восстановлены из декомпилированных исходников, с переменными типа var1, var2 и методами aaz и подобными, после минификации. Вот никакого желания их переименовывать нет)) Если посмотреть на код с т.з. чистоты — ужос ужос.
Код на гитхабе смотрят живые люди — опытные разработчики, часто тимлиды команд, куда ищем новых коллег (по-крайней мере, так происходит у нас). Если по коду/readme/комментариям понятно, что это декомпилированные исходники, то никто не будет придираться к чистоте.
Имхо — наоборот, интересно узнать как, зачем и почему вы этим занимались, я бы обсудила на собеседовании :)
Имхо — наоборот, интересно узнать как, зачем и почему вы этим занимались, я бы обсудила на собеседовании :)
Как-то странно вы его реверсили, classes.dex 4Мб, а в репозитории всего-то с дюжину *.java-файлов, да и те стандартные андроидовские, из SDK.
с переменными типа var1, var2 и методами aaz и подобными, после минификации. Вот никакого желания их переименовывать нет
fernflower -ren=1 ... да -urc=... по необходимости и железяка возьмёт всю рутину по переименованию на себя.
Потом пройтись с Shift-F6 наперевес в Android Studio и допилить до приемлемого состояния, попутно выкинув все SDK-шные классы.
Хранить на гитхабе старый код не просто можно, а даже нужно.
Это уникальная возможность посмотреть чему научился кандидат за какой-то промежуток времени, а одинаковые ошибки в коде недельной и годовой давности скажут сами за вас.
Это уникальная возможность посмотреть чему научился кандидат за какой-то промежуток времени, а одинаковые ошибки в коде недельной и годовой давности скажут сами за вас.
Тем не менее я предлагаю задуматься об этом, меняя работу в следующий раз: действительно ли ваше новое место лучше старого, есть ли там перспективы и возможности для роста, делает ли оно вас ближе к вашим глобальным карьерным целям? И есть ли они у вас?К примеру. Я работаю на себя, и все из перечисленного присутствует. Поэтому меня может многое не устроить на любом месте работы. Конечно по большому счету это компромисс, но мне кажется что многие самостоятельные товарищи думают с этой точки зрения.
Кстати, если вы собираетесь искать работу, потому что вас не устраивают устаревшие технологии или отсутствие хороших командных практик, предлагаю на минутку задуматься: а вы пытались это изменить? Если нет, то рекомендую попробовать. Неожиданно это может оказаться и возможностью для роста, и способом получить практический опыт в реальных рабочих условиях.Это то о чем потом, с уходом, можно сильно пожалеть. Те кто хотят получить опыт и научиться, будут скорее смотреть на других, делать как все или вышестоящий. Это правильная модель поведения для общества не больного моральным уродством, с беготней впереди повозки.
А если нужен отдел инноваций, то он для этого и создается. Там можно вполне оправданно фейлиться, если не получится. И не мучиться в статусе белой вороны, если вперед других убежал. Опять же реструктуризация и улучшения это общая работа.
Поэтому меня может многое не устроить на любом месте работы
Не понял взаимосвязь того, что вы работаете на себя и того, что вас может многое не устроить на любом месте работы? В чем корреляция?
Те кто хотят получить опыт и научиться, будут скорее смотреть на других, делать как все или вышестоящий
Сейчас куча информации в интернете и передача знаний из уст в уста уже не является основным способом обучения. Любой разработчик может узнать в интернете что-то новое и применить в своей работе.
А если нужен отдел инноваций
Инновации придумывают разработчики с высоким уровнем знаний, большинству остается только брать эти инновации и использовать.
В чем корреляция?А в чем смысл задумывается над условиями? Если мне на себя удобней работать чем в текущей компании. Мое следующее место работы это я сам. Из расчета условий которые я сам себе предоставляю, мне удобнее, перспективнее и продуктивнее. Действительно может быть, что на следующем месте работы, который мне захочется поискать, не будет так удобно как на текущем, но я всегда могу работать на себя. В этом смысле, я не буду задерживаться на любой работе, которая меня не устроит без каких либо обдумываний.
Любой разработчик может узнать в интернете что-то новое и применить в своей работе.Узнать может, а применить не всегда может быть к месту, все от общества зависит и от проекта. Одни кричат «не читай википедию — козленочком станешь», другие «читай википедию раз не знаешь». А если во главе нет опытного и знающего и каждый себе начальник и руководитель научного проекта, то «запчасти ракеты явно начинают лететь каждая по своей траектории». Децентрализованное обучение интересно для саморазвития, но не всегда помогает проекту который разрабатывают разные люди.
Инновации придумывают разработчики с высоким уровнем знаний, большинству остается только брать эти инновации и использовать.А я о чем по вашему написал? Или вы предлагаете каждому, как в статье, проявить себя в модернизации производства? Тем не менее отдел инноваций не куда не делся, а как раз работает, в том числе и над оценкой целесообразности внедрения того что может придумать разработчик с высоким уровнем знаний. И из-за его отсутствия, совсем не значит, что нужно внедрять все что предлагает товарищ с высоким уровнем знаний.
По поводу качества кода — довольно неблагодарное дело давать примеры, так как обычно разработчик считает плохим кодом либо тот код, который он перерос и видит проблемы, или тот, до которого он недорос и не понимает. Есть маленький слой кода, который попадает под определение хорошего для данного разработчика в данный момент, и попасть в него — всё равно, что играть в лотерею. Гораздо содержательнее побеседовать, почему в том или ином участке кода было принято решение написать именно так, на основе чего принималось решение? Это просто копирка или осознанное решение, лучшая практика не используется потому, что кандидат о ней не знает или потому, что в данном случае видит больше аргументов за другой подход, сразу становится понятен уровень кандидата.
Много кода в одном файле, огромные функции, большая вложенность.
Чем это всё плохо? Пример: код кодека Opus, opus_encode.c и, например, в нём opus_encode_native. Вы бы не взяли на работу разработчика этого кода?
Для сравнения в этом же кодеке есть код, написанный в другом стиле, в пакете silk.
Очевидное дублирование кода.
Часто так делается подразумевая, что будут вносится изменения или потому что это лишь визуальное сходство. Это бывает лучше, чем лишние условия в общем коде, наставленные ради создания общего кода.
Откровенно плохие названия переменных и функций.
Рассказать бы это тем, кто даёт названия консольным утилитам или тем, кто даёт названия стандартным функциям. И вообще, хорошие бывают?
Неиспользуемые переменные, функции, импорты.
Такое может быть на этапе работы над кодом, что в этом плохого?
Почему бы не пользоваться линтером(-ами) своей(-их) технологии(-й), чтобы исключить совсем «детские» code smell?
Поддерживать такое тяжело. Даже автору через определенное время.
В WIP ветке — пожалуй, ничего плохого, разве что CI красный.
Чем это всё плохо?
Поддерживать такое тяжело. Даже автору через определенное время.
Такое может быть на этапе работы над кодом, что в этом плохого?
В WIP ветке — пожалуй, ничего плохого, разве что CI красный.
Чем это всё плохо?
Тяжело развивать и поддерживать. Это важно для работы в команде и над долгоживущими проектами. Роберт Мартин в книге «Чистый код» дает хорошие рекомендации по организации кода с наглядными примерами.
это лишь визуальное сходство
Визуальное сходство — это одно. А вот копипасту одних и тех же блоков лучше избегать.
Просто для примера, допустим, проверяем, что код високосный в нескольких местах. И везде пишем:
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)) {
// …
}
И вообще, хорошие бывают?
Конечно, бывают. Но, к примеру, однобуквенные названия в большинстве случаев — плохой выбор.
К сожалению, вы ушли от ответов и дали сверхочевидные примеры.
Могу дать аналогично цитаты, например, из С. Макконнелл, «Совершенный код»:
«Одному из моих клиентов поручили разделить самый объемный метод унаследованной системы, включающий более 12 000 строк. Приложив немалые усилия, он смог уменьшить объем этого метода только примерно до 4000 строк.»
Могу дать аналогично цитаты, например, из С. Макконнелл, «Совершенный код»:
«Одному из моих клиентов поручили разделить самый объемный метод унаследованной системы, включающий более 12 000 строк. Приложив немалые усилия, он смог уменьшить объем этого метода только примерно до 4000 строк.»
Из любого правила существуют исключения, из рекомендаций тем более. Я думаю, что 4000 строк в одном методе это действительно редкое исключение, заслуживающие объемного комментария в самом начале о том почему так вышло. В любом случае большие куски кода — минимум повод подумать, а не стоит ли их разделить на кусочки поменьше.
Чем это всё плохо?
Разбираться и вносить изменения сложно.
Вы бы не взяли на работу разработчика этого кода?
Я собеседования никогда не проводил, но работать с тем, кто пишет такой код, я бы не хотел. По вышеуказанным причинам.
Это бывает лучше, чем лишние условия в общем коде, наставленные ради создания общего кода
Если у вас условия в общем коде, созданные для этой цели, значит вы написали неправильно. Общий код на то и общий, что везде работает одинаково.
И вообще, хорошие бывают?
Бывают. Например, не Fs, а frame_size.
Такое может быть на этапе работы над кодом, что в этом плохого?
То, что вы в резюме показываете не этап работы над кодом, а законченный код. Если у вас законченный код находится в таком же беспорядке, как незаконченный, то не надо удивляться, что другие не хотят работать с таким кодом.
Переформулирую вопрос: как на взгляд рекрутера выглядит код open source проектов и достойны ли их авторы быть нанятыми?
Примеры: Linux, Open JDK, Opus, Android SDK.
Или по-другому, какой проект по мнению рекрутера может быть рекомендован для подражания?
А разве не бывает наоборот? Читаешь как книжку без сносок на другие страницы и видишь связный текст.
Другой пример: обработка ввода пользователя в утилитах командой строки.
Может, тут просто есть еще разница, одни мыслят как Лев Толстой, а другие смс-ками?
Теория хороша, а на практике что делать если надо так же, но чуть по-другому?
Копировать код и вносить изменения или добавлять переменную?
Вы забыли про аргументы функции, название нельзя рассматривать в отрыве от них.
Ну и «ls -l» наверно знаете? Название функции из одной буквы (l) и сама буква та ещё.
Странное утверждение.
Примеры: Linux, Open JDK, Opus, Android SDK.
Или по-другому, какой проект по мнению рекрутера может быть рекомендован для подражания?
Разбираться и вносить изменения сложно.
А разве не бывает наоборот? Читаешь как книжку без сносок на другие страницы и видишь связный текст.
Другой пример: обработка ввода пользователя в утилитах командой строки.
Я собеседования никогда не проводил, но работать с тем, кто пишет такой код, я бы не хотел. По вышеуказанным причинам.
Может, тут просто есть еще разница, одни мыслят как Лев Толстой, а другие смс-ками?
Общий код на то и общий, что везде работает одинаково.
Теория хороша, а на практике что делать если надо так же, но чуть по-другому?
Копировать код и вносить изменения или добавлять переменную?
Бывают. Например, не Fs, а frame_size.
Вы забыли про аргументы функции, название нельзя рассматривать в отрыве от них.
Ну и «ls -l» наверно знаете? Название функции из одной буквы (l) и сама буква та ещё.
То, что вы в резюме показываете не этап работы над кодом, а законченный код.
Странное утверждение.
Ну, код Android SDK первых версий был тем еще ужасом, да и сейчас местами не блещет. Пусть со временем они и постарались немного выправить его, не сильно обратную совместимость ломая.
Переформулирую вопрос: как на взгляд рекрутера выглядит код open source проектов и достойны ли их авторы быть нанятыми?
Примеры: Linux, Open JDK, Opus, Android SDK.
Или по-другому, какой проект по мнению рекрутера может быть рекомендован для подражания?
А у вас есть данные по медианной длине функции в этих проектах? Может там функции не такие уж и длинные?
Ну не стоит сравнивать фронтэнд(да и бизнес-бэкэнд и вообще кровавый энтрпрайз), которым заведует автор, и низкоуровневое системное ПО, где вызов функции иногда считается дорогой операцией в плане производительности.
Ну и «ls -l» наверно знаете? Название функции из одной буквы (l) и сама буква та ещё.
ls — это не название функции в коде, а программа, которая обычно используется как команда в терминале. Т.е. ls как команда — чаще набирается и почти никогда не читается и самое главное она используется постоянно, функция ls где-то в коде в основном читается и очень редко набирается и используется крайне редко в расчете количество раз в год и в другом проекте может значить совершенно другое, в отличии от команды ls, которая во всех Unix-like ОС значит одно и тоже. Поэтому название функции ls — ужасное, лучше list_files или list_sockets или make_list т.е. то что она на самом делает. С аргументами команд/функций — аналогично.
как на взгляд рекрутера выглядит код open source проектов и достойны ли их авторы быть нанятыми?
Участие в open source не означает, что разработчик пишет хороший код, и что любого из них можно нанять. Кто-то пишет хороший, кто-то плохой, кто-то для себя пишет хороший, а в других проектах плохой, потому что там так исторически сложилось.
Или по-другому, какой проект по мнению рекрутера может быть рекомендован для подражания?
Не знаю как у рекрутеров, но я бы порекомендовал следовать рекомендациям из книги "Совершенный код". Или как выше "Чистый код" советуют.
Другой пример: обработка ввода пользователя в утилитах командной строки.
Я не понимаю, что этот пример должен показывать. Ввод пользователя нельзя на функции разбить? Параметры командной строки нельзя в структуру объединить? Сформулируйте словами пожалуйста.
А разве не бывает наоборот? Читаешь как книжку без сносок на другие страницы и видишь связный текст.
Что если в книге написано, что герой влюбился в блондинку, а на следующей странице что в брюнетку? Или что получил ранение в руку, а на следующей странице говорится, что в ногу? От этого становится понятнее, что в книге происходит?
Дело в том, что код это не книга, он делает работу. Просто так код обычно никто не читает, читают когда надо его изменить, или разобраться как он работает, чтобы изменить в другом месте. Копипаста и большие блоки этому мешают. Особенно если скопировано с небольшими изменениями.
Может, тут просто есть еще разница, одни мыслят как Лев Толстой, а другие смс-ками?
Разговор не о литературных изысканиях, а о работе. Есть работа, и ее надо сделать, желательно быстро. Если ваш код мешает работе, значит с вашим кодом никто не захочет работать. Все просто.
что делать если надо так же, но чуть по-другому? Копировать код и вносить изменения или добавлять переменную?
Разбить на функции и вызывать нужные. Если разбить почему-то нельзя, ну тогда только переменные добавлять. Копировать с незначительными изменениями точно не надо. А то потом в одном месте поменяют, а в другом нет, потому что не нашли.
Вы забыли про аргументы функции, название нельзя рассматривать в отрыве от них.
Ну аргумент функции так и называется Fs. И в вызывающей функции он называется Fs. И в вызывающей ее функции называется Fs. Что дальше?
Ну и «ls -l» наверно знаете?
Знаю. Что это должно доказывать? Сформулируйте словами пожалуйста.
Странное утверждение.
Нет. В продакшн идет законченный код, а не промежуточный. С этим кодом потом работают другие. Все промежуточные этапы должны оставаться только на вашей машине. Если вы показываете код, ожидается, что он законченный и работающий. Потому что такой же код вы должны будете показывать на pull-реквестах.
Разбить на функции и вызывать нужные. Если разбить почему-то нельзя, ну тогда только переменные добавлять. Копировать с незначительными изменениями точно не надо. А то потом в одном месте поменяют, а в другом нет, потому что не нашли.
Не согласен. Копирование это вполне нормально. Если ожидается что в дальнейшем этот код будет меняться и не будет никак связан с тем местом из которого скопирован. Т.е. если это просто так совпало что код похож, но делает он совершенно разное для разных частей бизнес логики. Как раз в случаях когда предполагается что если будут менять кусок в месте из которого копировали — это не должно повлиять на новый код.
В такой формулировке согласен. Но это требуется совсем не "часто". Ну и говорил я больше про условия в общем коде. Всякие флаги, меняющие режим работы, это обычно неправильный подход. Это потом разрастается, в вызывающих функциях появляются свои флаги, и потом не разберешься, что надо поменять, чтобы работало как надо. По-моему, у Макконнелла про это было.
Правильный подход в этом случае — «вот когда будет меняться, тогда и скопирую». А то, о чем говорите Вы — overenginering, и это отнюдь не хорошо. Поскольку если код таки не поменяется в будущем (нашли другое решение, задачу вообще сняли и т.д.) — у вас явное нарушение принципа DRY.
Программист пишет код на придуманном кем-то языке, в среде, которая постоянно меняется. Как решается, что хорошо?
Хороший код — конкурентное преимущество. Что вас заставит растаться с этим знанием?
Чем человек зарабатывает, который учит вас как хорошо писать код?
Посмотрите код утилит командной строки, который разбирает входные флаги. Там как правило на несколько экранов if-else.
Авторов таких утилит сразу никуда не брать?
Как сделать работу быстро? Утрировано: отрефакторив кучу кода, чтоб выделить функцию, или скопировать кусок? Что первично: работоспособность программы или отформатированный по придуманным кем-то, постоянно меняющимся правилам, текст кода? (Вечная проблема...)
Речь о том, что название frame_size нельзя признать хорошим не видя аргументов функции и не зная, для чего она предназначена. frame_size( bool flag ). И всё, название уже не выглядит столь хорошим, правда?
Это пример названия функции, предоставленной пользователю. На него тоже должны правила распространятся, нет? И разве это не более важно, чем то, что внутри?
Вот вроде и приходим к тому, что не спросив, почему сделано именно так, невозможно понять, хороший код или плохой, так?
А желание иметь код простым и понятным наталкивается на суровые требования к тому, что и как программа должна делать, за какое время должна быть написана и за какое вознаграждение?
Может, надо просить кандидата написать сочинение на родном языке и тогда станет понятно, может он мыслить связно или нет?
И проверять способен он учиться и учить других?
Хороший код — конкурентное преимущество. Что вас заставит растаться с этим знанием?
Чем человек зарабатывает, который учит вас как хорошо писать код?
Параметры командной строки нельзя в структуру объединить? Сформулируйте словами пожалуйста.
Посмотрите код утилит командной строки, который разбирает входные флаги. Там как правило на несколько экранов if-else.
Авторов таких утилит сразу никуда не брать?
Есть работа, и ее надо сделать, желательно быстро.
Как сделать работу быстро? Утрировано: отрефакторив кучу кода, чтоб выделить функцию, или скопировать кусок? Что первично: работоспособность программы или отформатированный по придуманным кем-то, постоянно меняющимся правилам, текст кода? (Вечная проблема...)
Ну аргумент функции так и называется Fs. И в вызывающей функции он называется Fs. И в вызывающей ее функции называется Fs. Что дальше?
Речь о том, что название frame_size нельзя признать хорошим не видя аргументов функции и не зная, для чего она предназначена. frame_size( bool flag ). И всё, название уже не выглядит столь хорошим, правда?
Что это должно доказывать? Сформулируйте словами пожалуйста.
Это пример названия функции, предоставленной пользователю. На него тоже должны правила распространятся, нет? И разве это не более важно, чем то, что внутри?
Вот вроде и приходим к тому, что не спросив, почему сделано именно так, невозможно понять, хороший код или плохой, так?
А желание иметь код простым и понятным наталкивается на суровые требования к тому, что и как программа должна делать, за какое время должна быть написана и за какое вознаграждение?
Может, надо просить кандидата написать сочинение на родном языке и тогда станет понятно, может он мыслить связно или нет?
И проверять способен он учиться и учить других?
Как решается, что хорошо?
Практикой. С одним чужим кодом проще работать, с другим сложнее.
Остальные вопросы я не понял, извините.
Там как правило на несколько экранов if-else. Авторов таких утилит сразу никуда не брать?
Если человек не приводит этот проект в качестве примера своего кода, то это не должно иметь значения. Если приводит, то если работодателю не нужен человек, который пишет такой код, то не брать. Если нужен, то брать. Если не нужен, но другие аспекты это компенсируют, то брать. Все как обычно.
Утрировано: отрефакторив кучу кода, чтоб выделить функцию, или скопировать кусок?
Вот в ваших рассуждениях в том и проблема, что утрировано. Вы не рассматриваете что произойдет дальше. Сегодня вы скопировали кусок и сэкономили время, завтра другой человек поменял в одном месте, а в другом не поменял, данные в базе попортились, пришлось отдельно исправлять код во втором месте, исправлять данные, компания получила недовольных клиентов и понесла убытки. В каком случае работа сделана быстрее и качественнее?
Что первично: работоспособность программы или отформатированный по придуманным кем-то, постоянно меняющимся правилам, текст кода?
Вы никак не поймете то, что вам несколько человек пытаются объяснить. Цель не в соответствии кода правилам оформления, а именно в его работоспособности, в том, что правильно написанный код улучшает эту работоспособность. В которую входит и приведение в работоспособное состояние при изменениях требований. Правила как раз для того и используют, потому что код, написанный по правилам, лучше работает, проще меняется и реже ломается.
Речь о том, что название frame_size нельзя признать хорошим не видя аргументов функции и не зная, для чего она предназначена.
Можно. frame_size в любом случае лучше, чем Fs, потому из него можно предположить назнчение переменной, а из названия Fs нельзя. Не должно быть необходимости изучать сотню строк, чтобы разобраться, для чего нужна переменная. Код, который этого требует, считается плохим. Потому что отнимает больше времени и внимания при анализе, чем код с понятными названиями.
Кроме того, я взял его из вашего примера, и говорю это из практического опыта анализа этого кода. Я потратил 10 минут, чтобы разобраться, что это действительно frame_size, а не сокращение от frames, выискивая, где эти функции вызываются и что туда передается. Зачем работать с человеком, который пишет непонятно, если можно работать с человеком, который сразу пишет понятно?
И всё, название уже не выглядит столь хорошим, правда?
Неправда. frame_size все равно лучше чем Fs. Потому что понятнее.
Это пример названия функции, предоставленной пользователю. На него тоже должны правила распространятся, нет?
Мне все равно непонятна ваша логика. Если некий известный Вася написал плохой код, значит все должны писать плохой код?
Как вам написали выше, это команда командной строки, которая в большинстве случаев печатается вручную, и короткое название оправдано. Но мне бы больше понравилось название list, оно тоже достаточно короткое и при этом более понятное.
Вот вроде и приходим к тому, что не спросив, почему сделано именно так, невозможно понять, хороший код или плохой, так?
Нет. Переменные с непонятными названиями это всегда плохой код. Потому что написать понятное название несложно, а усилий на анализ требует меньше.
наталкивается на суровые требования к тому, что и как программа должна делать, за какое время должна быть написана и за какое вознаграждение?
Мы говорим о коде, который можно показывать работодателю. Если вы написали плохой код из-за финансовых или временных ограничений, просто не надо его показывать. Но финансовые или временные ограничения не делают плохой код хорошим.
Может, надо просить кандидата написать сочинение на родном языке и тогда станет понятно, может он мыслить связно или нет?
Как это поможет в проверке качества кода, который пишет кандидат? Никак. Значит и просить об этом не надо.
Интересная статья, спасибо. Но как быть тем, у кого в последние годы все проекты за NDA и код показать нельзя)
Бóльшая часть нашего кода также хранится в приватных репозиториях, это норма, и мы все это понимаем :)
Мой посыл такой:
— Если вы изучаете что-то новое, бывает удобно сделать pet-проект, это и практика, и будет код, который можно показать.
— Если собираетесь давать ссылку на код в резюме, лучше, чтобы это был хороший код.
— Pet-проект — не требование, а способ попрактиковаться и привлечь к себе внимание. Рекомендую начинающим разработчикам или тем, кто меняет сферу работы.
А еще, об этом не было в статье, но иногда pet-проекты бывают такие классные, что сразу хочется общаться — видно, что человек горит своим делом.
Мой посыл такой:
— Если вы изучаете что-то новое, бывает удобно сделать pet-проект, это и практика, и будет код, который можно показать.
— Если собираетесь давать ссылку на код в резюме, лучше, чтобы это был хороший код.
— Pet-проект — не требование, а способ попрактиковаться и привлечь к себе внимание. Рекомендую начинающим разработчикам или тем, кто меняет сферу работы.
А еще, об этом не было в статье, но иногда pet-проекты бывают такие классные, что сразу хочется общаться — видно, что человек горит своим делом.
Тут и без NDA если не сохранил себе все что делал на работе, то считай что сам себе NDA устроил. На самом деле спустя годы практики, фанатично сохранять себе то, что сделал в N-ый раз кому то на чужих условиях, это стремно. Либо за свою практику сделал очень мало, что каждая реализация кажется неповторимой, либо просто ничего ни делал, поэтому сохранял чтоб хоть что то было.
У меня нет привычки тырить свой же код с предприятия где я работал, и так своего хватает. И чаще получается наоборот, я прихожу и внедряю свое решение, которое тестил для своих нужд. Какое тут может быть NDA? Ты уже этот алгоритм использовал у «дяди Пети с тетей Васей», а теперь ты не должен вспопинать про них, потому что использовал тоже самое на новом месте работы с NDA. Может еще про реализацию деревьев напрочь забыть.
На самом деле NDA не запрещает демонстрировать и свой код и знания. Помимо срока годности, если у кого то «бога боязнь» NDA, свободно демонстрируйте свой код как часть проекта не относящегося к работе где либо. Если работодатель хочет знать на каком предприятии вы это писали — нафиг такого работодателя.
У меня нет привычки тырить свой же код с предприятия где я работал, и так своего хватает. И чаще получается наоборот, я прихожу и внедряю свое решение, которое тестил для своих нужд. Какое тут может быть NDA? Ты уже этот алгоритм использовал у «дяди Пети с тетей Васей», а теперь ты не должен вспопинать про них, потому что использовал тоже самое на новом месте работы с NDA. Может еще про реализацию деревьев напрочь забыть.
На самом деле NDA не запрещает демонстрировать и свой код и знания. Помимо срока годности, если у кого то «бога боязнь» NDA, свободно демонстрируйте свой код как часть проекта не относящегося к работе где либо. Если работодатель хочет знать на каком предприятии вы это писали — нафиг такого работодателя.
НЛО прилетело и опубликовало эту надпись здесь
Для меня проблема выбрать, что писать. Хочу в процессе изучения Kotlin начать писать pet-project для Android, обязательно сетевое с использованием API, но не могу определится что. Уже просмотрел кучу списков с API, но идеи нет.
Я бы сказал, что в самом начале важнее не содержание опыта, а скорей стаж и набор ключевых навыков, по которым вы себя позиционируете, а детальный опыт можно указать ниже вместе с технологиями и достижениями.
Всё таки описание опыта может занять не одну страничку и не всегда сходу можно понять, а в чем кандидат хорош, а на самой первой стоит дать сразу понять HR или тех специалисту на собеседовании, какими навыками обладаете и как себя позиционируете.
Признаюсь, мысленно я ставлю дополнительный плюсик кандидатам с профильным образованием в топовых вузах.
Всегда такие требования раздражают, особенно когда еще просят PhD из топовых вузов. Ну вот не жил я в топовом городе с топовым вузом, а закончил обычный провинциальный вуз, и что, теперь на мне метка неполноценного специалиста?!
Мне кажется, вы меня не до конца поняли, или я недостаточно ясно донесла свою мысль. Если вы окончили не топовый вуз, это не проблема, я лично никогда не делала из этого каких-то плохих выводов. Главное, чтобы у вас были знания и навыки. Наоборот, в статье я никому не советую учиться только ради корочки. Это время можно потратить на самообразование и практику.
Как раз в статье я писала, что лично знаю несколько топовых коллег не окончивших ВУЗ. И также знаю очень скилловых ребят, учившихся не по IT-специальности.
Но если возможность такой топовый ВУЗ окончить есть — почему бы это не сделать? Это и база, и знакомства, и возможность стажировки и первого трудоустройства в хорошую компанию.
Дополнительный — ключевое слово. Приятно знать, что кандидат окончил ВУЗ, где дают хорошую базу, или выпускники этого ВУЗа у нас уже успешно работают.
Как раз в статье я писала, что лично знаю несколько топовых коллег не окончивших ВУЗ. И также знаю очень скилловых ребят, учившихся не по IT-специальности.
Но если возможность такой топовый ВУЗ окончить есть — почему бы это не сделать? Это и база, и знакомства, и возможность стажировки и первого трудоустройства в хорошую компанию.
Признаюсь, мысленно я ставлю дополнительный плюсик кандидатам с профильным образованием в топовых вузах.
Дополнительный — ключевое слово. Приятно знать, что кандидат окончил ВУЗ, где дают хорошую базу, или выпускники этого ВУЗа у нас уже успешно работают.
А как насчёт разнообразных mooc? Coursera там, stepic, edx, и прочее?
Или более основательные школы и курсы, где живые преподаватели чему-то обучают за деньгу?
Или более основательные школы и курсы, где живые преподаватели чему-то обучают за деньгу?
Тут у меня нет большого опыта, но расскажу, что знаю.
На Coursera мне очень нравятся курсы по алгоритмам, позволяют освежить знания. Особенно те, что ведет Седжвик — мы по его книге в универе учились, а тут он почти живьем читает лекции! Из прикладных курсов по разработке я пробовала только Python и что-то про мобильную разработку — просто для общего развития. Дело было давно, и тогда уровень мне не очень понравился. Как будто это были курсы программирования для непрограммистов, очень просто и медленно. Но возможно сейчас все поменялось.
С edx вообще не было опыта.
Из прикладных предпочитаю Pluralsight (за него плачу сама). Angular University и egghead у нас корпоративные, иногда там смотрю что-нибудь.
Про школы и курсы с живыми преподавателями — когда мне было актуально, это еще не было развито, поэтому сама обучение не проходила. На собеседовании встречалась с выпускниками некоторых онлайн-школ, уровень был пониже ожиданий. Но я прекрасно понимаю, что в любой школе можно плохо учиться, здесь во многом от студента зависит, его работы и мотивации.
Кстати, вот такую школу мы с коллегами проводим fintech.tinkoff.ru Но она не онлайн, занятия проходят раз в неделю в офисе + домашка.
Если говорить про резюме — при отсутствии опыта, я бы указала пройденные курсы (я и указывала, когда искала работу на фронтенде, а опыт у меня был с другими технологиями).
На Coursera мне очень нравятся курсы по алгоритмам, позволяют освежить знания. Особенно те, что ведет Седжвик — мы по его книге в универе учились, а тут он почти живьем читает лекции! Из прикладных курсов по разработке я пробовала только Python и что-то про мобильную разработку — просто для общего развития. Дело было давно, и тогда уровень мне не очень понравился. Как будто это были курсы программирования для непрограммистов, очень просто и медленно. Но возможно сейчас все поменялось.
С edx вообще не было опыта.
Из прикладных предпочитаю Pluralsight (за него плачу сама). Angular University и egghead у нас корпоративные, иногда там смотрю что-нибудь.
Про школы и курсы с живыми преподавателями — когда мне было актуально, это еще не было развито, поэтому сама обучение не проходила. На собеседовании встречалась с выпускниками некоторых онлайн-школ, уровень был пониже ожиданий. Но я прекрасно понимаю, что в любой школе можно плохо учиться, здесь во многом от студента зависит, его работы и мотивации.
Кстати, вот такую школу мы с коллегами проводим fintech.tinkoff.ru Но она не онлайн, занятия проходят раз в неделю в офисе + домашка.
Если говорить про резюме — при отсутствии опыта, я бы указала пройденные курсы (я и указывала, когда искала работу на фронтенде, а опыт у меня был с другими технологиями).
С удовольствием прочитала статью и решила написать вам спасибо. По делу, просто и понятно.
У самой проблема с кодом на ГитХабе, все проекты под NDA, работа кипит и свободного времени писать свое пока нет. Можно запилить конечно что-то простое и легкое, но не хочется.
У самой проблема с кодом на ГитХабе, все проекты под NDA, работа кипит и свободного времени писать свое пока нет. Можно запилить конечно что-то простое и легкое, но не хочется.
> Сомневаетесь, что считать достижениями? Вот несколько идей:
> Этот список можно продолжать
А если я не внедрял тайпскрипт, не летал на луну, не изобретал велосипед, а решал задачи и закрывал тикеты? Всё, негоден к строевой службе?
> Этот список можно продолжать
А если я не внедрял тайпскрипт, не летал на луну, не изобретал велосипед, а решал задачи и закрывал тикеты? Всё, негоден к строевой службе?
НЛО прилетело и опубликовало эту надпись здесь
другие наоборот ставят минус, типа тратит рабочее время на безделушки
Ну вообще ожидается что проекты на гитхабе в свободное время делаются (если это не руководитель поставил задачу внутреннюю либу или софт в open source выложить).
Ну вообще ожидается что проекты на гитхабе в свободное время делаютсяЛюбой проект, если это не страничка любимого кота в инете или новый калькулятор-медиаплеер с «нескучными скинами», занимает некоторое «место в голове».
Если после дня программирования вечером заняться художественным выпиливанием лобзиком — это переключение и отдых голове, а программировать на работе и дома уже нет, мне так кажется.
Как-то искал новую работу, работая на «текущей»…
Дали тестовое задания — ну и получалось, что на работе половину времени (а то и все) в голове крутились решения тестовых задач, а не текущих. Хотя весь код тестовых писался дома.
Но по факту я выпал из работы компании на 3 дня — до сих пор совесть мучает :(
Так что я хз как люди могут полностью отключится на работе от своих pet-проектов с «интереснейшими» задачами и заниматься текущими -«рутинными»
Дали тестовое задания — ну и получалось, что на работе половину времени (а то и все) в голове крутились решения тестовых задач, а не текущих. Хотя весь код тестовых писался дома.
Но по факту я выпал из работы компании на 3 дня — до сих пор совесть мучает :(
Так что я хз как люди могут полностью отключится на работе от своих pet-проектов с «интереснейшими» задачами и заниматься текущими -«рутинными»
Почти никогда такой проблемы не было. Может потому как раз, что если мне приходит мысль с чем-то поэкспериментировать то я это записываю в таск лист и не думаю эту мысль на работе, так как знаю что дома у меня еще будет на это время. Иногда конечно бывает что на работе что-то прорывается, но обычно что-то в стиле: о, применил то же что и дома; или: так, вот это я тут так сделал, можно будет дома поиграться на одном из игрушечных проектов с этим решением. И дальше иду.
Может это еще и от человека зависит. Кто-то вот на удаленке отвлекается на домашние дела, а кто-то нет.
Впрочем, хз как оно будет если буду тестовое делать для кого нибудь. Скорее всего тоже буду отвлекаться в рабочее время на подумать ибо там и сроки, и требования к коду и прочее.
Может это еще и от человека зависит. Кто-то вот на удаленке отвлекается на домашние дела, а кто-то нет.
Впрочем, хз как оно будет если буду тестовое делать для кого нибудь. Скорее всего тоже буду отвлекаться в рабочее время на подумать ибо там и сроки, и требования к коду и прочее.
С точки зрения работника такие статьи смысла не имеют. В соседнем таком же офисе что и автор сидит точно такая же кадровичка, но с диаметрально противоположными требованиями.Соглашусь — статья «В пользу бедных», с банальной идеей что «Лучше быть богатым и здоровым, чем бедным и больным».
Например:
Вы спросите: «А что насчет стандартных формулировок „стрессоустойчив“, „легко обучаем“ и подобных определений, которые все еще можно подсмотреть в примерах резюме?» На меня они не производят никакого впечатления, и я искренне не понимаю, почему их все еще используют.Зайдите на ХХ.РУ там в 90% вакансий «стрессоустойчивость» отдельно выделена, так же как и «динамично развивающаяся, лидер рынка» и «молодой-дружный коллектив». То есть Ваши коллеги не согласны с Вами чуть менее чем полностью.
PS По моему мнению, при отборе на технические специальности отдел кадров должен проверить справки из психушки-алкашки, а собеседование-тесты дело профессионалов.
Часто кадровицы сидят и из-за всех сил пытаются «обозначить свою значимость», находят какие-нибудь дебильные тесты в инете или просто додумывают за кандидата его историю и мнят себя великими психологами.
Кажется, всем уже известно, что частая смена работы не красит соискателя. Для меня частая смена работы — три и более мест, где вы работали меньше годаа если человека кинули три раза подряд с работой? А может человек приехал с «провинции», из города который «загибается»? надо подробно описывать все детали предыдущих увольнений? Кто-нить будет это читать? Или скажут сопли в резюме нам не нужны?
Ну конечно если речь идет о принятии нового работника в отдел кадров, то тут пусть развлекаются в полный рост, хоть с тестами Роршаха.))
> Зайдите на ХХ.РУ там в 90% вакансий «стрессоустойчивость» отдельно выделена, так же как и «динамично развивающаяся, лидер рынка» и «молодой-дружный коллектив». То есть Ваши коллеги не согласны с Вами чуть менее чем полностью.
Честно говоря, «стрессоустойчивость» в требованиях к разработчикам мне не попадалась как минимум очень давно. Для примера, я проверила актуальные вакансии для фронтендеров в Яндексе, Мейле, Авито…
И как разработчик, могу сказать, что на меня «стрессоустойчивость» и подобные фразы не производят впечатления — ни хорошего, ни плохого. Решает опыт и навыки, стэк технологий, сложные задачи, которые приходилось решать. Именно об этом и хочется читать в резюме, чтобы прикинуть насколько опыт матчится с работой в нашей команде.
Честно говоря, «стрессоустойчивость» в требованиях к разработчикам мне не попадалась как минимум очень давно. Для примера, я проверила актуальные вакансии для фронтендеров в Яндексе, Мейле, Авито…
И как разработчик, могу сказать, что на меня «стрессоустойчивость» и подобные фразы не производят впечатления — ни хорошего, ни плохого. Решает опыт и навыки, стэк технологий, сложные задачи, которые приходилось решать. Именно об этом и хочется читать в резюме, чтобы прикинуть насколько опыт матчится с работой в нашей команде.
. Решает опыт и навыки, стэк технологий, сложные задачи, которые приходилось решать. Именно об этом и хочется читать в резюме, чтобы прикинуть насколько опыт матчится с работой в нашей команде.Значит Вы приятное исключение.
Часто «стрессоустойчивость» маскируют «круглыми фразами», типа «умение работать в многозадачном режиме», «умение ориентироваться в динамично меняющейся обстановке », «способность быстро переключаться между задачами» и тд
Последний перл который мне попался, не помню уж чья вакансия — «Способность работать под давлением». Прям сразу перед глазами всплыл финальный эпизод из первого Терминатора, когда Т800 попал «под давление», но на последнем заряде батареи пытался выполнить задачу ))
Зайдите на ХХ.РУ там в 90% вакансий «стрессоустойчивость» отдельно выделена, так же как и «динамично развивающаяся, лидер рынка» и «молодой-дружный коллектив». То есть Ваши коллеги не согласны с Вами чуть менее чем полностью.
Значит, 90% коллег автора пишут булшит, потому что я не видел ни одного резюме с самоописанием типа «нервный, не уверенный в себе, быстро впадаю в панику, не могу общаться с коллегами» и прочее.
Значит, 90% коллег автора пишут булшит, потому что я не видел ни одного резюме с самоописанием типа «нервный, не уверенный в себе, быстро впадаю в панику, не могу общаться с коллегами» и прочее.Я как-то писал в отклике что хотел бы добавить в их «молодой и дружный коллектив» немного «старости и склочности».
Почему-то мне не ответили. ))
Любой состоявшийся специалист имеет специализацию, предпочитает какой-то конкретный стек технологий и позиционирует себя как носитель конкретного набора скилов. На мой взгляд, описание всех этих моментов — самая важная часть резюме. Однако, эта часть часто бывает либо полностью пропущена, либо отнесена к маловажным «дополнительным сведениям», типа «прав категории Б» и «стрессоустойчивости». Как и в данной статье.
Вообще, когда пишешь резюме, часто есть такое ощущение, что кроме тебя еще сотня кандидатов на какое-нибудь место.
В реальности (если вы не гугл), то на миддл-сеньор позицию вам пришлют дай боб штук 10 резюме, достойных внимания, плюс еще человек 5-10 смогут привести рекрутёры или сам тимлид поищет по профильным сообществам и сможет кого-то найти.
Мне понравилась фраза о том, что резюме — это как трейлер к фильму. Главная его задача — так, чтобы после прочтения было интересно поговорить еще.
Но на рынке такая ситуация, что если у вас там не написано совсем дикой дичи, на первый тур вас скорее всего позовут. А дальше оно уже не играет никакой роли.
В реальности (если вы не гугл), то на миддл-сеньор позицию вам пришлют дай боб штук 10 резюме, достойных внимания, плюс еще человек 5-10 смогут привести рекрутёры или сам тимлид поищет по профильным сообществам и сможет кого-то найти.
Мне понравилась фраза о том, что резюме — это как трейлер к фильму. Главная его задача — так, чтобы после прочтения было интересно поговорить еще.
Но на рынке такая ситуация, что если у вас там не написано совсем дикой дичи, на первый тур вас скорее всего позовут. А дальше оно уже не играет никакой роли.
Мне понравилась фраза о том, что резюме — это как трейлер к фильму. Главная его задача — так, чтобы после прочтения было интересно поговорить еще.Проблема только в том что пишешь трейлер для будущего «научного руководителя», а читает твой сценарий ( и принимает решение пущать/не пущать дальше ) «секретарь зама по хозяйственной части.»
PS Есть конечно специализированные кадровые агентства, при крупных софтовых конторах.
Там ХР-ы постоянно варятся в этой среде, знают все тонкости и толстости момента, ну и главное имеют возможность оперативно консультироваться со специалистами своей фирмы.
Такой вопрос, если ты идёшь на джуна, есть ли смысл указывать в резюме свои аккаунты на codewars, hackerRank и т.п.?
И что хуже, аккаунт там с плохим кодом или отсутствие ссылки на него?)))
Если аккаунты не совсем пустые, а реального рабочего опыта нет или мало — я бы точно указала. Да даже если и опыт есть — why not… Мы с коллегами, уже взрослые разработчики-тимлиды, тоже иногда решаем/обсуждаем и рекомендуем нашим джунам для развития.
Когда общаюсь с джунами / стажерами с прицелом в свою команду, я на аккаунты очень хорошо реагирую :)
Но даже если не указывать, такие сайты здорово помогают набить руку.
Когда общаюсь с джунами / стажерами с прицелом в свою команду, я на аккаунты очень хорошо реагирую :)
Но даже если не указывать, такие сайты здорово помогают набить руку.
Без обратной связи только больше научишься писать говнокод…
На сайтах типа LeetCode, CodeWars решение обычно небольшая функция, вряд ли именно там научишься писать говнокод. А вот закрепить знание синтаксиса и умение реализовать решение в коде — бесценно.
Тут еще замечу, что все джуны разные — кто-то джуниор во фронтенде, но до этого 4 года в университете занимался программированием, а кто-то раньше не программировал и пришел совсем из другой профессии. И как раз для тех, кто раньше не программировал, практика просто необходима.
Я всегда прошу стажеров и джуниоров писать код, и ожидаю, что кандидат понимает, что такое массив, цикл, условие… Это как минимум.
PS: на CodeWars среди решений других участников иногда вижу однострочные, но плохо читаемые функции, с большим числом голосов «Clever»… Если учиться исключительно на таких решениях, то можно нахвататься странных идей, но это прямо надо постараться.
PPS: Кстати, я нигде не писала, что отсутствие ссылки — это очень плохо ) В большинстве случаев такой ссылки нет, будем честными. Но это мой совет — практиковаться, и об этом активном желании развиваться сообщить потенциальному работодателю.
Тут еще замечу, что все джуны разные — кто-то джуниор во фронтенде, но до этого 4 года в университете занимался программированием, а кто-то раньше не программировал и пришел совсем из другой профессии. И как раз для тех, кто раньше не программировал, практика просто необходима.
Я всегда прошу стажеров и джуниоров писать код, и ожидаю, что кандидат понимает, что такое массив, цикл, условие… Это как минимум.
PS: на CodeWars среди решений других участников иногда вижу однострочные, но плохо читаемые функции, с большим числом голосов «Clever»… Если учиться исключительно на таких решениях, то можно нахвататься странных идей, но это прямо надо постараться.
PPS: Кстати, я нигде не писала, что отсутствие ссылки — это очень плохо ) В большинстве случаев такой ссылки нет, будем честными. Но это мой совет — практиковаться, и об этом активном желании развиваться сообщить потенциальному работодателю.
Ну у меня как раз ситуация, что я полез играться с высокоуровневыми языками после низкого уровня и у меня получается индусский код и я очень завидую этим однострочным решениям. А большинство хитрого синтаксиса всегда можно расписать простым.
p.s. я и спросил выше, что лучше, говнокод или отсутствие ссылки на него?
p.s. я и спросил выше, что лучше, говнокод или отсутствие ссылки на него?
А, понятно, выше я подумала, что это в контексте «говнокод или отсутствие ссылки» для джунов, но вы, похоже, говорите о другой ситуации — когда опыт есть, просто в других языках )
Чисто по-человечески, я бы не смогла отправить ссылку на код, который заведомо считаю плохим, потенциальному работодателю. А с другой стороны, если вы видите проблему, значит можете попытаться ее исправить и показать наилучший код, который способны написать сейчас.
Со стороны интервьюера — понимая, что у кандидата опыт в других технологиях, но сейчас он хочет переквалифицироваться, я бы, наверно, хотела посмотреть код — в худшем случае, кандидата не пригласят на собеседование, но зато все сэкономят время — кандидат в том числе (и может дело даже не в говнокоде, а в том, что в проект прямо сейчас нужен опытный разработчик, который начнет закрывать таски с первого дня). В теории, по коду могут дать фидбэк (или его можно попросить явно).
Чисто по-человечески, я бы не смогла отправить ссылку на код, который заведомо считаю плохим, потенциальному работодателю. А с другой стороны, если вы видите проблему, значит можете попытаться ее исправить и показать наилучший код, который способны написать сейчас.
Со стороны интервьюера — понимая, что у кандидата опыт в других технологиях, но сейчас он хочет переквалифицироваться, я бы, наверно, хотела посмотреть код — в худшем случае, кандидата не пригласят на собеседование, но зато все сэкономят время — кандидат в том числе (и может дело даже не в говнокоде, а в том, что в проект прямо сейчас нужен опытный разработчик, который начнет закрывать таски с первого дня). В теории, по коду могут дать фидбэк (или его можно попросить явно).
Для джунов, если я переквалифицируюсь, то естественно, что знания на уровне джуна или ниже… Или вы их тоже отправляете «начинать закрывать таски с первого дня»?
Сэкономит время интервьверу, но я не узнаю о своих косяках и ошибках.
Сэкономит время интервьверу, но я не узнаю о своих косяках и ошибках.
Сэкономит время интервьверу, но я не узнаю о своих косяках и ошибках.
И вам тоже время сэкономит, не надо лишний раз ехать на интервью (даже если по скайпу — тоже время). Кажется, что получить фидбэк по коду можно менее энергозатратным способом — опубликовать код на тематическом сайте или напрямую написать специалистам и попросить совета.
Опять же, интервью в разных местах по-разному проводят — где-то объяснят подробно что не так, где-то толком ничего не скажут, где-то дадут рекомендации и список материалов для подготовки, где-то нет… Но тут личный выбор каждого, каким способом искать фидбэк.
«начинать закрывать таски с первого дня»
Может грубовато прозвучало ) Идея в том, что иногда нужен разработчик опытный (уверенный миддл или выше), способный быстро влиться в команду и не требующий много опеки и обучения — вот это я назвала «начинать закрывать таски с первого дня». Иногда можно взять менее опытного миддла, есть возможность менторить и растить. Иногда готовы брать джунов без опыта, понимая, что обучать придется много, но зато и перспективы отличные.
Но так-то да, обычно джуны тоже приступают к работе над реальными задачами с первого дня. Просто это задачи другого уровня.
Спасибо за развёрнутый ответ.
Хотя я и не очень понял про публикацию кода с codewars на другом тематическом сайте ради фидбека))
Хотя я и не очень понял про публикацию кода с codewars на другом тематическом сайте ради фидбека))
Ну, я имела в виду, что если вы действительно хотите фидбэк, и есть код, чтобы предъявить, то можете его опубликовать где-то и напрямую задать вопрос об этом коде другим разработчикам. Будет ли это код с codewars? Не обязательно. Кажется, для качественного фидбэка надо чуточку больше кода… На самом codewars тоже есть некие дискуссии, но не уверена, что там часто дают ответ.
Вообще в последнее время LeetCode больше нравится )
Еще помню пару интервью, когда попадались вроде бы хорошие мотивированные ребята, но со слабыми навыками написания кода, взять их в команду не могли. И я им сама говорила, что надо попрактиковаться и можно задавать вопросы мне, если что. Никто, правда, с вопросами не обращался :-D
Вообще в последнее время LeetCode больше нравится )
Еще помню пару интервью, когда попадались вроде бы хорошие мотивированные ребята, но со слабыми навыками написания кода, взять их в команду не могли. И я им сама говорила, что надо попрактиковаться и можно задавать вопросы мне, если что. Никто, правда, с вопросами не обращался :-D
со слабыми навыками написания кода, взять их в команду не могли. И я им сама говорила, что надо попрактиковаться
Каковы симптомы подобного? Ну и вы же понимаете, что без реальных задач практиковаться сложно, тем более джуну.
Каковы симптомы подобного?
Допустим, решаем задачу, не требующую специальных знаний. Тот же fizzbuzz или что-то вроде этого leetcode.com/problems/valid-anagram
И кандидат не знает как подступиться вообще или не может реализовать озвученное на словах, потому что плохо представляет работу с циклами, переменными, условиями.
Будет полезнее дома задачки покодить, чем выходить на работу и сразу нырять в реальные задачи, где помимо синтаксиса языка еще фреймворк, бизнес-логика, большой объем кода, тесты надо учиться писать… Не до изучения циклов :)
Как-то у вас слишком просто получается, что вы готовы брать джунами тех, кто кое-как сможет написать такой код, про оптимальность которого вы даже не заикнулись, по сравнению с авито в соседней статье, которым нужны миддлы по цене джунов…
вот у меня сейчас «конфликтное» резюме… из-за того, что решил изучать новую технологию…
писал довольно долго на С++ на фрилансе, но решил выйти в «белую зп», а в своем городе смог найти только php-разработку
в итоге: с php разобрался довольно быстро, ну и менял работы раз в 6-9 месяцев по причине зарплатных хотелок (обычно +30-35% от текущей зп), потом пара сартапов не взлетело… итого куча смен мест работы…
вот как мне теперь быть, чтоб не пасть «лицом в грязь» перед HR?
писал довольно долго на С++ на фрилансе, но решил выйти в «белую зп», а в своем городе смог найти только php-разработку
в итоге: с php разобрался довольно быстро, ну и менял работы раз в 6-9 месяцев по причине зарплатных хотелок (обычно +30-35% от текущей зп), потом пара сартапов не взлетело… итого куча смен мест работы…
вот как мне теперь быть, чтоб не пасть «лицом в грязь» перед HR?
вот как мне теперь быть, чтоб не пасть «лицом в грязь» перед HR?Устроится на «галеру» и отпахать там 3-4 года, чтобы «смыть позор» пОтом и кровью стертых пальцев.
Оставьте пару более-менее нормальных мест, про остальные напишите "фриланс". Понятно, что это не совсем соответствует положению дел, но раз рекрутеры игнорируют, что так может быть по объективным причинам, то по-другому не получается.
Автор молодец, толковая статья. Вот только не надо было как бы невзначай впихивать эту «Британскую высшую школу дизайна» — слишком выпирает самолюбование. В-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Резюме глазами интервьюера