SVZ>>Ну а если он вносил точечные исправления в _чужой_ код, то тут как-бы и показывать нечего.
S>я видел живого человека которы1 15+ лет в уважаемой компании вносил точечные исправления
Ну и зачем им неудачники(c)?

U>Прошу, по возможности, прислать примеры вашего актуального кода на C#, чтобы не тратить не это время при созвоне.
U>вот реально что они хотят увидеть? накопипастить годного кода я могу. чего им это даст? конкретизировали бы хотябы какая область интересна
Смогут сказать "этот код неработоспособный", "вот тут у вас куча антипаттернов", и "ваша зарплата составит xx при выполнении kpi"

U>вот реально что они хотят увидеть? накопипастить годного кода я могу. чего им это даст? конкретизировали бы хотябы какая область интересна

Я такое только поддерживаю. Сам предпочитаю посмотреть на профиль человека на ГитХабе при найме.

Посмотреть на репу (или несколько) человека скажет о нем больше, чем зазубренные ответы на вопросы про люки и надро наученность грокать литкодовские задачи. А именно, репка (-ки) покажут, насколько человек профессионал, его культуру разработки и как он подходит к своей работе. Ну к примеру:
— как он оформляет коммиты
— комитит раз в месяц большим куском или нет
— как он делает МРы
— умеет ли релизить/теггировать
— как оформляет репозитория и код в целом
— ну про сам код молчу
— структура проекта
— различение на модули/сабмодули
— можно увидеть, насколько он шарит в CI/CD
— насколько уделяет внимание тестам

А если поглядеть чуть шире, как он участвует в коммьюнити (вопросы/ответы), то тогда вообще красота! Это не только про самостоятельность, умение излагать свои мысли (на английском в том числе), но и уровень общения с коллегами в целом.

Ну и в целом: по комитам можно проследить, как человек относится к продукту и как развивает его.

>репка (-ки) покажут, насколько человек профессионал, его культуру разработки и как он подходит к своей работе. Ну к примеру:
DP>- как он оформляет коммиты
DP>- комитит раз в месяц большим куском или нет
DP>- насколько уделяет внимание тестам
Всё равно придётся все эти привычки перенастраивать по целеуказаниям тимлида, нереально с улицы угадать в точности все мястечковые хотелки, слишком они диаметрально разные в разных командах.
DP>- как он делает МРы
DP>- умеет ли релизить/теггировать
DP>- как оформляет репозитория и код в целом
DP>- ну про сам код молчу
DP>- структура проекта
DP>- различение на модули/сабмодули
DP>- можно увидеть, насколько он шарит в CI/CD
А это вообще навыки релиз-мастера или архитектора. Который 1шт на предприятие, а всем остальным предложат с их личными предпочтениями по этим вопросам пойти подальше, и делать как велено.
DP>Ну и в целом: по кометам можно проследить, как человек относится к продукту и как развивает его.
Именно, куда-то в область астрологии всё это.

Здравствуйте, Pzz, Вы писали:

Pzz>Обычно в конторах нонешних модно кодить в стиле, описанным местечковым coding style guide-ом.
С ним лучше, чем без него. Еще лучше когда он основан на каком-нибудь более-менее популярном стандарте а-ля Qt или boost.

Pzz>Так что какая разница, как твой текущий код выглядит, все равно заставят писать по-другому.
Не, coding style guide это в основном про форматирование, а не про то как бизнес-задача выражена в коде.

Здравствуйте, sergii.p, Вы писали:

SP>Кстати, второй вариант предпочтительнее. Потому как когда любой программист видит код другого программиста, он теряет дар речи, переходит исключительно на мат, и говорит, что такого мудака брать точно не стоит. Ну говорю исключительно по себе.
Не везет вам, так далеко не всегда.

SP>Когда видел в резюме ссылку на гитхаб, точно туда лез и потом разносил чувака уже на собесе по найденным слабым местам.
У меня как-то раз было наоборот: дали тестовое задание, нашел решение на гитхабе, посмотрел, но сделал свое. На собеседование со стороны работодателя был автор решения с гитхаба и большую часть времени мы обсуждали почему мое решение лучше

