Меню

Запитання та відповіді на інтерв’ю SDET (повне керівництво)

sdet interview questions

Спробуйте Наш Інструмент Для Усунення Проблем

Прочитайте цей повний посібник для інженера-розробника програмного забезпечення в тестових інтерв’ю, щоб дізнатись формат та відповіді на запитання інтерв’ю SDET, задані в різних турах:

У цьому підручнику ми дізнаємося про деякі поширені запитання щодо інтерв’ю для ролей SDET. Ми також побачимо загалом загальну схему інтерв’ю та поділимося деякими порадами щодо досягнення успіху в інтерв’ю.

Ми будемо використовувати мову Java для проблем кодування цього підручника, однак, більшість підручників SDET є мовними агностиками, а інтерв'юери, як правило, гнучкі щодо мови, яку кандидат вирішив використовувати.

Запитання та відповіді на інтерв’ю SDET

Що ви дізнаєтесь:

Посібник з підготовки до інтерв’ю SDET

Інтерв’ю SDET у більшості провідних компаній-виробників дуже схожі на те, як проводяться співбесіди для ролей розвитку. Це пояснюється тим, що SDET також повинні знати і розуміти майже все, що знає розробник.

Різниця полягає у критеріях, за якими оцінюється співбесідник SDET. Інтерв'юери для цієї ролі шукають навички критичного мислення, а також те, чи має особа, з якою беруть інтерв'ю, практичний досвід кодування та чи орієнтується на якість та деталі.

Ось декілька моментів, на яких хтось, хто готується до співбесіди SDET, повинен в основному зосередитися:

де знайти відео віртуальної реальності
  • Оскільки в більшості випадків ці співбесіди є агностичними щодо технологій / мови, отже кандидати повинні бути готові вивчати нові технології (та використовувати наявні навички) у міру необхідності.
  • Повинні володіти хорошими комунікативними та командними навичками, оскільки сьогодні ролі SDET вимагають спілкування та співпраці на різних рівнях з багатьма зацікавленими сторонами.
  • Має базове розуміння різних концепцій проектування системи, масштабованості, паралельності, нефункціональних вимог тощо.

У розділах нижче ми спробуємо зрозуміти загальний формат інтерв’ю разом із деякими зразками запитань.

Формат інженера з розробки програмного забезпечення в тестовому інтерв’ю

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

Але тема інтерв’ю, як правило, базується на наведених нижче пунктах:

  • Телефонна дискусія: Розмова з менеджером та / або членами команди, яка зазвичай є скринінговим туром.
  • Письмовий тур: З тестуванням / тестуванням корпусу конкретні питання.
  • Раунд знання кодування: Прості питання кодування (мовний агностик) і кандидату пропонується написати код виробничого рівня.
  • Розуміння основних концепцій розвитку: Як концепції OOPS, ТВЕРДІ Принципи тощо.
  • Розробка та розробка фреймворку автоматизації тестів
  • Мови сценаріїв: Селен, Python, Javascript тощо
  • Culture Fit / HR обговорення та переговори

Запитання та відповіді на інтерв’ю SDET

У цьому розділі ми обговоримо деякі зразки запитань разом із детальними відповідями для різних категорій, які задаються більшістю компаній-виробників, які наймають на ролі SDET.

Володіння кодуванням

У цьому раунді даються прості завдання кодування для написання вибраною мовою. Тут інтерв'юер хоче оцінити вміння за допомогою конструкцій кодування, а також обробляти такі речі, як сценарії ребер та перевірка нуля тощо.

Іноді інтерв’юери можуть також попросити записати модульні тести для написаної програми.

Давайте розглянемо деякі приклади проблем.

Q # 1) Написати програму для обміну 2 числами без використання третьої (тимчасової) змінної?

Відповідь :

Програма для обміну двома числами:

