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

bnk>Такой навык хорош для поддержки. Для проектирования и разработки новой функциональности как-то не особо IMHO
bnk>То есть, даже если ты знаешь 100 способов как сделать X криво, это вовсе не значит что ты знаешь как X сделать прямо.

Так прикол-то в том, что то, что вынуждены поддерживать так, как Максим написал, родили как раз те, кто "разрабатывал и проектировал новую функциональность"

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

C>Давайте порассуждаем, почему так происходит? Совершенно очевидно, что пока подход не изменится, то "догнать и перегнать" не получится.

Ну вот не надо все под одну гребенку.
Компании — они сильно разные. Везде.

Если захотеть, я могу из своей практики полугодичной давности откопать пример, когда одна супер-пупер английская инвестиционная компания аутсорсит у нас, и им нужны мега-финансовые аналитики и девелоперы в одном флаконе. И надо офигенно разбираться в домене, потому что ночью может позвонить злой клиент и спросить, куда пропали его 50 лямов евро. И изъяснятся этот клиент будет с использованием всякого финансового сленга на английском.
На встречный вопрос, а как у них организован процесс тестирования, они ответили "ну, мы даем коллегам посмотреть код".

Или есть масса примеров, когда на собеседовании в наши компании со мной говорили офигезные спецы и задавали очень интересные вопросы. Хотя примеров наших "молодых, динамически развивающихся компаний" тоже хватает. И примеров распилов и откатов и там и тут предостаточно.

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

Тё>Можно заставить бесплатно фиксить баги.

На собеседовании? Артем, ну что за наивность.
На собеседовании ответ должен быть известен заранее, иначе нет никаких шансов понять, что делает кандидат, и как дать ему подсказку, если он застрял.

S>Кстати, я обычно проши собеседующих показать мне именно это: что и как они сделали сегодня или вчера. Таск, код, коммит.

Так может не сработать, особенно с реальными сеньорами. Потому что ответ будет, гм, странным. Примерно так: "написал документы о Х, У, сделал 5 код ревью, зафайлил 5 тасков, ну и вечерком по-быстрому пофиксил баг, который 20 человек искали уже месяц, баг простой, но надо было просмотреть сотню-другую вложенных вызовов в стеке среди разных языков".

bnk>Такой навык хорош для поддержки. Для проектирования и разработки новой функциональности как-то не особо IMHO

За столько лет опыта в индустрии я честно скажу: "новая функциональность" разрабатывается в 2-3% случаев. Все остальное — это повторение уже существующей функциональности (копи-паст, иногда со стековерфлоу напрямую, иногда — в виде перевода с одного языка на другой, иногда просто между разными файлами).

bnk>То есть, даже если ты знаешь 100 способов как сделать X криво, это вовсе не значит что ты знаешь как X сделать прямо.

В том и идея, что если ты знаешь 100 способов, как другие делают криво, подавляющего большинства кривизны удастся избежать. А если ты никогда не дебажил чужой код, то ты просто обязан сделать все те ошибки, которые они уже сделали. Только учиться на этих ошибках опять же будешь не ты, а те, кто поддерживает.
В больших конторах это особенно ярко выражено. До такой степени, что люди попросту никогда не рефакторят, а просто городят рядом велосипеды. Потому что рефакторинг — это сложно, это надо уметь читать код. А писать код большого ума не надо...

К>Тебе еще повезло, а один человек с 15 лет опыта пришел на собеседование, а его что такое ООП спросили.

Если тебя спрашивают про ООП на собеседовании, значит они просто не знают, что спросить. Дилетанты, короче.

Чуть более креативные чуваки спрашивают, как решать задачу, которую они только что решили. И если ты ее раньше не решал, то обломаешься (выдав какие-то убогие нерабочие варианты), а они таким образом самоутвердятся (ведь они-то ее решили, а ты нет, и не важно, что их было четверо и пара недель времени + глубокие знания и опыт в предметной сфере).

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

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

C>На этом фоне даже избитый формат собеседований FAANG кажется более адекватным. Давайте порассуждаем, почему так происходит? Совершенно очевидно, что пока подход не изменится, то "догнать и перегнать" не получится.

Очевидно, чтобы не взять болтуна, который даже в умные указатели не умеет.

R>Чуть более креативные чуваки спрашивают, как решать задачу, которую они только что решили. И если ты ее раньше не решал, то обломаешься (выдав какие-то убогие нерабочие варианты), а они таким образом самоутвердятся (ведь они-то ее решили, а ты нет, и не важно, что их было четверо и пара недель времени + глубокие знания и опыт в предметной сфере).

А если так получится, что ты решишь, и притом лучше, чем они? И за 45 минут, а не за пару недель.
Ибо глубокие знания и опыт в предметной сфере очень часто соседствуют с исключительно узким взглядом на вещи... а конкретнее, если эти четверо знают только С++, а им нужно что-нибудь вроде системы обмена сообщениями, то, конечно, они не то что 4, а 44 недели проведут, делая то, что другие могут просто выдать на-гора.

SD>В больших конторах это особенно ярко выражено. До такой степени, что люди попросту никогда не рефакторят, а просто городят рядом велосипеды. Потому что рефакторинг — это сложно, это надо уметь читать код. А писать код большого ума не надо...

Дело не в уме. Рефакторинг рисковый и трудозатратный. И похвастать в перформанс ревью им сложно. Гораздо больший выхлоп лично для разработчика это новые фичи.

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

G>Дело не в уме. Рефакторинг рисковый и трудозатратный. И похвастать в перформанс ревью им сложно. Гораздо больший выхлоп лично для разработчика это новые фичи.

