Чудовий випуск. Велике спасибі! Дивитися можна всім, не лише фронт-розробникам. В двох годинах роки досвіду і цінна інформація, один з кращих(на сьогодні) випусків. Не пожалкуєте.
Дякую за контент, дуже сподобались відповіді Дмитра, так як теж займаю посаду ліда його підходи мені дуже знайомі. В коментарях чомусь хотілось більше технічки, хоча на даних вакансіях запитувати про історію створення інтернету, "чи яка різниця між null & undefined" яку важливу інформацію воно дасть для інтервьювера? Тому мене трохи тривожать такий вид питань (на співбесідах), де ти як senior/lead хотів би поспілкуватись за архітектури, оптимізації чи дебагінг, але тебе запитують ванільні питання по JS.
От я подивився це інтерв’ю, і так не зрозумів під кінець, як оцінити відповіді співбесідника ? Саме відсутність «технічної» складової в питаннях, робить відповіді дуже субʼєктивними на рівні бачення, відчуттів та досвіду. Тобто це більше розмова на співпадіння людей по сенсам та баченню. Дякую за етер.
І так і ні. На не технічні питання також є неправильні відповіді. Ну тобто коли б я на питання як ви вирішуєте конфлікти відповів би - я звільняю конфліктних без роздумів, то це була б моя субʼєктивна думка, але яка не є правильною в термінах лідерства та стратегічного розвитку команди.
Нагадало мені мого першого team lead, як він терпів мої всі помилки, змушував переписувати по 100 разів одне ц те саме щоб зробити краще. Наразі розумію для чого це все і яка кропітка це робота. Наступного відео можливо зробите огляд на фічі React 19 ? Дуже актуально наразі. Уже і бета начебто доступна
Було цікаво - але дууууже багато питань до відповідей гостя --- практично кожна відповідь це щось просто "своє", з "практики", по людськи типу ми домовились і предомовились, зробив - молодець, архітекрури немає, я читав скрам, хтось може а хтось не може :). Насправді хотілося б від гостя почути відповіді на дуже практичні питання - а що ж таке скрам і чому він не працює? а що ж таке аджайл і як його використовувати на практиці? а чим поганий ватерфлоу і канбан? А які метрики продуктивності використовуєм і що це нам говорить про наші спринти? а які метрики еффективності команди юзаєм? а як організовуєм взаємодію між командами? а як вирішуувати конфлікти і проблеми в команді? SRE? організація customer support? і ще дуже багато питань і це тільки по менеджерській частині... Вже не говорячи про технічні питання
З душної точки зору ви підійшли 😊 Але якщо ви помітили то тут не було мети розібрати конкретні випадки. Ми не могли зосереджуватися на розборі архітектури бо це б зайняло весь етер. Для того щоб відповісти на питання що таке скрам і чому він не працює або працює треба для цього прям тему подкасту/етеру. То саме і з іншими. Тільки от де ви у мене побачили нерозуміння процесів і небажання навчатися? В будь якому випадку дякую вам за комент. Буде над чим подумати.
За "нерозуміння процесів і небажання навчатися" вибачте - це моє оціночне судження, і не має відношення до обєктивної реальності, а лише є відображенням мого власного досвіду.
@@Vitalik186 дякую за пояснення. Я просто з усих сил намагаюся змінити той аутсорс який бачу навколо. Бо як раз він загально і має ті риси які ви наводите. Типу ось вам весла, стрижемо капусту поки гребеться. І тільки невелика кількість аутсорсів які виросли і дійсно працюють на процесах. Ну принаймні мені це так здається зі сторони.
@@dmitriybraginets6750 то я знегативив :) мене просто негативна хвиля емоцій накриває кожен раз коли згадую аутсоурс в якому колись працював :) і здається пройшло багато років, а ви описали рівно те що в мене було Але з позитивного. Мені сподобалось що у вас є адаптивні рішення до проблем. Мені содобався ітеративний підхід - і відсутність архітектури на ранніх етапах. Єдине що про архітектуру я б додав - відсутність архітектури це теж такий вид архітектури, у якого є також декілька особливостей. Також у вас однозначно високий рівень стресостійкості, та лідерських якостей.
Мене цікавить чому такі люди працюють в аутсорсі. Для мене аутсорс то такий "плавильной котел", в якому гарно рости і набратись досвіду. Але коли доростаєш до певного рівня сеньйорності, оці постійні компроміси між бажанням писати хороший код і клієнту треба фігак-фігак щоб швидко, пофіг як, демотивують.
Та звичайні люди :) Я мабуть з вами погоджусь щодо того що аутсорс то "плавильний котел", і що якщо важко працювати, то можна за доволі короткий термін набратися досвіду у вирішенні самих різноманітних питань. Сіньорність звісно від цого не виросте, бо сіньорність це не знання двадцятитрьох фреймворків, а щось більш абстрактне. Я думаю що у будь якого інженера в житті є ось цей компроміс між написанням ідеального-коду-який-слідує-всім-паттернам (і який наступного ранку вже треба переписати, бо прийшло розуміння як зробити краще :) ) і того який потрібен, або навіть сказати достатній, для вирішення задачі. І ось тут у аутсорсу є як і плюси так і мінуси. З плюсів це те що у вас є можливість експерементувати, бо проєкти змінюються і ви не зв'язані підходами що вже стали скрижалями на вашому продукті. З мінусів - треба швидше. І зараз мені не дає спокою питання - чомусь на конференціях, в книжках, на подкастах, ми розмірковуємо саме про той ідеальний код/підхід/інфраструктуру/тощо і якось протистовляємо швидкість якості. Але ж насправді можна написати швидко і ДОСТАТНЬО якісно. Підкреслюю - достатньо. А ось тут вже на перший план і виходить ось так сіньорність яка дозволяє зрозуміти скільки зусиль достатньо прикласти і які підходи достатньо використати для ось цього конкретного проєкту щоб і задовільнити побажання замовника закінчити до різдва і одночасно написати якісну систему, яку можна буде і розширити і змінити, та і банально за яку не буде потім соромно якщо замовник через рік прийде до іншої команди щось дописати. Я бачів підходи деяких компаній в яких кожен наступний аутсорс проєкт був калькою з попереднього. Тобто всі архітектурні підходи, структура, тощо. Тобто техліди намагалися відлити ту саму "срібну кулю". І звісно воно має свої плюси, бо на проєкти легко вливатися, архітектура знайома, все як вдома. Але те що цю універсальну штуку в якій взаємодія між модулями орагнізована через MQTT і яку доволі легко розпилити на мікросервіси, ось коли її натягували на проєкт де воно взагалі не треба, то це мало вигляд певного знущання. І я навіть можу уявити біль розробників які кололился, але продовжували їсти кактус. Коротше кажучи, аутсорс не такий страшний як його малюють, головне знайти підходячу для вас компанію в якій розділяють ваші цінності, і в якій у вас буде можливість зростати. Не весь аутсорс це витискання соків з персоналу. Хоча мабуть в продуктах все одно більш розмірено і спокійно, навіть в порівнянні з гарним аутсорсом. Але я це можу тільки припустити :)
ми якось взяли на віру тех кваліфікацію спеціаліста, але тім лід, це впершу чергу людина, яка розуміє як писати єфективний код, а для цього стронг тех скіли маст хев, а тут жодного питання щодо технологій ((
Тут як кажуть it-depends. Бо з одного боку робота тімліда дуже рідко полягає саме в написанні ефективного коду. А от аналізувати, вміти читати те що написано, думати на перед, спілкуватися з людьми то от прям необхідність. Я звісно не кажу що я неймовірний кодописець, але без певної кваліфікації, як ви висловились, не вийде аналізувати і читати, і підказувати, і вчити інших. Хоча руки точно вже не такі шустрі як тоді коли ти постійно займаєшся кодінгом.
Честно кажучи, відповіді "Team Lead" скоріше звучали як відповіді проджект-менеджера. Досить мало конкретики, здебільшого абстракції. Сам формат крутий, аби був system design з тім лідом, про який на початку говорили, то було б набагато цікавіше
Звільняв після код рев‘ю. І як це варто сприймати?(пройоб при наймі, особиста неприязнь(тай спосіб діти людинку), мож писюн малий, тай хоче самозтвердитись). Словом, потрібно дивитись(щоб дізнатись).
Результат розіграшу квитка на ІТ Арена можна дізнатися тут, ввівши свій імейл:
www.random.org/draws/details/?draw=242812
Чудовий випуск. Велике спасибі!
Дивитися можна всім, не лише фронт-розробникам. В двох годинах роки досвіду і цінна інформація, один з кращих(на сьогодні) випусків.
Не пожалкуєте.
Дякую за контент, дуже сподобались відповіді Дмитра, чекаю подкаст!
Дякую) Ну та шо, то тільки від ваших переглядів залежить )
З великим задоволенням 😊
Дякую за випуск). Гарні питання та конструктивні і зважені відповіді. Дмитра було цікаво слухати. Хороше інтерв'ю вишло)
Дякую )
Нарешті послухав, дякую хороша розмова вийшла)
Пиліте подкаст, чекаємо Дмитра в гості і включіть про підхід до розробки фронтенду цікаво послухати.
Оооо, про widget based methodology я можу довго розповідати. Тим більш шо воно перевірено і працює.
Дякую за контент, дуже сподобались відповіді Дмитра, так як теж займаю посаду ліда його підходи мені дуже знайомі. В коментарях чомусь хотілось більше технічки, хоча на даних вакансіях запитувати про історію створення інтернету, "чи яка різниця між null & undefined" яку важливу інформацію воно дасть для інтервьювера? Тому мене трохи тривожать такий вид питань (на співбесідах), де ти як senior/lead хотів би поспілкуватись за архітектури, оптимізації чи дебагінг, але тебе запитують ванільні питання по JS.
Абсолютно згоден!
яке офігенне інтерв'ю!
видно людина дууже і дуже шарить, і таку людин просто оцікаво слухати
моя повага такому тімліду!
Дякую! Ретельно готувалися )
Такі коментарі прям додають впевненості у собі. Дякую!
Але насправді ще вчитися і вчитися 😅
Фантастичний етер. Дмитро супер класний і добрий.
не правда на такий вже і добрий, э багато речей котры він не любить - тайпскріпт, нест і тому подібне
А до чого одне до другого?
@@babichweb саме тому він злий олдскульний ворчун) забий, то локальний жарт)
Він чудовий тімлид, то я як член його команди кажу.
Дякую, це було надцікаво, неможливо було відірватись!
Дякую!
Правда, один з найкращих випусків! Радий за тих хто працює з Дмитром :)
Дякую)
От я подивився це інтерв’ю, і так не зрозумів під кінець, як оцінити відповіді співбесідника ? Саме відсутність «технічної» складової в питаннях, робить відповіді дуже субʼєктивними на рівні бачення, відчуттів та досвіду. Тобто це більше розмова на співпадіння людей по сенсам та баченню. Дякую за етер.
Абсолютно вірно
І так і ні. На не технічні питання також є неправильні відповіді. Ну тобто коли б я на питання як ви вирішуєте конфлікти відповів би - я звільняю конфліктних без роздумів, то це була б моя субʼєктивна думка, але яка не є правильною в термінах лідерства та стратегічного розвитку команди.
Технічну можна завчити але не знати на практиці.
От зраза, такий крутий ефір прогавив. Все ота клята робота 😂. Бабіч як завжди топ! Дякую за корисне відео.
Дякую)
Дмитрий мой первый Лид. Он самый лучший.
Гортав стрічку Ютуба, а тут Дмитро у прямому етері. Крутяк.
Отакі от несподіванки )
Ага, Дмитро і сюди добрався 😂
Дякуємо 🥳
Старалися )
@@babichweb поцьмав у лобіка🫶😁
Нагадало мені мого першого team lead, як він терпів мої всі помилки, змушував переписувати по 100 разів одне ц те саме щоб зробити краще. Наразі розумію для чого це все і яка кропітка це робота. Наступного відео можливо зробите огляд на фічі React 19 ? Дуже актуально наразі. Уже і бета начебто доступна
Дякую за відгук ) За оглядами реакту то не до мене, на жаль)
Було цікаво - але дууууже багато питань до відповідей гостя --- практично кожна відповідь це щось просто "своє", з "практики", по людськи типу ми домовились і предомовились, зробив - молодець, архітекрури немає, я читав скрам, хтось може а хтось не може :). Насправді хотілося б від гостя почути відповіді на дуже практичні питання - а що ж таке скрам і чому він не працює? а що ж таке аджайл і як його використовувати на практиці? а чим поганий ватерфлоу і канбан? А які метрики продуктивності використовуєм і що це нам говорить про наші спринти? а які метрики еффективності команди юзаєм? а як організовуєм взаємодію між командами? а як вирішуувати конфлікти і проблеми в команді? SRE? організація customer support? і ще дуже багато питань і це тільки по менеджерській частині... Вже не говорячи про технічні питання
З душної точки зору ви підійшли 😊
Але якщо ви помітили то тут не було мети розібрати конкретні випадки. Ми не могли зосереджуватися на розборі архітектури бо це б зайняло весь етер.
Для того щоб відповісти на питання що таке скрам і чому він не працює або працює треба для цього прям тему подкасту/етеру. То саме і з іншими.
Тільки от де ви у мене побачили нерозуміння процесів і небажання навчатися?
В будь якому випадку дякую вам за комент. Буде над чим подумати.
Дякую, я чекав на цей коментар
За "нерозуміння процесів і небажання навчатися" вибачте - це моє оціночне судження, і не має відношення до обєктивної реальності, а лише є відображенням мого власного досвіду.
@@Vitalik186 дякую за пояснення. Я просто з усих сил намагаюся змінити той аутсорс який бачу навколо. Бо як раз він загально і має ті риси які ви наводите. Типу ось вам весла, стрижемо капусту поки гребеться. І тільки невелика кількість аутсорсів які виросли і дійсно працюють на процесах. Ну принаймні мені це так здається зі сторони.
@@dmitriybraginets6750 то я знегативив :) мене просто негативна хвиля емоцій накриває кожен раз коли згадую аутсоурс в якому колись працював :) і здається пройшло багато років, а ви описали рівно те що в мене було
Але з позитивного. Мені сподобалось що у вас є адаптивні рішення до проблем. Мені содобався ітеративний підхід - і відсутність архітектури на ранніх етапах. Єдине що про архітектуру я б додав - відсутність архітектури це теж такий вид архітектури, у якого є також декілька особливостей. Також у вас однозначно високий рівень стресостійкості, та лідерських якостей.
Мене цікавить чому такі люди працюють в аутсорсі. Для мене аутсорс то такий "плавильной котел", в якому гарно рости і набратись досвіду. Але коли доростаєш до певного рівня сеньйорності, оці постійні компроміси між бажанням писати хороший код і клієнту треба фігак-фігак щоб швидко, пофіг як, демотивують.
Та звичайні люди :) Я мабуть з вами погоджусь щодо того що аутсорс то "плавильний котел", і що якщо важко працювати, то можна за доволі короткий термін набратися досвіду у вирішенні самих різноманітних питань. Сіньорність звісно від цого не виросте, бо сіньорність це не знання двадцятитрьох фреймворків, а щось більш абстрактне.
Я думаю що у будь якого інженера в житті є ось цей компроміс між написанням ідеального-коду-який-слідує-всім-паттернам (і який наступного ранку вже треба переписати, бо прийшло розуміння як зробити краще :) ) і того який потрібен, або навіть сказати достатній, для вирішення задачі. І ось тут у аутсорсу є як і плюси так і мінуси. З плюсів це те що у вас є можливість експерементувати, бо проєкти змінюються і ви не зв'язані підходами що вже стали скрижалями на вашому продукті. З мінусів - треба швидше. І зараз мені не дає спокою питання - чомусь на конференціях, в книжках, на подкастах, ми розмірковуємо саме про той ідеальний код/підхід/інфраструктуру/тощо і якось протистовляємо швидкість якості. Але ж насправді можна написати швидко і ДОСТАТНЬО якісно. Підкреслюю - достатньо. А ось тут вже на перший план і виходить ось так сіньорність яка дозволяє зрозуміти скільки зусиль достатньо прикласти і які підходи достатньо використати для ось цього конкретного проєкту щоб і задовільнити побажання замовника закінчити до різдва і одночасно написати якісну систему, яку можна буде і розширити і змінити, та і банально за яку не буде потім соромно якщо замовник через рік прийде до іншої команди щось дописати.
Я бачів підходи деяких компаній в яких кожен наступний аутсорс проєкт був калькою з попереднього. Тобто всі архітектурні підходи, структура, тощо. Тобто техліди намагалися відлити ту саму "срібну кулю". І звісно воно має свої плюси, бо на проєкти легко вливатися, архітектура знайома, все як вдома. Але те що цю універсальну штуку в якій взаємодія між модулями орагнізована через MQTT і яку доволі легко розпилити на мікросервіси, ось коли її натягували на проєкт де воно взагалі не треба, то це мало вигляд певного знущання. І я навіть можу уявити біль розробників які кололился, але продовжували їсти кактус.
Коротше кажучи, аутсорс не такий страшний як його малюють, головне знайти підходячу для вас компанію в якій розділяють ваші цінності, і в якій у вас буде можливість зростати. Не весь аутсорс це витискання соків з персоналу.
Хоча мабуть в продуктах все одно більш розмірено і спокійно, навіть в порівнянні з гарним аутсорсом. Але я це можу тільки припустити :)
ми якось взяли на віру тех кваліфікацію спеціаліста, але тім лід, це впершу чергу людина, яка розуміє як писати єфективний код, а для цього стронг тех скіли маст хев, а тут жодного питання щодо технологій ((
Тут як кажуть it-depends. Бо з одного боку робота тімліда дуже рідко полягає саме в написанні ефективного коду.
А от аналізувати, вміти читати те що написано, думати на перед, спілкуватися з людьми то от прям необхідність.
Я звісно не кажу що я неймовірний кодописець, але без певної кваліфікації, як ви висловились, не вийде аналізувати і читати, і підказувати, і вчити інших. Хоча руки точно вже не такі шустрі як тоді коли ти постійно займаєшся кодінгом.
Честно кажучи, відповіді "Team Lead" скоріше звучали як відповіді проджект-менеджера. Досить мало конкретики, здебільшого абстракції. Сам формат крутий, аби був system design з тім лідом, про який на початку говорили, то було б набагато цікавіше
System design він з техлідами обговорюється. Ну і з синьйорами. І мідлів пора б уже.
А тімлід то якраз більше менеджерська посада
Звільняв після код рев‘ю.
І як це варто сприймати?(пройоб при наймі, особиста неприязнь(тай спосіб діти людинку), мож писюн малий, тай хоче самозтвердитись).
Словом, потрібно дивитись(щоб дізнатись).
Треба дивитись
Подивився, і скажу що з таким лідом можна працювати.
І само собою з автором також😊
Дякую за випуск)
@havrilyk4115 дякую )
мотивація, код ревʼю, вирішення конфліктів, процеси, метрики - це все добре, але я так і не почув як ВІДЦЕНТРУВАТИ DIV?
За допомогою джуна, очевидно ж
не сподобалось...особисто моя думка. Хватило на 17 хв..ні про що...але дякую за україномовний контент.
Прикро.
Дякую.
ого який скарб українською відкопав
Не то, шоб я сильно закопувався )
йов, перший комент
Молодець )