public class SwapNos { public static void main(String() args) { System.out.println('Calling swap function with inputs 2 & 3'); swap(2,3); System.out.println('Calling swap function with inputs -3 & 5'); swap(-3,5); } private static void swap(int x, int y) { System.out.println('values before swap:' + x + ' and ' + y); // swap logic x = x + y; y = x - y; x = x - y; System.out.println('values after swap:' + x + ' and ' + y); } }

Ось результат вищенаведеного фрагмента коду:

output-swap2nos 8 нових 1

У наведеному вище фрагменті коду важливо зазначити, що інтерв'юер спеціально попросив поміняти місцями 2 номера без використання третьої тимчасової змінної. Крім того, важливо, щоб перед подачею рішення завжди рекомендувалося пройти (або пропустити) код щонайменше на 2-3 введення. Давайте спробуємо отримати позитивні та негативні значення.

Позитивні значення: X = 2, Y = 3

// swap logic - x=2, y=3 x = x + y; => x=5 y = x - y; => y=2 x = x - y; => x=3 x & y swapped (x=3, y=2)

Негативні значення: X = -3, Y = 5

// swap logic - x=-3, y=5 x = x + y; => x=2 y = x - y; => y=-3 x = x - y; => x=5 x & y swapped (x=5 & y=-3)

Q # 2) Написати програму для зворотного числа?

Відповідь: Зараз заява про проблему може спочатку виглядати лякаючою, але завжди доцільно попросити пояснити запитання інтерв'юеру (але не багато деталей). Інтерв'юери можуть надати підказки про проблему, але якщо кандидат задає багато питань, це також вказує на те, що кандидат не дає достатньо часу, щоб добре зрозуміти проблему.

Тут проблема вимагає, щоб кандидат також зробив деякі припущення - наприклад, число може бути цілим числом. Якщо вхід 345, тоді вихід повинен бути 543 (що є зворотним значенням 345)

Давайте подивимось фрагмент коду для цього рішення:

public class ReverseNumber { public static void main(String() args) { int num = 10025; System.out.println('Input - ' + num + ' Output:' + reverseNo(num)); } public static int reverseNo(int number) { int reversed = 0; while(number != 0) { int digit = number % 10; reversed = reversed * 10 + digit; number /= 10; } return reversed; } }

Вихід для цієї програми проти введення : 10025 - Очікуваним буде : 52001

вихід-реверс Число 6 нових

Q # 3) Написати програму для обчислення факторіалу числа?

Відповідь: Factorial - одне з найбільш часто задаваних питань майже у всіх інтерв’ю (включаючи інтерв’ю розробників)
Для співбесід з розробниками більша увага приділяється таким концепціям програмування, як динамічне програмування, рекурсія тощо, тоді як з точки зору Технічного розробника програмного забезпечення важливо обробляти такі крайові сценарії, як максимальні значення, мінімальні значення, від’ємні значення тощо та підхід / ефективність. важливі, але стають другорядними.

Давайте розглянемо програму для факторіалу з використанням рекурсії та for-loop з обробкою від’ємних чисел і поверненням фіксованого значення say -9999 для від’ємних чисел, яку слід обробляти в програмі, що викликає функцію факторіалу.
Зверніться до фрагмента коду нижче:

public class Factorial { public static void main(String() args) { System.out.println('Factorial of 5 using loop is:' + factorialWithLoop(5)); System.out.println('Factorial of 10 using recursion is:' + factorialWithRecursion(10)); System.out.println('Factorial of negative number -100 is:' + factorialWithLoop(-100)); } public static long factorialWithLoop(int n) { if(n <0) { System.out.println('Negative nos can't have factorial'); return -9999; } long fact = 1; for (int i = 2; i <= n; i++) { fact = fact * i; } return fact; } public static long factorialWithRecursion(int n) { if(n < 0) { System.out.println('Negative nos can't have factorial'); return -9999; } if (n <= 2) { return n; } return n * factorialWithRecursion(n - 1); } }

Давайте подивимося вихід для - факторіал з використанням циклу, факторіал з використанням рекурсії та факторіал від'ємного числа (що поверне значення за замовчуванням -9999)

вихід-факторіал 4 нові

Q # 4) Напишіть програму, щоб перевірити, чи має даний рядок збалансовані дужки?

Відповідь:

Підхід - Це дещо складна проблема, коли інтерв’юер шукає дещо більше, ніж знання просто конструкцій кодування. Тут сподівання полягає в тому, щоб продумати та використовувати відповідну структуру даних для даної проблеми.

Багато з вас можуть почуватися заляканими подібними проблемами, оскільки деякі з вас, можливо, їх не чули, і тому, навіть якщо вони прості, вони можуть здаватися складними.

Але загалом для таких проблем / питань: Наприклад, у поточному питанні, якщо ви не знаєте, що таке збалансовані дужки, ви можете дуже добре запитати інтерв’юера, а потім працювати над вирішенням, замість того, щоб потрапляти в глуху зону.

Давайте подивимося, як підійти до рішення: Зрозумівши, що таке збалансовані дужки, ви можете подумати про використання правильної структури даних, а потім почати писати алгоритми (кроки) перед тим, як розпочати кодування рішення. Багато разів самі алгоритми вирішують безліч крайових сценаріїв і дають багато ясності щодо того, як буде виглядати рішення.

Давайте розглянемо рішення:

Збалансовані дужки - це перевірка на даний рядок, який містить дужки (або дужки), повинен мати однаковий рахунок відкриття та закриття, а також позиційно добре структурований. Для контексту цієї проблеми ми будемо використовувати збалансовані дужки як - ‘()’, ‘()’, ‘{}’ - тобто вказаний рядок може мати будь-яку комбінацію цих дужок.

Зверніть увагу, що перед спробою вирішити проблему, добре пояснити, чи рядок міститиме лише символи дужок або будь-які цифри тощо (оскільки це може трохи змінити логіку)

Приклад: Даний рядок - '{() {} ()} - це збалансований рядок, оскільки він структурований і не має рівного числа закриваючих і відкриваючих дужок, але рядок -' {(}) {} () '- цей рядок - хоча має рівне число відкриваючих і закриваючих дужок, це все ще не збалансовано, оскільки ви можете бачити, що без замикаючого '(' ми закрили '}' (тобто всі внутрішні дужки повинні бути закриті перед закриттям зовнішньої дужки)

Для вирішення цієї проблеми ми будемо використовувати структуру даних стека. Якщо ви хочете дізнатись більше про основи стека, будь ласка, зверніться тут

Стек - це LIFO (тип даних 'Last In First Out'), подумайте про це як про стос / купу тарілок на весіллі - ви будете піднімати найвищу тарілку, коли б ви нею користувались.

Алгоритм:

# 1) Оголосіть стек символів (який міститиме символи в рядку та, залежно від певної логіки, виштовхує та виводить символи).

# 2) Обхід вхідного рядка та будь-коли

