Можливо, авторові на даному етапі байдуже, який там буде домен.
А ось мені, з багаторічним досвідом, саме це вже стало дуже важливо.

Достатньо рандомний набір технологій.

Взагалі ні те, ні інше.

Але, враховуючи реалії та свої цілі, особливо коли цікавить тільки конкретна позиція, я краще спеціально підготуюсь до обох варіантів.

я б навіть з досвіду роботи повикидував усякі говнопроекти на яких я скоріше деградував ніж розвивався

Ось це — окрема вподобайка.

В каждом проекте обязательно “Project goal” и “Personal contribution”.

Project goal — to support the project.
Personal contribution — fixed NN bugs, implemented NN small new changes, and (if you are especially lucky) implemented N new features.

Універсальний опис 90% робіт на аутсорсингу, і не варто очікувати іншого тим, хто буде читати резюме більшості айтівців не із США. :-)

Критерії якості можуть бути різними.

А ще буває код плюс-мінус нормальний, якщо дивитися абстрактно, тобто з точки зору якогось SonarCube все OK, але загалом виявляється якесь дуже дивне рішення.

Як це виправити — невідомо. Зазвичай просто робимо роботу як за трьох — за себе, за ту ексцентричну людину та за перекладача с однієї логіки до іншої.

P.S.:
Розумію вас.

А ще іноді на проектах бувають «flaky tests», котрі працюють не завжди, але випадково. Тобто кожен приблизно третій раз падають. Перестартували тест — він пройшов, працюємо далі. І ніхто в команді не підняв червоній прапорець, коли вперше побачив таку поведінку. Ось цей підхід я не розумію.

те що створено до них, то якась чухня і її треба переписати

З одного боку так, але іноді це дійсно «якась чухня» та її стільки, що шансів щось змінити немає.
Тому доводиться робити зайву роботу, — перекладати свої думки на чужорідну логіку та навпаки.

Очікування: я побудував дуже класну стратегію покращення низькоякісної legacy code base та слідую своєму плану.
Реальність: прибігає ефективний манагер та волає «ааа! все має бути зроблено вчора! який рефакторинг?!111»

Дякую.

А чим саме відрізняються QC 45 від QC 35?

35 тепер можна більше ніде не знайти. 45 ще десь залишаються.

Хто користувався навушниками Bose QC 45? Дуже цікавить один момент.

У мене Bose QC 35.
Мій головний use case:
Я підключаю їх по дроту до ноутбука. Включаю шумодав. Включаю аудіо чи учбове відео.
Все було ідеально, поки не зламалося гніздо дроту.

Купив Bose QuietComfort Black. З ними виявилася дуже велика підлість, ось таким чином: підключаю їх по дроту до ноутбука — можу щось слухати без шумодаву, але коли включаю шумодав — звук зникає, хоча сам шумодав працює.

Горити у пеклі усім тим діячам Bose, хто вирішив зіпсувати найкращій продукт та затверджував це «креативне» рішення.

Увага, питання! Рятуйте!

Чи працює Bose QC 45 таким чином? Підключив їх по дроту до ноутбука, включив шумодав, включив аудіо/відео, звук є. Саме такий спосіб. Працює чи ні?

P.S.:
Не хочу сенсорне керування наосліп та навпомацки в стилі Sony, бо це маячня. На превеликий жаль, ця маячня зараз стала трендом. Одна надія — купити одні з останніх QC 35 чи 45. Або може якась китайщина є, яка працює як QC 35.

Гірше. Підвипідверти з’явилися десь у глибині back end та не мають відношення до бізнес-логіці. Тобто, наприклад, «генію» закортіло зробити обгортки для String ключів у кеші та цілий abstraction layer до всього цього. Або додаткові обгортки до якогось нормального стандартного API. Не питайте навіщо...

По суті, ви очікуєте від інженера, що він буде «2 в 1»: фахівець в IT та в бізнес-галузі. А там, доречі, люди теж вищу освіту здобувають або вкладаються в самоосвіту у своїй галузі, якщо там таке в принципі можливо.

Я мав думки, особливо у зв’язку з розвитком ШІ: може виникнути ще більша спеціалізація, код будемо писати більш ефективно за допомогою різноманітних ШІ-копілотів, а фокус уваги частково (але значно) зміститься на бізнес-логіку.

Тобто зараз є Java developer або .NET developer,
потім будуть Java FinTech developer, Java healthcare systems developer, .NET bank systems developer, Python logistic systems developer,
тощо, все в такому дусі.

Поки що так мені здається зараз.

Дослідити всі ці бізнес-процеси і зрозуміти, як правильно інтегрувати їх у вже існуючу систему — ось що визначає складність поставленої задачі

Це не одна локальна задача. Це стратегічна довгострокова задача для senior інженера на проєкті.

Зараз складність задачі визначається якраз-таки складністю бізнес-процесів, вкладених у цю задачу.

Це в ідеалі.

А на реальних проєктах — найбільша складність та біль — це реалізувати фічу в існуючому коді, з його унікальними паттернами, створеними людиною з максимально загадковим стилем мислення. Тому що коли була можливість зробити все достатньо straightforward, якийсь «невизнаний геній» зробив усе з якимись одному йому зрозумілими підвипідвертами.

Я можу з упевненістю сказати, що майже будь-яке технічну задачу можна виконати за допомогою стандартного набору інструментів тієї чи іншої технології.

Так. Підтримую.

HP ProBook 4340s
Купував у 2013 році, користуюся досі.

китайських брендів

Навіть не розглядаю таке.

Тут майбутнє ні до чого. Що взагалі може змусити відпочивати від стосунків, які закінчилися? Окрім специфічної тяги до психопатів, аб’юзерів, тощо.

Навіщо такі стосунки, від котрих треба відпочивати?

Працювати з постійно включеною веб-камерою. Я інженер, а не якась вебкам-модель.

вивіряти технічні деталі треба в самоті і тиші.

Супер-абсолютно супер-згоден.