Дуже круто, що задаєш не просто теоретичні питання, а питання «на подумати», так справді можна побачити чи кандидат не просто завчив, а розуміє концепції.
Романе, я дозволю собі зробити Вам зауваження. Не втримаюсь. Знання - то одне. Але навчіться мовчати. Не треба щосекунди показувати, який ви крутий, ллючи воду, ще й не ту і не туди. Ефект протилежний. Лютий трешак. Не перебивайте людей!! Тупо навчіться вести виховану розмову. Довільну. Вас занадто важко витримати в розмові. Я зупиняла відео разів з -надцять, щоб видихнути і заспокоїтись. Працювати в команді - це не лише знання. Їх можна набути з часом і досвідом. З людиною має бути приємно і конструктивно розмовляти. Олексі моя повага за професіоналізм.
20:40 Backlog refinement це про вимоги та acceptance tests. Sprint planning це про технічну декомпозицію та оцінку. Але в Scrum як і в XP є така штука як R&D таска, або Spike в XP (Extreme programming).
На практиці, на жаль, багато факторів заважають нам зробити "красивий" процес. Але ми можемо адаптуватися та зробити навіть з "кривенького" процесу доволі ефективний та навіть "приємний".
Олекса, Ви круть💪, дуже цікаво і корисно. Дуже дякую за такий шторм мозку, коли під час вашого запитання стараєшся сам відповісти😶🌫️, і потім ще черпаєш знання з Вашого коригування відповіді кандидата. Щиро дякую 😊
Дякую, ще декілька пунктиків до надолуження знань. Роман - відчувається white box, та досвід в розробці. Олекса - окрема подяка за нові горизонти. Чекаємо наступних сміливців :)
@@qa.ukraineще б, до такого інтерв'юера :) одне задоволення. Хоча в мене і маленький досвід, але розумію - що Олекса - дуже терпляча людина :) Лише очі видають :)
Я б назвала це інтервʼю - « диявол в дрібницях». Дуже корисне для початківців, за це велике дякую!! ❤ Важко трохи було слухати, бо склалось враження, що Олекса питав, і просто чекав аби відповісти самому, Роман дуже молодець! 💪 дивилась і розуміла, шо без досвіду роботи - нема сенсу йти на інтервʼю такого плану, бо питання на розуміння, а не на знання, як Олекса сказав: теорія-питання памʼяті) А розуміння приходить лише з досвідом.. практикою.. цікаво було б послухати інтервʼю на тріні)
Можна підготуватися й без досвіду, хоча зараз повно різних програм для здобуття практики. Проблема багатьох не у практиці, а у відсутності базових знань, а без них спеціальні знання просто не утримуються в голові. Питання не стільки у практиці, скільки у тому, що для світчера швидких курсів (3 місяці) замало. То ж просто вчиться далі.
@@qa.ukraine я знаю який курс йому треба відкрити! Софт скіллний!)) Щоб ось так само спокійно задавати питання, відповідати, дискутувати і навіть ніііжно і філігранно валити людей)) Що аж приємно і ніхто навіть не за підозрює 😋 лиш очі іноді видають.
32:00 Хлопець має бекграунд програміста, тому розширює діяльність тетсувальника. Як на мене тестувальник має забути про ідею, що він точно показує причину помилки, бо це може бути не так і збити програміста. Прогер сам робить пошук. Тестувальник може показати якість закономірності хіба що.
It depends. Ми радимо аналізувати кожен проєкт та сетап команди, включно з рівнем експертизи розробників. Але погоджуємося, що тестувальник має залишатися тестувальником, навіть коли він частково кодер.
11:00 Мета тестування знайти баги. Позитивний тест той, який виявив баг. Що є багом визначають вимоги. Для програміста, починати роботу коли немає Definition of done - наївно. P.S: Принципи тестування описані у відомій книзі "Art of software testing" by Glenford Myers. Не завчайте принципи з сумнівних джерел.
Знаходити баги - лише один з поглядів та підходів до тестування, але не єдиний. Вимоги бувають у різних формах, не завжди це специфікація, особливо коли мова про scrum. Мати чіткий DoD - згодні, було б гарно, якби частіше на це звертали увагу та означали.
@@viktor-h3s Дивлячись як ви розумієте "забезпечення якості ПЗ". Жоден тестувальник принципово не може гарантувати, що баги не дойдуть до кінцевого користувача і що якість ПЗ сподобається користувачу. Отже, що ж тестувальники гарантують?! Відповідь: Нічого. Вони тільки збільшують ймовірність, що програмне забезпечення буде працювати коректно. Не вірити мені, читайте статтю на Dou про фундаментальні принципи тестування та вже культову книгу "The Art of software testing". Позитивний тест - тест, який виявив баг. Приклад. Розробник: Потрібно покрити автоматизованими тестами наш код? Менеджер: Навіщо? Наївний розробник: Щоб гарантувати відсутність багів. Професіонал: Щоб швидше робити ретест й регресійне тестування та збільшити надійність ПЗ.
@@yarikterletsky2863 Можна :) Та ми думаємо, що це ок, не любимо завчання, любимо міркування від кандидатів. Але Олексі скажемо, щоб менше рухав бровами 😅
@@qa.ukraine звичайно, міркування кандидатів це важливо) Олекса хай залишається таким як є) цікава і толкова не тільки сама співбесіда, а і емоції, очі і рухи бровами Олекси)
Як важко слухати цього джуна........ вибачте, але це дуууже важко.... коли людина не розуміє питання, але не може зупинитись триндіти щось "не туди".... 🤦🏼♀️ перебиває Алексу... а потім ще й "так, так, я так і хотів сказати"... це важко слухати.... В Алекси терплячка рівня бох
Ми всі такі різні, так? :) Інтерв’юери також, наприклад, досі ще можна зустріти тих, хто любить проводити стрес інтерв’ю для не синйорних позицій. Тут вже на кого потрапиш.
Залишити заявку на одну з наших тренувальних вакансій ось тут: qaukraine.online/vakansii-dlia-onlajn-spivbesid/ Якщо там нічого вам не личитиме, то можна написати просто Олексі t.me/oleksamashchyts або www.linkedin.com/in/oleksa-mashchyts/
Дуже гарна співбесіда насправді. Сподобався підхід розгортання базових та звичних речей, щоб зрозуміти хід думки респондента. Не вистачає хіба що таймкодів
Дякуємо за відгук! Ми хочемо показати не лише формат питання-відповіді, але й те, що співбесіди бувають різними й не вгадаєш, який стиль попадеться вам. Але дивлячись на різні співбесіди можна підготуватися краще.
Якби ж і у житті було так: що у вакансії написано - того компанія від тебе і очікує і це й буде +- головними темами співбесіди. Вже не раз стикалася із тим, що у вакансії щось не дописали, а це потім виявляється вкрай важливим для прийняття рішення щодо найму. Наскільки б усе було простіше, якби інтервʼюєри мислили так, як і Олекса
Так, це завжди трохи лотерея. Але не варто сумувати, просто існують "твої" та "не твої" вакансії. Навіть синйори провалюють співбесіди, хоча вони й синйори.
Новичков много, а вот практики мало. Многие талантливые не попадают в тему из-за отсутсвия практики. Хотя достаточно 1 мес и человек заткнул бы за пояс многих.
О, важка тема. З одного боку різні люди підходять різним людям. Тобто є умовно "свої" типажі. З іншого, якщо людина "не ваша", а ви маєте можливість обирати, то ймовірно, краще так й зробити. Все стає складнішим (та цікавішим), якщо ви менеджер.
Я б его не взял просто потому что он очень скользкий. Знанио очень поверхностные, но фиг бы с тем, это всё учится. А вот то что он выкручивается, всё вокруг да около, постоянно пытается угадать ... Такой сотрудник слишком дорого обойдётся в будущем
Дуже велике прохання, зроби відос інтервʼю з middle qa!
У нас вже навіть дві вакансії на порталі для мідлів є. Збираємо заявки. In progress.
Дуже круто, що задаєш не просто теоретичні питання, а питання «на подумати», так справді можна побачити чи кандидат не просто завчив, а розуміє концепції.
Згодні. Взагалі, мета показати різні стилі та підходи до співбесід.
За "контекстне меню" окреме дякую))
Ці співбесіди "на вагу золота" 😅 😍😍😍
Це одне з «фірмових» питань Олекси новачкам.
Романе, я дозволю собі зробити Вам зауваження. Не втримаюсь. Знання - то одне. Але навчіться мовчати. Не треба щосекунди показувати, який ви крутий, ллючи воду, ще й не ту і не туди. Ефект протилежний. Лютий трешак. Не перебивайте людей!! Тупо навчіться вести виховану розмову. Довільну. Вас занадто важко витримати в розмові. Я зупиняла відео разів з -надцять, щоб видихнути і заспокоїтись. Працювати в команді - це не лише знання. Їх можна набути з часом і досвідом. З людиною має бути приємно і конструктивно розмовляти. Олексі моя повага за професіоналізм.
20:40 Backlog refinement це про вимоги та acceptance tests. Sprint planning це про технічну декомпозицію та оцінку. Але в Scrum як і в XP є така штука як R&D таска, або Spike в XP (Extreme programming).
На практиці, на жаль, багато факторів заважають нам зробити "красивий" процес. Але ми можемо адаптуватися та зробити навіть з "кривенького" процесу доволі ефективний та навіть "приємний".
Олекса, Ви круть💪, дуже цікаво і корисно. Дуже дякую за такий шторм мозку, коли під час вашого запитання стараєшся сам відповісти😶🌫️, і потім ще черпаєш знання з Вашого коригування відповіді кандидата. Щиро дякую 😊
Круто читати такі відгуки, значить, ми все правильно робимо. Дякуємо, що дивитеся!
Дякую, ще декілька пунктиків до надолуження знань. Роман - відчувається white box, та досвід в розробці. Олекса - окрема подяка за нові горизонти. Чекаємо наступних сміливців :)
Вже черга, підписуйте та дивіться :)
@@qa.ukraineще б, до такого інтерв'юера :) одне задоволення. Хоча в мене і маленький досвід, але розумію - що Олекса - дуже терпляча людина :) Лише очі видають :)
Корисний контент, є над чим подумати, дякую за цікаве відео
Дякуємо. Приходьте ще, будуть співбесіди в різних стилях для різних рівнів.
Я б назвала це інтервʼю - « диявол в дрібницях». Дуже корисне для початківців, за це велике дякую!! ❤
Важко трохи було слухати, бо склалось враження, що Олекса питав, і просто чекав аби відповісти самому, Роман дуже молодець! 💪 дивилась і розуміла, шо без досвіду роботи - нема сенсу йти на інтервʼю такого плану, бо питання на розуміння, а не на знання, як Олекса сказав: теорія-питання памʼяті) А розуміння приходить лише з досвідом.. практикою.. цікаво було б послухати інтервʼю на тріні)
Можна підготуватися й без досвіду, хоча зараз повно різних програм для здобуття практики. Проблема багатьох не у практиці, а у відсутності базових знань, а без них спеціальні знання просто не утримуються в голові. Питання не стільки у практиці, скільки у тому, що для світчера швидких курсів (3 місяці) замало. То ж просто вчиться далі.
Олексі респект! Бог софт скіллс единий і неповторний.
Не вперше чуємо вже, цікаво :)
Дякуємо за відгук!
@@qa.ukraine я знаю який курс йому треба відкрити! Софт скіллний!)) Щоб ось так само спокійно задавати питання, відповідати, дискутувати і навіть ніііжно і філігранно валити людей)) Що аж приємно і ніхто навіть не за підозрює 😋 лиш очі іноді видають.
Дякую, дуже цікаве інтерв'ю
Дякуємо за відгук та приходьте ще!
32:00 Хлопець має бекграунд програміста, тому розширює діяльність тетсувальника. Як на мене тестувальник має забути про ідею, що він точно показує причину помилки, бо це може бути не так і збити програміста. Прогер сам робить пошук. Тестувальник може показати якість закономірності хіба що.
It depends. Ми радимо аналізувати кожен проєкт та сетап команди, включно з рівнем експертизи розробників. Але погоджуємося, що тестувальник має залишатися тестувальником, навіть коли він частково кодер.
52:14 Альо! - нова стоп кнопка в Скрамі)
Ахха 😆
Беремо на озброєння!
11:00 Мета тестування знайти баги. Позитивний тест той, який виявив баг. Що є багом визначають вимоги. Для програміста, починати роботу коли немає Definition of done - наївно.
P.S: Принципи тестування описані у відомій книзі "Art of software testing" by Glenford Myers. Не завчайте принципи з сумнівних джерел.
Знаходити баги - лише один з поглядів та підходів до тестування, але не єдиний. Вимоги бувають у різних формах, не завжди це специфікація, особливо коли мова про scrum. Мати чіткий DoD - згодні, було б гарно, якби частіше на це звертали увагу та означали.
@@qa.ukraine Добре, я не критикую, а доповнюю. Може хтось поклацає мої timecodes. Олекса молодець)
Мета тестування - Забезпечення якості пз , а не знайти баги, пошук багів це всього лиш одна із цілей
@@viktor-h3s
Дивлячись як ви розумієте "забезпечення якості ПЗ".
Жоден тестувальник принципово не може гарантувати, що баги не дойдуть до кінцевого користувача і що якість ПЗ сподобається користувачу. Отже, що ж тестувальники гарантують?! Відповідь: Нічого. Вони тільки збільшують ймовірність, що програмне забезпечення буде працювати коректно.
Не вірити мені, читайте статтю на Dou про фундаментальні принципи тестування та вже культову книгу "The Art of software testing".
Позитивний тест - тест, який виявив баг.
Приклад.
Розробник: Потрібно покрити автоматизованими тестами наш код?
Менеджер: Навіщо?
Наївний розробник: Щоб гарантувати відсутність багів.
Професіонал: Щоб швидше робити ретест й регресійне тестування та збільшити надійність ПЗ.
@@viktor-h3s Black bock testing і забезпечення якості))) Розсмішили 😊
По Олексиним очам і емоціям одразу можна зрозуміти туди чи не туди відповідає на запитання співбесідник)) це вже свого роду як підсказка)
Ахха)) Тепер питання наступне - чи користуються цим кандидати? 🙂
@@qa.ukraine хто кмітливий і помітив це - має користуватись)) я б користувався) це вже можна назвати тестовим завданням на уважність для справжніх QA)
@@yarikterletsky2863 Можна :) Та ми думаємо, що це ок, не любимо завчання, любимо міркування від кандидатів. Але Олексі скажемо, щоб менше рухав бровами 😅
@@qa.ukraine звичайно, міркування кандидатів це важливо) Олекса хай залишається таким як є) цікава і толкова не тільки сама співбесіда, а і емоції, очі і рухи бровами Олекси)
@@yarikterletsky2863 😃Гаразд
Як важко слухати цього джуна........ вибачте, але це дуууже важко.... коли людина не розуміє питання, але не може зупинитись триндіти щось "не туди".... 🤦🏼♀️ перебиває Алексу... а потім ще й "так, так, я так і хотів сказати"... це важко слухати.... В Алекси терплячка рівня бох
Ми всі такі різні, так? :)
Інтерв’юери також, наприклад, досі ще можна зустріти тих, хто любить проводити стрес інтерв’ю для не синйорних позицій. Тут вже на кого потрапиш.
А як записатись на таку інтерв'юшку?
Я jun qa, який в пошуках роботи😊
Залишити заявку на одну з наших тренувальних вакансій ось тут: qaukraine.online/vakansii-dlia-onlajn-spivbesid/
Якщо там нічого вам не личитиме, то можна написати просто Олексі t.me/oleksamashchyts або www.linkedin.com/in/oleksa-mashchyts/
Дуже гарна співбесіда насправді. Сподобався підхід розгортання базових та звичних речей, щоб зрозуміти хід думки респондента.
Не вистачає хіба що таймкодів
Дякуємо за відгук! Ми хочемо показати не лише формат питання-відповіді, але й те, що співбесіди бувають різними й не вгадаєш, який стиль попадеться вам. Але дивлячись на різні співбесіди можна підготуватися краще.
Якби ж і у житті було так: що у вакансії написано - того компанія від тебе і очікує і це й буде +- головними темами співбесіди. Вже не раз стикалася із тим, що у вакансії щось не дописали, а це потім виявляється вкрай важливим для прийняття рішення щодо найму. Наскільки б усе було простіше, якби інтервʼюєри мислили так, як і Олекса
Так, це завжди трохи лотерея. Але не варто сумувати, просто існують "твої" та "не твої" вакансії. Навіть синйори провалюють співбесіди, хоча вони й синйори.
Новичков много, а вот практики мало. Многие талантливые не попадают в тему из-за отсутсвия практики. Хотя достаточно 1 мес и человек заткнул бы за пояс многих.
Як мама, то я би добре вилупила Романа і казала «не ганьби мене своєю поведінкою».
Олекса дуже схожий манерою спілкування на українського генетика Олександра Коляду)
Отакої! :)
Чесно кажучи не дуже імпонує Роман, складається враження, що людина хоче когось здивувати..з ноткою нарцисизму
О, важка тема. З одного боку різні люди підходять різним людям. Тобто є умовно "свої" типажі. З іншого, якщо людина "не ваша", а ви маєте можливість обирати, то ймовірно, краще так й зробити. Все стає складнішим (та цікавішим), якщо ви менеджер.
Я б его не взял просто потому что он очень скользкий. Знанио очень поверхностные, но фиг бы с тем, это всё учится. А вот то что он выкручивается, всё вокруг да около, постоянно пытается угадать ... Такой сотрудник слишком дорого обойдётся в будущем