sdet interview questions
Прочитајте овај комплетан водич за инжењера за развој софтвера у пробним интервјуима да бисте знали формат и како одговорити на питања у вези са СДЕТ интервјуом која су постављена у разним рундама:
У овом упутству ћемо научити нека често постављана питања о интервјуима за улоге СДЕТ-а. Такође ћемо видети, опћенито, уобичајени образац интервјуа и подијелити неке савјете како се истакнути у интервјуима.
За проблеме кодирања у овом упутству користићемо језик Јава, међутим, већина водича за СДЕТ је агностички језик, а анкетари су углавном флексибилни око језика који кандидат одлучи да користи.
Шта ћете научити:
Водич за припрему интервјуа за СДЕТ
СДЕТ интервјуи у већини водећих компанија за производњу производа прилично су слични начину на који се интервјуи воде за развојне улоге. То је зато што се од СДЕТ-а такође очекује да знају и разумеју готово све што програмер зна.
Оно што се разликује су критеријуми на основу којих се оцењује саговорник СДЕТ-а. Анкетари за ову улогу траже вештине критичког мишљења, као и то да ли особа са којом се разговара има практично искуство у кодирању и има ли око за квалитет и детаље.
Ево неколико тачака на које би неко ко се припрема за интервју за СДЕТ углавном требао усредсредити:
најбољи питхон едитор мац ос к
- Будући да су ти интервјуи најчешће агностички на технологији / језику, кандидати морају бити спремни да науче нову технологију (и искористе постојеће вештине) по потреби.
- Требали би имати добре комуникацијске и тимске вјештине јер улоге СДЕТ-а данас захтијевају комуникацију и сарадњу на различитим нивоима са вишеструким дионицима.
- Треба да има основно разумевање различитих концепата дизајна система, скалабилности, паралелности, нефункционалних захтева итд.
У следећим одељцима покушаћемо да разумемо општи формат интервјуа заједно са неколико примера питања.
Формат инжењера за развој софтвера у тест интервјуу
Већина компанија преферира формат интервјуисања кандидата за улогу СДЕТ-а, понекад, улога је супер специфична за тим и очекује се да ће особа бити оцењена као савршена за тим за који је запослена.
Али, тема интервјуа се углавном заснива на следећим тачкама:
- Телефонска дискусија: Разговор са менаџером и / или члановима тима који је обично круг прегледа.
- Писмени круг: Са специфичним питањима за тестирање / тестирање кућишта.
- Круг познавања кодирања: Једноставна кодирајућа питања (језички агностик) и од кандидата се тражи да напише производни код.
- Разумевање основних развојних концепата: Попут ООПС концепата, ЧВРСТИХ принципа итд.
- Дизајн и развој оквира за аутоматизацију испитивања
- Језици за скриптовање: Селен, Питхон, Јавасцрипт, итд
- Цултуре Фит / ХР дискусија и преговори
Питања и одговори за интервју за СДЕТ
У овом одељку размотрићемо неколико примера питања заједно са детаљним одговорима за различите категорије које поставља већина компанија које производе производе за СДЕТ улоге.
Кодирање
У овом кругу дају се једноставни задаци кодирања за писање на језику који сте изабрали. Овде анкетар жели да измери стручност кодним конструкцијама, као и да се бави стварима као што су рубни сценарији и нулл провере итд.
Повремено анкетари могу такође затражити да напишу јединствене тестове за написани програм.
Погледајмо неке примере проблема.
П # 1) Напишите програм за замену 2 броја без употребе 3. (привремене) променљиве?
Одговор :
Програм за замену два броја:
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); } }Ево резултата горњег исечка кода:
У горе наведеном исечку кода, важно је напоменути да је испитивач посебно затражио замену 2 броја без употребе треће привремене променљиве. Такође је важно да се пре подношења решења увек препоручује да прођете (или прођете) код најмање 2-3 улаза. Покушајмо са позитивним и негативним вредностима.
Позитивне вредности: Кс = 2, И = 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)Негативне вредности: Кс = -3, И = 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)П # 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
П # 3) Написати програм за израчунавање факторијела броја?
Одговор: Фацториал је једно од најчешће постављаних питања у готово свим интервјуима (укључујући интервјуе за програмере)
За интервјуе са програмерима, већи фокус је на програмским концептима попут динамичког програмирања, рекурзије итд., Док је из инжењера софтверског развоја у перспективи теста важно руковати рубним сценаријима као што су максималне вредности, минималне вредности, негативне вредности итд. И приступ / ефикасност су важни, али постају споредни.
Погледајмо програм за факторијел који користи рекурзију и фор-лооп са руковањем негативним бројевима и враћањем фиксне вредности рецимо -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) Напишите програм за проверу да ли дати низ има уравнотежене заграде?
Одговор:
Приступ - Ово је мало сложен проблем, где анкетар тражи нешто више од знања само конструкције кодирања. Овде се очекује размишљање и употреба одговарајуће структуре података за проблем који је у питању.
Многи од вас би се могли осећати застрашено због ове врсте проблема, јер неки од вас их можда нису чули, па стога, иако су једноставни, могу звучати сложено.
Али генерално за такве проблеме / питања: На пример, у тренутном питању, ако не знате шта су уравнотежене заграде, врло добро можете питати анкетара и затим радити на решењу уместо да ударите у слепу тачку.
Погледајмо како приступити решењу: Након што сте разумели шта су уравнотежене заграде, можете размислити о коришћењу праве структуре података, а затим започети писање алгоритама (корака) пре него што започнете са кодирањем решења. Пуно пута сами алгоритми решавају пуно рубних сценарија и дају пуно јасноће како ће решење изгледати.
Погледајмо решење:
Уравнотежене заграде треба да провере за дати низ који садржи заграде (или заграде), треба да има једнак број отварања и затварања, као и позиционо добро структуриран. За контекст овог проблема користићемо уравнотежене заграде као - ‘()’, ‘()’, ‘{}’ - тј. Дати низ може имати било коју комбинацију ових заграда.
Имајте на уму да је пре покушаја проблема добро разјаснити да ли ће низ садржавати само заградне знакове или било које бројеве итд. (Јер би ово могло мало променити логику)
Пример: Дати низ - '{() {} ()} - уравнотежен је низ јер је структуриран и нема једнак број затварајућих и отварајућих заграда, већ низ -' {(}) {} () '- овај низ - иако има једнак број отварања и затварања заграда, ово још увек није уравнотежено јер можете видети да без затварања '(' смо затворили '}' (тј. све унутрашње заграде треба затворити пре затварања спољне заграде)
За решавање овог проблема користићемо структуру података стека. Ако желите да сазнате више о основама стека, погледајте овде
Стек је ЛИФО (врста података са подацима „Ласт Ин Фирст Оут“), замислите га као стог / гомилу тањира на венчању - подићи ћете највишу плочу кад год је будете користили.
Алгоритам:
# 1) Декларирајте скуп знакова (који би садржавао знакове у низу и, зависно од неке логике, гурао и искакао знакове).
# 2) Прелазак кроз улазни низ и кад год
- Постоји почетни знак заграде - тј. „(‘, {‘Или‘ (‘- притисните знак на Стацк-у.
- Постоји знак за затварање - тј. ')', '}', ')' - искочите елемент из Стацка и проверите да ли се подудара са супротним од знака за затварање - тј. Да ли је знак '}', онда на Стацк попу треба очекивати ' {'
- Ако се искочени елемент не подудара са затварајући заградом, тада низ није уравнотежен и можете вратити резултате.
- У супротном наставите са притиском и пуцањем стека (идите на корак 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 Излаз горњег исечка кода:
Као и за претходне проблеме са кодирањем, увек је добро покренути код са најмање 1-2 важећих и 1-2 неваљана уноса и осигурати да се сви случајеви правилно обрађују.
БЕЛЕШКА: Увек је добро добро размислити о решењу (и не само у мислима) - и изненађујуће је да је ово важна особина коју анкетари траже. Многи анкетари би могли једноставно да уклоне алгоритам и пређу на следећу изјаву о проблему.
У горе наведеном решењу за кодирање, за интервју за програмера, анкетар може затражити да га реши помоћу низова уместо да се директно слажу (тј. Користећи низ као стек), али генерално, више је реч о томе да буде концептуално јасан и способан да се носи са свим важећим и неважећи уноси.
У вези са оквиром за аутоматизацију тестова
Овај одељак интервјуа специфичнији је око тестирања и одговорности за СДЕТ. Очекујте питања дизајна оквира аутоматизације и питања везана за развој, предности и недостатке коришћења различитих приступа итд.
Погледајмо неколико примера питања и решења за исто.
П # 5) Објаснити и дизајнирати компоненте оквира за аутоматизацију за веб апликацију?
Одговор: Ово питање је мало субјективно и анкетар намерава да процени колико кандидат зна о дизајну и развоју оквира. Одговор на ово питање помаже анкетеру да разуме да ли кандидат може да креира или креира прилагођене оквире од нуле.
Погледајмо неколико тачака које би вам помогле да структуришете решење за ово питање:
- Можете разговарати о различитим врстама оквира као што су - На основу података, На основу кључних речи, Хибридни оквир.
- Модел објекта странице за чување детаља различитих елемената на различитим страницама / модулима веб апликације.
- Уобичајени модули као што су помоћне функције, услужни програми, записници итд.
- Модули за извештавање попут генерисања извештаја о извршењу теста, интегрисање извештаја са е-поштом и заказивање извршења теста итд.
Препоручено читање => Најпопуларнији оквири за аутоматизацију испитивања
6. питање) Објасните стратегије тестирања мобилне апликације?
Одговор: Ова питања се обично постављају у зависности од улоге. Ако је улога углавном рад на мобилним апликацијама, питање има већу важност. Из свог искуства можете разговарати ако сте планирали мобилно тестирање као део тренутне или претходне улоге.
Неки путокази за структурирање одговора на ово питање могу бити,
- Тестирање на уређајима наспрам емулатора.
- Идентификовање и чување објеката / елемената на различитим екранима - Пример: Модел објекта странице.
- Учитавање тестирање мобилне апликације.
- Можете разговарати о различитим врстама мобилних апликација попут - Изворне апликације, Хибридне апликације и разговарати о стратегијама / приступима које бисте користили за њихово тестирање.
Препоручено читање => Водичи за тестирање мобилних апликација
П # 7) Дизајнирати оквир за аутоматизацију за тестирање РЕСТ АПИ-ја?
Одговор: Ово је опет субјективно питање и можете поставити разјашњена питања да ли анкетар жели да развијете оквир за тестирање функционалног понашања АПИ-ја или нефункционалне захтеве попут тестирања оптерећења / перформанси.
Одговор можете започети покривајући следеће тачке:
- Компоненте оквира за аутоматизацију АПИ-ја, попут локалног подешавања, лажног подешавања АПИ-ја или хостованог АПИ тестирања.
- Алати који се користе за АПИ аутоматизацију. Постоје различити алати доступни одмах за потврду функционалних аспеката АПИ-ја заснованог на РЕСТ-у. Неки од таквих алата су Поштар, Будите сигурни итд. За детаљније детаље различитих алата можете се обратити нашем чланку овде .
- Нефункционална аутоматизација АПИ-ја.
- Планирано извршење тестова аутоматизације.
- Интегрисање тестова аутоматизације за АПИ-је.
П # 8) Питања специфична за оквир.
Одговор: Понекад, у зависности од профила са којим се разговара, може постојати захтев да кандидат буде вешт у одређеном оквиру - нпр. Селен, ЈМетер итд.
Препоручено читање => Поштар , Моцкито , Спецфлов , Селен , ЈМетер
У вези са тестирањем
Иако ретко, али у зависности од профила, могу постојати питања у вези са општим праксама тестирања, терминима и технологијама - попут озбиљности грешака, приоритета, планирања теста, кућишта теста итд. Очекује се да СДЕТ познаје све концепте ручног тестирања и треба да буде упознат са важним терминологијама.
У овом одељку можете очекивати оваква питања:
П # 9) Које су различите компоненте теста?
Одговор: Од њих се обично тражи да потврде основне концепте тестирања и начин размишљања. Ови термини и документи су нешто што би сваки ручни КА, као и СДЕТ-ови за аутоматизацију требали знати.
Овде можете разговарати о разним компонентама теста, попут,
- Критеријуми за улазак и излазак
- Обим: Разговарајте о карактеристикама теста које су у обиму и шта би све било аутоматизовано - да ли ће то бити само функционалне карактеристике или нефункционални захтеви попут скалабилности, перформанси итд.
- Временске линије
- Алати који се користе
- Додела ресурса итд
Препоручено читање => Како написати добар план теста
П # 10) Шта дефинише и одлучује о приоритету и тежини грешке?
Одговор: Приоритет и тежина недостатака могу се лако објаснити помоћу примера. Претпоставимо да је функција попут регистрације сломљена и спречава кориснике да приступе апликацији - онда је то проблем високог приоритета и озбиљности. Слично томе, могу бити примери дефеката ниске тежине / високог приоритета и разних других комбинација.
У глобалу,
- Приоритет означава важност питања.
- Озбиљност означава утицај који проблем има на купца или корисника апликације.
Препоручено читање => Приоритет и тежина недостатака
П # 11) Шта је еквивалентна партиција? Илуструјте примером.
Одговор: Еквиваленција партиционирања је техника која се углавном користи за тестирање црне кутије, за тестирање различитих комбинација улаза према датом пољу.
На пример, ако тестирате трговинску апликацију и желите да напишете све сценарије тестирања за поље „Количина“ - који би били различити улази које бисте тестирали за ово поље?
С обзиром на функционални захтев да количина треба да буде позитивна целобројна вредност између 1 и 100000. Дакле, да бисте тестирали различите улазе (и важеће и неваљане), можете имати тестове за 1 унос из сваке такве категорије.
- Важеће вредности: Између 1 и 100000 -> тестирајте било коју важећу вредност к такву да је к> 1 и к<100000.
- Граничне вредности: Тест за дозвољене граничне вредности, тј. 1 & 100000.
- Неважеће вредности: Вредности које се налазе изван дозвољеног опсега - тј. Тестирајте једну такву вредност за к, такву да је к 100000.
Препоручено читање => Стратегија поделе еквивалентности
У вези са дизајном система
Питања о дизајну система обично су прикладнија за разговоре са програмерима, где се програмер процењује на основу широког разумевања различитих општих концепата - попут скалабилности, доступности, толеранције кварова, избора базе података, навоја итд. Укратко, мораћете да употребите целокупан искуство и системско знање за одговор на таква питања.
Али можда осећате да систем за који су потребне године искуства и стотине програмера кодира, како би неко могао да одговори на питање за око 45 минута?
Одговор је: Овде се очекује судити о разумевању кандидата и широком спектру знања које он или она може применити током решавања сложених проблема.
У данашње време ова питања почињу да се бацају и у интервјуима СДЕТ-а. Овде очекивања остају иста као и за интервју са програмерима, али са опуштеним критеријумима просудбе и углавном кругом подизања нивоа, где се, у зависности од одговора кандидата, кандидат може сматрати следећим или преместити на нижи ниво.
Генерално, за питања интервјуа за дизајн система, кандидат треба да буде упознат са доњим концептима
- Основе оперативних система: Пејџинг, систем датотека, виртуелна меморија и физичка меморија итд.
- Концепти умрежавања: ХТТП комуникација, ТЦП / ИП стек, мрежне топологије.
- Појмови скалабилности: Хоризонтално и вертикално скалирање.
- Конкуренција / концепти навоја
- Типови база података: СКЛ / Нема СКЛ база података, када се користи која врста базе података, предности и недостаци различитих врста база података.
- Технике распршивања
- Основно разумевање КАПА теорема, оштрина, подела итд.
Погледајмо неколико примера питања
П # 12) Дизајнирајте систем скраћивања УРЛ адреса попут малени УРЛ ?
Одговор: Многи кандидати можда уопште не знају о системима скраћивања УРЛ адреса. У том случају је у реду питати анкетара о изјави проблема уместо да зароните без разумевања.
Пре него што уопште одговоре на таква питања, кандидати треба да структуришу решење и напишу тачке, а затим започну расправу о решењу са анкетером.
Размотримо решење укратко
а) Појаснити функционалне и нефункционалне захтеве
Функционални захтеви: Функционални захтев је једноставно из перспективе купца, то је систем који се храни великом (дугачком) УРЛ адресом, а излаз треба да буде скраћени УРЛ.
Када се приступи скраћеном УРЛ-у, требало би да корисника преусмери на оригинални УРЛ. На пример - покушајте да скратите стварни УРЛ на хттпс://тиниурл.цом/ веб страници, унесите улазни УРЛ као што је ввв.софтваретестингхелп.цом и требали бисте добити мали УРЛ попут хттпс://тиниурл.цом/схцлцка
Нефункционални захтеви: Систем би требало да буде ефикасан у погледу преусмеравања са милисекундним кашњењем (као додатни скок за корисника који приступа оригиналној УРЛ-у).
- Скраћени УРЛ-ови треба да имају подесиво време истека.
- Скраћени УРЛ-ови не би требало да буду предвидљиви.
б) Процена капацитета / саобраћаја
Ово је веома важно из перспективе свих питања дизајна система. Процена капацитета у основи одређује очекивано оптерећење које ће систем добити. Увек је добро започети претпоставку и разговарати са анкетером. Ово је такође важно из перспективе планирања величине базе података, било да је систем тежак за читање или тежак за писање итд.
Направимо неке бројеве капацитета за пример скраћивача УРЛ адреса.
Претпоставимо да ће постојати 100.000 нових захтева за скраћивање УРЛ-ова дневно (са односом читања и писања 100: 1 - тј. За сваки 1 скраћени УРЛ имаћемо 100 захтева за читање према скраћеном УРЛ-у)
Па ћемо имати,
100k write requests/day => 100000/(24x60x60) => 1.15 request/second 10000k read requests/day => 10000000/(24x60x60) => 1157 requests/second ц) Разматрање меморије и меморије
Након бројева капацитета, можемо их екстраполирати да добијемо,
- Капацитет складишта који би био потребан да прихвати очекивано оптерећење, На пример, можемо планирати да дизајнирамо решење за складиштење које ће подржати захтеве до 1 године.
Пример: Ако сваки скраћени УРЛ троши 50 бајтова, укупан број података / складишта потребних током једне године био би:
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB - Разматрање меморије је важно за планирање система из перспективе читаоца. тј. за системе који су тешки за читање - попут оног који покушавамо да направимо (јер би се УРЛ створио једном, али би му се приступило више пута).
Тешки системи за читање обично користе кеширање да би постали ефикаснији и избегавали читање из сталне меморије да би уштедели на И / О читању.
Претпоставимо, желимо да 60% наших захтева за читање спремимо у кеш меморију, тако да би током године било потребно 60% укупних читања током године к бајтова потребних за сваки унос
=> (60/100) x 100000 x 365 x (50/1024x1024) => 1045 MB ~ 1GBДакле, према нашим бројевима капацитета, овом систему би било потребно око 1 ГБ физичке меморије
д) Процене пропусног опсега
Процене пропусног опсега потребне су за анализу брзине читања и писања у бајтовима које би биле потребне за извођење система. Направимо процене према бројевима капацитета које смо узели.
Пример: Ако сваки скраћени УРЛ троши 50 бајтова, тада би укупне брзине читања и писања које би нам требале биле следеће:
WRITE - 1.15 x 50bytes = 57.5 bytes/s READS - 1157 x 50bytes = 57500 bytes/s => 57500 / 1024 => 56.15 Kb/s е) Дизајн система и алгоритам
Ово је у основи главна пословна логика или алгоритам који би се користио за испуњавање функционалних захтева. У овом случају желимо да генеришемо јединствене скраћене УРЛ адресе за дати УРЛ.
Различити приступи који би се могли користити за генерисање скраћених УРЛ-ова су:
Хасхинг: Можемо смислити генерисање скраћених УРЛ-ова тако што ћемо створити хеш улазне УРЛ адресе и доделити му хасх кључ као скраћену УРЛ адресу.
Овај приступ може имати неких проблема када постоје различити корисници услуге, а ако унесу исту УРЛ адресу, резултираће добијањем исте скраћене УРЛ адресе.
Унапред створене скраћене жицеи додељује се УРЛ-овима када се услуга зове: Други приступ може бити враћање унапријед дефинисаног скраћеног низа из спремишта већ генерисаних низова.
АПИ-ји услуге: Систем скраћивача УРЛ адреса можемо сматрати скупом АПИ-ја заснованих на РЕСТ-у који имају следеће крајње тачке:
- цреатеУрл (УРЛ низа, датум истека времена): Ова крајња тачка креира и враћа скраћени УРЛ са трајањем истека постављеним како је наведено у улазу.
- ретриевеУрл (Низ скраћениУрл): Ова крајња тачка преузима УРЛ који ће бити преусмерен према датом скраћеном УРЛ-у.
ф) Скалирање и паралелност
Скалирање је важно са аспекта нефункционалних захтева.
Бави се како систем може
- Скала под оптерећењем: Систем треба да буде у стању да се грациозно скалира под оптерећењем, а не само да престане да ради након што се догоди неочекивани скок оптерећења.
Препоручено читање => Технике скалирања
- Колико систем може бити ефикасан, на пример: ако се систем користи дуготрајног капацитета дуго времена, да ли ће се перформансе система погоршати или ће остати стабилно?
Може бити пуно различитих питања о дизајну система као доле, али уопштено говорећи, све ово би тестирало шире разумевање кандидата о различитим концептима о којима смо разговарали у решењу система за скраћивање УРЛ-ова.
П # 13) Дизајнирајте видео платформу попут Иоутубе-а.
Одговор: Овом питању се такође може приступити, на сличан начин као што смо горе расправљали о ТиниУрл питању (а ово се односи на готово сва питања о интервјуу за дизајн система). Један од фактора који би разликовао био би разгледање / детаље око система који желите да дизајнирате.
Дакле, за Иоутубе сви знамо његову апликацију за стримовање видео записа и има пуно могућности попут омогућавања кориснику да отпрема нове видео записе, стримовање веб емисија уживо итд. Дакле, док дизајнирате систем, требало би да примените потребне компоненте дизајна система. У овом случају, можда ћемо морати да додамо компоненте повезане са могућностима стримовања видео записа.
Можете разговарати о тачкама попут,
- Складиште: Какву бисте базу података изабрали за чување видео садржаја, корисничких профила, плејлиста итд.?
- Сигурност и аутентификација / ауторизација
- Кеширање: Будући да би стреаминг платформа попут иоутубе требала бити ефикасна, кеширање је важан фактор за дизајнирање било којег таквог система.
- Истовремено: Колико корисника може паралелно стримовати видео?
- Остале функционалности платформе попут услуге препоруке видео записа која препоручује / предлаже корисницима следеће видео снимке које могу гледати итд.
П # 14) Дизајнирајте ефикасан систем за управљање 6 лифтова и осигурајте да особа мора да сачека минимално време док чека да лифт стигне ?
Одговор: Ове врсте питања о дизајну система су нижег нивоа и очекује се да кандидат прво размисли о систему лифта и наведе све могуће функције које треба подржати и као решење дизајнира / креира класе и ДБ односе / шеме.
Из перспективе СДЕТ-а, анкетар би само очекивао главне класе за које мислите да би их имала ваша апликација или систем и да би се основним функционалностима бавило предложеним решењем.
Погледајмо разне функционалности система лифта које би се очекивале
Можете поставити разјашњења попут
- Колико има спратова?
- Колико има лифтова?
- Да ли су сви лифтови сервисни / путнички лифтови?
- Да ли су сви лифтови конфигурисани да се зауставе на сваком спрату?
Ево различитих случајева примене који су применљиви за једноставан систем лифта:
Што се тиче основних класа / објеката овог система, можете размотрити следеће:
- Корисник: Бави се свим својствима корисника и радњама које може предузети у вези са објектом лифта.
- Лифт: Лифт Специфична својства попут висине, ширине, елевације_серијски_број.
- Врата лифта: Све ствари повезане са вратима као што су врата, врста врата, аутоматска или ручна итд.
- Елеватор_Буттон_Цонтрол: Доступни су различити тастери / команде у лифту и различита стања у којима те контроле могу бити.
Када завршите са дизајнирањем класа и њихових односа, можете разговарати о конфигурисању ДБ шема.
Друга важна компонента система лифта је Евентинг Систем. Можете разговарати о примени редова или у сложенијој поставци стварањем токова догађаја користећи Апацхе Кафка где се догађаји достављају одговарајућим системима на које треба да се делује.
Евентинг систем је важан аспект јер лифт истовремено користи више корисника (на различитим спратовима). Стога би захтеви корисника требало да се ставе у ред чекања и послужују у складу са конфигурисаном логиком у контролерима лифта.
П # 15) Дизајнирајте Инстаграм / Твиттер / Фацебоок.
Одговор: Све ове платформе су на неки начин повезане, јер омогућавају корисницима да се на неки начин повежу и деле ствари путем различитих врста медија - попут порука / видео записа и ћаскања.
Дакле, за ове типове апликација / платформи друштвених медија, требали бисте укључити доленаведене тачке док разговарате о дизајнирању таквих система (поред онога што смо разговарали о дизајнирању система за скраћивање УРЛ-а):
- Процена капацитета: Већина ових система би била тешка за читање, стога је потребна процена капацитета и омогућила би нам да осигурамо да одговарајућа конфигурација сервера и базе података буде обезбеђена да служи потребном оптерећењу.
- ДБ шема: Главне важне ДБ шеме о којима би требало разговарати су - Кориснички детаљи, Кориснички односи, Шеме порука, Шеме садржаја.
- Сервери за хостинг видео и слика: Већина ових апликација има видео записе и слике које корисници деле. Стога сервери за хостовање видеа и слика треба да буду конфигурисани према потребама.
- Сигурност: Све ове апликације треба да обезбеде висок ниво сигурности захваљујући подацима о кориснику / подацима о личној идентификацији корисника које чувају. Било какав покушај хаковања, СКЛ Ињецтион не би требало да буде успешан на овим платформама, јер би могао коштати губитак података милиона купаца.
Проблеми засновани на сценарију
Проблеми засновани на сценарију углавном су за људе на вишем нивоу, где се дају различити сценарији у стварном времену и кандидати питају њихова размишљања о томе како ће се носити са таквом ситуацијом.
П # 16) С обзиром на то да хитну исправку треба објавити што је пре могуће - какву бисте стратегију тестирања имали?
Одговор: Сада овде суговорник у суштини жели да разуме
- Како и какве стратегије тестирања можете да смислите?
- Коју покривеност бисте учинили за хитну исправку?
- Како бисте потврдили хитну исправку након примене? итд.
Да бисте одговорили на таква питања, могли бисте да користите ситуације из стварног живота ако се можете повезати са проблемом. Такође бисте требали напоменути да без одговарајућег тестирања не бисте били спремни да пустите било који код у продукцију.
За критичне исправке увек треба да радите заједно са програмером и покушавате да разумете на која подручја то може утицати и припремите непроизводно окружење за копирање сценарија и тестирање исправке.
Овде је такође важно напоменути да бисте наставили да надгледате поправак (помоћу алата за надгледање, контролне табле, евиденције итд.) Након постављања како бисте видели било какво абнормално понашање у производном окружењу и осигурали да нема негативног утицаја исправке која је Готово.
Могу постојати и друга питања која су углавном за разумевање перспективе кандидата на тестирање аутоматизације, рокове испоруке итд. (А та питања могу се разликовати од компаније до компаније, као и стаж улоге. Генерално се ова питања постављају за виши / водећи ниво улоге)
П # 17) Да ли бисте жртвовали потпуно тестирање да бисте брзо објавили производ?
Одговор: Ова питања обично укључују анкетара да схвати ваше мисли из перспективе лидерства и које су ствари око којих бисте направили компромис и да ли бисте били спремни да уместо краћег времена пустите производ са грешком.
Одговори на ова питања треба да се поткрепе стварним искуствима кандидата.
На пример, могли бисте напоменути да сте раније морали да позовете да бисте објавили неку хитну исправку, али није могла да се тестира због недоступности интеграционог окружења. Дакле, издали сте га контролисано - избацивањем на мањи проценат, а затим надгледањем евиденција / догађаја и иницирањем пуног увођења итд.
П # 18) Како бисте креирали стратегију аутоматизације за производ који уопште нема тестове аутоматизације?
Одговор: Овакве врсте питања су отвореног типа и углавном су добро место за вођење расправе онако како ви желите. Такође можете представити своје вештине, знање и технолошка подручја која су ваша снага.
На пример, да бисте одговорили на ове врсте питања, можете навести примере Стратегије аутоматизације коју сте усвојили док сте производили производ у прошлој улози.
На пример, могли бисте споменути тачке попут,
- Будући да је производ захтевао покретање аутоматизације од нуле, добили сте довољно времена да размислите и дизајнирате одговарајући оквир аутоматизације избором језика / технологије коју би већина људи имала да би избегла увођење новог алата и искористила постојеће знање.
- Почели сте с аутоматизацијом најосновнијих функционалних сценарија за које се сматрало да су П1 (без којих ниједно издање не може проћи).
- Такође сте размишљали о тестирању перформанси и скалабилности система помоћу аутоматизованих алата за тестирање попут ЈМЕТЕР, ЛоадРуннер итд.
- Размишљали сте о аутоматизацији безбедносних аспеката апликације како су наведени у ОВАСП Стандарди безбедности.
- Интегрисали сте аутоматизоване тестове у цевовод изградње за ране повратне информације итд.
Теам Фит & Цултуре Фит
Овај круг углавном зависи од компаније до компаније. Али потреба / потреба овог круга је разумевање кандидата из перспективе тимске и организационе перспективе културе. Сврха ових питања је такође разумевање личности кандидата и њиховог приступа раду / људима итд.
Генерално, менаџери за људске ресурсе и запошљавање су ти који воде ову рунду.
Питања која се обично јављају током овог круга су следећа:
П # 19) Како решавате сукобе у оквиру ваше тренутне улоге?
Одговор: Даље објашњење је следеће: претпоставимо да имате сукоб са шефом или непосредним члановима тима, које кораке предузимате за решавање тих сукоба?
За ову врсту питања поткрепите што више можете стварним примерима који су се могли догодити током ваше каријере у тренутној или претходној организацији.
Можете споменути ствари попут:
- Волите да што пре решите све сукобе који настану као резултат професионалних разлога (и због којих не бисте желели да утичу на ваше личне односе).
- Можете напоменути да углавном покушавате да ефикасно комуницирате и разговарате / разговарате са особом појединачно како бисте решили било какве разлике / проблеме.
- Можете напоменути да бисте, ако се ствари погоршају, затражили помоћ старије особе / вашег менаџера и добили његове улоге.
Остали примери тимског / културног прилагођавања питања су у наставку (на већину њих треба одговорити на сличан начин на који смо дискутовали за претходно питање. Разговор о стварним сценаријима овде је кључ, јер га анкетар може повезати на бољи начин добро.
П # 20) Какву равнотежу између пословног и приватног живота очекујете од нове улоге за коју сматрате да сте ангажовани?
Одговор: Будући да је Хиринг Манагер неко ко зна шта захтева улога, колико додатних напора може бити потребно понекад, тако да генерално анкетар покушава да процени да ли се ваша очекивања радикално разликују од онога што улога очекује.
Претпоставимо да кажете да не желите да присуствујете ноћним састанцима, а улога очекује да имате велику сарадњу између тима који седи у другој временској зони, тада би испитивач могао покренути дискусију да су то очекивања од улоге - да ли ћете моћи да прилагодити? итд.
Дакле, ово је више лежеран разговор, али из перспективе анкетара, они желе да разумеју ваша очекивања да оцене вашу кандидатуру за позицију са којом сте интервјуисани.
П # 21) Који су твоји хобији осим посла?
Одговор: Ова питања су искључиво субјективна и специфична за појединца, а она су углавном корисна да би се кандидат осећао опуштено и лако и покренула неформалне дискусије.
Генерално, одговори на ова питања могу бити попут - волите да читате одређени жанр, волите музику, добили сте неку награду за неку добровољну / филантропску активност итд. Такође, ова питања се углавном постављају у кругу људских ресурса (и ређе ће бити затражено од техничког лица).
П # 22) Колико сте времена спремни да проактивно посветите учењу нових алата и технологија?
Одговор: Овде анкетар процењује вашу спремност да научите нове ствари ако вам се баци нешто необично или ново. Такође анкетару даје до знања да сте проактивни? Да ли сте спремни да инвестирате у себе и своју каријеру? итд.
Дакле, док одговарате на таква питања - будите искрени и своје одговоре поткрепите примерима - На пример, Можете напоменути да сте се прошле године појавили за Јава сертификат и да сте се припремали ван посла одузимајући неколико сати сваке недеље.
Закључак
У овом чланку разговарали смо о инжењеру софтверског развоја у процесу испитивања и узорцима питања која се углавном постављају од кандидата у различитим организацијама и профилима. Генерално, СДЕТ интервјуи су врло широке природе и увелико зависе од компаније до компаније.
Али процеси интервјуа слични су оним за профил програмера са већим нагласком на оквире квалитета и аутоматизације.
Важно је схватити да су данас компаније мање фокусиране на било који одређени језик или технологију, већ више на широко разумевање концепата и способност прилагођавања алатима / технологијама које компанија захтева.
Најлепше жеље за ваш СДЕТ интервју!
Препоручено читање
- Шта је СДЕТ: знајте разлику између тестера и СДЕТ-а
- Питања и одговори за интервјуе
- Питања и одговори за испитивање ЕТЛ-а
- Нека незгодна ручна тестирања питања и одговори
- Споцк интервју питања са одговорима (најпопуларније)
- 25 најбољих питања о агилном тестирању за интервјуе и одговоре
- 32 најбоља питања и одговори за интервју за Датастаге
- Топ 20+ .НЕТ питања и одговори за интервјуе