Здравствуйте, Skorodum, Вы писали:

Pzz>>Обычно в конторах нонешних модно кодить в стиле, описанным местечковым coding style guide-ом.
S>С ним лучше, чем без него. Еще лучше когда он основан на каком-нибудь более-менее популярном стандарте а-ля Qt или boost.

Лучше, когда он тулзами енфорсится, как в Go. Тогда во-первых некому предъявлять, что они своим уродским стилем подавляют моё уникальное самовыражение, а во-вторых, когда оно автоматически форматирует, это, блин, удобно.

Pzz>>Так что какая разница, как твой текущий код выглядит, все равно заставят писать по-другому.
S>Не, coding style guide это в основном про форматирование, а не про то как бизнес-задача выражена в коде.

Она как-то по-твоему будет выражена, если ты в решении этой бизнес-задачи участвуешь на промежутке от ее начала и до какого-то конца. А нонешнее поколение привыкло работать короткими задачами и без личной привязки к какому-то определенному месту в коде (т.е., с весьма поверхностным пониманием кода в целом).

Здравствуйте, Osaka, Вы писали:

O>Всё равно придётся все эти привычки перенастраивать по целеуказаниям тимлида, нереально с улицы угадать в точности все мястечковые хотелки, слишком они диаметрально разные в разных командах.
Нет, после определенного уровня все более-менее стандартно. Но да, этот уровень есть далеко не везде. Хорошо — оно более-менее одинаково хорошо, а вот плохо может быть очень по разному.

O>А это вообще навыки релиз-мастера или архитектора. Который 1шт на предприятие, а всем остальным предложат с их личными предпочтениями по этим вопросам пойти подальше, и делать как велено.
Хорошо, если для этого есть отдельная клетка, но это далеко не всегда так. Основной посыл тут в том, что человек должен вести проект так, чтобы он легко собирался CI/CD системой, а не только любимой средой разработки на локальном компьютере.

Здравствуйте, Pzz, Вы писали:

Pzz>Лучше, когда он тулзами енфорсится, как в Go. Тогда во-первых некому предъявлять, что они своим уродским стилем подавляют моё уникальное самовыражение, а во-вторых, когда оно автоматически форматирует, это, блин, удобно.
Так про это и речь. Для С/С++ это .clang-format в корне проекта и все

Pzz>Она как-то по-твоему будет выражена, если ты в решении этой бизнес-задачи участвуешь на промежутке от ее начала и до какого-то конца. А нонешнее поколение привыкло работать короткими задачами и без личной привязки к какому-то определенному месту в коде (т.е., с весьма поверхностным пониманием кода в целом).
Это все какая-то личная боль. Речь про то, что достатчно примера решения простой задачи, чтобы оценить стиль самовыражения с помощью кода и коммитов.

S>Нет, после определенного уровня все более-менее стандартно. Но да, этот уровень есть далеко не везде. Хорошо — оно более-менее одинаково хорошо, а вот плохо может быть очень по разному.

S>Хорошо, если для этого есть отдельная клетка, но это далеко не всегда так. Основной посыл тут в том, что человек должен вести проект так, чтобы он легко собирался CI/CD системой, а не только любимой средой разработки на локальном компьютере.

Да, мой посыл выше был о том, что по репам можно понять уровень человека. Ну условно:
— не пользуется системой контроля версий или закоммитил тестовое/что там еще один раз одним куском как было на локальном диске
— коммит раз в месяц с текстом "-" со всеми потрохами личных настроек его ИДЕ
— коммит раз в неделю с текстом "as is"
— обдуманные коммиты с разбиением на атомарные фичи + используется .gitignore
— настроенный CI/CD с пре-коммит хуком, автоматическим прогоном тестов
— все настроено с отвязкой от ИДЕ, можно девелопить продукт под все платформы
— все что выше + заполненный ридми
— все то же самое + выкатка релиза с автоматическими релиз ноутсами, документация
— все выше + поддержка проекта: нетоксичный ответ на вопросы пользователей, прием ПРов, ведение проекта в ГитХабе (задачи, планы по релизам) и прочее

