Розіграш призів серед усіх, хто вірно відповіді на питання від партнера, проведено. Перевірити, чи ви не є у списку переможців, можна тут: www.random.org/draws/details/?draw=230534 Я ж контактую переможців особисто, чекайте на листи. 1 місце - Ламзак + пляшка для води 2 місце - Шопер + пляшка для води 3 місце - Пляшка для води Дякую компанії Sombra за надані подарунки!
Мені сподобалась співбесіда, цікаві питання, нестандартний підхід до знайомства з технічною стороною кандидата. Олексій теж молодець. Я пригадую одну свою співбесіду, де дуже хвилювався, не зміг зібратись і голова просто не працювала нормально. Мені допомогло почати на борді замальовувати думки, ідеї, звʼязки. Так і розкрутив себе і зміг виконати завдання
Були дуже цікаві запитання, дякую за етер. Кожного разу коли дивлюсь твої співбесіди, намагаюсь і сама на ті питання відповісти. І кожного разу знаходжу щось нове і йду гуглити. За це окреме дякую) Поки є час до наступного твого етеру, пішла дивитись, що розповідає Lea Verou)
Сергій, перше враження - круто бачити такий контент українською. Друге - відео досить інформативне, а третє продовжуй і розвивай канал!! Дякую за контент!
хлопці, у нас tailwind всюди, як і в будь якій технології треба чимось жертвувати, жертвуємо абсолютною гнучкістю проте отримуємо уніфікацію без сотень css файлів написаних авторським стилем. я побував на двох берегах, берег хейтерів і апологетів. в 95% випадків додаємо стилі до компонентів за допомогою tailwind, інше - звичайний css.
дякую Сергію за інтервʼю, і Богдану за розбір та за те, що сказав за «людішєк». Субʼєктивно, не так важко було дивитись через рівень чи мікрофон кандидата, як через самого кандидата
@@babichweb Подобається формат співбесід, де не питають якісь терміни, чи синтаксис, які розробник на практиці може завжди легко піддивития в інтернеті. Мені здається часто достатньо знати що такий підхід, спосіб виконання існує, і є там якісь переваги чи недоліки. Подобається формат коли дають в голос подумати, але таких легких на поговорити кандидатів знайти важко, бо всі переживають і стараються просто дати відповідь стисло, або взагалі відповідають не на поставлене питання а щось плюс мінус. Формат простий, але цікавий, його завжди захопливо дивитись. Я б напевно починав з питань які не пов'язані на пряму саме з програмуванням, типу - чи може кандидат привести якісь приклади зі свого життя, коли він помічав що він думає алгоритмами, чи як він саме вирішує поставлену задачу (можливо в нього є свій підхід), чи наприклад з чого би починав розробку нового проекту(навіть якщо не починав, просто його думка). Ну такі загальні питання просто щоб розговорити. Бо якщо кандидат якось не впевнено відповідає на перші питання він вже все, сидить ображений, переляканий і думає скоріше б все це завершилось і я пішов спати. Моє улюблене питання це завжди про оптимізацію, бо це вже більше про підручники чим про ютуб, про це завжди цікаво послухати як відповідають
Пане, етер дуже сподобався😉 Дивилась вчора, коментую сьогодні😂 Кандидат попри хвилювання впорався чудово (на мою суб'єктивну думку). Не є експертом на рівень middle/senior, але питання були цікаві😊
не скажу про захід, але розкажу про восток - тут 3..5 років досвіду - це не то шоб не сінйор, це заледве мід - просто навряд людина бачила (а то і розрулювала) достатньо ситуацій, приймала серйозні рішення і реально драйвила розробку. ну і шо за "розроби компонент контекстного меню" - це ж ні разу не систем дизайн - це код дизайн. можна ж було б якусь фічу попросити зробити
Питання були хороші реально, та й відповіді були непоганими я думаю😊 Може відчуття "слабкості" є трішки через те що відповіді були трохи короткуваті, про що я, я про те що від сініора я очікував хоть трохи з чим цікавим він стикався чому так а не так, а чим саме краще це ніж то.😊
@@babichweb та я бачив, ти сам пробував декілька раз його на них вивести. Але в любому випадку хлопець молодець, замітно що хотів щоб було все ідеально і може трохи закіпішував. Легко мені тут в кріселку трендіть 😅
19:40 Переваги мікрофроненда: -Розмір команди в межах Scrum та XP. Не потрібно велику команду. -Різні технології можна використовувати для різних мікрофронендів. -Менше коду потрібно завантажувати локально. -Легше робити заміну модулів (мікрофронендів). Мінуси мікрофроненда: -Потрібна взаємодія між командами. -Незалежний деплой (розгортання). -Потрібно збирати частини в одне ціле. -CAP-теорема. -Важче керувати станами (state management).
Чому "нелажений деплой" до мінусів? Це навпаки одна з найбільших переваг - можливість незалежно розробляти та деплоїти тільки частину проекту, не "наступаючи на пальці" іншим і не ламаючи все якщо щось пішло не так.
Кльова співбесіда, але мені здалось, що пану Олексію для сіньорності дещо не вистачає досвіду проектування фіч та взаємодії безпосередньо з замовником.
Не розумію, чому респондент так фамільярно себе поводить в спілкуванні без жодної поваги до особистих меж інтерв'юверів та використовює матюки. Це вже норма в індустрії?
Так, можна вмовити свого колегу поміняти гарнітуру в процесі етеру, чи просто її зняти і говорити в ноутбук, або ще краще варіант перед етером за 10 хвилин зідзвонитись і перевірити всі технічні моменти, попереду багато етерів, сподіваюсь мої рекомендації допоможуть)
Він - не сіньор, навіть на мідла не тягне. Він навіть не відповів правильно "що таке архітектура?" - як сіньор цього може не знати... Це маст хев для такої позиції. Він сказав - що це стаорінки, мапа сайту і т.д. як сторінки працюють чи якось так. - що???? А якщо проект це не сайт? А якийсь десктоп чи зовсім программа яка у фоновому режимі працює наприклад як апач. Які сторінки саме тоді і там немає тоді архітектури виходить? Архітектура - це глобальні рішення. Архітектурні рішення - приймають якамога раніше. Чим раніше тим краще. Зміна архітектури у вже розробляємому проекті може вплинути на весь проект. Якщо рішення впливає глобально на весь проект - то це архітектурне рішення. Тому архітектуру затверджують до того як проект почне розроблятися. Дизайн - це локальні рішення. На відмінну від архітектурних, це рішення які приймаються на протязі розробки проекту і не впливають глобально на увесь проект. Якщо знаходиться рішення яке дуже сильно впливає глобально, і суперечить якимось частинам проекту - то це сигнал що були допущені не вірні рішення архитектури на самому початку проекту. І такі рішення вже архітектурні. А ще э реалізація - це ще більше локальні рішення, максимально деталізовані. Наприклад якщо наприклад паттерн controller це дизайн, а то як і що буде робитися безпосередньо з цим патерном можно відносити сюди. Паттерни дизайну - інглетон, та інщі - це все дизайн, не архітектура і не реалізація. Вони так і називаються паттерни ДИЗАЙНУ. Но питання було про архітектуру, і кандидат який стверджує що він сіньор не знає що таке архітектура - це нонсенс, це ще не сіньор і не мідл. Прикладами архітектури можуть бути: REST - це архітектурний стиль Наприклад SOAP - це нульовий рівень реста (теж відносимо значить до архітектури) Взаємодія різних компонентів системи може бути не тільки через рест, тобто можно ще висловитися що архітектура каже - як працює механізм взаємодії відправлення і отримання повідомлень між компонентами. Відповідь, кандидата у сіньори була на рівні гірше ніж джуніор. Можливо він і вміє писати код, можливо щось і розробляв на свій розсуд. Но знань конкретних немає. На посаду джуна думаю він підійде тому що як мінімум знає синтаксис мови, хоча повинен знати. Досвід роботи певної кількості років - не визначає рівень. Рівень визначається кількостью знань які підтверджуються досвідом. Просто працюючи декілька років не можно стати мідлом чи сіньором.
подобається коментар. архітектура таке широке поняття про яке можна говорити годинами. Наприклад: вибір бібліотеки для анімейшн, rest, Templates, scss чи windtail (щось не те з назвою). Я про те що якщо кожен почне тягнути, що йому подобається, і підходи до вирішення схожих проблем будуть різні, то серьозна архітектурна проблема. На мою думку архітектор має не допускати "зоопарку" і спрямовувати до вирішення задачі з існуючими засобами.
Розіграш призів серед усіх, хто вірно відповіді на питання від партнера, проведено.
Перевірити, чи ви не є у списку переможців, можна тут: www.random.org/draws/details/?draw=230534
Я ж контактую переможців особисто, чекайте на листи.
1 місце - Ламзак + пляшка для води
2 місце - Шопер + пляшка для води
3 місце - Пляшка для води
Дякую компанії Sombra за надані подарунки!
Привіт Сергій, а що треба зробити, щоб потрапити до вас на такий собес?
Я front-end dev Angular + Ionic 8 років досвіду, + трошки Java, Nestjs
forms.gle/nNRXahbPt4o3XDzg6
Мені сподобалась співбесіда, цікаві питання, нестандартний підхід до знайомства з технічною стороною кандидата.
Олексій теж молодець. Я пригадую одну свою співбесіду, де дуже хвилювався, не зміг зібратись і голова просто не працювала нормально. Мені допомогло почати на борді замальовувати думки, ідеї, звʼязки. Так і розкрутив себе і зміг виконати завдання
я поки на 18 хвилині. мені подобається як Сергій м'яко намагається привести Олексія до видповідей 👏
Були дуже цікаві запитання, дякую за етер.
Кожного разу коли дивлюсь твої співбесіди, намагаюсь і сама на ті питання відповісти. І кожного разу знаходжу щось нове і йду гуглити. За це окреме дякую)
Поки є час до наступного твого етеру, пішла дивитись, що розповідає Lea Verou)
Дякую щиро )
Я взагалі по мобайлу, але ваші абстрактні поведінкові/архітектурні питання були дуже цікаві!
Дякую!
Сергій, перше враження - круто бачити такий контент українською. Друге - відео досить інформативне, а третє продовжуй і розвивай канал!! Дякую за контент!
Дякую дуже!
хлопці, у нас tailwind всюди, як і в будь якій технології треба чимось жертвувати, жертвуємо абсолютною гнучкістю проте отримуємо уніфікацію без сотень css файлів написаних авторським стилем. я побував на двох берегах, берег хейтерів і апологетів. в 95% випадків додаємо стилі до компонентів за допомогою tailwind, інше - звичайний css.
дякую Сергію за інтервʼю, і Богдану за розбір та за те, що сказав за «людішєк». Субʼєктивно, не так важко було дивитись через рівень чи мікрофон кандидата, як через самого кандидата
супер супер, дякую дякую за старання!
Дякую! Яке питання сподобалось найбільше?
@@babichweb Подобається формат співбесід, де не питають якісь терміни, чи синтаксис, які розробник на практиці може завжди легко піддивития в інтернеті. Мені здається часто достатньо знати що такий підхід, спосіб виконання існує, і є там якісь переваги чи недоліки. Подобається формат коли дають в голос подумати, але таких легких на поговорити кандидатів знайти важко, бо всі переживають і стараються просто дати відповідь стисло, або взагалі відповідають не на поставлене питання а щось плюс мінус. Формат простий, але цікавий, його завжди захопливо дивитись. Я б напевно починав з питань які не пов'язані на пряму саме з програмуванням, типу - чи може кандидат привести якісь приклади зі свого життя, коли він помічав що він думає алгоритмами, чи як він саме вирішує поставлену задачу (можливо в нього є свій підхід), чи наприклад з чого би починав розробку нового проекту(навіть якщо не починав, просто його думка). Ну такі загальні питання просто щоб розговорити. Бо якщо кандидат якось не впевнено відповідає на перші питання він вже все, сидить ображений, переляканий і думає скоріше б все це завершилось і я пішов спати.
Моє улюблене питання це завжди про оптимізацію, бо це вже більше про підручники чим про ютуб, про це завжди цікаво послухати як відповідають
Сергію, дякую за гарні питання для інтервʼю!
Дякую! Стараюсь тепер підбирати питання під кожного гостя персонально.
Дякую учасникам! Гарне вийшло інтерв’ю. Сергію, до зустрічі на JS Fwdays.
До зустрічі)
Пане, етер дуже сподобався😉 Дивилась вчора, коментую сьогодні😂 Кандидат попри хвилювання впорався чудово (на мою суб'єктивну думку). Не є експертом на рівень middle/senior, але питання були цікаві😊
Дякую! Візьму до уваги.
Етер бомба ❤🔥
Цьом тобі в лобіка!
не скажу про захід, але розкажу про восток - тут 3..5 років досвіду - це не то шоб не сінйор, це заледве мід - просто навряд людина бачила (а то і розрулювала) достатньо ситуацій, приймала серйозні рішення і реально драйвила розробку. ну і шо за "розроби компонент контекстного меню" - це ж ні разу не систем дизайн - це код дизайн. можна ж було б якусь фічу попросити зробити
Як завжди на висоті!
Був би вдячний якщо поділитесь посиланнями на ЦСС гуру в твітері) нажаль не вдалося розчути про кого Богдан говорив.
Lea Verou
І ще про @anatudor я казав. Ця жінка дуже вправна.
Питання були хороші реально, та й відповіді були непоганими я думаю😊
Може відчуття "слабкості" є трішки через те що відповіді були трохи короткуваті, про що я, я про те що від сініора я очікував хоть трохи з чим цікавим він стикався чому так а не так, а чим саме краще це ніж то.😊
Згодний з тобою, я теж чекав дещо розгорнутіших відповідей, але спишемо це на хвилювання)
@@babichweb та я бачив, ти сам пробував декілька раз його на них вивести.
Але в любому випадку хлопець молодець, замітно що хотів щоб було все ідеально і може трохи закіпішував.
Легко мені тут в кріселку трендіть 😅
пишу комент в підтримку каналу. крутий контент
Дякую дуже за підтримку!
Просто цікаво, а хоч хтось з експертів в коментах, хоч раз прийшов і показав як треба?😂
Жоднісінького )
Напевно переведу відос у «переглянти пізніше» бо сусіди пилососять і нічого не чути😅
Питання супер)
Дякую)
Це прикол звісно, що сеньйор не може сформулювати визначення архітектури. Мікросервіси - окремий лол)
Радий, що змогли тобі підняти настрій.
Питання рівня джуніор/міддл, кандидат слабкий, а головне немає критики і додаткових питань. System-design - це не про це взагалі.
Покажеш як треба проводити? Я із задоволенням запрошу на канал.
19:40
Переваги мікрофроненда:
-Розмір команди в межах Scrum та XP. Не потрібно велику команду.
-Різні технології можна використовувати для різних мікрофронендів.
-Менше коду потрібно завантажувати локально.
-Легше робити заміну модулів (мікрофронендів).
Мінуси мікрофроненда:
-Потрібна взаємодія між командами.
-Незалежний деплой (розгортання).
-Потрібно збирати частини в одне ціле.
-CAP-теорема.
-Важче керувати станами (state management).
А ще дублювання копмонентів, навіть за викристанням мікріка ui-ліби
Чому "нелажений деплой" до мінусів? Це навпаки одна з найбільших переваг - можливість незалежно розробляти та деплоїти тільки частину проекту, не "наступаючи на пальці" іншим і не ламаючи все якщо щось пішло не так.
@@pavlogrydzhuk1913 Ті переваги, що ви пишете, я також вказав. А незалежний деплой в мінуси поставив, бо це банально повторення роботи, тобто дорожче.
@@dimapopov5962 , ну я б не назвав незалежний деплой мінусом чи плюсом. Скоріш просто особливість. Бо в цьому є як користь, так і не зовсім
БЕМ взявся за нашого Українського Сімферопольського відділення Яндекс, і один з його винахідників як не помиляюся працює зараз в Київі у Wix.
І чого я 6473?
Спочатку коменти пишемо, тоді дивемося відео)! Для рейтингу Бабіча
Теж варіант, дякую )
❤🔥❤🔥❤🔥
Кльова співбесіда, але мені здалось, що пану Олексію для сіньорності дещо не вистачає досвіду проектування фіч та взаємодії безпосередньо з замовником.
Я думаю, що він обов'язково здобуде такий досвід!
@@babichweb безумовно, досвід така штука, яка набувається безперервно.
Так хто книгу написав? Роберт Мартін ти Мартін Фавлер?
Джордж
Дядько Боб написав
Правильно Біб
З system design він трохи (взагалі) не туди пішов... Сіньори вони такі сіньори. )
Гарні питання, слабкі відповіді.
Можливо
Не розумію, чому респондент так фамільярно себе поводить в спілкуванні без жодної поваги до особистих меж інтерв'юверів та використовює матюки. Це вже норма в індустрії?
Гостів без окремого мікрофону і окремої вебкамери не запрошувати 😅
base.monobank.ua/945RjPetbDGaHT#subscriptions
Чому нама таймкодiв? 😭
Не зробив ніхто
щось результатів розіграшу не видно
Будуть, маю технічну заминочку
Шо по звуку?
Він хуйовий, очевидно
@@babichweb Ок. Бо я вже подумав, що оглох.
Чистий код Мартіна Фавлера
Ну та шо ж, shit happens
Дуже слабенько як на сініора… дуже…
І?
за бем тіпа дізлайк того шо з польщі
Ок
сеньор не може купити норм мікро? Чесно я намагався, але не зміг!
Порадиш якийсь?
Нажаль Арестовича чути було краще 😢
Допоможеш це виправити?
Так, можна вмовити свого колегу поміняти гарнітуру в процесі етеру, чи просто її зняти і говорити в ноутбук, або ще краще варіант перед етером за 10 хвилин зідзвонитись і перевірити всі технічні моменти, попереду багато етерів, сподіваюсь мої рекомендації допоможуть)
Ніколи б не додумався так зробити, дякую, шо б я без тебе робив.
Якщо що - пиши
Обов'язково
Він - не сіньор, навіть на мідла не тягне. Він навіть не відповів правильно "що таке архітектура?" - як сіньор цього може не знати... Це маст хев для такої позиції.
Він сказав - що це стаорінки, мапа сайту і т.д. як сторінки працюють чи якось так. - що???? А якщо проект це не сайт? А якийсь десктоп чи зовсім программа яка у фоновому режимі працює наприклад як апач. Які сторінки саме тоді і там немає тоді архітектури виходить?
Архітектура - це глобальні рішення. Архітектурні рішення - приймають якамога раніше. Чим раніше тим краще. Зміна архітектури у вже розробляємому проекті може вплинути на весь проект. Якщо рішення впливає глобально на весь проект - то це архітектурне рішення. Тому архітектуру затверджують до того як проект почне розроблятися.
Дизайн - це локальні рішення. На відмінну від архітектурних, це рішення які приймаються на протязі розробки проекту і не впливають глобально на увесь проект. Якщо знаходиться рішення яке дуже сильно впливає глобально, і суперечить якимось частинам проекту - то це сигнал що були допущені не вірні рішення архитектури на самому початку проекту. І такі рішення вже архітектурні.
А ще э реалізація - це ще більше локальні рішення, максимально деталізовані. Наприклад якщо наприклад паттерн controller це дизайн, а то як і що буде робитися безпосередньо з цим патерном можно відносити сюди.
Паттерни дизайну - інглетон, та інщі - це все дизайн, не архітектура і не реалізація. Вони так і називаються паттерни ДИЗАЙНУ.
Но питання було про архітектуру, і кандидат який стверджує що він сіньор не знає що таке архітектура - це нонсенс, це ще не сіньор і не мідл.
Прикладами архітектури можуть бути: REST - це архітектурний стиль
Наприклад SOAP - це нульовий рівень реста (теж відносимо значить до архітектури)
Взаємодія різних компонентів системи може бути не тільки через рест, тобто можно ще висловитися що архітектура каже - як працює механізм взаємодії відправлення і отримання повідомлень між компонентами.
Відповідь, кандидата у сіньори була на рівні гірше ніж джуніор. Можливо він і вміє писати код, можливо щось і розробляв на свій розсуд. Но знань конкретних немає. На посаду джуна думаю він підійде тому що як мінімум знає синтаксис мови, хоча повинен знати.
Досвід роботи певної кількості років - не визначає рівень. Рівень визначається кількостью знань які підтверджуються досвідом. Просто працюючи декілька років не можно стати мідлом чи сіньором.
Молодець
Ухх, таке враження що зайшов на DOU в коментарі)
подобається коментар. архітектура таке широке поняття про яке можна говорити годинами. Наприклад: вибір бібліотеки для анімейшн, rest, Templates, scss чи windtail (щось не те з назвою). Я про те що якщо кожен почне тягнути, що йому подобається, і підходи до вирішення схожих проблем будуть різні, то серьозна архітектурна проблема. На мою думку архітектор має не допускати "зоопарку" і спрямовувати до вирішення задачі з існуючими засобами.
щось пан Ілля Клімов не сильно вважає що ангуляр здох) певно оновлення інших фреймворків не вважаєте потрібним читати
це типу аксіома, якщо хтось там щось не вважає?
@@bkhtrv про аксіому нічого не було написано, питання довіри і аргументів. Якщо просто сказати що щось неактуальне і 0 фактів, це так собі відповідь
@babichweb вирішив добити його другим запитанням чи прояснити значення архітектури?