  • Існує символ, що відкриває дужку - тобто ‘(‘, {‘або‘ (‘- натисніть символ на Stack.
  • Існує символ закриття - тобто ')', '}', ')' - витягніть елемент зі Stack і перевірте, чи відповідає він протилежному символу, що закривається - тобто, якщо символ має значення '}', тоді на Stack pop слід очікувати ' {'
    • Якщо спливаючий елемент не збігається із закритими дужками, рядок не збалансований, і ви можете повернути результати.
    • В іншому випадку продовжуйте підхід стека та поп (перейдіть до кроку 2).
  • Якщо рядок обведено повністю, а розмір стека також дорівнює нулю, тоді ми можемо сказати / зробити висновок, що даний рядок є збалансованим рядком у дужках.

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

Код:

import java.util.Stack; public class BalancedParanthesis { public static void main(String() args) { final String input1 = '{()}'; System.out.println('Checking balanced paranthesis for input:' + input1); if (isBalanced(input1)) { System.out.println('Given String is balanced'); } else { System.out.println('Given String is not balanced'); } } /** * function to check if a string has balanced parentheses or not * @param input_string the input string * @return if the string has balanced parentheses or not */ private static boolean isBalanced(String input_string) { Stack stack = new Stack(); for (int i = 0; i

Вихідні дані вищезазначеного фрагмента коду:

випуск збалансованийПарантези 2 нові

Як і раніше для попередніх проблем з кодуванням, завжди добре запустити код із використанням щонайменше 1-2 дійсних, а також 1-2 невірних входів і забезпечити належну обробку всіх випадків.

ПРИМІТКА: Завжди добре продумати рішення вголос (і не лише в розумі) - і на диво, це важлива риса, яку шукають інтерв’юери. Багато інтерв'юерів могли просто покінчити з алгоритмом і перейти до наступного твердження про проблему.

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

Пов’язані з рамками автоматизації тестів

Цей розділ співбесіди є більш конкретним щодо тестування та обов'язків SDET. Очікуйте питання автоматизації проектування та питання, пов'язані з розробкою, плюси та мінуси використання різних підходів тощо.

Давайте подивимось кілька зразків запитань та рішень для них самих.

Q # 5) Поясніть та спроектуйте компоненти системи автоматизації веб-додатків?

Відповідь: Це питання трохи суб'єктивне, і інтерв'юер має намір оцінити, наскільки кандидат знає про структуру та розробку рамок. Відповідь на це запитання допомагає інтерв’юеру зрозуміти, чи може кандидат будувати чи створювати власні рамки з нуля.
Давайте розглянемо кілька моментів, які допоможуть вам структурувати рішення цього питання:

  • Ви можете говорити про різні типи фреймворків, такі як - на основі даних, на основі ключових слів, гібридна фреймворк.
  • Модель об'єкта сторінки для зберігання деталей різних елементів на різних сторінках / модулях веб-програми.
  • Поширені модулі, такі як допоміжні функції, утиліти, реєстратори тощо.
  • Модулі звітування, такі як створення звітів про виконання тесту, інтеграція звітів з електронною поштою та планування виконання тесту тощо.

Рекомендована література => Найпопулярніші рамки автоматизації тестів

Q # 6) Поясніть стратегії тестування мобільного додатка?

Відповідь: Ці питання зазвичай задаються залежно від ролі. Якщо роль головним чином полягає у роботі над мобільними додатками, то питання набуває більшої актуальності. Ви можете поговорити зі свого досвіду, якщо ви планували мобільне тестування як частину своєї поточної або попередньої ролі.

Деякі вказівки на структурування відповіді на це питання можуть бути:

  • Тестування на пристроях проти емуляторів.
  • Ідентифікація та зберігання об’єктів / елементів на різних екранах - Приклад: Модель об'єкта сторінки.
  • Тестування навантаження мобільного додатка.
  • Ви можете поговорити про різні типи мобільних додатків, таких як - власні програми, гібридні програми, та обговорити стратегії / підходи, які ви використовували б для їх тестування.

Рекомендована література => Підручники з тестування мобільних додатків

Q # 7) Розробити структуру автоматизації для тестування REST API?

Відповідь: Це знову суб’єктивне запитання, і ви можете задати уточнюючі запитання, чи хоче інтерв’юер розробити структуру для тестування функціональної поведінки API або нефункціональних вимог, таких як тестування навантаження / продуктивності.

Ви можете розпочати свою відповідь з наступних пунктів:

  • Компоненти фреймворку API Automation, такі як Локальне налаштування, Фіктивне налаштування API або Розміщене тестування API.
  • Інструменти, що використовуються для автоматизації API. Для перевірки функціональних аспектів API на основі REST доступні різні інструменти. Деякі з таких інструментів - «Листоноша», «Будьте впевнені» тощо. Щоб отримати детальнішу інформацію про різні інструменти, ви можете звернутися до нашої статті тут .
  • Нефункціональна автоматизація API.
  • Планове виконання тестів автоматизації.
  • Інтеграція тестів автоматизації для API.

Q # 8) Конкретні питання.

Відповідь: Часом, залежно від профілю, з яким беруть інтерв’ю, може існувати вимога до кандидата, який повинен володіти певними рамками - напр. Селен, JMeter та ін.

Рекомендована література => Листоноша , Мокіто , Спектр , Селен , JMeter

Пов’язане тестування

Хоча і рідко, але залежно від профілю, можуть виникати запитання щодо загальних практик тестування, термінів і технологій - таких як серйозність помилок, пріоритет, планування тестів, корпус тестів тощо. Очікується, що SDET знає всі концепції тестування вручну і повинен бути знайомим з важливими термінологіями.

У цьому розділі ви можете очікувати таких питань:

Q # 9) Які різні складові плану тестування?

Відповідь: Їх зазвичай просять перевірити основні концепції тестування та мислення. Ці терміни та документи - це те, про що повинен знати кожен посібник з контролю якості, а також автоматизовані SDET.
Тут ви можете обговорити різні компоненти плану випробувань, наприклад,

  • Критерії входу та виїзду
  • Сфера застосування: Обговоріть тестові функції, які входять до сфери застосування, і те, що все буде автоматизовано - чи будуть це лише функціональні особливості або нефункціональні вимоги, такі як масштабованість, продуктивність тощо.
  • Графіки
  • Інструменти, які слід використовувати
  • Розподіл ресурсів тощо

Рекомендована література => Як написати хороший план тестування

Q # 10) Що визначає та вирішує пріоритет і серйозність помилки?

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

В загальному,

  • Пріоритет означає важливість питання.
  • Серйозність означає вплив, який ця проблема справляє на клієнта або користувача програми.

Рекомендована література => Пріоритет та серйозність дефектів

Q # 11) Що таке розділення еквівалентності? Проілюструйте на прикладі.

Відповідь: Розбиття на еквівалентність - це техніка, яка в основному використовується для тестування чорної скриньки, щоб перевірити різні комбінації входів проти даного поля.

Наприклад, якщо ви тестуєте торговий додаток і хочете написати всі тестові сценарії для поля “Кількість” - якими вхідними даними ви б тестували це поле?
Враховуючи функціональну вимогу, кількість повинна бути цілим додатним значенням від 1 до 100000. Отже, щоб перевірити різні вхідні дані (як дійсні, так і недійсні), ви можете провести тести на 1 вхід з кожної такої категорії.

  • Дійсні значення: Між 1 і 100000 -> перевіряємо на будь-яке дійсне значення x таке, що x> 1 та x<100000.
  • Граничні значення: Перевірте допустимі граничні значення, тобто 1 & 100000.
  • Недійсні значення: Значення, що знаходяться за межами дозволеного діапазону - тобто перевіряють одне таке значення для x, таке що x 100000.

Рекомендована література => Стратегія розподілу еквівалентності

Пов’язане з дизайном системи

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

Але ви можете відчувати, що система, яка вимагає багаторічного досвіду та сотень розробників, щоб кодувати, як людина може відповісти на питання приблизно за 45 хвилин?

Відповідь така: Тут очікується судити про розуміння кандидата та широкий спектр знань, які він може застосовувати під час вирішення складних проблем.

У наш час ці питання також починають кидатись в інтерв'ю SDET. Тут очікування залишаються такими ж, як і на співбесіду з розробником, але з розслабленими критеріями судження та, в основному, підняттям бару, коли, залежно від відповіді кандидата, кандидата можна розглядати на наступний рівень або перенести на нижчий рівень.

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

  1. Основи операційних систем: Пейджинг, файлові системи, віртуальна пам’ять, фізична пам’ять тощо.
  2. Мережеві концепції: Зв'язок HTTP, стек TCP / IP, топології мережі.
  3. Концепції масштабованості: Горизонтальне та вертикальне масштабування.
  4. Концепції паралельності / потоків
  5. Типи баз даних: Бази даних SQL / відсутність SQL, коли використовувати тип бази даних, переваги та недоліки різних типів баз даних.
  6. Техніка хешування
  7. Базове розуміння CAP теорема, шардінг, секціонування тощо.

Давайте подивимось кілька зразків запитань

Q # 12) Створіть систему скорочення URL-адрес, як крихітна URL-адреса ?

Відповідь: Багато кандидатів можуть навіть не знати про системи скорочення URL-адрес загалом. У такому випадку нормально запитати інтерв’юера про постановку проблеми, замість того, щоб зануритися, не розуміючи.

Перш ніж навіть відповідати на такі запитання, кандидати повинні структурувати рішення і написати пункти, а потім розпочати обговорення рішення з інтерв'юером.

Давайте коротко обговоримо рішення

а) Уточнити функціональні та нефункціональні вимоги

Функціональні вимоги: Функціональна вимога - це просто з точки зору замовника, це система, яка отримує велику (довгу) URL-адресу, а результатом має бути скорочена URL-адреса.

Коли здійснюється доступ до скороченої URL-адреси, вона повинна перенаправити користувача на вихідну URL-адресу. Наприклад - спробуйте скоротити фактичну URL-адресу на веб-сторінці https://tinyurl.com/, додайте вхідну URL-адресу, наприклад www.softwaretestinghelp.com, і ви повинні отримати крихітну URL-адресу, наприклад https://tinyurl.com/shclcqa

Нефункціональні вимоги: Система повинна бути ефективною з точки зору переадресації із затримкою в мілісекунди (як додатковий стрибок для користувача, який отримує доступ до вихідної URL-адреси).

  • Скорочені URL-адреси повинні мати настроюваний термін дії.
  • Скорочені URL-адреси не повинні бути передбачуваними.

б) Оцінка пропускної спроможності / трафіку

Це дуже важливо з точки зору всіх питань проектування системи. Оцінка потужності по суті визначає очікуване навантаження, яке збирається отримати система. Завжди добре починати з припущення та обговорювати з інтерв’юером. Це також важливо з точки зору планування розміру бази даних, незалежно від того, чи система важка для читання, чи важка для запису тощо.

Давайте зробимо деякі номери ємності для прикладу укорочувача URL-адрес.

Припустимо, буде 100 тисяч нових запитів на скорочення URL-адрес на день (із співвідношенням 100: 1 читання-запис - тобто на кожну 1 скорочену URL-адресу ми матимемо 100 запитів на читання щодо скороченої URL-адреси)

Отже, ми матимемо,

100k write requests/day => 100000/(24x60x60) => 1.15 request/second 10000k read requests/day => 10000000/(24x60x60) => 1157 requests/second

в) Міркування щодо зберігання та пам'яті

Після номерів ємності ми можемо екстраполювати ці числа, щоб отримати,

  • Ємність для зберігання, яка була б необхідна для розміщення очікуваного навантаження, Наприклад, ми можемо планувати розробити рішення для зберігання для підтримки запитів на термін до 1 року.
    Приклад: Якщо кожна скорочена URL-адреса споживає 50 байт, то загальний обсяг даних / сховища, який нам знадобиться протягом року, буде:
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB
  • Міркування щодо пам’яті важливі для планування системи з точки зору читача. тобто для систем, які важкі для читання - на зразок тієї, яку ми намагаємось створити (оскільки URL-адреса буде створена один раз, але доступ до неї буде здійснено кілька разів).
    Системні системи читання зазвичай використовують кешування для підвищення продуктивності та уникають читання з постійного сховища, щоб заощадити на читанні вводу-виводу.

Припустимо, ми хочемо зберігати 60% наших запитів на читання в кеш-пам’яті, тому протягом року нам буде потрібно 60% загального зчитування за рік x байтів, необхідних для кожного запису

=> (60/100) x 100000 x 365 x (50/1024x1024) => 1045 MB ~ 1GB

Отже, згідно з нашими номерами ємності, цій системі буде потрібно близько 1 ГБ фізичної пам’яті

г) Оцінка пропускної здатності

Оцінки смуги пропускання необхідні для аналізу швидкості читання та запису в байтах, які були б необхідні для виконання системи. Давайте зробимо оцінки щодо кількості пропускної спроможності, яку ми взяли.

Приклад: Якщо кожна скорочена URL-адреса споживає 50 байт, то загальна швидкість читання та запису, яка нам потрібна, буде такою, як показано нижче:

WRITE - 1.15 x 50bytes = 57.5 bytes/s READS - 1157 x 50bytes = 57500 bytes/s => 57500 / 1024 => 56.15 Kb/s

д) Проектування системи та алгоритм
Це, по суті, основна бізнес-логіка або алгоритм, який би використовувався для виконання функціональних вимог. У цьому випадку ми хочемо створити унікальні скорочені URL-адреси для даної URL-адреси.

Різні підходи, які можна використовувати для створення скорочених URL-адрес:

Хешування: Ми можемо думати про створення скорочених URL-адрес, створивши хеш вхідної URL-адреси та призначивши хеш-ключ як скорочену URL-адресу.

Хешування

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

Попередньо створені скорочені рядкиі призначаються URL-адресам при виклику послуги: Іншим підходом може бути повернення заздалегідь визначеного скороченого рядка з пулу вже створених рядків.

Попередньо створені скорочені рядки

Сервісні API: Ми можемо розглядати систему скорочення URL-адрес як набір API на основі REST, які мають такі кінцеві точки:

  • createUrl (URL-адреса рядка, DateTime expiryTime): Ця кінцева точка створює та повертає скорочену URL-адресу з тривалістю закінчення, встановленою, як зазначено у введенні.
  • retrieveUrl (рядок скороченийUrl): Ця кінцева точка отримує URL-адресу, яка буде перенаправлена ​​на вказану скорочену URL-адресу.

f) Масштабування та паралельність

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

Він має справу з тим, як може система

