Відповідаю.

є компанії, де є певні додаткові компенсаційні пакети на випадок виходу жінки на maternity leave.
А іноді навпаки — дають знати, що просто звільнять. Все. Просто потім не треба дивуватись, коли людина не бажає розуміти потреби бізнесу. Це не зовсім зріла позиція.

Ось і все.

Дивіться.
По-перше, коли людина приходить в компанію, можуть спитати, чи є в родині дитина. Чому — просто компанії роблять подарунки на День Св. Миколая.
По-друге, є компанії, де є певні додаткові компенсаційні пакети на випадок виходу жінки на maternity leave.
А іноді навпаки — дають знати, що просто звільнять. Все. Просто потім не треба дивуватись, коли людина не бажає розуміти потреби бізнесу. Це не зовсім зріла позиція.
Про те, що ви говорите — ви гадаєте, що інша людина якось може про щось знати, чи сидить через медитацію намагається узнати про когось через відкриття чакр?
Знову хотів би підкреслити — є для цього певні мітинги, де можна спокійно і в виважених виразах поспілкуватись. Задача менеджера забезпечити максимальний профіт на проєкті і спитати, що впливає на настрій, якщо людина має не високий перформанс. Це аксіома менеджменту в нормальних компаніях.

Для менеджера важливо планувати. Для жінки це нормально мати дитину. Для цього власне існують one-to-one, щоб нормально спитати про певні плани на життя, тому що це має вплив на бізнес. Те що для вас трігер — це тригер, який треба пропрацювати. А так виглядає, що менеджер ще має бути психологом :) Матусею чи опекуном. Не треба перегібати.

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

З цих всіх питань — про queue, то таке. Тільки один раз при навантаженні треба було створити свою, і то тільки після піфоманс тестів. В більшості випадків достатньо було застосовувати звичайні механізми GCD. Зараз Apple створив ще один механізм Tasks.
Мене б більше цікавили речі, як реактів стек і взагалі завдяки чому все це працює і для чого. Далі можна спокійно про патерни «банди» поговорити і про архітектуру.
Cтосовно Viper — жодного разу не було потреби його застосовувати.
Цікаві питання бувають про computer science.
Якщо хтось просто задає питання на інтервʼю за документацією, все зрозуміло і можна закінчувати.

Про SOLID — то ви дарма так кажете. Насправді, треба не повторювати, як завєти ООП :)
А так, як приклад їх порушення. Простий приклад — як виявити у коді не хай Swift — порушення принципа Лісков.

Стосовно InAppPurchases — відверто скажу, я не звертаю в CV не це увагу (хоча завжди моя рекомендація — кожне слово, написане в CV має бути підтвердженим, але підкреслю, що не все можна памʼятати). Зі своїй практики в мобільній розробці я з цим функціоналом стикався лише раз і жодного разу у проєктах для ентерпрайс. Хоча веду розробку і для десктоп і на беці — маю зацікавленність і в інших напрямках.
Зазвичай я починаю інтервʼю з проєктів кандидата і розкручую через це все інше (починаючи з простого), SOLID — не тільки, як кандидат розкаже по памʼяті, але і саме розуміння — як це втілюється саме на тій платформі. Те ж саме стосується і паттернів. Як закінчую — просто, кажу, що більше запитань не маю. Час — це головне. Я краще щось цікаве для себе почитаю чи зроблю щось інше.

Насправді — як повезе :) На приклад, в SoftServe дійсно інтервʼювера підготовують, щоб у кандидата не склалось хибне враження, принаймі, з усіма, з ким там стикався — все було ок, незалежно від напряму технології. А ось з Luxoft зовсім протилежне враження.
Ще класно, коли приходять на інтервʼю і не вмикають камеру.
Також був цікавий випадок, коли приходять і інтервʼювери ведуть себе немов вони з Netflix.
Якось пара хлопців дали код у Google Doc перевернути певну структуру даних, розгорнув, прийшлось дещо пригадати, але все ж таки, один за все інтервʼю жодного слова не вимовив, інший, коли вже закінчували — сказав, що я мав би спілкуватись... Facepalm
Ще випадок, це коли в маленькому віконці пишуть код, а потім, щоб його додивитись — треба розгорнути те вікно, але воно не розгортається. Задають питання застосування деяких речей і наполягають, що так правильно, а ти відразу розумієш, що люди не користуються лінтерами і не читають best practices. Це було у одну крупну українську аутсорсінгову компанію.

Відверто кажучи, дійшовши до «декілька видів

InAppPurchases

» виникає питання, а що це дає? На справді — ця інформація знаходиться у документації Apple. Тримати це в голові — на що. Про паттерни — це ок, тому що дає розуміння про досвід побудови архітектури. І взагалі — тримати в голові такі речі ви можете, тільки якщо недавно з цим працювали. З мого досвіду краще запитував, на приклад, такі речі чи варто/не варто застосовувати на View @NSFetchRequest плюс деякі контейнери і в якому випадку який краще (дає відразу всю інформацію), а далі як піде.
Ще один момент — дуже залежить від того, як інтервʼювер налаштован і як відповідає кандидат. Іноді просто відразу хочется все закінчити. Як показує практика, десь 10-15 хвилин технічних питань вже достатньо для розуміння.

