Микола,

вчитись фултайм по 8-годин так само реально, як і працювати фултайм.

Тобто 5 місяців фултайм навчання і десь в середньому 500 годин написання коду, який перевіряють ментори і дають фідбек, за твоєю логікою готують «верстальника з фіолетовим розумінням джс», а перегляд 24 годин відео CS50 без перевірок проєктів — людину, яка навчиться «програмування, як концепту мислення»? Все вірно?

і не кажи!

Олександр, там всі відгуки від реальних людей. ти себе накручуєш.

Андрій, коміти в бранчі яка ревювиться менторами але не мержиться в наш репозиторій: github.com/...​bar-airbnb/pull/874/files

організував би просту штуку — платив би $1000 розробникам, щоб вони форкали ріпи, писали відгуки і спілкувалися в позитивному ключі. Оскільки оплата зі студента $4000 — це вигідна пропозиція

спробуй так зробити. дуже цікаво побачити що в тебе вийде :)

це наші випускники. вони до цього не працювати в IT. після отримання оффера ми просимо залишти відгук. і потім можуть не писати нічого на форумі dou.

цілий відділ, який працює над створенням позитивних відгуків

такого відділу немає

Олександр привіт,

в доу профілях є посилання на соц мережі людей (треба щоб ти був залогінений). наприклад: dou.ua/users/mariia-bila-1

Обери будь-який відгук звідси dou.ua/forums/topic/23173 і напиши їм в соц мережі

метафора чудова :)

треба його розшукати і подарувати якийсь мерч :D

ахаха, хороший коментар.

позитивні відгуки про сервіс це звичайно розрив шаблонів, ми розуміємо що люди до такого не звикли :)

well, наш дохід росте тоді коли росте дохід наших студентів. нічого поганого в цьому не бачу.

шукаєш зраду там де її немає.

чому вибрали це робити в топіку, а не в відгуках до компанії?

було питання на dou, на яке не було відповідей, і високо показувалось в гуглі — тому тут і попросили залишати відгуки.

наприклад eduzorro

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

а поки що вони сеошаться по:
«Деньги в долг на карту срочно без отказа в РФ»

їм точно варто вірити.

Так от же ж відгуки від людей які вчились: dou.ua/...​rums/topic/23173/#2582168

третій квартиль

що і не кожного дня релізи

наклеп

лупаєм сю скалу ©

вона взагалі для бізнесу невігідна

ти ж бачив штрафи за недотримання gdpr? фіча 100% вигдіна :D

тоді, щось мені підказує, що ваша LMS виглядає як зоопарк з купою милиць, обмотаний ізоляційною стрічкою

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

ми там user generatad **JAVA** код компілюємо на льоту і ранимо по ньому тести. там все добре працює :)

well, щоб це працювало не потрібно щоб розробники овертаймили. середній вік розробників 27.

1) є також дизайнери / продакти. великі фічі робляться декількома розробниками. але акцент на тому, що довгостроково ефективність розробника оцінюється по результатах роботи фічі, а не просто «запущено». тому відсидітись в режимі «скажіть мені який код писати» не вийде.
2) так, розробка фічі займай скільки потрібно часу: тиждень/місяць/більше. за допомогою feature flags коли фіча готова вона включається в продакшені.

Тож, як я розумію, сама платформа розроблялась вами раніше трохи за іншим процесом, ніж описаний у статті?

та ні, все по такому процесу працювало відколи в нас з’явився лендінг

Дякую за коментар. Багато хороших думок.

чи є у вас автотести які раняться не на PullRequests, a просто на production для моніторингу та сповіщення чи всі сервіси працюють як годиться?

Немає. Орієнтуємось на моніторинг ментрик / помилок.

Чи очікуєте ви щоб співробітник сам ініціював розмову про perofrmance review, чи Engineering Manager ініціюють її дивлячись на результати розробника?

Співробітник повинен сам ініціювати розмову. Якщо 9-12 місяців співробітник не ініційовує розмову — EM повинен ініціювати її.

Чи робите ви щомісячну оцінку OKR щоб зрозуміти чи все йде згодно планом?

Так.

А як порадите інженеру з 3+ досвідом не чіплятись за технології минулого а перевіряти чи нова технологія вирішить проблему краще чи ні?

Так, це хороше питання. Важливо витримувати баланс між тим щоб не приносити все підряд в продакшен і не отримати legacy stack. Infrastructure team допомагає приймати такі рішення.

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

в кожної фічі повинен бути owner. Owner пише дизайн доки, як фіча буде працювати. Будь-хто може коментувати ці рішення і пропонувати альтернативи але рішення приймає овнер.

Мітинги взагалі не потрібні.