Не всегда.
Рефакторинг может сильно снизить стоимость поддержки системы. Убрать операционные риски.
Тут выхлоп может быть покруче

L>Тут выхлоп может быть покруче

Не "может", а почти всегда намного круче, чем очередной велосипед рядом.

Только это совершенно недоказуемо в крупной конторе. Так что да, gardener правильно написал — "это недоказуемо на перформанс ревью".

Вот потому у маленьких контор — стартапов — таки есть много шансов тягаться с громадами. Ибо люди работают на результат, а не на ревью...

L>Не всегда.
L>Рефакторинг может сильно снизить стоимость поддержки системы. Убрать операционные риски.
L>Тут выхлоп может быть покруче

Для компании — да. А вот для меня например, рядового разработчика — нет. Ну скажем так, как правило нет.

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

G>Дело не в уме. Рефакторинг рисковый и трудозатратный. И похвастать в перформанс ревью им сложно. Гораздо больший выхлоп лично для разработчика это новые фичи.

Да вроде можно, главное не рефакторить то, что и так работает нормально. А так, берешь проект который в полной жопе, делаешь его чуть менее (лучше, конечно, побольше чем "чуть", но тут уж как получится) жутким и менеджмент писает кипятком

KP>Да вроде можно, главное не рефакторить то, что и так работает нормально. А так, берешь проект который в полной жопе, делаешь его чуть менее (лучше, конечно, побольше чем "чуть", но тут уж как получится) жутким и менеджмент писает кипятком

Боюсь, ты путаешь контракторов с FTE (которые на performance review).

Также ты можешь иметь несколько иное мнение про "проект в полной жо". Я неоднократно видел, как в отлично вылизанный проект приходил кто-нибудь со стороны, и в течение буквально 2-3 месяцев колбасил столько tech debt, что его потом нужно было разгребать еще год, причем целой командой. И да, первые 2-3 месяца начальство "писало кипятком", потому что, ого — ну сколько всего было реализовано!
Но потом наставало понимание, что реализовано было в долг, который, увы, кому-то все же придется отдавать. К этому моменту контрактор со стороны уже тогось и более того, получал хорошие отзывы (ибо их пишут обычно по окончанию контракта, а не через год тяжелого рефакторинга наколбашеного).

Хорошим индикатором в такой ситуации является отсутствие повторных приглашений этого контрактора на тот же самый проект.

KP>Да вроде можно, главное не рефакторить то, что и так работает нормально. А так, берешь проект который в полной жопе, делаешь его чуть менее (лучше, конечно, побольше чем "чуть", но тут уж как получится) жутким и менеджмент писает кипятком

Это сложно продать.
А вот например когда жирный клиент эскалирует, а проблема не твоя, но ты ее решаешь быстро — тут да, все довольны. А решил может криво-косо, но быстро.
Или там например сильно улучшил какие-то ключевые параметры, которые легко измерить — производительность там, латенси. Числа получены, подверждены — все понимают, всем видно. Легко показать, легко в перформанс ревью.
Или какую-то совсем новую фичу, особенно когда она стандартами требуется — тут тоже все просто.
А продать уменьшение технического долго — это сложно. Затрат много, а выхлопа для себя любимого не сильно. Ну и нафиг. Вот когда будет все разваливаться, когда всем будет очевидно что все плохо — вот тогда продать будет легко, и личная выгода будет.

R>>Чуть более креативные чуваки спрашивают, как решать задачу, которую они только что решили. И если ты ее раньше не решал, то обломаешься (выдав какие-то убогие нерабочие варианты), а они таким образом самоутвердятся (ведь они-то ее решили, а ты нет, и не важно, что их было четверо и пара недель времени + глубокие знания и опыт в предметной сфере).

SD>А если так получится, что ты решишь, и притом лучше, чем они? И за 45 минут, а не за пару недель.

Чуваки решили за твой счет самоутвердиться, а ты их самих опустил. "Мы вам перезвоним," — ибо зачем нам нужен такой умный.

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

SD>Так может не сработать, особенно с реальными сеньорами. Потому что ответ будет, гм, странным. Примерно так: "написал документы о Х, У, сделал 5 код ревью, зафайлил 5 тасков, ну и вечерком по-быстрому пофиксил баг, который 20 человек искали уже месяц, баг простой, но надо было просмотреть сотню-другую вложенных вызовов в стеке среди разных языков".
И? Почему это не сработает?

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

scf>Очевидно, чтобы не взять болтуна, который даже в умные указатели не умеет.

Разговор про прошлый опыт раскроет кандидата гораздо лучше чем знания об умных указателях.

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

G>Я бы сказал, что можно, хотя и с трудом, выделить общепринятые "там" и "тут" шаблоны собеседований. Но делать выводы о на порфессионализме

У меня перекос опыта в сторону "там", но в России преимущественно все собеседования были с лёгким (или сильным) налётом надменности.

Я не отрицаю, что у нас есть отличные команды.

К>Тебе еще повезло, а один человек с 15 лет опыта пришел на собеседование, а его что такое ООП спросили.
После 15 лет опыта я не знал, что такое ООП.
А опыт был серьезный: проектирование и разработка бортовой операционной системы на голую машину.
С отладкой в восьмеричных кодах.
И до того было много других задач на других архитектурах, на других языках и в других предметных областях.
И было это в 1990 году.
Я тогда купил первый раз первую книжку Страуструпа — и ничего не понял...
Так студентам и говорю: до меня доходит медленно...
Как до жирафа.