sdet interview questions
Læs denne komplette guide til softwareudviklingsingeniør i testinterviews for at kende formatet og hvordan man besvarer SDET-interviewspørgsmål stillet i de forskellige runder:
I denne vejledning lærer vi om nogle ofte stillede interviewspørgsmål til SDET-roller. Vi vil også generelt se det fælles mønster for interviews og dele nogle tip til at udmærke sig i interviews.
Vi bruger Java-sprog til kodningsproblemerne til denne tutorial, men de fleste af SDET-tutorials er sprogagnostiske, og interviewere er generelt fleksible omkring det sprog, som kandidaten vælger at bruge.
Hvad du lærer:
Guide til forberedelse af SDET-interview
SDET-interviews, i de fleste af de største produktfirmaer, ligner meget den måde, interviews gennemføres på for udviklingsroller. Dette skyldes, at SDET'er også forventes at vide og forstå stort set alt, hvad udvikleren ved.
Hvad der adskiller sig er kriterierne, som SDET-interviewpersonen vurderes på. Interviewere til denne rolle ser efter kritiske tænkningskompetencer, såvel som om den person, der interviewes, har praktisk erfaring med kodning og har øje for kvalitet og detaljer.
Her er nogle punkter, som nogen, der forbereder sig på et SDET-interview, i høj grad bør fokusere på:
netværk fejlfinding interview spørgsmål og svar pdf
- Da disse interviews oftest er agnostiske inden for teknologi / sprog, skal kandidater derfor være villige til at lære ny teknologi (og udnytte eksisterende færdigheder) efter behov.
- Bør have gode kommunikations- og teamfærdigheder, da SDET-roller i disse dage kræver kommunikation og samarbejde på forskellige niveauer med flere interessenter.
- Bør have en grundlæggende forståelse af forskellige systemdesignkoncepter, skalerbarhed, samtidighed, ikke-funktionelle krav osv.
I afsnittene nedenfor vil vi forsøge at forstå det generelle format for Interviewet sammen med nogle eksempler på spørgsmål.
Format af softwareudviklingsingeniør i testinterview
De fleste af virksomhederne har deres foretrukne format til at interviewe kandidater til en SDET-rolle som til tider, rollen er superspecifik for et team, og personen forventes at blive evalueret som en perfekt pasform til det team, personen bliver ansat til.
Men temaet for interviews er generelt baseret på nedenstående punkter:
- Telefonisk diskussion: Samtale med manager og / eller teammedlemmer, som normalt er en screeningsrunde.
- Skriftlig runde: Med test / test casing specifikke spørgsmål.
- Kodningsfærdighedsrunde: Enkle kodningsspørgsmål (sprogagnostik), og kandidaten bliver bedt om at skrive produktionskodekode.
- Forståelse af grundlæggende udviklingskoncepter: Ligesom OOPS-koncepter, SOLID-principper osv.
- Test Automation Framework design og udvikling
- Scripting sprog: Selen, Python, Javascript osv
- Culture Fit / HR diskussion og forhandlinger
SDET Interview Spørgsmål og svar
I dette afsnit vil vi diskutere nogle eksempler på spørgsmål sammen med detaljerede svar for forskellige kategorier, der stilles af de fleste produktfirmaer, der ansætter til SDET-roller.
Kodningsfærdighed
I denne runde gives enkle kodningsproblemer til at skrive på det valgte sprog. Her ønsker intervieweren at måle færdighederne med kodningskonstruktioner samt håndtere ting som kantscenarier og nulchecks osv.
Lejlighedsvis kan interviewere også bede om at nedskrive enhedstest til det skrevne program.
Lad os se nogle eksempler på problemer.
Q # 1) Skriv et program til at bytte 2 tal uden at bruge den tredje (midlertidige) variabel?
Svar :
Program til at bytte to tal:
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); } }
Her er output fra ovenstående kodestykke:
I ovenstående kodestykke er det vigtigt at bemærke, at intervieweren specifikt har bedt om at bytte 2 numre uden at bruge en tredje midlertidig variabel. Det er også vigtigt, at det altid anbefales at gå igennem (eller tørre) koden til mindst 2-3 input, før løsningen sendes. Lad os prøve at få positive og negative værdier.
Positive værdier: 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)
Negative værdier: 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) Skriv et program for at vende et nummer?
Svar: Nu kan problemangivelsen oprindeligt se skræmmende ud, men det er altid klogt at bede om at afklare spørgsmål til intervieweren (men ikke mange detaljer). Interviewere kan vælge at give tip om problemet, men hvis kandidaten stiller mange spørgsmål, peger det også på, at kandidaten ikke giver nok tid til at forstå problemet godt.
Her forventer problemet, at en kandidat også kommer med nogle antagelser - for eksempel, tallet kunne være et heltal. Hvis input er 345, skal output være 543 (hvilket er omvendt fra 345)
Lad os se kodestykket til denne løsning:
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; } }
Output for dette program mod input : 10025 - Forventet ville være : 52001
Spørgsmål nr. 3) Skriv et program til beregning af et tal?
Svar: Faktor er et af de mest stillede spørgsmål i næsten alle interviews (inklusive udviklerinterviews)
For udviklerinterviews er der mere fokus på programmeringskoncepter som dynamisk programmering, rekursion osv. Mens det fra Software Development Engineer i testperspektiv er det vigtigt at håndtere kantscenarier som maksimumværdier, minværdier, negative værdier osv. Og tilgang / effektivitet er vigtige, men bliver sekundære.
Lad os se et program til faktorielt brug af rekursion og for-loop med håndtering af negative tal og returnering af en fast værdi på sige -9999 for negative tal, som skal håndteres i programmet, der kalder faktorfunktionen.
Se nedenstående kodestykke:
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); } }
Lad os se output for - factorial ved hjælp af loop, factorial ved hjælp af rekursion og factorial af et negativt tal (som ville returnere en standardindstillet værdi på -9999)
Q # 4) Skriv et program for at kontrollere, om en given streng har afbalancerede parenteser?
Svar:
Nærme sig - Dette er et lidt komplekst problem, hvor intervieweren ser lidt mere ud end viden om bare kodningskonstruktioner. Her er forventningen at tænke og bruge den apt datastruktur til det aktuelle problem.
Mange af jer føler sig måske skræmte af disse typer problemer, da nogle af jer måske ikke har hørt disse, og selvom de er enkle, lyder de måske komplekse.
Men generelt til sådanne problemer / spørgsmål: For eksempel i det aktuelle spørgsmål, hvis du ikke ved hvad afbalancerede parenteser er, kan du meget vel spørge intervieweren og derefter arbejde hen imod løsningen i stedet for at ramme en blind plet.
Lad os se, hvordan vi nærmer os en løsning: Efter at have forstået, hvad afbalancerede parenteser er, kan du tænke på at bruge den rigtige datastruktur og derefter begynde at skrive algoritmer (trin), før du begynder at kode løsningen. Mange gange løser algoritmerne i sig selv mange kantscenarier og giver meget klarhed over, hvordan løsningen vil se ud.
Lad os se på løsningen:
Balancerede parenteser er at kontrollere for en given streng, der indeholder parenteser (eller parenteser), skal have lige antal åbning og lukning såvel som positionelt godt struktureret. I forbindelse med dette problem bruger vi afbalancerede parenteser som - '()', '[]', '{}' - dvs. en given streng kan have en hvilken som helst kombination af disse parenteser.
Vær opmærksom på, at inden du prøver problemet, er det godt at afklare, om strengen bare indeholder parentestegn eller tal osv. (Da dette kan ændre logikken en smule)
Eksempel: En given streng - '{[] {} ()} - er en afbalanceret streng, da den er struktureret og har lige stort antal lukke- og åbningsparenteser, men streng -' {[}] {} () '- denne streng - selvom har lige stort antal åbnings- og lukkeparenteser, dette er stadig ikke afbalanceret, fordi du kan se, at uden at lukke '[' vi har lukket '}' (dvs. alle indre parenteser skal lukkes, inden du lukker en ydre parentes)
Vi bruger en stakdatastruktur til at løse dette problem. Hvis du vil vide mere om grundlæggende stak, se her
En stak er en LIFO (Last In First Out type datastruktur), tænk på den som en stak / bunke af plader ved et bryllup - du henter den øverste plade, når du bruger den.
Algoritme:
# 1) Erklær en tegnstabel (som vil indeholde tegnene i strengen og afhængigt af en eller anden logik, skub og pop tegnene ud).
# 2) Gå gennem inputstrengen og når som helst
- Der er et åbningsbeslagstegn - dvs. '[', {'eller' ('- skub tegnet på Stack.
- Der er et lukkende tegn - dvs. ']', '}', ')' - pop et element fra Stack og kontroller, om det svarer til det modsatte af lukkende karakter - dvs. hvis tegnet er '}' så skal du forvente på Stack pop {'
- Hvis det poppede element ikke stemmer overens med de afsluttende parenteser, er strengen ikke afbalanceret, og du kan returnere resultater.
- Ellers fortsæt med stack push og pop tilgang (gå til trin 2).
- Hvis strengen krydses fuldstændigt, og stakstørrelsen også er nul, kan vi sige / udlede, at den givne streng er en afbalanceret parentesstreng.
På dette tidspunkt vil du måske også diskutere den løsningsmetode, du har som algoritme, og sikre, at intervieweren er ok med tilgangen.
Kode:
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 Outputtet fra ovenstående kodestykke:
Som vi gjorde for vores tidligere kodningsproblemer, er det altid godt at tørre køre koden med mindst 1-2 gyldige såvel som 1-2 ugyldige input og sikre, at alle sager håndteres korrekt.
BEMÆRK: Det er altid godt at tænke løsningen højt (og ikke kun i sindet) - og overraskende er dette et vigtigt træk, som interviewere leder efter. Mange interviewere kunne bare fjerne algoritmen og gå videre til næste problemopgørelse.
I ovenstående kodeløsning til udviklerinterviewet kan intervieweren bede om at løse det ved hjælp af arrays i stedet for direkte stack (dvs. ved hjælp af array som en stack), men generelt handler det mere om at være konceptuelt klar og i stand til at håndtere alle gyldige og ugyldige input.
Test Automation Framework-relateret
Dette afsnit af interviewet er mere specifikt omkring testning og SDET-ansvar. Forvent automatiseringsrammedesign og udviklingsrelaterede spørgsmål, fordele og ulemper ved at bruge forskellige tilgange mv.
Lad os se nogle eksempler på spørgsmål og løsninger til det samme.
Spørgsmål nr. 5) Forklar og design komponenter i automatiseringsrammen til en webapplikation?
Svar: Dette spørgsmål er lidt subjektivt, og intervieweren har til hensigt at måle, hvor meget kandidaten ved om rammedesignet og -udviklingen. Svaret på dette spørgsmål hjælper intervieweren med at forstå, om kandidaten kan oprette eller oprette brugerdefinerede rammer fra bunden.
Lad os se et par punkter, der kan hjælpe dig med at strukturere løsningen på dette spørgsmål:
- Du kan tale om forskellige typer rammer som - Datadrevet, Keyword-driven, Hybrid Framework.
- Sideobjektmodel til lagring af detaljer om forskellige elementer på forskellige sider / moduler i webapplikationen.
- Almindelige moduler som hjælperfunktioner, hjælpeprogrammer, loggere osv.
- Rapporteringsmoduler som generering af rapporter om testudførelse, integration af rapporter med e-mail og planlægning af testudførelse osv.
Anbefalet læsning => Mest populære testautomatiseringsrammer
Q # 6) Forklar teststrategier for en mobilapplikation?
Svar: Disse spørgsmål stilles typisk afhængigt af rollen. Hvis rollen hovedsagelig er at arbejde på mobilapps, er spørgsmålet mere relevant. Du kan tale fra din oplevelse, hvis du har planlagt mobil test som en del af dine nuværende eller tidligere roller.
Nogle tips til at strukturere svaret på dette spørgsmål kan være,
- Test på enheder vs emulatorer.
- Identificering og lagring af objekter / elementer på forskellige skærme - Eksempel: Sideobjektmodel.
- Loadtestning af en mobilapplikation.
- Du kan tale om forskellige typer mobilapplikationer som - Native apps, Hybrid-apps og diskutere strategier / tilgange, du vil bruge til at teste dem.
Anbefalet læsning => Vejledninger til test af mobilapps
Q # 7) Designe en automatiseringsramme til test af REST API'er?
Svar: Dette er igen et subjektivt spørgsmål, og du kan stille afklarende spørgsmål, om intervieweren vil have dig til at udvikle en ramme til test af funktionel opførsel af API eller ikke-funktionelle krav som Load / Performance-test.
Du kan starte dit svar, der dækker nedenstående punkter:
- API Automation-rammekomponenter som lokal opsætning, Mock-opsætning af API eller hostet API-test.
- Værktøjer, der bruges til API-automatisering. Der er forskellige værktøjer tilgængelige ud af kassen til at validere de funktionelle aspekter af en REST-baseret API. Nogle af disse værktøjer er postbud, være sikre osv. For detaljerede detaljer om forskellige værktøjer kan du henvise til vores artikel her .
- Ikke-funktionel automatisering af API'erne.
- Planlagt udførelse af automatiseringstest.
- Integrering af automatiseringstest til API'er.
Q # 8) Rammespecifikke spørgsmål.
Svar: Til tider afhængigt af den profil, der interviewes, kan der være et krav for, at en kandidat skal være dygtig med en bestemt ramme - f.eks. Selen, JMeter osv.
Anbefalet læsning => Postbud , Mockito , Specflow , Selen , JMeter
Testrelateret
Selvom det sjældent, men afhængigt af profilen, kan der være spørgsmål omkring generel testpraksis, vilkår og teknologier - som sværhedsgrad, prioritet, testplanlægning, testkabinet osv. En SDET forventes at kende alle manuelle testkoncepter og bør være bekendt med de vigtige terminologier.
I dette afsnit kan du forvente spørgsmål som disse:
Q # 9) Hvad er de forskellige komponenter i en testplan?
Svar: Disse bliver generelt bedt om at validere de grundlæggende testkoncepter og tankegang. Disse vilkår og dokumenter er noget, som enhver manuel kvalitetssikring såvel som automatiserings-SDET'er bør kende.
Du kan diskutere forskellige komponenter i testplanen her som,
- Indgangs- og udgangskriterier
- Anvendelsesområde: Diskuter testfunktionerne, der er inden for omfanget, og hvad alt ville være automatiseret - vil det bare være funktionelle funktioner eller ikke-funktionelle krav som skalerbarhed, ydeevne osv.
- Tidslinjer
- Værktøjer, der skal bruges
- Ressourcetildeling mv
Anbefalet læsning => Hvordan man skriver en god testplan
Spørgsmål nr. 10) Hvad definerer og bestemmer en fejls prioritet og sværhedsgrad?
Svar: Defektprioritet og sværhedsgrad kan let forklares ved hjælp af eksempler. Antag at en funktion som tilmelding er brudt og forhindrer brugere i at få adgang til applikationen - så er det et højt prioriteret og højt alvorligt problem. Tilsvarende kan der være eksempler på defekter med lav alvorlighedsgrad / høj prioritet og forskellige andre kombinationer.
Generelt,
- Prioritet betyder betydningen af problemet.
- Alvorlighed betyder den indvirkning, som problemet har på kunden eller brugeren af applikationen.
Anbefalet læsning => Defektprioritet og sværhedsgrad
Spørgsmål nr. 11) Hvad er ækvivalenspartitionering? Illustrer med et eksempel.
Svar: Ækvivalenspartitionering er en teknik, der oftest bruges til Black Box-test til at teste forskellige kombinationer af input mod et givet felt.
For eksempel, hvis du tester en handelsapplikation, og du vil skrive alle testscenarier for feltet 'Mængde' - hvad ville de forskellige input være, du ville teste for dette felt?
I betragtning af at det funktionelle krav er, at mængden skal være et positivt heltal mellem 1 og 100000. Så for at teste forskellige input (både gyldige og ugyldige) kan du have tests til 1 input fra hver sådan kategori.
- Gyldige værdier: Mellem 1 og 100000 -> test for enhver gyldig værdi x sådan at x> 1 og x<100000.
- Grænseværdier: Test for de tilladte grænseværdier, dvs. 1 & 100000.
- Ugyldige værdier: Værdier, der ligger uden for det tilladte interval - dvs. test for en sådan værdi for x, således at x 100000.
Anbefalet læsning => Ækvivalensopdelingsstrategi
Systemdesign relateret
Systemdesignspørgsmål er typisk mere velegnede til udviklerinterviews, hvor en udvikler vurderes ud fra en bred forståelse af forskellige generelle begreber - som skalerbarhed, tilgængelighed, fejltolerance, databasevalg, trådning osv. I en nøddeskal skal du bruge hele din erfaring og systemviden til at besvare sådanne spørgsmål.
Men du føler måske, at et system, der tager mange års erfaring og hundreder af udviklere til at kode, hvordan kunne en person besvare spørgsmålet omkring 45 minutter?
Svaret er: Her forventes det at bedømme kandidatens forståelse og det brede spektrum af viden, som han eller hun kan anvende, mens han løser komplekse problemer.
I dag begynder disse spørgsmål også at blive kastet i SDET-interviews. Her forbliver forventningen den samme som for udviklerinterviewet, men med afslappede vurderingskriterier og det er for det meste en bar-raiser-runde, hvor en kandidat afhængigt af kandidatens svar kan overvejes til næste niveau eller flyttes til et lavere niveau.
Generelt skal kandidaten være fortrolig med nedenstående begreber for spørgsmål til systemdesigninterview
- Grundlæggende om operativsystemer: Personsøgning, filsystemer, virtuel hukommelse og fysisk hukommelse osv.
- Netværkskoncepter: HTTP-kommunikation, TCP / IP-stak, netværkstopologier.
- Skalerbarhedskoncepter: Vandret og lodret skalering.
- Konkurrence / trådkoncepter
- Databasetyper: SQL / Ingen SQL-databaser, hvornår man skal bruge hvilken type database, fordele og ulemper ved forskellige typer databaser.
- Hashing teknikker
- Grundlæggende forståelse af KASKET sætning, sharding, partitionering osv.
Lad os se nogle eksempler på spørgsmål
Q # 12) Design et URL-forkortelsessystem som en lille URL ?
Svar: Mange kandidater kender muligvis ikke engang URL-forkortelsessystemer generelt. I så fald er det ok at spørge intervieweren om problemstillingen i stedet for at dykke ned uden forståelse.
Inden selv svar på sådanne spørgsmål skal kandidaterne strukturere løsningen og skrive punkter og derefter begynde at diskutere løsningen med intervieweren.
Lad os diskutere løsningen kort
a) Afklare funktionelle og ikke-funktionelle krav
Funktionelle krav: Funktionelt krav er bare ud fra en kundes perspektiv, det er et system, der tilføres en stor URL (lang længde), og output skal være en forkortet URL.
Når der er adgang til den forkortede URL, skal den omdirigere brugeren til den oprindelige URL. For eksempel - prøv at forkorte en faktisk URL på https://tinyurl.com/ webside, feed en input URL som www.softwaretestinghelp.com, og du skal få en lille URL som https://tinyurl.com/shclcqa
Ikke-funktionelle krav: Systemet skal være performant med hensyn til omdirigering med millisekund latenstid (da det er et ekstra hop for en bruger, der får adgang til den oprindelige URL).
- Forkortede webadresser skal have en konfigurerbar udløbstid.
- Forkortede webadresser bør ikke være forudsigelige.
b) Kapacitet / trafikestimering
Dette er meget vigtigt set ud fra alle systemdesignspørgsmål. Kapacitetsestimering bestemmer i det væsentlige den forventede belastning, som systemet vil få. Det er altid godt at starte med en antagelse og diskutere med intervieweren. Dette er også vigtigt ud fra perspektivet ved planlægning af databasestørrelsen, hvad enten systemet er læsetungt eller skrivetungt osv.
Lad os lave nogle kapacitetsnumre til eksemplet på URL-forkortelsen.
Antag, at der vil være 100.000 nye URL-forkortelsesanmodninger pr. Dag (med 100: 1 læse-skrive-forhold - dvs. for hver 1 forkortede URL vil vi have 100 læseanmodninger mod den forkortede URL)
Så vi får,
100k write requests/day => 100000/(24x60x60) => 1.15 request/second 10000k read requests/day => 10000000/(24x60x60) => 1157 requests/second
c) Opbevaring og hukommelse
Efter kapacitetstallene kan vi ekstrapolere disse tal for at få,
- Den lagringskapacitet, der kræves for at imødekomme den forventede belastning, For eksempel, Vi kan planlægge at designe en lagerløsning, der understøtter anmodningerne i op til 1 år.
Eksempel: Hvis hver forkortede URL bruger 50 byte, vil den samlede data / lagerplads, som vi har brug for over et år, være:
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB
- Hukommelsesovervejelser er vigtige for at planlægge systemet ud fra læsernes perspektiv. dvs. for systemer, der er læsetunge - som den, som vi prøver at bygge (fordi URL'en oprettes en gang, men der er adgang til den flere gange).
Læs tunge systemer bruger generelt caching for at blive mere performante og undgå læsning fra den permanente lager for at spare på læst I / O.
Lad os antage, at vi vil gemme 60% af vores læseanmodninger i cachen, så i løbet af året ville vi kræve 60% af de samlede læsninger i løbet af året x byte, der kræves af hver post
=> (60/100) x 100000 x 365 x (50/1024x1024) => 1045 MB ~ 1GB
Så i henhold til vores kapacitetstal ville dette system kræve ca. 1 GB fysisk hukommelse
d) Skøn over båndbredde
Der kræves båndbreddestimater for at analysere læse- og skrivehastigheden i bytes, der kræves for at et system skal udføres. Lad os foretage skøn over de kapacitetstal, vi har taget.
Eksempel: Hvis hver forkortede URL bruger 50 byte, vil de samlede læse- og skrivehastigheder, som vi har brug for, være som nedenfor:
WRITE - 1.15 x 50bytes = 57.5 bytes/s READS - 1157 x 50bytes = 57500 bytes/s => 57500 / 1024 => 56.15 Kb/s
e) Systemdesign og algoritme
Dette er i det væsentlige den vigtigste forretningslogik eller -algoritme, der vil blive brugt til at opfylde de funktionelle krav. I dette tilfælde ønsker vi at generere unikke forkortede URL'er til en given URL.
De forskellige tilgange, der kunne bruges til at generere forkortede webadresser, er:
Hashing: Vi kan tænke på at generere forkortede URL'er ved at oprette en hash af input-URL'en og tildele hash-nøglen som den forkortede URL.
Denne tilgang kan have nogle problemer, når der er forskellige brugere af tjenesten, og hvis de indtaster den samme URL, vil de resultere i at få den samme forkortede URL.
Forudoprettede forkortede strengeog tildeles URL'er, når tjenesten kaldes: En anden tilgang kan være at returnere en foruddefineret forkortet streng fra puljen af allerede genererede strenge.
Service-API'er: Vi kan tænke på URL-forkortelsessystemet som et sæt REST-baserede API'er, der har følgende slutpunkter:
- createUrl (String url, DateTime expiryTime): Dette slutpunkt opretter og returnerer en forkortet URL med udløbsvarighed indstillet som angivet i input.
- retrieveUrl (streng afkortetUrl): Dette slutpunkt henter URL, der skal omdirigeres mod den givne forkortede URL.
f) Skalering og samtidighed
Skalering er en vigtig overvejelse fra et ikke-funktionelt kravperspektiv.
Det handler om, hvordan kan systemet
- Skala under belastning: Systemet skal være i stand til at skalere under belastning og ikke bare stoppe med at arbejde efter en uventet stigning i belastning opstår.
Anbefalet læsning => Skaleringsteknikker
- Hvor effektiv kan systemet være, for eksempel: hvis systemet bruges med vedvarende kapacitet i lang tid, ville systemets ydelse forringes eller forblive det stabilt?
Der kan være mange forskellige spørgsmål om systemdesign som nedenfor, men generelt vil alle disse teste kandidatens bredere forståelse af forskellige begreber, som vi har diskuteret i løsningen på URL-afkortningssystemet.
Q # 13) Design en videoplatform som Youtube.
Svar: Dette spørgsmål kan også tilgås på samme måde som vi har diskuteret TinyUrl-spørgsmålet ovenfor (og dette gælder næsten alle spørgsmål om systemdesigninterview). Den eneste differentierende faktor ville være at se / detaljer omkring det system, du vil designe.
Så for Youtube ved vi alle, at det er en applikation til videostreaming og har mange muligheder som at lade en bruger uploade nye videoer, streame live webcasts osv. Så mens du designer systemet, skal du anvende de nødvendige systemdesignkomponenter. I dette tilfælde skal vi muligvis tilføje komponenter relateret til videostreamingfunktioner.
Du kan diskutere punkter som,
- Opbevaring: Hvilken type database ville du vælge at gemme videoindhold, brugerprofiler, afspilningslister osv.?
- Sikkerhed og godkendelse / godkendelse
- Caching: Da en streamingplatform som youtube skal være performant, er caching en vigtig faktor for design af et sådant system.
- Samtidighed: Hvor mange brugere kan streame video parallelt?
- Andre platformsfunktioner som videoanbefalingstjeneste, som anbefaler / foreslår brugere de næste videoer, de kan se osv.
Q # 14) Design et effektivt system til betjening af 6 elevatorer og sørg for, at en person skal vente i min tid, mens de venter på, at liften ankommer ?
Svar: Disse typer af systemdesignspørgsmål er mere lavt niveau og forventer, at kandidaten først tænker igennem elevatorsystemet og viser alle mulige funktioner, der skal understøttes, og designer / opretter klasser og DB-relationer / skemaer som løsningen.
Fra SDET-perspektivet ville intervieweren bare forvente de hovedklasser, som du tror, din applikation eller dit system ville have, og de grundlæggende funktioner blev håndteret med den foreslåede løsning.
Lad os se forskellige funktioner i liftsystemet, som man kunne forvente
Du kan stille afklarende spørgsmål som f.eks
- Hvor mange etager er der?
- Hvor mange elevatorer er der?
- Er alle elevatorer service- / passagerlifte?
- Er alle elevatorer konfigureret til at blive stoppet på hver etage?
Her er de forskellige brugssager, der gælder for et simpelt elevatorsystem:
Med hensyn til kerneklasser / objekter i dette system kan du overveje at have:
- Bruger: Beskæftiger sig med alle brugerens egenskaber og handlinger, de kan udføre på Elevator Object.
- Elevator: Elevator Specifikke egenskaber som højde, bredde, elevator_serienummer.
- Elevatordør: Alle ting relateret til døren som ingen døre, type dør, automatisk eller manuel osv.
- Elevator_Button_Control: Forskellige knapper / knapper findes i elevatoren og forskellige tilstande, som disse kontroller kan være i.
Når du er færdig med at designe klasser og deres forhold, kan du tale om konfiguration af DB-skemaer.
En anden vigtig komponent i Elevator-systemet er Eventing System. Du kan tale om implementering af køer eller i en mere kompleks opsætning ved at oprette begivenhedsstrømme ved hjælp af Apache Kafka, hvor begivenhederne leveres til de respektive systemer, der skal handles efter.
Eventing System er et vigtigt aspekt, da der er flere brugere (på forskellige etager), der bruger liften på samme tid. Derfor skal brugerens anmodninger stå i kø og serveres i henhold til den konfigurerede logik i Elevator-controllerne.
Q # 15) Design Instagram / Twitter / Facebook.
Svar: Alle disse platforme er på en måde relateret, da de giver brugerne mulighed for at blive forbundet på en eller anden måde og dele ting via forskellige medietyper - som beskeder / videoer og chats også.
Så for disse typer sociale medieapplikationer / -platforme skal du medtage nedenstående punkter, mens du diskuterer design af sådanne systemer (ud over det, vi har diskuteret for design af URL-forkortelsessystem):
- Kapacitetsestimering: De fleste af disse systemer vil være læsetunge, hvorfor kapacitetsestimering er påkrævet og giver os mulighed for at sikre, at passende server- og databasekonfiguration er sikret til at betjene den krævede belastning.
- DB-ordning: De vigtigste vigtige DB-skemaer, der skal diskuteres, er - Brugeroplysninger, Brugerforhold, Beskedskemaer, Indholdsskemaer.
- Video- og billedhosting-servere: De fleste af disse applikationer har videoer og billeder, der deles på tværs af brugere. Derfor skal Video- og Image Hosting-serverne konfigureres efter behov.
- Sikkerhed: Alle disse apps skal sikre et højt sikkerhedsniveau på grund af brugerinformation / personligt identificerbar information om de brugere, de gemmer. Ethvert forsøg på hacking, SQL Injection bør ikke være vellykket på disse platforme, da det kan koste at miste data fra millioner af kunder.
Scenariobaserede problemer
Scenariobaserede problemer er generelt for folk på seniorniveau, hvor forskellige realtidsscenarier gives, og kandidaten bliver spurgt om deres tanker om, hvordan de vil håndtere en sådan situation.
Spørgsmål nr. 16) I betragtning af at et kritisk hotfix skal frigives så hurtigt som muligt - Hvilken slags teststrategi ville du have?
Svar: Nu, her vil intervieweren i det væsentlige forstå
- Hvordan og hvilken slags teststrategier kan du tænke på?
- Hvilken dækning ville du gøre for et hotfix?
- Hvordan ville du validere hotfix efter implementering? etc.
For at besvare sådanne spørgsmål du kunne bruge virkelige situationer, hvis du kunne forholde dig til problemet. Du skal også nævne, at uden passende test ville du ikke være villig til at frigive nogen kode til produktion.
For de kritiske rettelser skal du altid arbejde sammen med udvikleren og prøve at forstå, hvilke områder det kan påvirke og forberede et miljø, der ikke er produktion, til at replikere scenariet og teste rettelsen.
Det er også vigtigt her at nævne, at du fortsætter med at overvåge rettelsen (ved hjælp af overvågningsværktøjer, dashboards, logfiler osv.) Efter implementering for at se unormal adfærd i produktionsmiljøet og sikre, at der ikke er nogen negativ indvirkning på den rettelse, der er Færdig.
Der kan også være andre spørgsmål, som for det meste er at forstå kandidatens perspektiv på automatiseringstest, leveringstidslinjer osv. (Og disse spørgsmål kan variere fra virksomhed til virksomhed såvel som anciennitet i rollen. Generelt stilles disse spørgsmål til senior / lead-niveau roller)
Spørgsmål nr. 17) Vil du ofre fuld test for at frigive et produkt hurtigt?
Svar: Disse spørgsmål involverer typisk intervieweren til at forstå dine tanker fra et lederskabsperspektiv, og hvad er de ting, du vil gå på kompromis med, og ville du være villig til at frigive et buggy-produkt i stedet for kortere tid.
Svarene på disse spørgsmål skal underbygges i forhold til kandidatens faktiske erfaringer.
For eksempel, du kunne nævne, at du tidligere var nødt til at ringe til at frigive noget hotfix, men det kunne ikke testes på grund af manglende tilgængelighed af integrationsmiljøet. Så du frigav det på en kontrolleret måde - ved at rulle ud til en mindre procentdel og derefter overvåge logfiler / begivenheder og derefter startede fuld udrulning osv.
Spørgsmål nr. 18) Hvordan ville du oprette automatiseringsstrategi for et produkt, der slet ikke har nogen automatiseringstest?
Svar: Disse typer af spørgsmål er åbne og er generelt et godt sted at tage diskussionen på den måde, du vil. Du kan også fremvise dine færdigheder, viden og teknologiområder, der er din styrke.
For eksempel, for at besvare disse typer spørgsmål kan du nævne eksempler på den automatiseringsstrategi, du har vedtaget, mens du bygger et produkt i din tidligere rolle.
For eksempel kan du nævne punkter som,
- Da produktet krævede start af automatisering fra bunden, fik du tid nok til at tænke og designe til en passende automatiseringsramme, der valgte et sprog / teknologi, som de fleste mennesker havde viden til at undgå at introducere et nyt værktøj og udnytte eksisterende viden.
- Du startede med at automatisere de mest grundlæggende funktionelle scenarier, der blev anset for at være P1 (uden hvilken ingen frigivelse kunne gå igennem).
- Du overvejede også at teste systemets ydeevne og skalerbarhed gennem automatiserede testværktøjer som JMETER, LoadRunner osv.
- Du overvejede at automatisere sikkerhedsaspekterne i applikationen som anført i OWASP Sikkerhedsstandarder.
- Du integrerede de automatiserede tests i build pipeline til tidlig feedback osv.
Team Fit & Culture Fit
Denne runde afhænger generelt af virksomhed til virksomhed. Men behovet / nødvendigheden af denne runde er at forstå kandidaten fra perspektivet af team- og organisationskulturperspektiv. Formålet med disse spørgsmål er også at forstå kandidatens personlighed og deres tilgang til arbejde / mennesker osv.
Generelt er HR- og ansættelsesledere dem, der gennemfører denne runde.
Spørgsmål, der typisk kommer op i løbet af denne runde, er som:
Spørgsmål nr. 19) Hvordan løser du konflikter inden for din nuværende rolle?
Svar: Yderligere forklaring her er: antag at du har en konflikt med din chef eller dine nærmeste teammedlemmer, hvad er de skridt, du tager for at løse disse konflikter?
For denne type spørgsmål underbygges så meget som muligt med reelle eksempler, der måske er sket inden for din karriere hos nuværende eller tidligere organisationer.
Du kan nævne ting som:
- Du kan lide at sortere eventuelle konflikter så hurtigt som muligt, der opstår som følge af faglige årsager (og vil ikke gerne påvirke dine personlige forhold på grund af disse).
- Du kan nævne, at du generelt forsøger at kommunikere effektivt og tale / diskutere med personen individuelt for at løse eventuelle forskelle / problemer.
- Du kan nævne, at hvis tingene begynder at blive værre, vil du tage hjælp fra en senior person / din leder og få hans / hendes input.
Andre eksempler på team fit / culture fit-spørgsmål er nedenfor (de fleste af dem skal besvares i en lignende tilgang, som vi diskuterede for spørgsmålet ovenfor. At tale om virkelige scenarier er en nøgle her, da intervieweren kan relatere det på en bedre måde, da godt.
Spørgsmål nr. 20) Hvilken slags balance mellem arbejde og privatliv forventer du af den nye rolle, som du anses for at være ansat til?
Svar: Da Hiring Manager er en person, der ved, hvad rollen kræver, hvor meget ekstra indsats der til tider kan kræves, så generelt forsøger intervieweren at måle, om dine forventninger er radikalt forskellige fra, hvad rollen forventer.
Antag at du siger at du ikke foretrækker at deltage i natmøder, og rollen forventer, at du har større samarbejde mellem et team, der sidder i en anden tidszone, så kan intervieweren indlede en diskussion om, at det er forventningerne fra rollen - vil du være i stand til tilpasse? etc.
Så igen, dette er mere en afslappet samtale, men set fra interviewerens perspektiv ønsker de at forstå dine forventninger til at evaluere din kandidatur til den stilling, der interviewes til.
Spørgsmål nr. 21) Hvad er dine hobbyer bortset fra arbejde?
Svar: Disse spørgsmål er rent subjektive og individuelle, og disse spørgsmål er generelt nyttige for at få kandidaten til at føle sig afslappet og let og indlede afslappede diskussioner.
Generelt kan svarene på disse spørgsmål være som - du kan godt lide at læse en bestemt genre, du kan lide musik, du har modtaget en pris for nogle frivillige / filantropiske aktiviteter osv. Disse spørgsmål stilles generelt i HR-runden (og mindre sandsynligt at blive bedt om af en teknisk person).
Spørgsmål nr. 22) Hvor meget tid er du villig til at bruge læring på nye værktøjer og teknologier proaktivt?
Svar: Her måler intervieweren din vilje til at lære nye ting, hvis noget usædvanligt eller nyt kastes mod dig. Det lader også intervieweren vide, at du er proaktiv? Er du villig til at investere i dig selv og din karriere? etc.
Så mens du besvarer sådanne spørgsmål - vær ærlig og begrunder dine svar med eksempler - For eksempel, Du kan nævne, at du optrådte til en Java-certificering sidste år og forberedte dig uden for arbejdet ved at tage et par timer hver uge.
Konklusion
I denne artikel diskuterede vi Software Development Engineer i testinterviewsprocessen og eksempler på spørgsmål, der generelt stilles fra kandidaterne på tværs af forskellige organisationer og profiler. Generelt er SDET-interviews meget brede og afhænger meget af virksomheden til virksomheden.
Men interviewprocesserne ligner det, der findes for en udviklerprofil med større vægt på kvalitet og automatiseringsrammer.
Det er vigtigt at forstå, at virksomheder i dag er mindre fokuserede på ethvert specifikt sprog eller teknologi, men mere om en bred forståelse af koncepter og evnen til at tilpasse sig de værktøjer / teknologier, som virksomheden kræver.
De bedste ønsker til dit SDET-interview!
Anbefalet læsning
- Hvad er SDET: Kend forskellen mellem tester og SDET
- Interviewspørgsmål og svar
- ETL Testing Interview Spørgsmål og svar
- Nogle vanskelige manuelle testspørgsmål og svar
- Spock Interview-spørgsmål med svar (mest populære)
- 25 bedste spørgsmål om svar på Agile Testing Interview og svar
- Top 32 Bedste Datastage Interview Spørgsmål og svar
- Top 20+ .NET Interview Spørgsmål og svar