Вот это все — совершенно разные профессиональные уровни и уровни автономности.

А так: порой удивляешься коллегам и их уровню владения не то что ребейзами и МРам, но элементарно владению гитом. И это синьоры-помидоры

Ну и да, коммиты показывают +- что у человека в голове и как он структурирует информацию и как мыслит.

Здравствуйте, undo75, Вы писали:


U>

U>Спасибо за отклик!
U>Прошу, по возможности, прислать примеры вашего актуального кода на C#, чтобы не тратить не это время при созвоне.

Нормальный запрос. Залей куда-нибудь свой любой пет проект, на конец — сделай если нету.
Тут важен не столько размер проекта, сколько просто показать что ты умеешь писать понятный код, умеешь пользоваться каким-то стеком, посмотри в вакансии что используют, сделай под их запрос.
Уточни это в сопроводительном письме чтобы было однозначно понятно что это не единственное что ты сделал, а просто "демка" для оценки качества кода.
Если тебе данная работа интересна и важна ты это сделаешь, если нет — то не стоит и брать тебя на работу которая тебе не так важна.

U>подмывает ответить этим

Будешь воспринят как неадекват

Здравствуйте, DiPaolo, Вы писали:

DP>Да, мой посыл выше был о том, что по репам можно понять уровень человека. Ну условно:
...
Хороший список, но я бы дополнил, что выполнение некоторых пунктов все же зависит от приоритетов, наличия ресурсов и стадии жизни проекта, что-то может быть еще не реализовано по объективным причинам, в то время как причин для плохихи коммитов в условном "мастере" нет никогда.

DP>А так: порой удивляешься коллегам и их уровню владения не то что ребейзами и МРам, но элементарно владению гитом. И это синьоры-помидоры
Это да, все чаще прихожу к выводу, что владение системой контроля версий, понимание почему хорошие коммиты это важно и способносить писать грамотные комментарии к коммитам это совершенно отдельный набор навыков, который с "сеньёрностью" очень часто имеют обратную корреляцию.

DP>Ну и да, коммиты показывают +- что у человека в голове и как он структурирует информацию и как мыслит
И насколько он понимает, что для решения практически любой более-менее сложной задачи надо грамотно коммуницировать с другими людьми. Коммит это ведь как код — послание другим разработчикам, в т.ч. самому себе в будущем.

Здравствуйте, Pzz, Вы писали:

Pzz>А что, интересно, должен делать человек, который всю жизнь по найму работал?
Потратить час и сделать проект по решению квадратного уровня/судоку/что вам нравится Ничем не хуже тестового задания. Это может сэкономить время обоим сторонам.

Здравствуйте, Osaka, Вы писали:

>>репка (-ки) покажут, насколько человек профессионал, его культуру разработки и как он подходит к своей работе. Ну к примеру:
DP>>- насколько уделяет внимание тестам
O>Всё равно придётся все эти привычки перенастраивать по целеуказаниям тимлида, нереально с улицы угадать в точности все мястечковые хотелки, слишком они диаметрально разные в разных командах.

Не надо ничего угадывать, более менее адекватный тим-лид понимает это не хуже тебя и не будет сравнивать твой код с местным и отсеивать только по той причине что ты используешь другой стиль или делаешь иначе чем принято у них.
А если лид не дорос еще — то тебе же лучше будет если он тебя "отсеет" из-за личных хотелок.

DP>- все выше + поддержка проекта: нетоксичный ответ на вопросы пользователей, прием ПРов, ведение проекта в ГитХабе (задачи, планы по релизам) и прочее
DP>Вот это все — совершенно разные профессиональные уровни и уровни автономности.

Полагаю, что для некоторых областей разработки этот подход уместен. Особенно в случае, если для вакансии требуются именно перечисленные компетенции и навыки.
Но это не универсально. Например там где я работал, релизами и пр. ноутсами и документациями занимались ответственные за это отделы.
Не говоря уже об ответах на вопросы пользователей.

Если речь про pet-проекты, то как уже писали в этой теме? их может и не быть.
Вот у меня никогда не было (по крайней мере вышедших за рамки исследования/PoC).
Потому что свободное время интереснее было потратить на улучшения по основному месту работы (техдолг и пр. всегда есть).