  • Вага під навантаженням: Система повинна мати можливість витончено масштабувати під навантаженням, а не просто припиняти роботу після того, як відбувся несподіваний стрибок навантаження.

Рекомендована література => Техніка масштабування

  • Наскільки ефективною може бути система, наприклад: якщо система використовується тривалий час зі стабільною потужністю, чи буде погіршуватися продуктивність системи чи вона залишається стабільною?

Тут може бути багато різних питань проектування системи, як показано нижче, але загалом, усі вони перевіряли б ширше розуміння кандидатом різних концепцій, які ми обговорювали у вирішенні системи скорочення URL-адрес.

Q # 13) Створіть відео платформу, таку як Youtube.

Відповідь: До цього питання можна також підійти, подібним чином, як ми вже обговорювали питання TinyUrl вище (і це стосується майже всіх питань інтерв'ю щодо проектування системи). Одним диференційованим фактором буде розгляд / деталізація системи, яку ви хочете спроектувати.

Отже, для Youtube ми всі знаємо його програму для потокового передавання відео та має безліч можливостей, таких як дозволяти користувачеві завантажувати нові відео, транслювати трансляції в прямому ефірі тощо. Тож під час проектування системи слід застосовувати необхідні компоненти системного дизайну. У цьому випадку нам може знадобитися додати компоненти, пов’язані з можливостями потокового відео.

Ви можете обговорити такі моменти, як

  • Зберігання: Яку базу даних ви вибрали б для зберігання відеовмісту, профілів користувачів, списків відтворення тощо?
  • Безпека та автентифікація / авторизація
  • Кешування: Оскільки потокова платформа, як youtube, повинна бути ефективною, кешування є важливим фактором для проектування будь-якої такої системи.
  • Паралельність: Скільки користувачів може паралельно транслювати відео?
  • Інші функції платформи, такі як служба рекомендацій щодо відео, яка рекомендує / пропонує користувачам наступні відео, які вони можуть переглянути тощо.

Q # 14) Створіть ефективну систему для роботи з 6 ліфтами та переконайтеся, що людина повинна чекати мінімальний час, очікуючи прибуття ліфта ?

Відповідь: Ці типи запитань щодо проектування системи є на нижчому рівні, і очікується, що кандидат спочатку продумає систему ліфта та перерахує всі можливі функції, які потрібно підтримувати, і вирішить питання проектування / створення класів та взаємозв’язків / схем БД.

З точки зору SDET, інтерв'юер просто очікував би основних класів, які, на вашу думку, мали б ваша програма або система, і основні функціональні можливості були б оброблені із запропонованим рішенням.

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

Ви можете задати уточнюючі запитання типу

  • Скільки там поверхів?
  • Скільки там ліфтів?
  • Чи всі ліфти обслуговують / пасажирські ліфти?
  • Чи всі ліфти налаштовані на зупинку на кожному поверсі?

Ось різні варіанти використання, які застосовуються для простої ліфтової системи:

system-design-elevator_system

Що стосується основних класів / об'єктів цієї системи, ви можете розглянути можливість наявності:

  • Користувач: Має справу з усіма властивостями користувача та діями, які він може виконати щодо об’єкта ліфта.
  • Ліфт: Специфічні властивості ліфта, такі як висота, ширина, номер_серійного_ліфта.
  • Двері ліфта: Усі речі, пов’язані з дверима, такі як відсутність дверей, тип дверей, автоматичні чи ручні тощо.
  • Elevator_Button_Control: Різні кнопки / елементи керування, доступні в ліфті, і різні стани, в яких ці елементи управління можуть бути.

Після закінчення проектування класів та їх взаємозв’язків ви можете поговорити про налаштування схем БД.

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

Система проведення змагань є важливим аспектом, оскільки одночасно ліфтом користується декілька користувачів (на різних поверхах). Отже, запити користувача повинні потрапляти в чергу та обслуговуватися відповідно до налаштованої логіки в контролерах ліфта.

Q # 15) Дизайн Instagram / Twitter / Facebook.

Відповідь: Всі ці платформи певним чином пов’язані, оскільки вони дозволяють тим чи іншим чином підключати користувачів та обмінюватися речами через різні типи медіа - наприклад, повідомлення / відео та чати.

Отже, для цих типів програм / платформ соціальних медіа ви повинні включити нижче пункти під час обговорення проектування таких систем (на додаток до того, що ми обговорювали для проектування системи скорочення URL-адрес):

  • Оцінка потужності: Більшість із цих систем будуть важкими для читання, отже, необхідна оцінка пропускної здатності, і це дозволить нам забезпечити належну конфігурацію сервера та бази даних для забезпечення необхідного навантаження.
  • Схема БД: Основними важливими схемами БД, які слід обговорити, є - Інформація про користувача, Відносини з користувачами, Схеми повідомлень, Схеми вмісту.
  • Сервери хостингу відео та зображень: У більшості цих програм є відео та зображення, якими користувачі діляться. Отже, сервери хостингу відео та зображень повинні бути налаштовані відповідно до потреб.
  • Безпека: Усі ці програми повинні забезпечувати високий рівень безпеки завдяки Інформації про Користувача / Інформації, що ідентифікує особу користувачів, яких вони зберігають. Будь-які спроби злому, SQL Injection не повинні мати успіху на цих платформах, оскільки це може коштувати втрати даних мільйонів клієнтів.

Проблеми на основі сценарію

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

Q # 16) З огляду на те, що критичне виправлення потрібно випустити якомога швидше - яку стратегію тестування ви б мали?

Відповідь: Зараз тут інтерв’юер по суті хоче зрозуміти

  • Як і які стратегії тестування ви можете придумати?
  • Яке покриття ви зробите для виправлення?
  • Як би ви перевірили виправлення після розгортання? тощо

Щоб відповісти на такі запитання, Ви могли б використовувати ситуації з реального життя, якби могли пов’язати проблему. Ви також повинні згадати, що без відповідного тестування ви не хотіли б випускати будь-який код для виробництва.

Для вирішення критичних виправлень слід завжди працювати в парі з розробником і намагатися зрозуміти, на які сфери це може вплинути, та підготувати невиробниче середовище для копіювання сценарію та тестування виправлення.

Тут також важливо згадати, що ви продовжуватимете моніторинг виправлення (за допомогою інструментів моніторингу, інформаційних панелей, журналів тощо) після розгортання, щоб побачити будь-яку ненормальну поведінку у виробничому середовищі та переконатися, що немає негативного впливу виправлення, яке зроблено.

Можуть бути й інші запитання, які здебільшого стосуються розуміння точки зору кандидата на тестування автоматизації, терміни постачання тощо (і ці питання можуть різнитися від компанії до компанії, а також від стажу ролі. Як правило, ці питання задаються для старшого / керівного рівня ролі)

Q # 17) Ви б пожертвували повним тестуванням, щоб швидко випустити продукт?

Відповідь: Ці запитання, як правило, залучають інтерв’юера до розуміння ваших думок з точки зору керівництва та щодо того, на що б ви пішли компроміси, і чи готові ви випустити баггі замість меншого часу.

Відповіді на ці запитання повинні обґрунтовуватися фактичним досвідом кандидата.

Наприклад, Ви можете згадати, що раніше вам потрібно було зателефонувати, щоб випустити якесь виправлення, але його не вдалося перевірити через відсутність середовища інтеграції. Отже, ви випустили його контрольовано - розгортанням до меншого відсотка, а потім моніторингом журналів / подій, а потім ініціювали повне розгортання тощо.

Q # 18) Як би ви створили стратегію автоматизації для продукту, який взагалі не має тестів автоматизації?

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

Наприклад, щоб відповісти на такі типи запитань, ви можете навести приклади Стратегії автоматизації, яку ви прийняли, будуючи продукт у минулому.

Наприклад, ви можете згадати такі моменти, як,

  • Оскільки продукт вимагав запуску автоматизації з нуля, у вас було достатньо часу, щоб продумати та розробити відповідну систему автоматизації, вибравши мову / технологію, яку б знала більшість людей, щоб уникнути впровадження нового інструменту та використовувати наявні знання.
  • Ви розпочали з автоматизації основних функціональних сценаріїв, які вважалися P1 (без яких жоден випуск не міг пройти).
  • Ви також думали про тестування продуктивності та масштабованості системи за допомогою автоматизованих інструментів тестування, таких як JMETER, LoadRunner тощо.
  • Ви думали про автоматизацію аспектів безпеки програми, як зазначено в OWASP Стандарти безпеки.
  • Ви інтегрували автоматизовані тести в конвеєр збірки для раннього зворотного зв'язку тощо.

Team Fit & Culture Fit

Цей раунд, як правило, залежить від компанії до компанії. Але необхідність / необхідність цього раунду полягає у розумінні кандидата з точки зору командної та організаційної культури. Мета цих питань - також зрозуміти особистість кандидата та їх підхід до роботи / людей тощо.

Як правило, менеджери з персоналу та найму є тими, хто проводить цей раунд.

Зазвичай під час цього раунду виникають такі запитання:

Q # 19) Як ви вирішуєте конфлікти в рамках вашої поточної ролі?

Відповідь: Подальше пояснення тут: припустимо, у вас конфлікт із вашим начальником або безпосередніми членами команди, які кроки ви робите для вирішення цих конфліктів?

Для цього типу запитань обґрунтуйте якомога більше реальними прикладами, які могли траплятись у вашій кар’єрі в поточній чи попередній організаціях.

Ви можете згадати такі речі, як:

  • Ви хочете якомога швидше розібратися в будь-яких конфліктах, які виникають внаслідок професійних причин (і не хотіли б впливати на ваші особисті стосунки через них).
  • Ви можете зазначити, що, як правило, ви намагаєтеся ефективно спілкуватися та розмовляти / обговорювати з людиною індивідуально, щоб вирішити будь-які розбіжності / проблеми.
  • Ви можете згадати, що якщо справа почне погіршуватися, ви скористаєтесь допомогою старшого керівника / вашого менеджера та отримаєте його / її вказівки.

Інші приклади запитань щодо придатності команди / культури відповідають нижче (на більшість з них слід відповісти подібним підходом, який ми обговорювали для вищезазначеного питання. Розмова про реальні сценарії є тут ключовим фактором, оскільки інтерв’юер може це краще пов’язати, оскільки добре.

Q # 20) Який баланс між роботою та особистим життям ви очікуєте від нової ролі, на яку вас вважають найманим?

Відповідь: Оскільки менеджер з найму - це той, хто знає, чого вимагає роль, скільки додаткових зусиль може знадобитися часом, тому загалом інтерв'юер намагається визначити, чи ваші очікування кардинально відрізняються від очікуваних ролей.

Припустимо, ти кажеш що ви не віддаєте перевагу відвідувати нічні зустрічі, і роль очікує від вас великої співпраці між командою, яка сидить в іншому часовому поясі, тоді інтерв'юер може ініціювати дискусію про те, що це очікування від ролі - чи зможете ви пристосуватися? тощо

Тож знову ж таки, це швидше невимушена розмова, але з точки зору інтерв’юера, вони хочуть зрозуміти ваші очікування щодо оцінки вашої кандидатури на посаду, на яку беруть інтерв’ю.

Q # 21) Окрім роботи, якими є ваші захоплення?

Відповідь: Ці запитання суто суб’єктивні та індивідуальні, і, як правило, ці питання корисні для того, щоб кандидат почувався розслабленим та легким та ініціював невимушені дискусії.

Взагалі, відповіді на ці запитання можуть бути такими - ви любите читати певний жанр, любите музику, отримали якусь нагороду за якусь добровільну / благодійну діяльність тощо. Крім того, ці запитання, як правило, задають у раунді з управління персоналом (і рідше запитує технічна особа).

Q # 22) Скільки часу ви готові присвятити вивченню нових інструментів та технологій заздалегідь?

Відповідь: Тут інтерв’юер оцінює вашу готовність вивчати нові речі, якщо вам підкидають щось незвичне чи нове. Це також дає можливість інтерв’юеру зрозуміти, що ви ініціативні? Чи готові ви інвестувати в себе та свою кар'єру? тощо

Тож відповідаючи на такі запитання - будьте чесними та обґрунтовуйте свої відповіді прикладами - Наприклад, Ви можете згадати, що минулого року ви з’явились на сертифікацію Java і підготувались до роботи поза роботою, займаючи кілька годин щотижня.

Висновок

У цій статті ми обговорили інженера-розробника програмного забезпечення в процесі тестового співбесіди та зразки питань, які зазвичай задають кандидати в різних організаціях та профілях. Взагалі, інтерв'ю SDET мають дуже широкий характер і дуже залежать від компанії до компанії.

Але процеси співбесіди схожі на ті, що існують для профілю розробника з більшим акцентом на якості та системах автоматизації.

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

З найкращими побажаннями для Вашого інтерв’ю SDET!

Рекомендована література

^