Насправді бекенд він різний буває. Тут головне зрозуміти, що яку саме мову обирати.
C#, Java, NjdeJS чи ще щось.
С# - простіше, тому що все в одному місці (.Net, документація і тулкіт) у Microsft, плюс іх екосистема з Cloud, тобто Azure.
Java — скоріше за все це Spring і все інше, повʼязане з цим.
Свою нішу також має Scala — після Swift взагалі, що майже теж саме, але на JVM. Я б більше акцентував, що ця мова більше зараз націлена на Data Science, як і Python.
Власне про Python — тут свої фреймворки.
Що тут головне, так це на мікросервіси.
Якщо відверто є досвід хоча б з однією екосистемою, то переходити багато часу не забирає. Як уже сказано було, головне розібратися, як будуються мікросервіси, як в них побудована взаємодія, які брокери застосовуються. Відомі — Kafka (в більшості випадків для Java, іноді RabbitMQ), .Net віддають перевагу RabbitMQ.
І все як це працює у кластері/ах. Перевагу тут має Kubernetes, ніж у Docker Swarm.
Kubernetes — тому що усі Cloud вже мають під це окремі сервіси на кшталт EKS.
Що можна сказати про них, то це якщо людина опановую будь яку Cloud інфраструктуру, то майже всі інші мають подібні сервіси, просто з іншими назвами.
І ще одна складова — це робота з базами даних. Але знов таки, всі мають ту чи іншу реалізацію ORM (Java — Spring Data/Hibenate, .Net — Entity Framework). Щоб розуміти іх, краще опанувати ANSI SQL. Якщо був досвід з SQLite, то це навіть краще. Плюс дрібниця — розуміння, як працювати в скоупі цих речей з міграціями.
І на останок — то це як працювати з CI/СD, мабуть тут перевагу має Jenkins через свою універсальність. Є варіанти, коли будують на базі Git.
Головне обрати правильні джерела інформаціі — книги Manning та курси від Udemy.
Тільки відео не вистачить.

Не впевнений, що ви маєте на увазі у випадку ресурсів, адже RX ними не керує ... хіба за потоки мова, але про це ви написали другий пункт :)

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

kotlin coroutine,

це якщо було прийнято рішення писати бек на Kotlin, то це має сенс. Є як завжди свої pros і cons. Основний недолік, все ж таки Kotlin не завжди підтримує останню JVM.
Для Android — то тут вже інше питання, скоріш за все таки буде Kotlin. І тут RxJava може використовуватися, як база (депенденсі) для RxKotlin.
Щоб багато не писати, раджу прочитати Т. Нуркевича (це якщо про RxJava) — там як раз про всі підходи і про scheduler і про бекпреже і про все інше (до речі це теж про ресурси).
Якщо для беку на Java — то «Hands-On Reactive Programming in Spring 5» — тут на початку про різне, потім вже про Reactor.
Для Android — то вже є що почитати на kodeco (взагалі про світ мобайлу). Але якщо цікаво, як це працює в інших мовах, то можна і по ним знайти і для C++ і для .Net.
І вже на останок — Rx — це функціональний підхід, замішаний на класичних патернах плюс конкаренсі.

Насправді в свій час був популярний підхід Event Bus в Android, але його мало хто застосовував, тому що йшли на багато простішим шляхом через колбеки. Той же Event Bus перекочував і в бекенд (Spring цей підхід є і в .Net навіть окремі сутності зробили — event). Просто треба розбиратись у підходах, а у нас як... Просто взяли відео продивились і все. Нема глибоко і продуманого підходу. На простих проєктах — це працює. На великих — потім все приводить до втрати часу (тут попрацював і далі пішов). Це відомі проблеми і добре все описано у Р. Мартіна.
Щодо coroutines — ідея не нова і має імплементацію і в С++, як власне будь які інші підходи, які кочують між мовами і фреймворками.
Як висновок — як би це був поганий підхід, його не намагалися б застосовувати і інших мовах.

Дві речі яуі вирішує ця технологія.
1. Це підхід до ресурсів.
2. Це конкаренсі.
Якщо складно розуміти технололгію, то не треба писати, що вона вам не потрібна.
Я десь вже писав. Але Angular на цьому побудован та SwiftUI на це перейшов. Android в багатьох фреймоворках це підтримує (і Rx і coroutines).
Якщо вам треба щось швидко — то це не про Rx.
І ще раз — це не про швидкість — це про ресурси.
Усі мови цю технологію підтримують і навіть Spring теж має — Reactor.
Ще одна цікава технологія існує, але її теж рідко використовують, це модель актор.
Є дуже багато компаній, які викорустивують Akka і Tesla там теж. Але нікому з їх інженерів не йде в голову писати про те, що ця технологія не потрібна.
Як приклад — вона є базою в Erlang, завдяки цьому продукти мають дуже великий процент стійкості до відмови — 99,99999%.
Все, що маю додати.

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