DP>Ну и да, коммиты показывают +- что у человека в голове и как он структурирует информацию и как мыслит.

Определенно, но отмечу, что с другими VCS (не git) я был более продуктивен.

O>>Всё равно придётся все эти привычки перенастраивать по целеуказаниям тимлида, нереально с улицы угадать в точности все мястечковые хотелки, слишком они диаметрально разные в разных командах.
S>Нет, после определенного уровня все более-менее стандартно. Но да, этот уровень есть далеко не везде. Хорошо — оно более-менее одинаково хорошо, а вот плохо может быть очень по разному.
В том и проблема, что свои неповторимые хотелки начальнег начинает выдавать за нечто "одинаково общепринятое везде, которое смеют не знать только полные дебилы", а все кто не угадал — у него неадекваты, преступно отказывающиеся предвосхищать его невысказанные желания. А в следующем месте — за "общепринятое везде" начальнег выдаёт совершенно противоположное.

Pzz>Лучше, когда он тулзами енфорсится, как в Go. Тогда во-первых некому предъявлять, что они своим уродским стилем подавляют моё уникальное самовыражение, а во-вторых, когда оно автоматически форматирует, это, блин, удобно.

немножко игрался с https://go.dev/play/. Дико раздражало, что оно строки с импортом "неиспользуемых" пакетов удаляло не спросив.
Может такое поведение характерно только для этой песочницы, но ведь это своего рода "витрина".

Здравствуйте, Osaka, Вы писали:

O>В том и проблема, что свои неповторимые хотелки начальнег начинает выдавать за нечто "одинаково общепринятое везде, которое смеют не знать только полные дебилы", а все кто не угадал — у него неадекваты, преступно отказывающиеся предвосхищать его невысказанные желания. А в следующем месте — за "общепринятое везде" начальнег выдаёт совершенно противоположное.
Значит один (или оба) этих начальника вам неподходят и чем раньше это видно — тем лучше.
И это никак не противоречит факту, что объективно хороший стандард в отрасли существует.

Здравствуйте, m2user, Вы писали:

M>Но это не универсально. Например там где я работал, релизами и пр. ноутсами и документациями занимались ответственные за это отделы.
Пользователи обнаружили баг в версии x.y.z, вам надо взять соответсвующую версию исходников собрать и отладить. То, как вы используете CI/CD позволяет это сделать легко?

M>Определенно, но отмечу, что с другими VCS (не git) я был более продуктивен.
Какого функционала не хватает в git?

Pzz>А что, интересно, должен делать человек, который всю жизнь по найму работал? Спроси их, как они отнесутся, если ты какое-то время у них поработаешь, а потом написанный на работе код другим работодателям будешь показывать.

ну как вариант:
— потратить время не на зазубривание алгоритмов, а на написание кода
— сделанные до этого тестовые опубликовать на ГитХабе
— код лабораторок с универа привести в удобочитаемый вид
— просто сделать что-то полезное для себя/соседки/друга
— порой пишутся всякие вспомогательные утилиты. ну типа:
* выдернуть по АПИшке какие-то данные для теста
* замокать асинхронный сервер с генерацией туевой тучи запросов; прикрутив потом туда ручку регулировки частоты запросов; а потом прикручиваешь туда рандомизацию, то или иное распределение, потом имитируешь нагрузку юзеров в зависимости от времени суток, прикручиваешь к этому UI/АПИ/CLI, заворачиваешь в докер — и вот это уже вполне солидный продукт, родившийся из мимолетной необходимости потестить очередной эндпоинт своей АПИшки
* сходить залогиниться по РЕСТу и тоже получить какие-то данные, раскрасить их и сделать из них другие нужные тебе данные
* качнуть эксельку по некоему вычисляемому УРЛу с текущей датой и распрасить данные, сложив их в базку

да полно таких примеров и повседневных задач!

ессно это все альтернативы коду на бумажке, онлайн кодингу и заученным задачам на люки и алгоритмы тут уж у всех свои предпочтения с обеих сторон