Судя по тому как они работают - не особо оно и проходит =\
Я так ни разу хорошего программиста среди индусов не встретил. Один хороший продакт овнер, одни средний it owner и 1 хреновенький, но хотя бы отвечающий бизнес аналитик.
>Из того, что ты описал выше - тестов толковых не было, а значит оунер проебалнил свою часть. Я не утверждаю, но я бы рассуждал так.
С моей точки зрения - тесты должны писаться во время написания кода. Овнер не читает код, а значит не может сказать покрыли ли они такие случаи. Вполне вероятна ситуация когда негативные ситуации описаны, но тестами пренебрегли. Так же возможно что тесты покрывали только бизнес-кейсы, а всевозможные программные дела типа нулл поинтера или коррапта данных со стороны UI не покрыты. Бизнес же не знает про АПИ и как оно работает. Не говоря уже о сложных задачах, где описать все негативные кейсы невозможно ввиду опять же технической стороны вопроса.
Я не имею ввиду алгоритмы когда говорю про наблюдение за подходом к решению. Алгоритмы занимают ничтожное время процесса работы. "Погонять" по паттернам и теории тоже относительно быстро можно. Это база и тупо заучивается. А вот как раз таки дизайн и анализ существующего кода (разумеется фэйкового, мы же про собес говорим) - показывают кандидата как специалиста. Если кандидат способен решить задачу по созданию архитектуры для приложения за короткий срок - значит либо человек превышает квалификацию, либо задача подобрана недостаточно сложной. С моей точки зрения важно именно замешательство и попытка решения с тем что знаешь.
>Но по существу - код ревью в таком случае должен был делать оунер проекта.
Project Owner как правило человек без технического бэкграунда. Напоминаю, это финтех, а не айти ради айти. Практически везде оунер берется не из разрабов (которые вероятней уходят в архитект и тех.директоров), а из бизнесовой части.
Есть, но опыт одной из крупнейших айти (не FAANG) компаний показывает что менеджмент с удовольствием ставит палки в колёса и не даёт тебе усложнять вопросы или давать нерешаемые (за разумное время) задачи чтобы пронаблюдать за подходом к решению.
>Если человек нормально проходит задачи на оптимизацию - шанс того, что он будет писать гавно около нулевой.
Если у тебя не типовая задача, то может и около нулевой. К несчастью многие бигтеки имеют свой список вопросов для интервью и отклоняться от него нельзя. А вот сами вопросы вполне себе утекают и на них можно надрочиться. Не говоря уже о том что заучивание небольшой области знаний - не самая сложная в мире вещь.
Самый попердоленый случай - когда индусы из другого проекта писали в базу данных. Закорраптили кучу данных.
Почти весь код будто намеренно усложнён. Вместо обычного getter'а вызов через рефлексию джавы. Классы и методы забившие на принципы ООП, хотя язык ООПшный и не знать парадигму они не должны. Там буквально код стрелявший хуй пойми куда, хуй пойми откуда. Если "баг" заключается в банальной "не то число" или "не тот знак" - это одно, а когда вычисления идут через десяток сторонних мест с задействованием рефлексии - это другое.
Значительную часть проекта зарефакторили чтобы читать стало хотя бы немного легче, баги начали искаться за день-два (проблемы с тестовыми данными и логами, проект то старый).
Код тех времен, когда индусам платили за строку кода похоже. (помянем те проклятые времена)
А самое ужасное что эти же люди всё ещё работают и работают как привыкли.
>Нет конечно, но если мы уж пытаемся хоть как-то быть объективными то логично брать из самого верхнего пулла, потому, что корпорации такого масштаба не развились и не существовали бы на таком уровне, если бы внутри происходило описанное тобой.
Так они основаны не индусами. Если бы ты привел пример мощной IT корпорации основанной индусами, было бы другое дело.
>Но опять же, могу предположить, что сфера страхования банально больше подвержена дешевому аутсорсу, чем тот-же выше указанный финтех.
Сфера крупного страхования - и есть фин тех. Там обороты как у банков ибо страхуются такие же корпорации.
>Ты так говоришь, будто декомишшен это что-то исключительно плохое. Время идет, появляются новые технологии и зачастую проще и рациональнее декомиснуть и переписать, чем поддерживать.
Да, но когда сложность возрастает слишком быстро - это не нормально. Обычный срок жизни критического ПО - 10-20 лет, где вторая половина - дожитие в ожидании замены. Вот только когда через 10 лет ПО просто невозможно поддерживать - это проблема. Лично знаю 3 проекта написанных индусами и через 10 лет даже простой фикс занимает месяцы, не из-за сложной бизнес логики, а из-за чудовищного кода. А замену в одном из них пишут индусы, так что вместо декомишена за 5 лет выходит декомишен за 10.
>В любой стране первого мира такая "стратегия" не прошла бы даже первый раунд дебатов, потому, что это откровенная дискриминация по национальному признаку.
Я название своей корпы называть не буду. Оно не шло в дебаты, индусам банально отдали самые неприбыльные проекты. Их никто не выкидывал на мороз, им просто не дают писать критически важный код.
Посмотри на ключевые проекты в FAANG и тех кто их поддерживает. Индусов там по минимуму. Майкрософт конечно тот ещё уровень нынче, Без матов ни виндой, ни облаком их пользоваться уже не получается.
>За исключением Амазона у всех остальных очень, ОЧЕНЬ высокие требования вообще ко всему
Требования высокие, но индусы умеют проходить интервью, а дальше как повезет с конкретным индусом. Все эти FAANG и крупные корпы имеют один огромный недостаток - тех интервью четко регламентировано и посмотреть как человек мыслит - не дают. Четкие задачи и четкие ответы, ни шагу в сторону.
>Если ты думаешь, что в биг техе просто сидит ужасное индийское лобби - это уже в плоскость конспирологии, а не инжиниринга.
Прошу, изучи культуру Индии. В особенности их рабочую культуру. Если ты не работал с индусами - не втирай мне дичи. Мотивация индусов простая - место получше и повыше, делать хороший продукт и быть продуктивным сотрудником - не в их интересах.
Я так ни разу хорошего программиста среди индусов не встретил. Один хороший продакт овнер, одни средний it owner и 1 хреновенький, но хотя бы отвечающий бизнес аналитик.
С моей точки зрения - тесты должны писаться во время написания кода. Овнер не читает код, а значит не может сказать покрыли ли они такие случаи. Вполне вероятна ситуация когда негативные ситуации описаны, но тестами пренебрегли. Так же возможно что тесты покрывали только бизнес-кейсы, а всевозможные программные дела типа нулл поинтера или коррапта данных со стороны UI не покрыты. Бизнес же не знает про АПИ и как оно работает. Не говоря уже о сложных задачах, где описать все негативные кейсы невозможно ввиду опять же технической стороны вопроса.
Project Owner как правило человек без технического бэкграунда. Напоминаю, это финтех, а не айти ради айти. Практически везде оунер берется не из разрабов (которые вероятней уходят в архитект и тех.директоров), а из бизнесовой части.
Так всю архитектуру они же и настраивали. Они же и занимают все ответственные за это позиции. Ребятам дали сервис на поддержку и похороны.
>А юнит тестов не было от слова совсем? Нет, я все понимаю, но кто-то же умный делал код ревью? У этого человека не возникло вопросов?
Если правильно помню, у них были какие-то тесты. Разумеется мало и все проходили. Ревью делали те же индусы. Просто доверили проекты индусам и забили.
>Тут мои полномочия все. Что значит сторонние места? Инкапсулирование - это один из главных принципов ОО языков, или я что-то не выкупаю? Памагите.
Да, именно так. Оно было нарушено. Следить за ними конечно никто не следил. Наняли же "профессионалов" из Индии.
Если у тебя не типовая задача, то может и около нулевой. К несчастью многие бигтеки имеют свой список вопросов для интервью и отклоняться от него нельзя. А вот сами вопросы вполне себе утекают и на них можно надрочиться. Не говоря уже о том что заучивание небольшой области знаний - не самая сложная в мире вещь.
Почти весь код будто намеренно усложнён. Вместо обычного getter'а вызов через рефлексию джавы. Классы и методы забившие на принципы ООП, хотя язык ООПшный и не знать парадигму они не должны. Там буквально код стрелявший хуй пойми куда, хуй пойми откуда. Если "баг" заключается в банальной "не то число" или "не тот знак" - это одно, а когда вычисления идут через десяток сторонних мест с задействованием рефлексии - это другое.
Значительную часть проекта зарефакторили чтобы читать стало хотя бы немного легче, баги начали искаться за день-два (проблемы с тестовыми данными и логами, проект то старый).
Код тех времен, когда индусам платили за строку кода похоже. (помянем те проклятые времена)
А самое ужасное что эти же люди всё ещё работают и работают как привыкли.
Так они основаны не индусами. Если бы ты привел пример мощной IT корпорации основанной индусами, было бы другое дело.
>Но опять же, могу предположить, что сфера страхования банально больше подвержена дешевому аутсорсу, чем тот-же выше указанный финтех.
Сфера крупного страхования - и есть фин тех. Там обороты как у банков ибо страхуются такие же корпорации.
>Ты так говоришь, будто декомишшен это что-то исключительно плохое. Время идет, появляются новые технологии и зачастую проще и рациональнее декомиснуть и переписать, чем поддерживать.
Да, но когда сложность возрастает слишком быстро - это не нормально. Обычный срок жизни критического ПО - 10-20 лет, где вторая половина - дожитие в ожидании замены. Вот только когда через 10 лет ПО просто невозможно поддерживать - это проблема. Лично знаю 3 проекта написанных индусами и через 10 лет даже простой фикс занимает месяцы, не из-за сложной бизнес логики, а из-за чудовищного кода. А замену в одном из них пишут индусы, так что вместо декомишена за 5 лет выходит декомишен за 10.
>В любой стране первого мира такая "стратегия" не прошла бы даже первый раунд дебатов, потому, что это откровенная дискриминация по национальному признаку.
Я название своей корпы называть не буду. Оно не шло в дебаты, индусам банально отдали самые неприбыльные проекты. Их никто не выкидывал на мороз, им просто не дают писать критически важный код.
>За исключением Амазона у всех остальных очень, ОЧЕНЬ высокие требования вообще ко всему
Требования высокие, но индусы умеют проходить интервью, а дальше как повезет с конкретным индусом. Все эти FAANG и крупные корпы имеют один огромный недостаток - тех интервью четко регламентировано и посмотреть как человек мыслит - не дают. Четкие задачи и четкие ответы, ни шагу в сторону.
>Если ты думаешь, что в биг техе просто сидит ужасное индийское лобби - это уже в плоскость конспирологии, а не инжиниринга.
Прошу, изучи культуру Индии. В особенности их рабочую культуру. Если ты не работал с индусами - не втирай мне дичи. Мотивация индусов простая - место получше и повыше, делать хороший продукт и быть продуктивным сотрудником - не в их интересах.