Ви не праві. Junior — це не Trainee, ця людина як мінімум має добре розуміти мову програмування, але не має чіткого розуміння який фреймворк застосувати і як. Для робітників такого рівня треба витрачати більше часу (на менторство і на кодревʼю) і розписувати таски дуже ретельно. І звісно, що Junior не зможе зробити складний проєкт з нуля (це навіть і мідл нормально не зробить). Але є деякі — хто дуже швидко навчається. І з таких за рік-півтора при нормальному вкладанні зусиль можна зробити хорошего мідла.
На справді в нормальні часи деякі великі аутсорсінгові компанії мали внутрішні курси, які набирали на горячі напрямки як раз Trainee — ця ситуація власне є win-win.

Що стосується PalmOS — то тут я вже не памʼятаю в чому була трабла. А ось Symbian — просто закрили через те, що Microsoft викупив Nokia і вони перейшли на WinPhone з підтримкою .Net, для того часу була норм система, деякі компанії ії ставили, але все ж таки Android і iOS переграли. Що стосується розробки софта — ось на мобайлі намагаються зробити певні гібриди, які в дійсності більш нагадують Франкенштейнів. А все потому — що не має стандарта і його не буде, тому що... ведучі компанії розвивають свої мовb і фреймворки. Колись був єдиним C++, але Apple все рівно застосовував Objective-C (як на мене простіша і потужна мова) на той час поховали Carbon, пізніше — подивившись, що коїться зі стандартом С++ — так і продовжили, склепав Swift та вже поховали той Objective-C. Щодо беку — все впирається в розподіленість і підходи. Раніше достатньо було написати аплікацію і розгорнути на премісис сервері. Зараз — це ціле діло. Kubernetes, AWS, GCP, Azure — і всі зі своіми підходами, DevOps, плюс більш менш належне тестування.

За док дякую, почитаю. У функціонального підходу є два дробека, це скейлінг і власне — нема бескінцевої памʼяті, тобто треба розглядати комбінований підхід. І все ж таки Rx — не вважається чистим функціональних підходом.
Про добре і швидко — знову, залежить від певних обставин. Для стартапа — так, важливіше швидше написати, навіть якщо мати потім посередньої якості код. Але якщо вже більш менш зрозуміло, то тут як раз важливіше правильні підходи. Я бачив деякі проєкти, які були швидко зроблені та продані. Але потім їх сапорт виходив для замовника дуже дорого, і власне — в деяких просто відмовлялись його якось розвивати.

Можете написати тести і привести результати, може тоді у вас буде можливість опублікувати і довести всім іншим, що праві саме ви.
Я ж поки що скажу ось що.
Mobile — SwiftUI, Combine — Rx підхід,
Android — на приклад Retrifit — підтримує і Rx і Coroutines плюс багато інших фреймворків, рекомендовано Rx,
Angular — RxJS — це вже саме за себе говорить.
Back — Java — для навантажень рекомендується теж саме — Rx, нарешті допрацьований для відповідальної підтримки, тобто драйвер баз даних — асинхроний, сервлет теж саме.
Тобто західні інженери виглядають, як недолугі? :) Ага :)

Я б вам рекомендував ще раз переглянути базові патерни проєетування і спробувати зрозуміти, на базі пари яких вся ця ідея побудована. До того що вмре. Проблема в тому, що рективність — це не про швидкість, а про ресурси і систему обміну даними між потоками. Вже проведені певні дослідження і доказано, що рективна система краще тримає навантаження. Як джерело — достатньо відкрити першу главу RxJava Т. Нуркевича, де є чіткі графіки. Стосовно віртуальних тредів — які б вони не було, все рівно вони не є сферичним конем в вакуумі, а це значить, що будуть використувувати певний ресурс, як памʼять. Так, не мапяться на системні потоки OS (які все ж таки обменжені), але... все рівно буде привʼязка — потік — реквест, це означає, що якась I/O операція його заблокує до моменту отримання результату. В реактивній системі — нічого не блокується, а просто очікується результат. Система піша далі виконувати свої задачі.

Дивіться, тут все дуже просто — перша вправа, треба просто відкрити сторінку з багами Flutter, Відразу все стане на свої місця. Друга вправа — подивитись, як і що працює на певних платформах. Як приклад — iOS. SwiftUI out of the box підтримую відразу всю екосистему. Від iPhone і закінчуючи Apple Watch. Теж саме і з Android Kotlin/Compose. Можна розписати по леєрам і фремворкам — але то зайве. І все це має підтримувати Flutter.
Єдине, де має сенс таких гибридів — це показати швидко бізнес ідею потенційним інвесторам. Потім все викинути. Бо як ви можете бачити — технології змінюються.
Apple поступово відходить від UIkit, Google — від старого управляння UI.