Менеджер, який влаштовується в IT компанію, розуміє, що він має працювати з командою технарів, які розмовляють «своєю мовою». Розуміння технічної сторони робочих процесів допоможе менеджеру вести проєкти правильно, зменшити ймовірність помилок та вирішити велику кількість складнощів у роботі з клієнтами.
Зібрали в статтю секрети та рекомендації спікерів курсу TechMind — досвідчених менеджерів та технарів. Читайте, забирайте в скарбничку та легко проходьте найскладніші співбесіди.
12 головних пунктів, за якими ставлять питання на технічній співбесіді
Більшість технічних співбесід проходять приблизно однаково. Рекрутер може ставити різні питання, але всі вони стосуються певних тем та напрямків. Ми виділяємо 12 головних пунктів, за якими, напевно, будуть питання:
- Життєвий цикл продукту
- Методології
- Бізнес-аналіз
- Технічна документація
- Інструментарій проєкту
- Архітектура
- Клієнт-сервер
- REST
- Фреймворки, бібліотеки
- Git
- Натив/крос-платформи
- Тестування
Давайте детальніше пройдемо по кожному та розберемо, які питання можуть ставити у цих темах.
Життєвий цикл продукту
Це не стільки технічна тема, скільки перевірка загальних знань менеджера, який прагне в IT-сферу. Ви повинні впевнено підготуватися до цих питань, оскільки вже з них рекрутер зрозуміє, наскільки ви знаєтеся на темі розробки і чи зможете працювати в команді з технарями. Отже, запитання та відповіді до них:
Які етапи є у життєвому циклі ПЗ
Формування вимог до ПЗ на стадії аналізу, проєктування, реалізація, тестування, впровадження, експлуатація та супровід, зняття з експлуатації. Спочатку йде стадія, яка відповідає на запитання: «Що ми робитимемо?». Друга стадія відповідає питанням «Як ми це робитимемо?». Далі стадія реалізації задуманого проєкту, потім – тестування та впровадження. Завершальна стадія — реліз проєкту та подальша технічна підтримка.
Чим відрізняється формування вимог від проєктування
Формування вимог – це процес, при якому менеджер з’ясовує у замовника, які саме бізнес-процеси він хоче автоматизувати і що хоче отримати. На цьому етапі працюють аналітики та проєктний менеджер. Проєктування – процес, при якому збирається команда розробників та визначає, як будуть реалізовані вимоги.
Що таке підтримка
Технічна підтримка не означає, що ви відповідатимете на дзвінки клієнтів вашого замовника. Йдеться про вирішення проблемних задач у разі порушення роботи продукту. Якщо щось «ламається», перестає працювати, команда розробників має оперативно відреагувати та зробити так, щоб усе було добре.
Як відбувається зняття з експлуатації
Якщо продукт втрачає свою актуальність, або його замінюють на нове та технічне рішення, відбувається зняття з експлуатації. Розробляється план, узгоджується, після чого починається поступове зняття з експлуатації.
Приклад: на підприємстві є десктопна версія продукту, але компанія вирішила перейти на нову програму, яка працює з мобільних пристроїв.
Розробляється стратегія переходу, готується продукт, поступово переносяться всі дані, навчаються співробітники, впроваджуються нові інструменти.
Які співробітники потрібні на кожному етапі життєвого циклу
При формуванні вимог беруть участь бізнес-аналітики, на стадії проєктування ключові люди — архітектори та ліди розробників. На реалізацію проєкту потрібні програмісти, дизайнери. Тестування займаються QA інженери. Для впровадження потрібні практично всі учасники проєкту, а «зірка» проєктний менеджер. Якщо команда виділяє інженера супроводу, він відповідає за техпідтримку. Якщо його немає, то беруть участь QA, розробники та проєктний менеджер.
Методології
Вибір методології не відноситься до технічної співбесіди, але є питання, які опосередковано впливають на команду розробників. Наприклад, яку форму оплати праці вибрати. Ви можете зіткнутися з такими питаннями:
У чому різниця між Fix Price та Time&Materials
Fix Price має на увазі, що ми ведемо проєкт за певний бюджет. Компанія обговорює із замовником, що вона робить і за які гроші. Time&Materials застосовується в тому випадку, якщо клієнт має невизначеність і не знає, яким буде фінальний продукт. Він готовий викуповувати команду та платити за зроблену роботу. Time&Materials часто застосовується у гнучкій методології Scrum.
Яка модель краща
Fix Price чудово працює для проєктів, які мають суворий фіксований бюджет, і вони чітко знають, що хочуть отримати. У такому разі будь-які доповнення, зміни чи пропозиції просто не реалізуються. Time&Materials підходить для стартапів та проєктів, де складно зрозуміти точну кількість задач та як виглядатиме фінальний продукт.
Бізнес-аналіз
Проєктний менеджер часто виконує функції бізнес-аналітика. Навіть якщо цього не відбувається, на співбесідах рекрутери хочуть зрозуміти, наскільки ви знаєтеся в напрямку BA, і чи зможете виконувати його завдання. На вас чекають наступні питання:
У чому різниця між бізнес-аналітиком та системним аналітиком
Бізнес-аналітик — це людина, яка розуміється на бізнес-процесах компанії, які необхідно автоматизувати. Детально розуміється на їхніх особливостях і шукає підходи, які допоможуть покращити процеси. Вивчає вимоги, цілі та завдання замовника.
Системний аналітик перекладає інформацію з формату «Що потрібно зробити» до формату «Як це зробити». Він складає схеми, діаграми, працює з технічною командою та занурюється в архітектуру.
Що таке User Story та Use Cases
User Story – це “історія” клієнта компанії, який проходить шлях з нею від початку до кінця. Наприклад, від входу в інтернет-магазин до реєстрації, оформлення заявки та купівлі товару.
Use Cases – це докладний розгляд User Story на певному етапі. Наприклад клієнт залишив заявку на сайті. Це один із етапів User Story. Але сам кейс це заповнення конкретних полів при замовленні.
Різниця між функціональними та нефункціональними вимогами
Функціональні вимоги припускають опис того, що потрібно зробити. Вивчаються вимоги замовника. Нефункціональні вимоги стосуються нетехнічної частини. Наприклад, час відгуку, на яких пристроях має працювати програма. У нас є окремий курс з нефункціональних вимог, можете вивчити його програму на сайті.
Технічна документація
Менеджеру доводиться постійно працювати з технічною документацією. Очевидно, що на співбесіді будуть питання у цій темі.
Що таке технічне завдання
Без ТЗ – результат ХЗ. Це найголовніший документ, завдання на розробку, де описується, що потрібно зробити, як це зробити. Туди ж пишуться функціональні та нефункціональні вимоги. Технічне завдання – це документ, який визначає, що має вийти в результаті. Ці вимоги фіксуються і є основою роботи всієї команди. ТЗ дає захист як розробникам, і клієнту. Тому що кожен дотримується вимог ТЗ.
Use Cases, Test Cases
Use Cases описує сценарій взаємодії учасників. Він може бути представлений у вигляді діаграм або текстовому вигляді. Вони потрібні розробникам, тестувальникам та всій проєктній команді, щоб розуміти повну специфікацію вимог. Test Cases потрібні для того, щоб тестувальник пройшов по всьому продукту і не втратив нічого. Вони мають бути написані так, щоб будь-який тестувальник з іншого проєкту міг розібратися в них.
Де зберігати та менеджерити вимоги
Все залежить від взаємовідносин із замовником. Для цього завдання підходить Confluence, причому зручніше зберігати у себе, а не на сервері замовника. Тому що менеджер може писати ту інформацію, яку не хотів би показувати замовнику. Також можна використовувати Jira або Notion.
Інструменти проєкту
На співбесідах рекрутери хочуть дізнатися, з якими інструментами ви можете працювати. Тож треба бути готовим до питань. У цих питаннях краще підготуватися заздалегідь, хоча б поверхово вивчити інструменти, які використовує менеджер. Ви можете зіткнутися з такими питаннями:
Який Task Tracker краще вибрати
Кожен таск трекер має багато класних фіч, тому потрібно дивитися можливості інструментів та підбирати під конкретні проєкти. Часто користуються Jira. Це не означає, що вона найкраща, але цей інструмент у 33% вакансій на посаду проєктного менеджера.
Для чого потрібний Project Planning
Насамперед, щоб побудувати діаграму Ганта. Це базовий інструмент проєктного менеджера, де можна відстежувати етапи ведення проєкту, будувати його від початку остаточно. Інструменти Project Planing потрібні для того, щоб відстежувати результативність виконання завдань, дивитися скільки залишається часу та бюджету.
Архітектура
Це окрема велика тема, в якій менеджер повинен добре розумітися, якщо хоче якісно вести IT-проєкти. З архітектури у нас є окремий великий курс Delivery Mind, на якому ми докладно розуміємо, що це таке, як влаштована і навіщо менеджеру взагалі знати архітектуру. Перегляньте програму на сайті і реєструйтесь на курс, щоб вивчити архітектуру. Скажіть менеджеру, що ви прийшли зі статті про проходження технічної співбесіди, та отримаєте персональну знижку. Ну, а тут ми розберемо питання, з якими ви можете зіткнутися вже на співбесіді.
Архітектура для проєктного менеджера
PM повинен розуміти, де ми зберігаємо дані, за допомогою яких даних ми виймаємо ці дані, чи буде архітектура клієнт-серверної чи іншої. Архітектура – це схематичне пояснення, звідки і куди перетікають дані, як вони обробляються, яких етапах надаються користувачам.
На співбесідах можуть питати детальніше про архітектуру, але це тема окремої статті. У нашому блозі ви можете почитати, як виглядає архітектура та як менеджеру розуміти її.
Чим відрізняються бекенд та фронтенд
Наприклад, у нас є мобільний додаток. Те, що у вас на пристрої, це фронтенд. Те, з чим користувач взаємодіє та бачить. Бекенд – це процеси, які не видно користувачеві. Обробка даних, зберігання, передача, звернення до серверів. Цей принцип працює з будь-яким продуктом. Те, що бачить користувач – фронтенд. Все, що відбувається за дверима — це бекенд.
Що означає тонкий клієнт та товстий клієнт
Ні, це не про обсяги талії. На цьому питанні «валяться» всі, хто не має технічної освіти та скілів. Тому ми рекомендуємо прокачувати навички на курсі Techmind. Ви отримаєте практику та знання, які допоможуть проходити співбесіди і не потрапляти на такі прийоми рекрутерів. Тепер до питання.
“Товщина” клієнта залежить від того, скільки логіки знаходиться на клієнті. Якщо у програми мінімальна логіка на клієнті, а основна — на сервері, то утворюється тонкий клієнт. Якщо при завантаженні програми обробляється відразу велика кількість даних на клієнті, то «товщина» збільшується.
Різниця між ними у варіантах обробки даних. Товсті клієнти переважно працюють з інформацією на основі власних програмних можливостей, тоді як тонкі клієнти застосовують ПЗ центрального сервера для обробки. Всі браузери та веб-додатки, онлайн ігри – це тонкі клієнти. А ось Microsoft Outlook або Office 365 – товсті.
Що таке база даних
Це місце, де зберігаються та обробляються всі дані. Подані у вигляді таблиць, в яких поділяються дані на стовпці та рядки. Наприклад, ім’я користувача, номер телефону, пошта. Всі таблиці пов’язані між собою, тому при запиті одних даних можна отримати й іншу інформацію.
DNS – що це таке
На співбесідах часто наводять таку ситуацію: користувач вводить якісь дані в пошуковий рядок браузера та натискає кнопку «Знайти». Як відбувається весь процес? На це питання можна відповідати детально, але рекрутер чекає на пояснення, що таке DNS.
Якщо є фізичні сервери, на яких розташована інформація, до них потрібно отримати доступ. Кожен сервер має ім’я, яке виглядає у вигляді IP-адреси. Щоб не запам’ятовувати велику кількість цифр, було розроблено DNS систему. DNS має читабельний вигляд та ієрархічну структуру, завдяки чому користувач надає запит та отримує доступ до інформації. На курсі Techmind ми докладно розповідаємо, як працює DNS та бази даних.
Навіщо потрібна реплікація
Реплікація потрібна, щоб робити копії бази даних. Сама база даних зберігається на сервері, але що з нею станеться, якщо з сервером щось станеться? Згорить, пошкодиться, буде зламано? База даних загубиться. Роки роботи можуть зникнути. Уникнути цього допомагає реплікація. Робляться копії баз даних та розміщуються на різних серверах та локальних носіях. Регулярно БД оновлюється, і з періодичністю, що настроюється, репліки поповнюються оновленою інформацією.
У чому різниця між мікросервісом та монолітом
Моноліт – це централізована обробка запитів, а мікросервіси – індивідуальна обробка запитів. Монолітна програма виглядає, як єдиний загальний модуль, в якому відбувається вся робота. Архітектура мікросервісу має кілька невеликих служб, що розгортаються.
Що краще – не можна однозначно сказати, бо кожен має свої особливості. Монолітна архітектура вважається традиційнішою, незалежною від інших сервісів, має єдину основу коду. Щоб змінити щось, необхідно оновлювати весь стек. На початкових етапах проєкту це вигідне рішення, оскільки розгортання відбувається легше. Мікросервіс легше масштабувати, тестування та оновлення відбуваються швидше та дешевше, додаток стає більш гнучким.
Клієнт-сервер
Заглиблюючись у технічні знання, проєктний менеджер повинен розуміти, що таке клієнт-сервер. Ось найчастіші питання, які ставлять на цю тему:
Що таке клієнт-сервер
Це елементи архітектури, які мають на увазі, що є клієнтська частина, яка взаємодіє з користувачем, а є серверна частина – логіка програми. Клієнтська частина відповідає за те, як показати користувачеві дані, яким кольором вивести віконця, де буде кнопка. Серверна частина відповідає за збирання та зберігання даних, обробку запитів та логіку взаємодії користувача з продуктом.
Навіщо потрібний REST
Це набір певних правил, які показують, як потрібно спілкуватися між клієнтом та сервером. Це якийсь «транспорт», яким передаються дані. Клієнт запитує сервера якісь дані. Цей запит йде на сервер, і він віддає їх. REST – це зведення правил, що допомагає серверу та клієнту розуміти один одного.
Куди виносити логіку
Тут немає універсальної відповіді. Одні вважають, що краще всю логіку вибудовувати на бекенді, а клієнт не давати навантаження. Інші стверджують зовсім навпаки. Відповідь, яка сподобається: все залежить від того, що ми робимо і в якому середовищі знаходимося. Можна вносити все на клієнта, але все, що пов’язане з безпекою, вибудовувати на бекенд. Складні обчислення пов’язані з оплатою, теж краще залишати в бекенд.
REST
У двох словах ми вже сказали, що REST – це певний стиль взаємодії між клієнтом та сервером. Він допомагає налагодити комунікацію між запитом та отриманням даних. У темі REST можуть виникнути такі питання:
Що таке json, xml, html
Це формати файлів, якими обмінюється клієнт та сервер. Вони не перераховують усі дані через кому, їх потрібно структурувати. І це є варіанти структури. Json використовується для обміну даними в мобільних пристроях, xml, html працюють у Інтернеті.
Методи update, delete, get, post
Мобільні девайси взаємодіють із бекендом якимись запитами. Умовно кажучи, це посилання та якісь додаткові поля. Ми йдемо на посилання та даємо одну з команд: update, delete, get, post.
- get – ми щось забираємо, наприклад «Дай список контактів»
- post — кажемо, що треба щось додати, наприклад, нового друга у соціальній мережі
- delete — цією командою ми говоримо, що потрібно видалити дані, наприклад файл із телефону
- update – оновлення файлу: перейменування, внесення нових даних.
Ці чотири команди потрібно знати детально. Рекомендуємо почитати окремо. На курсі Techmind ми розбираємо їх докладніше та навчаємо, як працювати з цими командами.
Фреймворки та бібліотека
На цю тему нетехнічних фахівців запитують досить часто. Тому краще заздалегідь підготуватися та заглибитись у знання фреймворків, розібратися з бібліотеками. Ось головне питання, яке можуть поставити:
У чому різниця між фреймворком та бібліотекою
Фреймворк — це структура з кодом, яка дозволяє зручно щось розробляти. Бібліотека це теж структура з кодом, але вона береться ззовні. Її беруть як готове рішення для розробки. Здається, що це більш зручний та легкий спосіб розробки. Але бібліотека — це стороннє рішення, яке складно доопрацьовувати.
Наприклад, потрібен календар. Можна взяти готове рішення з бібліотеки та впровадити додаток. Але якщо замовник попросить додати кольори до календаря, змінити шрифт, змінити початок тижня не з неділі, а з понеділка, правити його буде складно. Бібліотека підходить для типових та швидких рішень.
Git
Git – це система управління версіями. У нас є розробники, які постійно допрацьовують, впроваджують нові фічі. Щоб не заплутатися та отримати строгу структуру, вводиться система керування версіями. По ній нетехнічному фахівцю можуть ставити такі питання:
Як працює Git
Щоб не втратити готових результатів, створюється головна гілка – Майстер. Це вже затверджені робочі рішення, які підходять для релізу. Далі приходить ідея впровадити нову фічу. У майстрі фіксується «відправна точка», робиться фіча, тестується та перевіряється. У Git вона йде окремою гілкою. У ній ведеться технологія, пов’язана тільки з цією новою фічею. Коли вона зроблена, протестована і прийнято рішення впроваджувати її, вона мерзне в Майстер.
Навіщо потрібний Git
Щоб не заплутатися. Найскладніша гілка – розробників. Там відбуваються основні процеси, з’являється багато багів у ході роботи та відстежувати їх стає складно. Але Git допомагає вибудувати гілки так, щоб було наочно зрозуміло, що вже працює, а що потребує доопрацювання.
Що таке merge, push, pull
Merge це процес злиття коду з однієї гілки в іншу. Мерджити – переносити код. Коли вам зрозуміло, що фіча працює, вона додається до основної версії Git.
Push – процес, коли окремий шматок коду потрібно додати в якусь гілку. Pull – зворотний процес, коли потрібно щось прибрати з гілки з кодом.
Крос-платформа
У сучасній розробці все рідше використовуються лише десктопні або мобільні версії продукту. Але окремо розробляти під кожну систему продукт досить дорого. Тому часто використовується крос-платформа. Нетехнічний фахівець повинен розуміти, що це за процеси та як вони влаштовані.
Що таке натив
Якщо розробка ведеться рідною для певної платформи, це називається натив. Наприклад, якщо виробляється продукт під операційну систему iOs, використовується Swift.
Що таке крос-платформа
Це процес, при якому програма розробляється з кодовою базою, яка працює на різних операційних системах. Тобто додаток працюватиме як на «яблуках», так і на андроїдах. Незважаючи на те, що це здається вигіднішим, крос-платформні рішення мають досить багато недоліків і не завжди працюють якісно. Під кожен проєкт визначається стек технологій, і при розробці архітектури вирішується використовувати натив або крос-платформу.
Що дешевше
Для швидкого запуску стартапу з якоюсь функціональністю дешевше зробити крос-платформне рішення. Якщо потрібна хороша функціональність, вигідніше робити її на нативі. Тому що на крос-платформі доведеться «натягувати» багато рішень, у результаті це займе більше часу та сил. З точки зору загальної оцінки, дешевша крос-платформа. Але не завжди вона підходить для проєктів.
Тестування
Які типи тестування бувають
Функціональне тестування – ми беремо та тестуємо конкретну функціональність. Смоук тестування застосовується, коли виявляється маленький баг, який впливає функціональність. Регресійне тестування це повний процес перевірки на баги всього коду, як правило, застосовується перед релізом продукту.
Тестування навантаження застосовується для складних продуктів з нефункціональними вимогами, пов’язаними з навантаженням. Наприклад, програма має працювати при одночасному навантаженні в 20 000 користувачів.
Інтеграційне тестування застосовується тоді, коли сервер вже написано, а клієнт ще змінюється. Автотести працюють так: кодуються певні дії чи запити, та перевіряються відповіді. Часто застосовується під час інтеграційного тестування.
Що таке пріоритети
Кожному багу надають статус, який визначає важливість тестування та виправлення. Як правило, використовуються статуси “Критичний”, “Високий”, “Середній”, “Низький”, “Блокер”. При критичному статусі продукт не може працювати, поки його не виправлять, але функціональність можна перевіряти. Блокер – це статус, при якому неможливе подальше проведення тестів, доки він не буде усунений.
Висновок
Це не всі питання, які можуть ставити менеджеру на технічній співбесіди. Щоб влаштуватися в IT компанію, необхідно розуміти робочі процеси, термінологію та мову технарів. Щоб вивчити все це однієї дуже корисної статті недостатньо. Тому ми створили курс TechMind для нетехнічних фахівців, які працюють в IT. За декілька місяців ви навчитеся керувати командою розробників, правильно ставити завдання, вести проєкти, підбирати оптимальні рішення та уникати помилок. Подивіться програму курсу та зрозумійте, що він зроблений для повного освоєння технічних процесів.
Записуйтесь на курс TechMind, прокачуйте навички та з легкістю проходьте технічні співбесіди. А якщо скажете менеджеру, що ви читали статтю про 37 питань на співбесіді – отримайте додаткову персональну знижку;)