Все так. Знакомый Java-сеньор в Озоне получал два года назад 250к. Через год ушел на 400+. Даже не представляю, кого они рассчитывают нанять с таким конкурентным подходом.
В Казахстане тоже большой рынок разработки, это если забыть про слона в комнате. Если все-таки вспомнить реалии сегодняшнего дня, то компании подстраиваются, дабы иметь возможность нанимать сотрудников за пределами РФ. У Т-банка есть офисы в Армении и Казахстане, у Яндекса тоже + Сербия, Авито, Контур - да почти у всех, кроме Сбера и прочих "системно значимых".
умер, на .net из-за этого не пишут всякие тяжелейшие энтерпрайзы переходя с кобола и прочего фортрана
просто потому что нафиг никому не впилось каждые два года легаси переписывать
Разумеется, пишут. Иначе бы я давно остался без работы. Каждые два года переписывать и не нужно, нужно было один раз - когда MS волевым решением похоронили .NET Framework (опять же, кроме поддержки). Кто хотел жить с легаси, остался на .NET Framework и живет с ним (да, и такие проекты приходилось встречать). Кто не хотел - пишет на .NET 8/9 (переехав с Core 2.2 с минимальной болью и трудозатратами) и радуется жизни. Но даже легасный .NET Framework все равно намного удобнее джавы как платформа.
потому что это нужно бизнесу
в 2015 году моей задачей было переписывания микросервиса с java 1.2 на 6 при актуальной на тот момент 8й
Так и я о чем - тяжелое историческое наследие. И я с этим и не спорю, что переписывать затратно итд итп. Я изначально говорил о том, что вкатываться в Java с нуля в 2025 - задача очень тяжкая и на мой взгляд, не оправдывающая собственно затраты времени и сил. Сравнимые зарплаты можно получать на других технологиях, которые не требуют прокаченных археологических навыков для того, чтобы разобраться, как это вообще работает.
Очень легко. Переписать JVM избавиться от доброй половины Abstraction Penalty, происходящих только потому, что большая часть абстракций реализована в виде синтаксического сахара, а байт код их не видит. Самый очевидный пример - generic types, которые для компилятора не существуют и все кастятся к базовым типам. Другой пример - value types (ключевое слово struct в C#) которых в Java нет до сих пор. И очевидно, до создателей языка тоже начинает что-то доходить (project Valhalla), только вот они опять не готовы выкинуть обратную совместимость, из-за чего делают данные возможности "параллельно включаемыми" с основным языком. Что начинает смахивать на шизу, в которой несведующий человек запутается - как писать, чтобы скомпилировалось по-новому а не по старому? Про async/await, десятилетиями живущий в .NET но о котором только сейчас задумались в Java, думаю, можно даже не говорить. Как это так, сломать обратную совместимость и написать почти с нуля новую платформу? Ну не знаю, всеми ненавидимый Microsoft с .NET Core справился как-то. И ничего, никто не умер, а легаси пришлось переписывать. Ужас, конечно, но меня такая ситуация гораздо больше радует, чем когда платформа тащит за собой костыли двадцатилетней давности и не может их похоронить.
Просто автор выбрал для перехода Java да ещё и в связке со Spring. Java сама по себе многословна и полна тяжкого исторического наследия, которое никак не подчистят, потому что "обратная совместимость" у Oracle не полезный принцип, а религия. А spring это ещё более тяжкое историческое наследие времен, когда людям казалось, что приложение должно уметь по паре кнопок создать вселённую, ну или как минимум, фреймворк должен это уметь. За прошедшие десятилетия он должен был бы умереть, но от привычек трудно отказываться, тем более - от плохих. По этой причине, в свое время, узрев все это шаманство с магией аннотаций под капотом, взял себя в руки и перешёл на .NET. За десять лет карьеры единожды попытался вернуться к Java, лишь затем, чтобы убедиться в том, что ничего в лучшую сторону не изменилось. Даже попытки сделать из этой субстанции конфетку (Kotlin/Scala) ничего глобально не меняют, потому что нужно менять саму платформу, ломая ту самую обратную совместимость. А на это оракл никогда не пойдёт. В итоге имеем корпоративного монстра, подпираемого чудовищной конструкцией из костылей, который однажды захватил большую часть северного рынка и теперь с этой иглы уже так просто не слезть, потому что столько кода переписывать с нуля никто не рискнет. Отсюда и куча вакансий и зарплаты. Нечто подобное, кстати, произошло с COBOL - идейным вдохновителем SAP и 1с. Язык сейчас один из самых высокооплачиваемых и спецы очень нужны, потому что триллион строк американской банковской системы переписывать никто не рискнет, хотя сам язык абсолютно всем сообществом программистов презираем и считается одним из эталонов неудачного дизайна. С Java ситуация лучше, потому что она как минимум на три десятилетия младше, но история повторяется.
Spring - это тяжкое наследие времен становления Java как серверного языка и принятых тогда стандартов разработки. Считалось, что хорошее приложение умеет все, что нужно клиенту, в одном месте и сразу, а хороший фреймворк умеет вообще все, вплоть до сборки вселенной за 6 дней. Проблема в том, что от этого исторического наследия так и не избавились, а продолжают его тащить в проект за проектом, несмотря на то, что ущербность такого подхода стала очевидна задолго до того, как десять лет назад я впервые устроился на работу программистом. Потому что людям, особенно принимающим решения в корпоративной среде, особенно в банковском, например, секторе, где Java традиционно популярна, неочевидно, зачем менять подход, который столько лет работал. Да, сервер жрал память как кашалот, да ущербный фронт на JSP запускался нормально только в IE 9 (привет мантры про кроссплатформенность), да, внедрение новых фич растягивалось на месяцы и годы, ну и что? Работает же. Зачем менять? Ок, IE 9 больше не поддерживается и JSP наконец-то похоронили, ладно, так уж и быть, мы попробуем новые технологии. Но ровно настолько, чтобы по-минимуму трогать легаси, которому этак 20 лет без малого. С другой стороны, Oracle всячески поощрает такое поведение пользователей, потому что сам тоже следует этому принципу. Менеджерам и адептам всячески внушается, что "не язык отсталый" а "не гонимся за новым в ущерб стабильности". У нас нет нормальных дженериков и типы в рантайме затираются? Ну и что, зато любой софт запустится под платформой версии 1.6 вышедшей в 98м году! Так и живут.
Потому что, полагаю, у создателей языков разные идеологии развития. Там, где C# и .NET обрастают новыми фичами почти каждый год, часто - ценой обратной совместимости, Java как платформа... консервативна. Неявную типизацию (var) разработчики ввели лет этак на 10 позже, и у многих Java-разрабов это все еще вызывает пригорание. Да ладно, затирание типов все еще, в 2025 году и никто от него избавляться не хочет - это ж поломает совместимость! Я Java-стек последний раз трогал в 20м году, работая в компании, которая пишет бэкенд на Kotlin (да, и такое бывает). И там я узрел зоопарк из систем сборки (Maven, Gradle, Aunt - все в одном(!) проекте) и отдельный самописный сборщик для того, чтобы вся эта черная магия собиралась. Idea тех лет постоянно теряла индексы и могла перестать собирать проект, пока ты вручную не удалишь все кэши. Под виндой мог сгенериться classpath такой длины, который не помещается в виндовую консоль и нужно танцевать с бубном, чтобы это обойти. Spring - огроменный глобус, в котором не разобраться без поллитры, поверх него аж написан SpringBoot чтобы было чуть менее больно. Ужаснулся, в общем, и вернулся к .NET, больше пробовать не хочется. И это, если что, не хейт Java как платформы, я понимаю ограничения и почему они такие - исторический контекст. Просто объясняю, почему шарпистам не очень-то хочется туда соваться.
Двадесять. Тридесять. Четридесять. Сербский язык по формам намного логичнее русского, внезапно. Только 7 падежей вместо 6 (но и в русском "звательный" падеж не вытравили до конца, он просто возникает только в разговорной речи).
Согласен, если человек этого не знает, конечно, это повод насторожиться. Но я бы на месте интервьювера, если спросил про GC и в ответ сразу слышу про три поколения и цикл сборки - сразу бы прервал и продолжил с другими вопросами, потому что время не резиновое, а если человек в курсе про поколения, значит он про это читал и знает. Ну это так, мысли вслух. К слову, некоторые интервьюверы именно так и делали, что ок на мой взгляд. Про профайлер и проблемы памяти в целом тоже соглашусь, только вот в 99.99% проектов на .NET этого не требуется. За 10 лет в разработке я только несколько раз встречал задачи, требующие глубинной оптимизации и профилировки, потому что, будем честными, абсолютное большинство бэкенд-задач - перекладывание JSON'ов по CRUD'ам и если там и есть узкие места, то они как правило упираются в БД а не в бизнес-логику. Разумеется, мое мнение не более, чем ошибка выжившего и я уверен, что есть люди, которые именно критикал-перформансом на .NET занимаются большую часть времени, но личная статистика говорит, что таких скорее всего сильное меньшинство.
Все так. Зачастую на собеседование дергают рандомного разработчика рандомной команды просто потому что ну очень надо, а некому. Многие из таких "выдернутых" из процесса людей не очень-то представляют процесс собеседования как таковой. Как спрашивать, что спрашивать - в итоге получается каша из "примерно помню как меня собеседовали" и "ну наверное что-то такое кандидат должен знать". Отсюда рождаются банальные, достаточно бестолковые но буквально общеупотребимые вопросы, которые задают абсолютно все. Например, вопрос про три поколения GC мне задавали на вообще всех собеседованиях за последние четыре года. Понятно, что я это знаю. Понятно, что любой, кто читал про .NET это знает. Равно как и любой, кто прошел больше одного собеседования, потому что даже если ты совсем твердолобый, то не с первого, так с пятого раза пойдешь и погуглишь. Как это сакральное знание влияет на написание кода? Да никак, конечно. Просто надо что-то спросить, вот и спрашивают. Про две секции - в нормальных компаниях, которые ценят не только свое время, но и время соискателя так все и происходит. Если компания не Яндекс, который свято уверен, что работать в их конторе такая большая честь, что можно соискателя месяц по литкод-задачкам гонять и потом еще месяц думать.
Речь шла о намного меньших сроках, порядка двух месяцев. Но вообще, имхо, это фундаментальная разница в подходах. Я действительно не люблю "Гибкие методологии" в таких вещах и ватерфолл при разработке полностью документированного продукта с нуля мне кажется гораздо более приемлемым выбором. Но это, конечно, вопрос срачный дискуссионный.
Ну меня как-то припекло и я занимался. Не так уж все сложно на самом деле, заскринил все переписки, записал на диктофон разговор с начальством, пошел к юристу и мне помогли составить грамотно досудебную претензию. Отправил ее в компанию официальной почтой после чего они резко вспомнили нормы ТК и выплатили мне три зарплаты. Но, конечно, мой случай, вероятно, ошибка выжившего.
Запрет на трудоустройство к конкурентам, как правило, оформляется не в виде договора с сотрудником лично, а в виде "соглашения о неконкуренции и непереманивании сотрудников" с этим самым конкурентом (картельный сговор, ст. 178 УК РФ). За это по-идее ФАС должна сажать на бутылку, но в реалиях РФ всем как обычно.
Ну я в целом о том и толкую - язык, созданный по-быстрому скидать crud-микросервис и забыть о нем. А никак не "серебрянная пуля" чтобы превратить вашу самотрансформирующуюся шаттл-субмарину с вертикальным взлетом легаси-экосистему в суперпроизводительную вундервафлю.
Помним контекст - это финтех. Сервис предполагается, предоставляет готовое решение по оценке активов (недвижимость вроде, не помню уже). Какое там value промежуточное вообще можно доставить, мне не пояснили, хотя я специально попросил уточнить после собеседования, ну просто для общего развития.
Собесился как-то в один желтый банк (другой, не Т, догадайтесь сами), так меня там на полном серьезе заставили развернуть связный список. Я как-то раньше ронял реплики про "там на собеседовании заставляют развернуть связный список" в иронично-утрированном ключе - ан нет, реальность мощнее иронии и такое бывает. На втором собеседовании (собеседование, к слову, было на синьора с перспективами техлида), меня спросили, дескать, вот фича, вот компоненты необходимые для реализации, как выстроишь процесс? К слову, оговорено, что компоненты сильно завязаны и без каждого в отдельности ничего как надо не заработает. Ну я подошел к этому как к технической задаче - реализуем фундамент, на нем промежуточные сервисы, потом сверху натягиваем фронт. Результат - отказ, по их словам, "слишком долго работал в аутсорсе, поэтому не думаю доставке минимального value клиенту в каждой итерации". Какое там value можно доставить, если без каждого в отдельности сервиса ничего не заработает, по их же словам - я не знаю. Это в финтехе, где абсолютно все сроки, этапы и требования обычно строго согласованы заранее. Вопрос, почему вообще именно разработчик, пусть даже и техлид, должен угадывать, как лучше угодить клиенту, остается открытым.
Все так. Знакомый Java-сеньор в Озоне получал два года назад 250к. Через год ушел на 400+. Даже не представляю, кого они рассчитывают нанять с таким конкурентным подходом.
В Казахстане тоже большой рынок разработки, это если забыть про слона в комнате. Если все-таки вспомнить реалии сегодняшнего дня, то компании подстраиваются, дабы иметь возможность нанимать сотрудников за пределами РФ. У Т-банка есть офисы в Армении и Казахстане, у Яндекса тоже + Сербия, Авито, Контур - да почти у всех, кроме Сбера и прочих "системно значимых".
И что в итоге? Пошли работать в это райское место, или свернули общение?))
Более того, шансы сесть есть и у тех, кто пониже. Потому что виноватых найти достаточно легко не в организаторах, а в исполнителях.
Понятия не имею. Сборка проекта занимала полчаса минимум, запуск дебага отжирал почти всю память. Уфф, как вспомню, так вздрагиваю
Разумеется, пишут. Иначе бы я давно остался без работы. Каждые два года переписывать и не нужно, нужно было один раз - когда MS волевым решением похоронили .NET Framework (опять же, кроме поддержки). Кто хотел жить с легаси, остался на .NET Framework и живет с ним (да, и такие проекты приходилось встречать). Кто не хотел - пишет на .NET 8/9 (переехав с Core 2.2 с минимальной болью и трудозатратами) и радуется жизни. Но даже легасный .NET Framework все равно намного удобнее джавы как платформа.
Так и я о чем - тяжелое историческое наследие. И я с этим и не спорю, что переписывать затратно итд итп. Я изначально говорил о том, что вкатываться в Java с нуля в 2025 - задача очень тяжкая и на мой взгляд, не оправдывающая собственно затраты времени и сил. Сравнимые зарплаты можно получать на других технологиях, которые не требуют прокаченных археологических навыков для того, чтобы разобраться, как это вообще работает.
Очень легко. Переписать JVM избавиться от доброй половины Abstraction Penalty, происходящих только потому, что большая часть абстракций реализована в виде синтаксического сахара, а байт код их не видит. Самый очевидный пример - generic types, которые для компилятора не существуют и все кастятся к базовым типам. Другой пример - value types (ключевое слово struct в C#) которых в Java нет до сих пор. И очевидно, до создателей языка тоже начинает что-то доходить (project Valhalla), только вот они опять не готовы выкинуть обратную совместимость, из-за чего делают данные возможности "параллельно включаемыми" с основным языком. Что начинает смахивать на шизу, в которой несведующий человек запутается - как писать, чтобы скомпилировалось по-новому а не по старому? Про async/await, десятилетиями живущий в .NET но о котором только сейчас задумались в Java, думаю, можно даже не говорить.
Как это так, сломать обратную совместимость и написать почти с нуля новую платформу? Ну не знаю, всеми ненавидимый Microsoft с .NET Core справился как-то. И ничего, никто не умер, а легаси пришлось переписывать. Ужас, конечно, но меня такая ситуация гораздо больше радует, чем когда платформа тащит за собой костыли двадцатилетней давности и не может их похоронить.
Просто автор выбрал для перехода Java да ещё и в связке со Spring. Java сама по себе многословна и полна тяжкого исторического наследия, которое никак не подчистят, потому что "обратная совместимость" у Oracle не полезный принцип, а религия. А spring это ещё более тяжкое историческое наследие времен, когда людям казалось, что приложение должно уметь по паре кнопок создать вселённую, ну или как минимум, фреймворк должен это уметь. За прошедшие десятилетия он должен был бы умереть, но от привычек трудно отказываться, тем более - от плохих. По этой причине, в свое время, узрев все это шаманство с магией аннотаций под капотом, взял себя в руки и перешёл на .NET. За десять лет карьеры единожды попытался вернуться к Java, лишь затем, чтобы убедиться в том, что ничего в лучшую сторону не изменилось. Даже попытки сделать из этой субстанции конфетку (Kotlin/Scala) ничего глобально не меняют, потому что нужно менять саму платформу, ломая ту самую обратную совместимость. А на это оракл никогда не пойдёт. В итоге имеем корпоративного монстра, подпираемого чудовищной конструкцией из костылей, который однажды захватил большую часть северного рынка и теперь с этой иглы уже так просто не слезть, потому что столько кода переписывать с нуля никто не рискнет. Отсюда и куча вакансий и зарплаты. Нечто подобное, кстати, произошло с COBOL - идейным вдохновителем SAP и 1с. Язык сейчас один из самых высокооплачиваемых и спецы очень нужны, потому что триллион строк американской банковской системы переписывать никто не рискнет, хотя сам язык абсолютно всем сообществом программистов презираем и считается одним из эталонов неудачного дизайна. С Java ситуация лучше, потому что она как минимум на три десятилетия младше, но история повторяется.
Spring - это тяжкое наследие времен становления Java как серверного языка и принятых тогда стандартов разработки. Считалось, что хорошее приложение умеет все, что нужно клиенту, в одном месте и сразу, а хороший фреймворк умеет вообще все, вплоть до сборки вселенной за 6 дней. Проблема в том, что от этого исторического наследия так и не избавились, а продолжают его тащить в проект за проектом, несмотря на то, что ущербность такого подхода стала очевидна задолго до того, как десять лет назад я впервые устроился на работу программистом. Потому что людям, особенно принимающим решения в корпоративной среде, особенно в банковском, например, секторе, где Java традиционно популярна, неочевидно, зачем менять подход, который столько лет работал. Да, сервер жрал память как кашалот, да ущербный фронт на JSP запускался нормально только в IE 9 (привет мантры про кроссплатформенность), да, внедрение новых фич растягивалось на месяцы и годы, ну и что? Работает же. Зачем менять? Ок, IE 9 больше не поддерживается и JSP наконец-то похоронили, ладно, так уж и быть, мы попробуем новые технологии. Но ровно настолько, чтобы по-минимуму трогать легаси, которому этак 20 лет без малого.
С другой стороны, Oracle всячески поощрает такое поведение пользователей, потому что сам тоже следует этому принципу. Менеджерам и адептам всячески внушается, что "не язык отсталый" а "не гонимся за новым в ущерб стабильности". У нас нет нормальных дженериков и типы в рантайме затираются? Ну и что, зато любой софт запустится под платформой версии 1.6 вышедшей в 98м году! Так и живут.
Потому что, полагаю, у создателей языков разные идеологии развития. Там, где C# и .NET обрастают новыми фичами почти каждый год, часто - ценой обратной совместимости, Java как платформа... консервативна. Неявную типизацию (var) разработчики ввели лет этак на 10 позже, и у многих Java-разрабов это все еще вызывает пригорание. Да ладно, затирание типов все еще, в 2025 году и никто от него избавляться не хочет - это ж поломает совместимость! Я Java-стек последний раз трогал в 20м году, работая в компании, которая пишет бэкенд на Kotlin (да, и такое бывает). И там я узрел зоопарк из систем сборки (Maven, Gradle, Aunt - все в одном(!) проекте) и отдельный самописный сборщик для того, чтобы вся эта черная магия собиралась. Idea тех лет постоянно теряла индексы и могла перестать собирать проект, пока ты вручную не удалишь все кэши. Под виндой мог сгенериться classpath такой длины, который не помещается в виндовую консоль и нужно танцевать с бубном, чтобы это обойти. Spring - огроменный глобус, в котором не разобраться без поллитры, поверх него аж написан SpringBoot чтобы было чуть менее больно. Ужаснулся, в общем, и вернулся к .NET, больше пробовать не хочется.
И это, если что, не хейт Java как платформы, я понимаю ограничения и почему они такие - исторический контекст. Просто объясняю, почему шарпистам не очень-то хочется туда соваться.
Двадесять. Тридесять. Четридесять. Сербский язык по формам намного логичнее русского, внезапно. Только 7 падежей вместо 6 (но и в русском "звательный" падеж не вытравили до конца, он просто возникает только в разговорной речи).
Согласен, если человек этого не знает, конечно, это повод насторожиться. Но я бы на месте интервьювера, если спросил про GC и в ответ сразу слышу про три поколения и цикл сборки - сразу бы прервал и продолжил с другими вопросами, потому что время не резиновое, а если человек в курсе про поколения, значит он про это читал и знает. Ну это так, мысли вслух. К слову, некоторые интервьюверы именно так и делали, что ок на мой взгляд.
Про профайлер и проблемы памяти в целом тоже соглашусь, только вот в 99.99% проектов на .NET этого не требуется. За 10 лет в разработке я только несколько раз встречал задачи, требующие глубинной оптимизации и профилировки, потому что, будем честными, абсолютное большинство бэкенд-задач - перекладывание JSON'ов по CRUD'ам и если там и есть узкие места, то они как правило упираются в БД а не в бизнес-логику. Разумеется, мое мнение не более, чем ошибка выжившего и я уверен, что есть люди, которые именно критикал-перформансом на .NET занимаются большую часть времени, но личная статистика говорит, что таких скорее всего сильное меньшинство.
Все так. Зачастую на собеседование дергают рандомного разработчика рандомной команды просто потому что ну очень надо, а некому. Многие из таких "выдернутых" из процесса людей не очень-то представляют процесс собеседования как таковой. Как спрашивать, что спрашивать - в итоге получается каша из "примерно помню как меня собеседовали" и "ну наверное что-то такое кандидат должен знать". Отсюда рождаются банальные, достаточно бестолковые но буквально общеупотребимые вопросы, которые задают абсолютно все. Например, вопрос про три поколения GC мне задавали на вообще всех собеседованиях за последние четыре года. Понятно, что я это знаю. Понятно, что любой, кто читал про .NET это знает. Равно как и любой, кто прошел больше одного собеседования, потому что даже если ты совсем твердолобый, то не с первого, так с пятого раза пойдешь и погуглишь. Как это сакральное знание влияет на написание кода? Да никак, конечно. Просто надо что-то спросить, вот и спрашивают.
Про две секции - в нормальных компаниях, которые ценят не только свое время, но и время соискателя так все и происходит. Если компания не Яндекс, который свято уверен, что работать в их конторе такая большая честь, что можно соискателя месяц по литкод-задачкам гонять и потом еще месяц думать.
Речь шла о намного меньших сроках, порядка двух месяцев. Но вообще, имхо, это фундаментальная разница в подходах. Я действительно не люблю "Гибкие методологии" в таких вещах и ватерфолл при разработке полностью документированного продукта с нуля мне кажется гораздо более приемлемым выбором. Но это, конечно, вопрос
срачныйдискуссионный.Ну меня как-то припекло и я занимался. Не так уж все сложно на самом деле, заскринил все переписки, записал на диктофон разговор с начальством, пошел к юристу и мне помогли составить грамотно досудебную претензию. Отправил ее в компанию официальной почтой после чего они резко вспомнили нормы ТК и выплатили мне три зарплаты. Но, конечно, мой случай, вероятно, ошибка выжившего.
Запрет на трудоустройство к конкурентам, как правило, оформляется не в виде договора с сотрудником лично, а в виде "соглашения о неконкуренции и непереманивании сотрудников" с этим самым конкурентом (картельный сговор, ст. 178 УК РФ). За это по-идее ФАС должна сажать на бутылку, но в реалиях РФ всем как обычно.
Ну я в целом о том и толкую - язык, созданный по-быстрому скидать crud-микросервис
и забыть о нем.А никак не "серебрянная пуля" чтобы превратить вашусамотрансформирующуюся шаттл-субмарину с вертикальным взлетомлегаси-экосистему в суперпроизводительную вундервафлю.Помним контекст - это финтех. Сервис предполагается, предоставляет готовое решение по оценке активов (недвижимость вроде, не помню уже). Какое там value промежуточное вообще можно доставить, мне не пояснили, хотя я специально попросил уточнить после собеседования, ну просто для общего развития.
Собесился как-то в один желтый банк (другой, не Т, догадайтесь сами), так меня там на полном серьезе заставили развернуть связный список. Я как-то раньше ронял реплики про "там на собеседовании заставляют развернуть связный список" в иронично-утрированном ключе - ан нет, реальность мощнее иронии и такое бывает. На втором собеседовании (собеседование, к слову, было на синьора с перспективами техлида), меня спросили, дескать, вот фича, вот компоненты необходимые для реализации, как выстроишь процесс? К слову, оговорено, что компоненты сильно завязаны и без каждого в отдельности ничего как надо не заработает. Ну я подошел к этому как к технической задаче - реализуем фундамент, на нем промежуточные сервисы, потом сверху натягиваем фронт. Результат - отказ, по их словам, "слишком долго работал в аутсорсе, поэтому не думаю доставке минимального value клиенту в каждой итерации". Какое там value можно доставить, если без каждого в отдельности сервиса ничего не заработает, по их же словам - я не знаю. Это в финтехе, где абсолютно все сроки, этапы и требования обычно строго согласованы заранее. Вопрос, почему вообще именно разработчик, пусть даже и техлид, должен угадывать, как лучше угодить клиенту, остается открытым.
А уволили как? По собственному, или с тремя зарплатами как положено?